Dear Ag,
I would strongly advise for storing the data in two different
files, because these are effectively two different measurements. As an
atmospheric chemistry modeler I have to work with many different data
sets, and I try to always convert them to netcdf before using them (it
helps in identifying errors and inconsistencies, and it is much more
convinient than the thousand different ASCII "standards" which
exist). Broadly, all data sets fall into certain categories, but they
usually have a well-defined coordinate set. This is the minimal
"common denominator", which is often relied on by visualisation and
processing software. Having two different vertical axes in one file
therefore doesn't sound like a good idea. You mention that you would
like to plot a day at once: well, there are several options: (a) the
data aquisition program produces two netcdf files per day (one for
each mode), and you use the append functionality [if the time
dimension is "unlimited", this is no problem]. Option (b), you produce
chunks of data and at the end of the day use the NCO tool ncrcat to
merge them together. It may be a little more work now, but I am sure
it would facilitate the exchange of your data with colleagues quite a
bit.
Best regards,
Martin Schultz
ncdigest writes:
>
> ncdigest Thursday, June 5 2003 Volume 01 : Number 699
>
>
>
> Today's Topics:
> Multiple altitude axes in one NetCDF file
> Re: Multiple altitude axes in one NetCDF file
> RE: Multiple altitude axes in one NetCDF file
>
> ----------------------------------------------------------------------
>
> Date: Thu, 5 Jun 2003 09:11:50 +0100
> From: "Stephens, A (Ag) " <A.Stephens@xxxxxxxx>
> Subject: Multiple altitude axes in one NetCDF file
>
> Dear all,
>
> I have been trying to convert a colleague to using NetCDF and conforming to
> the Climate and Forecasts Metadata Convention. However, she has some sodar
> data that has an interesting quirk to it.
>
> The instrument sits on the ground and looks vertically up, measuring the
> profile of wind speed and direction. It therefore has two coordinate
> variables: time and altitude.
>
> There are two modes in which the instrument can measure which vary the
> altitude coordinates so during the course of a day the sodar may be run in
> each mode for different periods. This produces output with two altitude
> dimensions.
>
> The easiest option for NetCDF would be to output to a new file each time the
> mode changes. However, it is useful to be able to plot the entire day onto
> one graph. Does NetCDF have a suitable solution to this problem?
>
> My hunch would be to create two altitude dimensions, say 'altitude1' and
> 'altitude2' and two lots of wind parameters that vary with each altitude.
> Alternatively, you can define the altitudes for each time step throughout
> the measurement period (but this is inefficient).
>
> I would hope there was a more elegant solution which would allow plotting
> packages to view the entire dataset as continuous rather than separate
> variables defined on separate dimensions.
>
> Any ideas?
>
> Thanks,
>
> Ag
> - -------------------------------------------------------------
> Ag Stephens Ph : +44 (0)1235 446220
> Data Scientist, Fax: +44 (0)1235 446314
> British Atmospheric Data Centre,
> Rutherford Appleton Laboratory,
> Chilton, Didcot, OX11 0QX, U.K.
> Email: A.Stephens@xxxxxxxx Web: http://badc.nerc.ac.uk
> - -------------------------------------------------------------
>
> ------------------------------
>
> Date: Thu, 05 Jun 2003 08:04:56 -0700
> From: Steve Hankin <Steven.C.Hankin@xxxxxxxx>
> Subject: Re: Multiple altitude axes in one NetCDF file
>
> Hi Ag,
>
> Do the two vertical modes of measurement each have the same number of points
> on
> the axes? Or if they do not, then would it be acceptable to utilize a single
> vertical dimension of size equal to the larger of the two and to allow
> missing
> value flags for the unused space on the shorter vertical axis?
>
> If the answer to either of these is yes, then the problem reduces to the
> "sigma
> coordinate problem". To encode sigma coordinate data in netCDF one creates
> an
> additional *dependent* variable (not a standard netCDF coordinate variable)
> whose vertical dimension is the length above and whose values are the
> (time-varying) heights (or depths). I believe that you'll find this is
> documented in the CF conventions -- together with the conventions that link
> the
> measured variables to these time-varying (or space-varying) Z coordinates.
>
> Hope this helps.
>
> - steve
>
> P.S. There is a specific function in the Ferret program called ZAXIS_REPLACE
> to
> allow you to shift between sigma coordinates and fixed coordinates when
> working
> with the data. I'm sure there are equivalent techniques in IDL and Matlab
> and I
> presume GrADS, too.
>
> ===================================================
>
> "Stephens, A (Ag)" wrote:
>
> > Dear all,
> >
> > I have been trying to convert a colleague to using NetCDF and conforming to
> > the Climate and Forecasts Metadata Convention. However, she has some sodar
> > data that has an interesting quirk to it.
> >
> > The instrument sits on the ground and looks vertically up, measuring the
> > profile of wind speed and direction. It therefore has two coordinate
> > variables: time and altitude.
> >
> > There are two modes in which the instrument can measure which vary the
> > altitude coordinates so during the course of a day the sodar may be run in
> > each mode for different periods. This produces output with two altitude
> > dimensions.
> >
> > The easiest option for NetCDF would be to output to a new file each time
> > the
> > mode changes. However, it is useful to be able to plot the entire day onto
> > one graph. Does NetCDF have a suitable solution to this problem?
> >
> > My hunch would be to create two altitude dimensions, say 'altitude1' and
> > 'altitude2' and two lots of wind parameters that vary with each altitude.
> > Alternatively, you can define the altitudes for each time step throughout
> > the measurement period (but this is inefficient).
> >
> > I would hope there was a more elegant solution which would allow plotting
> > packages to view the entire dataset as continuous rather than separate
> > variables defined on separate dimensions.
> >
> > Any ideas?
> >
> > Thanks,
> >
> > Ag
> > -------------------------------------------------------------
> > Ag Stephens Ph : +44 (0)1235 446220
> > Data Scientist, Fax: +44 (0)1235 446314
> > British Atmospheric Data Centre,
> > Rutherford Appleton Laboratory,
> > Chilton, Didcot, OX11 0QX, U.K.
> > Email: A.Stephens@xxxxxxxx Web: http://badc.nerc.ac.uk
> > -------------------------------------------------------------
>
> - --
>
> Steve Hankin, NOAA/PMEL -- Steven.C.Hankin@xxxxxxxx
> 7600 Sand Point Way NE, Seattle, WA 98115-0070
> ph. (206) 526-6080, FAX (206) 526-6744
>
> ------------------------------
>
> Date: Thu, 5 Jun 2003 16:51:52 +0100
> From: "Stephens, A (Ag) " <A.Stephens@xxxxxxxx>
> Subject: RE: Multiple altitude axes in one NetCDF file
>
> Dear Steve,
>
> Thanks for your feedback. I will have a look at using your approach,
> hopefully it should solve the issue.
>
> Kind regards,
>
> Ag
>
> > -----Original Message-----
> > From: Steve Hankin [mailto:Steven.C.Hankin@xxxxxxxx]
> > Sent: 05 June 2003 16:05
> > To: Stephens, A (Ag)
> > Cc: netcdfgroup@xxxxxxxxxxxxxxxx
> > Subject: Re: Multiple altitude axes in one NetCDF file
> >
> >
> > Hi Ag,
> >
> > Do the two vertical modes of measurement each have the same
> > number of points on
> > the axes? Or if they do not, then would it be acceptable to
> > utilize a single
> > vertical dimension of size equal to the larger of the two and
> > to allow missing
> > value flags for the unused space on the shorter vertical axis?
> >
> > If the answer to either of these is yes, then the problem
> > reduces to the "sigma
> > coordinate problem". To encode sigma coordinate data in
> > netCDF one creates an
> > additional *dependent* variable (not a standard netCDF
> > coordinate variable)
> > whose vertical dimension is the length above and whose values are the
> > (time-varying) heights (or depths). I believe that you'll
> > find this is
> > documented in the CF conventions -- together with the
> > conventions that link the
> > measured variables to these time-varying (or space-varying) Z
> > coordinates.
> >
> > Hope this helps.
> >
> > - steve
> >
> > P.S. There is a specific function in the Ferret program
> > called ZAXIS_REPLACE to
> > allow you to shift between sigma coordinates and fixed
> > coordinates when working
> > with the data. I'm sure there are equivalent techniques in
> > IDL and Matlab and I
> > presume GrADS, too.
> >
> > ===================================================
> >
> > "Stephens, A (Ag)" wrote:
> >
> > > Dear all,
> > >
> > > I have been trying to convert a colleague to using NetCDF
> > and conforming to
> > > the Climate and Forecasts Metadata Convention. However, she
> > has some sodar
> > > data that has an interesting quirk to it.
> > >
> > > The instrument sits on the ground and looks vertically up,
> > measuring the
> > > profile of wind speed and direction. It therefore has two coordinate
> > > variables: time and altitude.
> > >
> > > There are two modes in which the instrument can measure
> > which vary the
> > > altitude coordinates so during the course of a day the
> > sodar may be run in
> > > each mode for different periods. This produces output with
> > two altitude
> > > dimensions.
> > >
> > > The easiest option for NetCDF would be to output to a new
> > file each time the
> > > mode changes. However, it is useful to be able to plot the
> > entire day onto
> > > one graph. Does NetCDF have a suitable solution to this problem?
> > >
> > > My hunch would be to create two altitude dimensions, say
> > 'altitude1' and
> > > 'altitude2' and two lots of wind parameters that vary with
> > each altitude.
> > > Alternatively, you can define the altitudes for each time
> > step throughout
> > > the measurement period (but this is inefficient).
> > >
> > > I would hope there was a more elegant solution which would
> > allow plotting
> > > packages to view the entire dataset as continuous rather
> > than separate
> > > variables defined on separate dimensions.
> > >
> > > Any ideas?
> > >
> > > Thanks,
> > >
> > > Ag
> > > -------------------------------------------------------------
> > > Ag Stephens Ph : +44 (0)1235 446220
> > > Data Scientist, Fax: +44 (0)1235 446314
> > > British Atmospheric Data Centre,
> > > Rutherford Appleton Laboratory,
> > > Chilton, Didcot, OX11 0QX, U.K.
> > > Email: A.Stephens@xxxxxxxx Web: http://badc.nerc.ac.uk
> > > -------------------------------------------------------------
> >
> > --
> >
> > Steve Hankin, NOAA/PMEL -- Steven.C.Hankin@xxxxxxxx
> > 7600 Sand Point Way NE, Seattle, WA 98115-0070
> > ph. (206) 526-6080, FAX (206) 526-6744
> >
> >
>
> ------------------------------
>
> End of ncdigest V1 #699
> ***********************
--
[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[
[[ Dr. Martin Schultz Max-Planck-Institut fuer Meteorologie [[
[[ Bundesstr. 55, 20146 Hamburg [[
[[ phone: +49 40 41173-308 [[
[[ fax: +49 40 41173-298 [[
[[ martin.schultz@xxxxxxx [[
[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[
