[ncl-talk] CF Convention

[Dennis Shea]

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/20180105/a0eddacd/attachment.html>