[ncl-talk] CF Convention

Mon Jan 8 15:54:12 MST 2018

Carl, Ken

It was suggested to me that the following may be helpful to you:

==
The 'suggestor' wrote he would use either H.4.3 or H.4.4
http://cfconventions.org/Data/cf-conventions/cf-conventions-
1.7/cf-conventions.html#trajectory-data

Let ncl-talk know what 'trajectory' [ I'm so clever :-) !!! ] you decide to
pursue.

Regards
D

On Fri, Jan 5, 2018 at 10:47 AM, Dennis Shea <shea at ucar.edu> wrote:

> Hi Carl, Ken
>
>
> The following  can be used to check for CF conformance:
>
>    http://puma.nerc.ac.uk/cgi-bin/cf-checker.pl
>
> ==========================================
>
> As you likely know, there are:
>    (i) "coordinate variable(s)"
> and
>    (ii) variable(s) that contain coordinates.
>
> :-)
> ====
> Unidata:
>     https://www.unidata.ucar.edu/software/netcdf/docs/netcdf_dat
> a_set_components.html
>
> Coordinate Variables (CVs):
>    https://www.unidata.ucar.edu/software/netcdf/docs/netcdf_dat
> a_set_components.html#coordinate_variables
>
> Best Practices:
>    https://www.unidata.ucar.edu/software/netcdf/docs/BestPractices.html
>
> A 'coordinate variable' (CV) is a  "*convention* that such variables
> should be treated in a special way by software using this library." (eg:
> NCL) In short, a CV is a one-dimensional array (vector) containing
> monotonically {in/de}creasing numeric values. Further, the variable name
> should match the dimension name: time(time), lat(lat),
> longitude(longitude), p(p), etc
>
> Note: There is nothing in the netCDF software to preclude associating an
> _FillValue or missing_value attribute with a coordinate-variable. Still,
> the best practices recommends that a CV should contain no _FillValue
> values. Hence, no need for and _FillValue attribute.
>
> The following is a 'variable that contains coordinates'. Further, the
> 'units' attribute is definitely not CF conforming.
>
>         double time(storm, time) ;      ; 'time' is a 2D variable and a
> dimension name.
>                                                        ; best practices
> would say this is not recommended
>                 time:long_name = "time" ;
>                 time:standard_name = "time" ;
>                 time:units = "days after " ;       <=== not CF conforming
>
> ===================
>
> 'storm' is a dimension name with no 'values' associated. There is nothing
> wrong with this but I suggest:
>
> --- NCL
>    nstorm = 310
>    storm   = toshort(ispan(1, nstorm,1) )
>    storm!0 = "storm"
>    storm at long_name = "storm id: ALL storms"
> --- nc file
>    short storm(storm)
>    storm: long_name = "storm id: ALL storms"
>
> Also, suggested is a name change as you mentioned:
>
>    TIME(storm, time) ;
>
> Thing is that 'time' varies with *each* storm (100 for storm 1, 3 for
> storm 2, ...)
>
> To me this is analogous to station data (time series) where each station
> may have a different time series length.
>
> Maybe, the following would be useful in guiding the development of your
> netCDF file
>
>    https://www.unidata.ucar.edu/software/thredds/current/netcdf
> -java/reference/FeatureDatasets/CFpointImplement.html
>
> I think that the "*Trajectory data*" category  would be appropriate.
>
> ====
> I have not dealt with this issue so I can't suggest a specific approach.
>
> Hopefully, someone else will chime in.
>
> Happy New Year
>
> On Fri, Jan 5, 2018 at 9:39 AM, Carl Schreck via ncl-talk <
> ncl-talk at ucar.edu> wrote:
>
>> Sorry, I misframed the question.... We know the files aren't cf compliant
>> yet, we're just curious if there's a particular version ncl uses. More
>> importantly, if anyone has experience or examples making trajectory files
>> with trajectories of different lengths, that'd be helpful. Thanks!
>>
>> --
>> Sent from my phone. Sorry for the brevity.
>>
>> On Jan 5, 2018 10:56 AM, "Carl Schreck" <cjschrec at ncsu.edu> wrote:
>>
>>> Which CF convention version does NCL primarily use?
>>>
>>> Ken Knapp (CC'd) is developing a new version of IBTrACS (beta version
>>> attached) and says it's CF 1.6/1.7 compliant. But he uses "time" as one of
>>> the named dimensions of many of the variables, but also uses "time" as a
>>> 2-d variable, not related to that dimension.
>>>
>>> When I try to read any of the variables that have time as a dimension, I
>>> get this error:
>>>
>>> fatal:_NclOneDValCoordDataCreate: Number of dimensions is greater than
>>> one, could not create coordinate data object
>>>
>>> I also cannot write a _FillValue to the time variable since NCL believes
>>> time to be a coordinate variable. (no error provided, it just doesn't do
>>> it).
>>>
>>> It'd probably be cleaner to just rename one of the "times", but we were
>>> just curious if the current format runs afoul of the CF convention or
>>> whether NCL is adding the extra limitations.
>>>
>>> Thanks!
>>> Carl
>>>
>>> --
>>>
>>> <https://ncics.org/> *Carl J. Schreck III, PhD*
>>> *Research Scholar*
>>> North Carolina State University <http://ncsu.edu/>
>>> North Carolina Institute for Climate Studies (NCICS)
>>> <https://ncics.org/>
>>> 151 Patton Ave, Asheville, NC 28801
>>> e: cjschrec at ncsu.edu
>>> o: +1 828 257 3140 <(828)%20257-3140>
>>> c: +1 828 484 1702 <(828)%20484-1702>
>>> Publications
>>> <http://scholar.google.com/citations?hl=en&user=th8ONEcAAAAJ&view_op=list_works&sortby=pubdate>
>>> ncics.org/mjo
>>> CycloneCenter.org <https://www.cyclonecenter.org/>
>>>
>>
>> _______________________________________________
>> ncl-talk mailing list
>> ncl-talk at ucar.edu
>> List instructions, subscriber options, unsubscribe:
>> http://mailman.ucar.edu/mailman/listinfo/ncl-talk
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ucar.edu/pipermail/ncl-talk/attachments/20180108/1a64a3e8/attachment.html>