Hi Alison and Roy,
I think that the solution you proposed is suitable to the O3 community.
Having the canonical unit (mol/m-2) for the O3 columns in the
vocabulary server is fine as long as it is not a problem to use a
different unit (Dobson Unit) in the NetCDF files. The important point is
Hi Alex,
Our current GridSpec input file implementation is minimal at best,
because we just did
a single tile and anything distinctly GridSpeccian comes in with
multiple tiles. It's as
much intention as implementation at this point.
Still, we have had to worry about multiple GridSpec
Hi Alison,
This is now fine with me. Thank you for being so thorough :-).
Philip
---
Dr Philip Cameron-Smith, p...@llnl.gov, Lawrence Livermore National Lab.
Hi Cecelia:
Thanks for this information. A few questions:
* So you are not supporting standard Gregorian calendar even though
thats the CF default?
* Do modelers need to match historical dates? If so, what calendar do
they use?
* Is the time library suitable to be released seperate from
Hi John and all,
Thanks for this information. A few questions:
* So you are not supporting standard Gregorian calendar even though
thats the CF default?
Correct, the climate modelers that we work with don't use it. AFAIK the
decision of
CESM was to reject the CF default as unreasonable for
Hi Steve, Cecelia:
I agree we should move to a better default calendar, probably
proleptic_gregorian. We are stuck with mixed Gregorian for previous CF
versions.
I think we just need a proposal that says As of version X, the default
calender is proleptic_gregorian. You should explicitly add
On 12/6/2012 1:37 PM, John Caron wrote:
Hi Steve, Cecelia:
I agree we should move to a better default calendar, probably
proleptic_gregorian. We are stuck with mixed Gregorian for previous CF
versions.
I think we just need a proposal that says As of version X, the
default calender is
John
There is some meteorological data that is available pre-Gregorian
calendar (paleo data, some temperature datasets) and of course there are
other scientific fields where data is pre-1500 (e.g. astronomy,
archeology) . Given that netCDF files with data dates spanning ~1550 probably
already
Hi All,
After considerable thought, I do support addition of this std_name, but
recommend that we add a comment to the description (as described below).
The problem is that
atmosphere_mole_content_of_ozone (proposed, units = moles/m2, typically
expressed in DU)
and
Hi Cathy:
There no question that CF currently defaults to mixed gregorian
calendar. The discussion is whether thats the best choice (probably
not), and to advise users not to cross the discontinuity (eg store
modern dates starting from 1-1-1).
Im curious as to how you generate the dates
On 12/6/2012 4:09 PM, John Caron wrote:
Hi Cathy:
There no question that CF currently defaults to mixed gregorian
calendar. The discussion is whether thats the best choice (probably
not), and to advise users not to cross the discontinuity (eg store
modern dates starting from 1-1-1).
Im
All,
I agree that the current calendar definitions and usage have a lot of
problems. Following are some proposals that are geared towards both
accuracy and backward compatibility.
1. Please, NO default calendar. Starting with the next CF version,
the calendar attribute should be required on
Dear all,
I would also like to support this proposal. And I thank Philip for his
careful thinking.
If these were the only aspects to consider then I would be against the new
std_name. However, there
are many more species than ozone, and ozone is the only one that I see
expressed as
13 matches
Mail list logo
