[mpas-developers] mpas_timekeeping branch

[Mark Petersen]

Conrad,

This looks great.  I would like to give the ocean core a spin, but I get 
compile errors on the ESMF variables.  It looks like I need to compile 
with the ESMF library.  I think it would make sense to add variables to 
the Makefile to automate this, so that the make command is

make ifort CORE=ocean NETCDF={netcdf_path} ESMF={esmf_path}

I may need to install the ESMF library on my own machine.  Are you using 
v5.2.0r?

Mark




On Mon, 22 Aug 2011, Conrad Roesch wrote:

> 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
>
>
>
> _______________________________________________
> mpas-developers mailing list
> mpas-developers at mailman.ucar.edu
> http://mailman.ucar.edu/mailman/listinfo/mpas-developers
>