Enhancement use case: User has a parent with monthly fields for T,U,V grids and wants to generate boundary conditions that are also monthly (allowing NEMO to interpolate onto the model time step).
Current behaviour: pyBdy will take monthly inputs and interpolate to produce daily boundary files.
New behaviour: A boolean option has been added to the namelist called ln_time_interpolation. If this option is set to true or omitted then behaviour will continue as before. If it is set to false then the boundary files generated will use the source calendar to create the monthly boundary files.
Limitations: This is currently only set up to work with input files that are monthly.
Testing: Tested on benchmark and also creating multiple years worth of monthly boundary files for T,U,V (2d+3d) from GO8->AMM7
Other things: I found I needed to change the time_counter output type from f4 to f8 , in profiler.py line 255 there is a typo bug that was erroring when trying to run over multiple years. Given what you said in the meeting you might want to double check this, it seems to just be some logic to send info to the logger.
close #124
Enhancement use case: User has a parent with monthly fields for T,U,V grids and wants to generate boundary conditions that are also monthly (allowing NEMO to interpolate onto the model time step).
Current behaviour: pyBdy will take monthly inputs and interpolate to produce daily boundary files.
New behaviour: A boolean option has been added to the namelist called ln_time_interpolation. If this option is set to true or omitted then behaviour will continue as before. If it is set to false then the boundary files generated will use the source calendar to create the monthly boundary files.
Limitations: This is currently only set up to work with input files that are monthly.
Testing: Tested on benchmark and also creating multiple years worth of monthly boundary files for T,U,V (2d+3d) from GO8->AMM7
Other things: I found I needed to change the time_counter output type from f4 to f8 , in profiler.py line 255 there is a typo bug that was erroring when trying to run over multiple years. Given what you said in the meeting you might want to double check this, it seems to just be some logic to send info to the logger.