[mpas-developers] update on date/time manager

Michael Duda duda at ucar.edu
Tue Jun 7 17:20:05 MDT 2011


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
> 
> 
> 


More information about the mpas-developers mailing list