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
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
===================================================================
Cecelia DeLuca
NESII/CIRES/NOAA Earth System Research Laboratory
325 Broadway, Boulder 80305-337
Email: [email protected]
Phone: 303-497-3604
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
