[mpas-developers] mpas_timekeeping branch

Conrad Roesch croesch at ucar.edu
Mon Aug 22 18:30:08 MDT 2011


MPAS Developer Team:


We believe that the mpas_timekeeping branch is in a mature enough state 
that we would like to propose the current version as a candidate for 
merging into the trunk.  Please review the following changes, and let me 
know if you have any questions or need me to make (or roll back) any 
changes to the code.

Notable changes include:

- The addition of module_mpas_timekeeping.F and the supporting ESMF 
external libraries.

- The clock and alarms have been integrated into the shallow water, 
ocean, and hydrostatic atmospheric cores.  When a core is initialized, 
we initialize a clock and set start/stop times, set the timestep 
duration, and set alarms which specify when output and restart files are 
written.  The core now runs by advancing the clock (rather than 
incrementation of an integer time-step) and at each interval ringing 
alarms specify what actions should be taken, such as writing the current 
frame to the output file.  The GlobalDiagnostics in the ocean and 
shallow water cores is still called using the old integer time-step 
method, however, I have included commented-out code that will call 
GlobalDiagnostics using alarms; this code may be used if it is desirable 
to print time stamps rather than integer time-steps to the stats text 
files that this method generates.

- The registry and namelists have been updated to use date/time and 
timespan strings to specify the start time, duration of a run, and the 
frequency which output and restart files are written.
     - Date/times are described in the format 
"YYYY-MM-DD_HH:mm:ss.fff...".  If the time portion is unspecified, the 
time is assumed to be 00:00:00.
     - Timespans are described by the format "D_HH:mm:ss.fff...", where 
the day argument is optional.
     - The date/time and timespan strings are not required to be 
fixed-width, for example "2000-02-09_06:00:00.000" and 
"2000-2-9_6:00:00" would be parsed  identically.
     - The duration of a run can either be specified by a timespan 
(config_run_duration) or a stop date/time (config_stop_time).  If both 
are specified and are inconsistent, a warning message is written in the 
log file and the run-duration timespan is used.
     - If there is an alternative preference for how date/time and 
timespan strings are formatted, or if there is a desire to specify the 
date/time parts as separate integers, this would be straightforward to 
implement using the existing timekeeping module, and if necessary, 
config date/time formats can be specified differently between cores.

- The xtime variable in the restart files is now specified as a 
date/time string rather than real-value seconds.  This same change was 
made to the xtime written in the ocean core's 
module_global_diagnostics.F: if this change is inappropriate, the 
real-value seconds can be obtained from the timekeeping module and 
passed into this module instead of the date/time string.

- The addition of an option to split output frames between multiple 
files, which can be specified in the namelist using 
config_frames_per_outfile.  If this variable is unspecified or set to 
zero, all output will be written to the single specified output file as 
it is currently.  If config_frames_per_outfile is set to an integer 
greater than zero, this will limit the number of frames written to a 
particular output file, where the multiple output files are 
differentiated by the file's first date/time appended to the filename.

- The current version of the clock should be suitable for 
forward-running scenarios, and though the clock the will operate in 
reverse, the current behavior may not be exactly as desired, and some 
discussion should probably go into what the exact specification should 
be.  For example, should a start time always be temporally before the 
stop time, and if not, does clock direction refer to whether the clock 
advancement is temporally increasing or whether the clock is moving in 
the direction of start to stop?

Please let me know if you have any questions, feedback, or requests.


Regards,

Conrad





More information about the mpas-developers mailing list