Thanks Cecelia!
Is it written in C++ or Fortran90 or ?
John
On 4/18/2011 3:22 PM, Cecelia DeLuca wrote:
> Hi John, Chris, all:
>
> Here's a more direct link to the ESMF utility for timekeeping than
> Brian provided:
>
> http://www.earthsystemmodeling.org/esmf_releases/public/last/ESMF_refdoc/node5.html#SECTION05040000000000000000
>
>
> There are a number of calendars supported (Proleptic Gregorian,
> no-leap, Julian and
> Julian day calendars, 360 day, custom calendars for planets, etc.).
> Proleptic Gregorian
> is used already by some climate groups; I would think its use would
> increase as modelers
> try to answer questions that combine climate model output with other
> kinds of information,
> and perform comparisons of model output with observations.
>
> The length of days can change with the calendar, so they're not a
> basic time unit.
>
> ESMF has time instant and time interval classes. Their operators
> (+,-,<,>, ==, etc.) are
> overloaded so you can write, for example:
> time = init_time + timeinterval
> or
> timeinterval = init_timeinterval * 3
>
> Increments can be in many different time units, including months. If
> you add three months
> to a date like April 1 you will get July 1. ESMF computes to the
> same day that many months later. There is a special end-of-the-month
> case so that
> if you add three month to March 31 you will get June 30.
> I think John was originally wondering if there was a lib that does
> this sort of thing.
>
> Other methods it offers include getting things like middle of the
> month and
> day of the week. There are clock and alarm classes to manage model
> time, with clocks
> that can run forward or backward in time. Development priorities were
> set by modelers
> so most of what's there was needed by somebody.
>
> It's portable and pretty widely used in the modeling community. If
> you think there's
> something that could be done to make it more accessible or useful to
> the data community,
> please write.
>
> Note, one calendar that ESMF does not support is the mixed
> Gregorian/Julian calendar that
> is the CF default. For modelers having to use the mixed
> Gregorian/Julian calendar just
> doesn't make sense.
>
> -- Cecelia
>
> On 4/1/2011 9:50 AM, Brian Eaton wrote:
>> Hi John,
>>
>> You might have a look at the ESMF time handling utilies for some ideas
>> about what a library that supports modelling (i.e., non-standard
>> calendars)
>> contains.
>>
>> http://www.earthsystemmodeling.org/esmf_releases/public/last/ESMF_refdoc/
>>
>>
>> Brian
>>
>>
>> On Fri, Apr 01, 2011 at 05:04:42AM -0600, John Caron wrote:
>>> Hi Martin and all:
>>>
>>> Im wondering what essential methods a calendar library needs to have
>>> to support, eg 360 day calendars? The only one that comes to mind is
>>> to calculate the difference between two dates in, say, seconds? What
>>> else?
>>>
>>> John
>>>
>>> On 4/1/2011 12:55 AM, Schultz, Martin wrote:
>>>> Hi Chris et al.,
>>>>
>>>> indeed it seems like some clarification is necessary about
>>>> the use of different calendars in modelling. Your suggestion to
>>>> "map" the 360 day calendar onto the Gregorian calendar in output
>>>> files won't work: there would be no need for a 360 day calendar if
>>>> it would. The idea behind fixed-length-year calendars is precisely
>>>> the opposite: preserve seasonality without having to deal with leap
>>>> years etc. Of course you need to adjust the solar cycle
>>>> accordingly, that means your model will have a solar year that is
>>>> precisely 360 days long (and not 365.25 as in reality). If you were
>>>> to map these dates onto the gregorian calendar, you would have to
>>>> interpolate the time axis so that days 1 to 360 fit into the range
>>>> 1 to 365 or 366, respectively. Yes - a converter 360-days (or
>>>> 365-days) to gregorian (and reverse) could be written, but you
>>>> would redce the number of your friends if you insist that this is
>>>> the only valid way to represent time of the model output ;-)
>>>>
>>>> You are right that a date such as 1960-01-31 is invalid in a
>>>> 360-day calendar, and indeed a smart tool should flag this as an
>>>> error.
>>>>
>>>> Hope this helps,
>>>>
>>>> Martin
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------------------------
>>>>
>>>> ------------------------------------------------------------------------------------------------
>>>>
>>>> Forschungszentrum Juelich GmbH
>>>> 52425 Juelich
>>>> Sitz der Gesellschaft: Juelich
>>>> Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
>>>> Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
>>>> Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
>>>> Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
>>>> Prof. Dr. Sebastian M. Schmidt
>>>> ------------------------------------------------------------------------------------------------
>>>>
>>>> ------------------------------------------------------------------------------------------------
>>>>
>>>>
>>>> Besuchen Sie uns auf unserem neuen Webauftritt unterwww.fz-juelich.de
>>>> _______________________________________________
>>>> CF-metadata mailing list
>>>> CF-metadata at cgd.ucar.edu
>>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>> _______________________________________________
>>> CF-metadata mailing list
>>> CF-metadata at cgd.ucar.edu
>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
Received on Fri Apr 22 2011 - 08:34:37 BST
