Hi Alex, thank you! The timeframe I am hoping for is the next couple
months -
then we would have clear versions for our next set of releases.
I understand the appeal of correspondence on list, but maybe a call is
warranted to come up with a proposal for a coordinated strategy for
versioning,
documenting, and evolving GridSpec, UGRID, and maybe discrete geometries?
Then that proposal could be vetted on the list.
That does not seem to exist right now ... but maybe Jeff has one in mind?
Best,
- Cecelia
On 12/7/2012 9:12 AM, Alexander Pletzer wrote:
Hi Cecelia,
We can certainly add a version to the wiki. I'd like to wait for Jeff
to come back from vacation and see what the typical procedure is in
this case (if there is one), if that's ok with you. Otherwise I cannot
make some version number, put it on the wiki some time next week....
Cheers,
--Alex
On 12/06/2012 11:43 AM, Cecelia DeLuca wrote:
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 flavors already.
ESMF also
supports the Common Information Model (CIM) grids package, a slightly
different version
of GridSpec, as a metadata output format. This is part of our
general CIM XML output
support. That's a pain, but not unworkable: the distinctions in our
software could be
made clearly, if we had versioned reference documents. We do on the
CIM side.
It's problematic for us to use the libCF implementation as a kind of
substitute for a
specification of the GridSpec convention. The convention needs to be
able to
evolve, and to support multiple reference implementations. Using
libCF could be terrific
and valuable for us (and something to talk more about offline) but
unfortunately it
doesn't address the problem at hand.
We could say in our documentation that we support the version of
GridSpec approved last
May, but without a version number or static doc, and without a path
to evolve the
convention forward, the solution feels pretty shaky.
I think there's an awkward question that needs to be answered about
whether your team
wants to keep managing and evolving the specification on your wiki -
that evolution needs to be done somewhere. Or maybe the expectation
is that the whole
text will be incorporated into the main CF document and evolved there?
There already seem to be some ideas, with respect to UGRID and
staggering, about
how GridSpec might grow or change.
For GridSpec in CF it might make the most sense to resolve the
question about where
the thing lives (in a perfect world, the approach might be consistent
for GridSpec,
UGRID, and discrete geometries), and wherever that is, put an initial
GridSpec version
on it and generate a static doc, and then sit back and think about
evolution.
Best,
- Cecelia
On 12/6/2012 9:10 AM, Alexander Pletzer wrote:
Hi Cecelia,
Great to hear that ESMF is implementing gridspec. We're in the same
boat, we had to settle on some specifics before implementing
gridspec into libCF. Like Bert, I'm a little worried about a
proliferation of gridspec flavours, even with versions attached.
Another concern is that our funding for this particular work has
stopped, we will not be able to provide continuous support for
gridspec ad infinitum, in the short term this means fixing small
things. The good news is the specification has been accepted by the
CF committee in its present form, although suggestions for further
improvement have since come, particularly in view of consolidating
the syntax between ugrid and gridspec.
This leaves a couple of options for ESMF: use libCF to handle the
gridspec aggregation. We made an effort to make libCF compatible
with the specification. The library is pure C so should be easy to
link against and it is hosted on sourceforge. Or state that ESMF
implements the gridspec approved by the committee last May. On our
side, we can try to highlight any changes on the wiki.
Cheers,
--Alex
On 12/05/2012 05:16 PM, Cecelia DeLuca wrote:
Steve, I agree that solutions may be different in the near term and
long term,
that seems reasonable - and Alex, I understand about coordinating
with Jeff.
I still worry about maintaining versions on a wiki ... I think to
work in
practice it would need to be set up with some attention to navigation.
Some more background...
ESMF is already building versioned software based on UGRID and
(sort of,
in a single tile way) GridSpec. We need to cite distinct
and static versions of the conventions for both developers and
users, since
our software may not work, or our documentation may be wrong, if the
conventions evolve. Further, since we're committed to supporting ESMF
versions for up to three years, we expect, at any given time, to
have access
to multiple static versions of these conventions.
For the last couple ESMF releases, we used the URL of the UGRID
wiki with
an associated date as the version reference, but that's not the
greatest solution.
Hence the request for static versioned documents, but I know they
are a pain
to produce. At a minimum, if GridSpec and UGRID stay on wikis, it
would be
helpful to have a version table with links on the front wiki page
so that someone
who ended up there could quickly see and navigate to other
versions. Does
that make sense?
Thanks,
- Cecelia
On 12/5/2012 2:17 PM, Steve Hankin wrote:
Cecelia et. al.,
An important and somewhat awkward topic. I like your suggestion,
myself. I might suggest slightly different terminology to
describe it, though. I think we are proposing that _for the
present_ *gridspec *and/or *ugrid *(there need not be the same
answer for both) ought to be published as independent standards,
and therefore have their own version numbering. These standards
publications would internally refer to CF as a "normative
standard"
(https://en.wikipedia.org/wiki/Normative#Standards_documents --
"considered to be a prescriptive part")
* They could be published on their own Wiki sites, or they could
alternatively be published on the CF site. The latter approach
would emphasize their close relationship to CF -- part of a
family of standards. But they would not be "chapters" in the
CF document ... at this time.
* The CF document would point to them, say, in brief appendices
that explained that gridspec and/or ugrid were at this time
being managed as separate standards.
* There would preferably be a generally agreed strategy, that
when judged sufficiently stable at a future time, the ugrid
and gridspec standards would become chapters in some future
version CF ... but not yet.
Underlying any final decision would be an open-eyed awareness of
how stable and well-tested ugrid and/or gridspec rightly are (or
are not) at the current time. This would need to be judged by
people who use the standards on a day to day basis *_and_*
interchange files containing outputs of distinct models with one
another. I do not myself have this level of day-to-day
familiarity to judge the demonstrated stability and
interoperability of either gridspec or ugrid datasets ... but it
seems like you and your group probably do, Cecelia, which is why
I'm inclined to back this as a sensibly cautious idea that leaves
the wiggle room needed for rapid evolution.
- Steve
==========================
On 12/5/2012 11:43 AM, Cecelia DeLuca wrote:
Thanks Alex and Jeff - sorry, I'm not clear on how you plan to
proceed.
Is the following an acceptable plan?
Create a separate version now for GridSpec, so that it is not
versioned in lockstep
with the rest of CF.
Create a fixed (non-wiki) specification document for this version
of GridSpec.
[Again, that would be nice because then we could begin to build
software on it now.]
When changes or updates occur, update the version and create a
new specification
document.
Point to the GridSpec version and spec document that is current
when CF 1.7 comes out.
If this isn't an okay plan, could you please indicate what you
will do to be sure
that GridSpec versions are unambiguous, and all versions of
GridSpec will be very
easy to retrieve?
Thanks,
Cecelia
On 12/5/2012 11:33 AM, Alexander Pletzer wrote:
Thanks Jeff!
--Alex
On 12/05/2012 11:04 AM, Jeffrey F. Painter wrote:
Yes, Gridspec didn't make it into CF 1.6 and will be in 1.7.
There's no scheduled release date, but I hope to get to it soon.
I'm sorry I couldn't reply sooner - I was on vacation from
November 22 and just got back.
- Jeff Painter
On 11/26/12 10:49 AM, Allyn Treshansky wrote:
Hello Alex,
Thank you for the reply. My comments are inline.
Thanks,
Allyn
On 11/26/2012 09:45 AM, Alexander Pletzer wrote:
Hi Allyn,
On 11/23/2012 01:02 PM, Allyn Treshansky wrote:
Hello.
I am confused as to the relationship between GridSpec and
the official CF Conventions. In particular, it's not clear
whether or not GridSpec is part of the latest version (v1.6).
According to the CF Tracker
[https://cf-pcmdi.llnl.gov/trac/ticket/63], the GridSpec
proposal has been approved. However, there is no mention of
it in the latest Convention Documentation
[http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html].
I think Gridspec did not quite make it into CF 1.6, Jeff
Painter may know whether it will be incorporated into 1.7.
Okay. Is there a scheduled release date for v1.7?
The ticket does reference a formal extension to CF
[https://ice.txcorp.com/trac/modave/wiki/CFProposalGridspec]. Presumably,
this is what users should reference for GridSpec
documentation. Is that correct,
Yes.
Okay.
or is there another document we should be using? And it
remains odd that there is no link from the v1.6
documentation to GridSpec documentation (either that techX
page or another one).
Assuming that the techX page is the correct location for
GridSpec CF documentation, it is lacking any version
information.
You mean CF version?
Yes. I mean which CF version does that documentation apply to.
How will future governance be handled without that? Should
we consider the page as it stands CF version 1.6?
Also, can the GridSpec convention only be expressed as a
netCDF file?
Yes it was written for netcdf. I'm assuming that anything
that can be done in netcdf can be done in XML though I'm not
a XML specialist.
Best,
--Alex
Are there other formats (such as XML) for the CF Conventions
that support GridSpec?
Many thanks for your help.
Regards,
Allyn
--
Allyn Treshansky
NESII/CIRES/NOAA Earth System Research Laboratory
325 Broadway, Boulder CO 80305 USA
Email:[email protected]
Phone: +1 303-497-7734
_______________________________________________
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
--
Allyn Treshansky
NESII/CIRES/NOAA Earth System Research Laboratory
325 Broadway, Boulder CO 80305 USA
Email:[email protected]
Phone: +1 303-497-7734
_______________________________________________
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
--
===================================================================
Cecelia DeLuca
NESII/CIRES/NOAA Earth System Research Laboratory
325 Broadway, Boulder 80305-337
Email:[email protected]
Phone: 303-497-3604
--
===================================================================
Cecelia DeLuca
NESII/CIRES/NOAA Earth System Research Laboratory
325 Broadway, Boulder 80305-337
Email:[email protected]
Phone: 303-497-3604
--
===================================================================
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
