[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