Subject: time in netCDF

From: [email-masked] (Daniel Packman)
Date: Wed, 2 Feb 1994 10:39:03 -0700

> ...
> I recall seeing something you posted recently (I think on the
> netcdf mail group) about keeping time on uars. It sounded like
> a good system, can you repeat it?

We keep time in a totally nonstandard way in netCDF files.  We use
the variables "time_day" and "time_msec" for the julian day (minus
12 hours) and the millisecond of day, respectively.  With your background
in astronomy, I don't have to remind you what julian day is.  It's the
ignorant unwashed masses in other fields who have fouled the use of this
term by confusing it with day of year or some such.  With a system like
this we don't need to specify an epoch since julian day is absolute.
The system is non-standard because we should have the single dimension
variable "time(time)".  The problem with this is that we would have to
use the only primitive data type that would work (double) and we wish
to rigorously maintain every bit of the millisecond of day.

> Are you making netcdf data or satellite attitude files from uars?
> If so, maybe I should use something similiar. ...

The uars project has its own complicated scheme to predict the satellite
path together with sub-satellite path, and various tangent points.  I
work with actual VMS specific files that I merely have to convert to
netCDF.

We are awaiting word of a standard from EOS for the use of HDF and will
no doubt migrate to that in the future.

---

From: [email-masked] (Daniel Packman)
Date: Wed, 2 Feb 1994 16:19:42 -0700

>Would it be easy to summarize the form of your netcdf file? What does
>an ncdump of one look like?

We have different formats for profile data and "mapped" data (or synoptic
global planetary wave decomposition).  An example of a netCDF header for
profile data from the CLAES insrument is:

netcdf 568_570v6c1 {
dimensions:
	npress = 25 ;
	ntime = UNLIMITED ; // (3578 currently)
	nelem = 1 ;
	nparts = 3 ;
	ntwo = 2 ;

variables:
	float press(npress) ;
		press:gridded = "T" ;
		press:units = "mb" ;
		press:long_name = "Pressure" ;
		press:grid = 464.15887f, 316.22775f, 215.44347f, 146.77994f, 100.f, 68.129211f, 46.415886f, 31.622774f, 21.544348f, 14.677991f, 10.f, 6.8129196f, 4.6415896f, 3.1622777f, 2.1544344f, 1.4677995f, 1.f, 0.681292f, 0.46415898f, 0.31622776f, 0.21544343f, 0.14677995f, 0.099999994f, 0.068129227f, 0.046415873f ;
		press:missing_value = 0s ;
		press:valid_range = 9.9999997e-05f, 1000.f ;
	float datap(ntime, npress) ;
		datap:units = "k" ;
		datap:missing_value = -999.f ;
		datap:valid_range = 180.f, 300.f ;
		datap:min = 141.60358f ;
		datap:max = 371.46439f ;
	float qual(ntime, npress) ;
		qual:units = "k" ;
		qual:missing_value = -999.f ;
		qual:valid_range = 0.f, 30.f ;
		qual:min = 0.00029128758f ;
		qual:max = 100.f ;
	long crtim(nparts, ntwo) ;
		crtim:long_name = "Creation time" ;
	long strtim(nparts, ntwo) ;
		strtim:long_name = "Start time" ;
	long stoptim(nparts, ntwo) ;
		stoptim:long_name = "Stop time" ;
	short vers(nparts, ntwo) ;
		vers:long_name = "Version" ;
		vers:missing_value = -1s ;
	float lon(ntime) ;
		lon:long_name = "Longitude" ;
		lon:units = "degrees east" ;
		lon:missing_value = -999.f ;
		lon:valid_range = 0.f, 360.f ;
	float lat(ntime) ;
		lat:gridded = "F" ;
		lat:missing_value = -999.f ;
		lat:long_name = "Latitude" ;
		lat:units = "degrees" ;
		lat:valid_range = -90.f, 90.f ;
		lat:min = -80.334213f ;
		lat:max = 34.50919f ;
		lat:grid = -80.f, -76.f, -72.f, -68.f, -64.f, -60.f, -56.f, -52.f, -48.f, -44.f, -40.f, -36.f, -32.f, -28.f, -24.f, -20.f, -16.f, -12.f, -8.f, -4.f, 0.f, 4.f, 8.f, 12.f, 16.f, 20.f, 24.f, 28.f, 32.f, 36.f ;
	long time_day(ntime) ;
		time_day:units = "day" ;
		time_day:long_name = "Julian Day" ;
		time_day:missing_value = 0 ;
	long time_msec(ntime) ;
		time_msec:units = "msec" ;
		time_msec:long_name = "Millisecond of Day" ;
		time_msec:missing_value = -1 ;
		time_msec:valid_range = 0, 86399999 ;
	float sza(ntime) ;
		sza:units = "degrees" ;
		sza:long_name = "Solar Zenith Angle" ;
		sza:missing_value = -999.f ;

// global attributes:
		:history = "Created from cdhf data" ;
		:datkind = "3AT" ;
		:dattyp = "CLAES" ;
		:subtyp = "Temperature" ;
		:UARSsubtyp = "TEMP" ;
		:node = "sign encoded" ;
		:versmin = 6s, 1s ;
		:versmax = 6s, 1s ;
		:creation = "Sep  2, 1993   6:32:58.84" ;
		:crtim = 2449233, 23578840 ;
		:start = "Apr  1, 1993   0:01:47.06" ;
		:strtim = 2449079, 107065 ;
		:stop = "Apr  3, 1993  23:58:25.41" ;
		:stoptim = 2449081, 86305416 ;
		:type = "profile" ;
		:nparts = 3 ;
}

---

From: [email-masked] (Daniel Packman)
Date: Wed, 2 Feb 1994 16:31:26 -0700

>... I've heard that netcdf calls
>will work in the hdf lib, so that might make it ieasier for me.

For us as well.  I fooled around with an hdf library version that
read either hdf or netcdf and wrote hdf.  Conversion from netCDF
to hdf was quite straightforward... the code looked as if it just
copied the file from input to output via netCDF calls.