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:allyn.treshansky at noaa.gov
>>>>>>>> Phone: +1 303-497-7734
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Allyn Treshansky
>>>>>> NESII/CIRES/NOAA Earth System Research Laboratory
>>>>>> 325 Broadway, Boulder CO 80305 USA
>>>>>> Email:allyn.treshansky at noaa.gov
>>>>>> Phone: +1 303-497-7734
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>
>>>
>>> _______________________________________________
>>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20121206/adacc7c3/attachment-0001.html>
Received on Thu Dec 06 2012 - 09:10:55 GMT
