[ncl-talk] CF Convention
Dennis Shea
shea at ucar.edu
Wed Jan 10 15:45:11 MST 2018
Hi Ken, all, I am leaving for Florida& Cuba tomorrow. Likely, I won't be able to get back to you till I return. Cheers, D
Sent from my iPhone
> On Jan 10, 2018, at 2:01 PM, Ken Knapp - NOAA Federal <ken.knapp at noaa.gov> wrote:
>
> Hi Dennis
>
> Thanks for the info. The form that best fits my needs is H.4.1
>>> H.4.1. Multidimensional array representation of trajectories
>>> When storing multiple trajectories in the same file, and the number of elements in each trajectory is the same, one can use the multidimensional array representation. This representation also allows one to have a variable number of elements in different trajectories, at the cost of some wasted space. In that case, any unused elements of the data and auxiliary coordinate variables must contain missing data values (section 9.6).
>
> I've underlined the part that I thought gave me this option: some tracks are long and some aren't. However, keeping the variable that holds the tracks all the same size makes file manipulation easy.
>
> The underlined portion above seems to suggest that this should be possible. But it would imply that there is no track data for some parts of the variable, which would imply that the coordinate variable would have missing data. But that seems at odds with other portions of the documentation. (where it says coordinate variable data should not be missing).
>
> Thoughts?
> -Ken
>
>
>> On Mon, Jan 8, 2018 at 4:54 PM, Dennis Shea <shea at ucar.edu> wrote:
>> 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_data_set_components.html
>>>
>>> Coordinate Variables (CVs):
>>> https://www.unidata.ucar.edu/software/netcdf/docs/netcdf_data_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
>>>>>
>>>>> --
>>>>>
>>>>> Carl J. Schreck III, PhD
>>>>> Research Scholar
>>>>> North Carolina State University
>>>>> North Carolina Institute for Climate Studies (NCICS)
>>>>> 151 Patton Ave, Asheville, NC 28801
>>>>> e: cjschrec at ncsu.edu
>>>>> o: +1 828 257 3140
>>>>> c: +1 828 484 1702
>>>>> Publications
>>>>> ncics.org/mjo
>>>>> CycloneCenter.org
>>>>
>>>> _______________________________________________
>>>> ncl-talk mailing list
>>>> ncl-talk at ucar.edu
>>>> List instructions, subscriber options, unsubscribe:
>>>> http://mailman.ucar.edu/mailman/listinfo/ncl-talk
>>>>
>>>
>>
>
>
>
> --
> Ken Knapp, Ph.D.
> Meteorologist, Center for Weather and Climate
> NOAA National Centers for Environmental Information
> formerly NOAA’s National Climatic Data Center
>
> E/NE31
> 151 Patton Ave
> Asheville, NC 28801
> 828-271-4339 (voice) 828-271-4328 (fax)
> http://www.cyclonecenter.org/ where your clicks count!
>
> "Leave this world a little better than you found it."
> ---Baden-Powell's Last Message (1945)
>
> Disclaimer:
> The opinions expressed in this email are those of the author. They do not necessarily reflect the official views or policies of NOAA, Department of Commerce, or the US Government.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ucar.edu/pipermail/ncl-talk/attachments/20180110/495adb19/attachment.html>
More information about the ncl-talk
mailing list