[mpas-developers] mpas_timekeeping branch

Tue Aug 23 11:45:25 MDT 2011

Mark,

I believe that we have found why the ifort compiler was failing when 
building the ESMF code in the external directory.  In the root Makefile, 
under the target "ifort:" change the line

"FFLAGS = -real-size 64 -O3 -convert big_endian" \
to
"FFLAGS = -real-size 64 -O3 -convert big_endian -FR" \

This flag instructs the ifort compiler to use free-form, which needs to 
be specified as it is not the default form the compiler assumes for the 
*.f files that, as you noticed, were being created in the ESMF folder 
during the build.

Also, in that same root Makefile, depending on the version of NetCDF you 
have, you may find that you need to change the line:

LIBS = -L$(NETCDF)/lib -lnetcdf -lnetcdff
to
LIBS = -L$(NETCDF)/lib -lnetcdf

Let me know if these Makefile changes work out for you, and if they do, 
I will commit these changes so as to avoid these build errors in the future.

Conrad

On 8/23/11 10:05 AM, Conrad Roesch wrote:
> Hello Mark,
>
> The external directory should contain all of the ESMF code that you 
> need- it is actually an older, Fortran version of ESMF that is 
> currently being used rather than the latest v5.2.0.   If you let me 
> know which compiler are you using and what errors you are getting, I 
> can try and figure out what is going wrong.
>
> On a side note, the 5.2.0 (C++) version of ESMF is a much larger 
> package, and in addition to clocks contains a lot of other 
> functionality that we were not using, and this is why Michael had 
> selected the older, but leaner, Fortran ESMF libraries.  
> Unfortunately, there are many parts of this older ESMF library which 
> were left unimplemented (for example, I actually wrote all of our own 
> alarm code because the ESMF alarms in the Fortran version were 
> inadequate), but since the timekeeping module abstracts the underlying 
> ESMF methods, if we ever need to move to a newer version of ESMF, or 
> some other date/time library, we can implement it without affecting 
> anything outside of the timekeeping module.
>
> Also, if you need to reach me by phone, my office number is 303-497-8998.
>
> Conrad
>
>
>
>
> On 8/23/11 7:53 AM, Mark Petersen wrote:
>> 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
>>>
>