[mpas-developers] proposed date/time manager

[Michael Duda]

Hi, Todd.

I agree that we should not exclude the ability to have dt change
in time; the intent was for 2.1.4 to require this ability, but
perhaps I did a poor job at phrasing the explanation of the
requirement.

After Phil has had added his additions to the document, I'll add
in a requirement to support multiple calendars. I think at a
minimum we'd like a standard Gregorian and a no-leap-year
calendar, but perhaps a quick chat with some climate or regional
climate folks would reveal additional calendars that would be
needed.

Cheers,
Michael


On Fri, Feb 18, 2011 at 10:19:26AM -0700, Todd Ringler wrote:
> 
> Hi Michael,
> 
> My only addition is that we probably want to not exclude to ability to have dt change in time. The reason for this is that we expect to have a fully implicit time stepping option available in MPAS (at least in ocean and sw). With this time stepping scheme we can control error (at every time step) by changing dt.
> 
> Regarding the calendar, I would expect that we could abstract the calendar to allow for multiple mapping from time (in seconds since some point) to a day/month/year.
> 
> Thanks for pushing on this.
> 
> Cheers,
> Todd
> 
> On Feb 17, 2011, at 7:17 PM, 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
> > <time_manager_reqts.tex><time_manager_reqts.pdf>_______________________________________________
> > mpas-developers mailing list
> > mpas-developers at mailman.ucar.edu
> > http://mailman.ucar.edu/mailman/listinfo/mpas-developers
>