Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow for reading alternatives to daily files #154

Open
rdPatmore opened this issue Sep 26, 2023 · 6 comments
Open

Allow for reading alternatives to daily files #154

rdPatmore opened this issue Sep 26, 2023 · 6 comments

Comments

@rdPatmore
Copy link
Contributor

I am currently trying use GloSea6 data as the source for the boundaries. This data is saved as daily output in 5-day chunks. This format does not seem compatible with pyBDY.

Rather than processing my inputs to be compatible with pyBDY, I think pyBDY should be more flexible to read a wider range of input types.

Thoughts?

@jdha
Copy link
Collaborator

jdha commented Sep 26, 2023

@rdPatmore pyBDY should be (at least it was in the past) fine with any input time frequency. The only thing it requires is that the time stamp information in the file is correct - something that is not always the case. You can even redefine the calendar and timestamp information in an NCML files for pyBDY - so you don't have to reformat anything. Happy to chat about options.

@rdPatmore
Copy link
Contributor Author

Ah, right, ok. I will close this as an issue. It might be that I've defined the NCML files incorectly. Perhaps we can chat about this by email or teams.

@jdha jdha reopened this Sep 26, 2023
@jdha
Copy link
Collaborator

jdha commented Sep 26, 2023

Let's leave this open until we're sure. First thing would be to output the time information to double check it's within the range you expect. One feature pyBDY hasn't got yet is extrapolation. e.g. if you have 1 year's worth of 5 day means it can't process that year without the last 5 day mean from the previous year and one from the next. e.g. if you have 73 time slices from say the year 2000 and you want to produce a BDY file for 2000, you'll need the 73rd time slice from 1999 and 1st time slice from 2001. You can get round this by 'tricking' pyBDY with a pseudo 1999 file containing the 1st time slice from 2000 and a pseudo 2001 file containing the 73rd slice from the 2000 file .... redefining the timestamp information in these file accordingly.

@rdPatmore
Copy link
Contributor Author

Yes, this is part of the issue. It doesn't catch the first few days of the year.

The other thing is that it seems to run through month-by-month but the number of records in each month do not match with the source data nor the time_counter in the inerpolation. For the interpolation in the first month, the time_counter has 22 records and d_bdy has 22. In the second month, the time_counter has 22 records and d_bdy has 53. The interpolation fails here due to the differing number of records.

@jdha
Copy link
Collaborator

jdha commented Sep 26, 2023

I'll try and have a look at the logic tomorrow. It hasn't been an issue previously (I've used single 5 day files, monthly and annual files as input). Perhaps the recent code modifications in the interpolation routine have introduced a bug. Are you around on Thursday - perhaps we can have a quick catch up then?

@rdPatmore
Copy link
Contributor Author

Yes, we can chat on Thursday. My only comitment that day is the MSM meeting at 3pm.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants