Hi John,
It's written in C/C++.
There's a full Fortran interface, common functions have a C interface,
and we've started some esmf python interfaces (for remapping, not time yet).
What's most useful to you?
Cecelia
On 4/22/2011 8:34 AM, John Caron wrote:
> 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
>>
>>
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
===================================================================
Cecelia DeLuca
NESII/CIRES/NOAA Earth System Research Laboratory
325 Broadway, Boulder 80305-337
Email: cecelia.deluca at noaa.gov
Phone: 303-497-3604
Received on Mon Apr 25 2011 - 12:10:08 BST
