[mpas-developers] update on date/time manager

[Michael Duda]

Hi, Phil.

Taking another look, it appears that the current release of ESMF
(5.2.1) does support setting and getting intervals in terms of
years and months, and one can even choose which calendar to use
when doing so. However, the ESMF time manager code that I had been
using was based off of ESMF 2.1.1, and it does not support getting
intervals in terms of years and months (though it does, contrary
to what I had thought, permit the setting of intervals in years
and months). 

I think this does re-raise the issue, then, of whether we want to
require everyone to have a recent release of ESMF installed before
building MPAS, or whether we want to stick with the stand-alone
(but very out-of-date) ESMF time manager that we can build in to
the MPAS src/external directory. What do you think? Does anyone
have any experience regarding the ease or difficulty of building
the full ESMF?

Cheers,
Michael


On Wed, Jun 08, 2011 at 03:14:04PM -0600, Jones, Philip W wrote:
> Michael,
> 
> I mentioned in the earlier message that I thought we could kludge a monthly ot annual time interval, so no worries about trying to come up with a new interface for that.
> 
> But we do need monthly and annual alarms and I'm positive the ESMF time mgr supports that (ringing at month or year boundaries based on the associated calendar).  We also had a mid-month requirement for the original ESMF project, so I suspect that's supported too.
> 
> Phil
> 
> ----- Original Message -----
> From: Michael Duda <duda at ucar.edu>
> To: Jones, Philip W
> Cc: mpas-developers at ucar.edu <mpas-developers at ucar.edu>
> Sent: Tue Jun 07 17:20:05 2011
> Subject: Re: [mpas-developers] update on date/time manager
> 
> Hi, Phil.
> 
> I can certainly appreciate that we will like to compute monthly or
> annual diagnostics, which implies the need to measure intervals of time
> in months or years. Setting and retrieving intervals in terms of months
> and years is not something that ESMF supports, so this would be
> functionality that we would need to build on top of what ESMF provides;
> and we could certainly do this given a careful specification of exactly
> how the time manager should behave (e.g., if a time interval is
> specified as M months in, say, a leap year, how many days should it be
> retrieved as in a different, non-leap year?) I think that, in general,
> specifying alarms that recur with a constant interval by one measure
> (months) but with a varying interval by a different measure (days) may
> be tricky to implement correctly and in a way that is intuitive to a
> wide range of users.
> 
> Would it be reasonable to see how we get along without the ability to
> use months and years with time intervals, and if we find the lack of
> this ability to be burdensome, then we could specify how it should be
> added to the time manager? Or perhaps we can anticipate how the
> inability to specify a recurring event in terms of months might affect
> us already: would the need to ring an alarm on the first day of every
> month for a 100-year simulation using a Gregorian calendar be something
> that we might like to do? This might be painful without the ability to
> specify an alarm that rings with an interval of one month, but having a
> routine that returns the number of days in the current/previous/next
> month might simplify matters greatly; we could handle the above
> situation with the following, I think
> 
>    do while (.not. MPAS_isClockEndTime(clock))
> 
>       ! If it is the first day of the month according to a previously-set
>       !   timer with ID 'xyz'
>       if (MPAS_isAlarmRinging(clock, xyz)) then
>          ! get days until the first day of the next month
>          n = MPAS_daysPerMonth(clock, MPAS_CURRENT_MONTH)
>    
>          ! Set alarm 'xyz' to ring on the first day of the next month
>          call MPAS_setTimeInterval(interval, D=n)
>          call MPAS_addClockAlarm(clock, xyz, alarmTimeInterval=interval,
>                                  relativeToTime=now)
> 
>          ! Process a monthly mean using 
>          !   MPAS_daysPerMonth(clock, MPAS_PREVIOUS_MONTH)
>       end if
> 
>       ! Time stepping, I/O, and everything else that goes in our main
>       !   time loop
> 
>    end do
> 
> One can imagine how easy it would be to write a routine that, given the
> current date, tells how many days are in the current/previous/next
> month. Essentially, I'm wondering if we can do what we'd like to do by
> adding other functionality, rather than tackling the difficult issue of
> time intervals that use months and years. What do you think about this
> approach?
> 
> Cheers,
> Michael
> 
> 
> On Tue, Jun 07, 2011 at 02:55:14PM -0600, Jones, Philip W wrote:
> > 
> > Michael,
> > 
> > Just a couple quick comments:
> > 
> > > 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?);
> > 
> > We often do monthly or annual diagnostics (monthly/annual means in particular) where we need to divide by the number of seconds in the current month/year, so a month or year time interval would refer to current (or maybe previous depending on when the flag is triggered) month or year.  If it's too problematic, we can get these numbers in other ways (e.g. difference two time instances), so it's not critical.
> > 
> > On a recurring alarm, an end time might be handy, but you can also remove the alarm if no longer needed.
> > 
> > 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
> > 
> > 
> >