NOC-MSM / pyBDY

pyBDY: a Python based regional NEMO model configuration toolbox.
GNU General Public License v3.0
7 stars 7 forks source link

Allow for reading alternatives to daily files #154

Open rdPatmore opened 11 months ago

rdPatmore commented 11 months ago

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 commented 11 months ago

@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 commented 11 months ago

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 commented 11 months ago

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 commented 11 months ago

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 commented 11 months ago

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 commented 11 months ago

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