[mpas-developers] update on date/time manager

Todd Ringler ringler at lanl.gov
Tue Jun 7 14:40:53 MDT 2011


Hi Michael,

Thanks for pushing on this. I am by no means an expert on the nuances of time management, but all of your recommendations look very reasonable to me.

Having an ending time for notifications might be useful (and used). For example, if one wanted to write high-frequency output for part of a big simulation then this option would be very useful.

I say go ahead with what you have. We can then tackle the larger issues that you alluded to you in your previous email.

Cheers,
Todd

On Jun 6, 2011, at 11:27 AM, Michael Duda wrote:

> Hi, All.
> 
> I think I've almost finished an initial implementation of the MPAS time
> manager based on the Fortran-only, standalone time manager code from
> ESMF v2.1.1; I used this version of ESMF primarily because the time
> manager code in the current ESMF release is not really separable from
> the rest of ESMF, though perhaps we could discuss whether it might be
> better to use the current ESMF release and require that MPAS users
> install the full ESMF libraries before compiling MPAS. Using the old
> v2.2.1 time manager, we can add all of the necessary code in the
> src/external directory and just compile it along with the rest of the
> MPAS code.
> 
> A couple of small items came up while writing code that I think we might
> like to change in our design document. In the methods for setting and
> getting time intervals, I think the year (YYYY) and month (MM) arguments
> don't make sense (if I set an interval of one month, how many days are
> in that month?); and, we should probably add an argument for Julian day
> to the set and get routines for time objects. Also, I was wondering
> whether it might make sense to have an optional ending time for
> recurring notifications.
> 
> If the above changes sound reasonable, I'll make those changes in the
> design document and also in the implementation. I do have a few other
> (and bigger) issues to offer for consideration, but I'll send them in a
> separate e-mail to minimize the number of issues up for discussion at
> any one time.
> 
> Cheers,
> Michael
> 
> 
> On Thu, Jun 02, 2011 at 02:18:57PM -0600, Michael Duda wrote:
>> Hi, Phil et al.
>> 
>> I think I'm ready to pick up again on the time manager after another
>> unplanned hiatus. I like the suggestion of simply allowing the year to
>> grow from four to five or more digits to accommodate very long runs.
>> Regarding time intervals as doubles, I think this is something that we
>> could overload the interface to provide.
>> 
>> Unless anyone objects, I'll have a go at implementing the interface
>> described in the design document. Then, perhaps we can review its
>> functionality before making use of it in the rest of the MPAS code.
>> 
>> Cheers,
>> Michael
>> 
>> 
>> On Thu, Apr 21, 2011 at 04:09:40PM -0600, Jones, Philip W wrote:
>>> 
>>> Michael,
>>> 
>>> Looks good.  A few comments below.
>>> 
>>> On 4/21/11 2:30 PM, "Michael Duda" <duda at ucar.edu> wrote:
>>> One question that came to my mind is whether the requirement that the
>>> time manager support simulations of 100,000 years without round-off
>>> imply the need to support a millenium in addition to a four-digit year?
>>> 
>>> You could handle it that way.  However, a more flexible approach would be to handle it similar to the optional HMS.  That is, if the year is longer than four digits, allow the string to include all significant digits (and if its an input argument check for the number of digits before the first hyphen).  I would still keep a floor of 4 digits - no one likes to see a 1,2,3-digit year and would prefer seeing the leading zeros in those cases.   BTW, I wouldn't consider this a high priority requirement, but there are a class of climate users who run coarse resolution configurations for very long paleoclimate simulations, so we'll need it eventually.
>>> 
>>> Is there a reason for a direction?  Seems like a negative time interval would meet that requirement and eliminate some arguments.  I seem to remember this turned into a heated argument during the ESMF design, but can't remember what the controversy was...
>>> 
>>> It might be nice to have a time interval returned in floating point seconds (actually a double) for cases where you really just want to divide by a time interval (e.g. For time averaging), but maybe it's best to leave the interface cleaner and let the user compute that from the S,Sn,Sd args.  Again, I'm ok either way - just happens enough that it might be a convenient shortcut.
>>> 
>>> Thanks,
>>> 
>>> Phil
>>> 
>>> ---
>>> Correspondence/TSPA/DUSA EARTH
>>> ------------------------------------------------------------
>>> Philip Jones                                pwjones at lanl.gov
>>> Climate, Ocean and Sea Ice Modeling
>>> Los Alamos National Laboratory
>>> T-3 MS B216                                 Ph: 505-500-2699
>>> PO Box 1663                                Fax: 505-665-5926
>>> Los Alamos, NM 87545-1663
>>> 
>>> 
>>> 
> _______________________________________________
> mpas-developers mailing list
> mpas-developers at mailman.ucar.edu
> http://mailman.ucar.edu/mailman/listinfo/mpas-developers



More information about the mpas-developers mailing list