[mpas-developers] proposed date/time manager

[Michael Duda]

Hi, Mark.

Thanks very much for your comments. 

Regarding 2.2.2, perhaps this should be split into two
sub-requirements for the querying of notifications:

  1) Query for notifications which have occurred since the last query 
     of the time manager. If the previous query was at time T1, and the
     current query is at time T2, the time manager should return any
     notifications scheduled in the interval (T1,T2], plus any notifications
     that were returned in the previous query but not yet cleared.

  2) Query for notifications that will occur in the interval (T,T+dt], where
     T is the current time, and dt is some time increment specified in the
     query; each notification that is scheduled in that interval is returned,
     along with the exact time for which it is scheduled.

I think that, if the time manager were also required to perform
basic operations on dates/times, then the restart issue you
mentioned in your second paragraph might be handled on the user's
side, as you suggested.

The comment regarding notifications in terms of wall-clock time is
interesting; I had been thinking of the time manager as handling
only simulation time. Given the fundamental differences between
wall-clock and simulation time, it might be worth giving some more
thought to how this might be implemented before deciding whether
we want to require the ability to handle both.

Cheers!
Michael


On Fri, Feb 18, 2011 at 10:04:30AM -0700, Mark Petersen wrote:
> Michael,
> 
> Thanks for making the requirements document!  It is great to have this 
> discussion at such an early stage.
> 
> My few comments:
> On 2.2.2 Query for notifications, a possible requirement is that the time 
> manager needs to test if time+dt exceeds the point, and return the 
> remaining time that will be the new dt to reach that point exactly.  This 
> is important if we want i/o reported at exactly the requested time for 
> variable timestepping.  The other option, for fixed timestepping, is 
> to require that all i/o intervals are multiples of the timestep.
> 
> On 2.1.1 Set the starting and ending date/time: For long runs we often run 
> many queue cycles and use resubmit scripts, so I would want to read the 
> start date from the restart file, and have a simulation duration in the 
> namelist file.  That can easily be converted to start and end dates, so 
> that might be outside of the scope of this document.
> 
> Notifications:  It would be convenient to be able to specify a 
> notification in ellapsed wall-clock hours, so one could have a restart 
> file written after 11:45 in a 12 hour queue.
> 
> Mark
> 
> 
> 
> 
> On Thu, 17 Feb 2011, Michael Duda wrote:
> 
> >Hi, All.
> >
> >Todd and several of us at NCAR had the chance to meet earlier this
> >week to discuss MPAS developments, and one of the items that
> >appeared at the top of the list of needs in MPAS is a date/time
> >manager. To begin the requirements and design process for this new
> >module, I've written a first draft of a summary and requirements
> >list based on the MPAS design template that was circulated in
> >January; I've attached this draft herewith as a PDF document and
> >LaTeX source.
> >
> >Since I've not consulted with anyone on the requirements in the
> >document, I expect that others may have additional items to add,
> >or may like to modify the requirements that I've written;
> >essentially, I claim no particular ownership of the document, so
> >anyone should feel free to comment, modify, or update as
> >necessary.
> >
> >Once we are all satisfied that the stated requirements will meet
> >our needs in MPAS, perhaps we could then come up with a design and
> >implementation plan to meet those requirements. Also, it occurred
> >to me that the time manager might also serve as a test of our
> >requirements and design process to see, e.g., whether it is too
> >heavy or too light-weight.
> >
> >Any contributions or comments on the attached document would be
> >greatly welcomed!
> >
> >Cheers,
> >Michael
> >