-
Notifications
You must be signed in to change notification settings - Fork 62
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
Users set solo driver forcing time records per day #793
Users set solo driver forcing time records per day #793
Conversation
Refactored the solo_driver version of MOM_surface_forcing to modify how the time levels to read from forcing files, with a series of 11 new runtime parameters (WIND_FILE_DAYS_PER_RECORD, etc.) giving the user to specify how many days each time record spans (for positive values) or the number of time records in the file per day (for negative values). If these parameters are set to 31, the month returned by the FMS `get_date()` function sets the time level. If they are set to 0 (the default) the previous behavior is obtained, in which the time level is determined from the number of records in the file. To always take the first record in the file, set these parameters to large values (greater than 1000000 will always work, but in practice smaller values do the same thing). By default all answers are bitwise identical, but there are up to 10 new runtime parameters in some MOM_parameter_doc files for cases that have `WIND_CONFIG = "file"` or `BUOY_CONFIG = "file"`. The list of new runtime parameters is `WIND_FILE_DAYS_PER_RECORD`, `LONGWAVE_FILE_DAYS_PER_RECORD`, `SHORTWAVE_FILE_DAYS_PER_RECORD`, `EVAPORATION_FILE_DAYS_PER_RECORD`, `LATENTHEAT_FILE_DAYS_PER_RECORD`, `SENSIBLEHEAT_FILE_DAYS_PER_RECORD`, `RAIN_FILE_DAYS_PER_RECORD`, `SHORTWAVE_FILE_DAYS_PER_RECORD`, `RUNOFF_FILE_DAYS_PER_RECORD`, `SSTRESTORE_FILE_DAYS_PER_RECORD` and `SALINITYRESTORE_FILE_DAYS_PER_RECORD`. The problem identified in github.com/NOAA-GFDL/issues/631 is addressed by this commit, and that issue can be closed once this commit is merged onto the main branch of MOM6.
this code improves over the bits it replaces, for more advance file handling one can use |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Per @raphaeldussin recommendation
This has passed pipeline testing at https://gitlab.gfdl.noaa.gov/ogrp/mom6ci/MOM6/-/pipelines/25986 with the expected warnings about new runtime parameters. |
Refactored the solo_driver version of
MOM_surface_forcing
to modify how the time levels to read from forcing files, with a series of 11 new runtime parameters (WIND_FILE_DAYS_PER_RECORD
, etc.) giving the user to specify how many days each time record spans (for positive values) or the number of time records in the file per day (for negative values). If these parameters are set to 31, the month returned by the FMSget_date()
function sets the time level. If they are set to 0 (the default) the previous behavior is obtained, in which the time level is determined from the number of records in the file. To always take the first record in the file, set these parameters to large values (greater than 1000000 will always work, but in practice smaller values do the same thing). By default all answers are bitwise identical, but there are up to 10 new runtime parameters in some MOM_parameter_doc files for cases that haveWIND_CONFIG = "file"
orBUOY_CONFIG = "file"
.The list of new runtime parameters is
WIND_FILE_DAYS_PER_RECORD
,LONGWAVE_FILE_DAYS_PER_RECORD
,SHORTWAVE_FILE_DAYS_PER_RECORD
,EVAPORATION_FILE_DAYS_PER_RECORD
,LATENTHEAT_FILE_DAYS_PER_RECORD
,SENSIBLEHEAT_FILE_DAYS_PER_RECORD
,RAIN_FILE_DAYS_PER_RECORD
,SHORTWAVE_FILE_DAYS_PER_RECORD
,RUNOFF_FILE_DAYS_PER_RECORD
,SSTRESTORE_FILE_DAYS_PER_RECORD
andSALINITYRESTORE_FILE_DAYS_PER_RECORD
.The problem identified in #631 is addressed by this commit, and that issue can be closed once this commit is merged onto the main branch of MOM6. This PR is a more comprehensive and general solution than the one proposed in #648 , and that PR should be closed after this one is merged into dev/gfdl.