Re: non-standard axes

[Keith Lindsay <klindsay@xxxxxxxx>]

Gabriel,

I am familiar with POP model output from CCSM, which it appears you have
(based on the form of the metadata). First I'll try to explain the
dimensions for the MOC variable and then describe a way to get ferret to
ingest it.

MOC in the model output is indeed 5 dimensional. This includes the 3
usual dimensions, time (time), depth (moc_z), and latitude
(lat_aux_grid). The other 2 dimensions, transport_reg and moc_comp,
correspond to spatial regions and particular components of the MOC
respectively. Typical transport_reg indices correspond to Global and
Atlantic. A typical moc_comp index is Eulerian Mean. The meanings of
these dimensions for your particular file are in the file metadata via
the variables moc_components & transport_regions, which are pointed to
by the attribute coordinates that is attached to the MOC variable. This
sort of metadata is adopted from the CF-metadata conventions
(http://www.cgd.ucar.edu/cms/eaton/cf-metadata/index.html).

ferret cannot handle these extra dimensions. I haven't downloaded the
most recent ferret version, so this statement may be outdated. My
suggestion is to eliminate them with the ncwa command found in NCO
(http://nco.sourceforge.net/). An example is

ncwa -d transport_reg,0 -d moc_comp,0 -a transport_reg,moc_comp \
   -v MOC MOC.b30.104_0270.nc MOC.nc

This will extract the variable MOC w/ indices 0 and 0 for transport_reg
and moc_comp and will not have the transport_reg and moc_comp dimensions
in the result. ferret then will be able to handle MOC.nc. The particular
indices to use in the above command depend on what region you want the
MOC restricted to and what component of the MOC you are interested in.
Refer to the moc_components & transport_regions variables for more
information.

Hope this helps, Keith

******************************************************************
Keith Lindsay                http://www.cgd.ucar.edu/oce/klindsay/
email: klindsay@ucar.edu   phone: 303-497-1722   fax: 303-497-1700

On Thu, 23 Sep 2004, Gabriel Clauzet wrote:

>  Hi all,
>
>  I'm trying to read Meridional Overturning Circulation file from the POP
>  model output. The file have an unusual ordering of axes and apparently
> FERRET
>  is very confused about the non-standard axes used to define MOC.
>
>  When I try to read the file a message says:
>  > use MOC.b30.104_0270.nc
>  >  *** NOTE: unsupported ordering of axes in variable MOC
>  >  *** NOTE: The default ordering will be used
>  > yes? sh da
>  >      currently SET data sets:
>  >     1> ./MOC.b30.104_0270.nc  (default)
>  >   name MOC
>  >    I             J         K     L
>  >  1:395    1:41      1:1    1:2
>
>  When I try to visualize the data:
>  > yes? sta MOC
>  >  ** netCDF error:
>  > yes? list MOC
>  >  ** netCDF error:
>
>  The atributs of my file are:
>  > netcdf MOC.b30.104_0270 {
>  > dimensions:
>  >          time = UNLIMITED ; // (1 currently)
>  >          transport_reg = 2 ;
>  >          moc_comp = 1 ;
>  >          moc_z = 41 ;
>  >          lat_aux_grid = 395 ;
>  > variables:
>  >          float MOC(time, transport_reg, moc_comp, moc_z, lat_aux_grid) ;
>  >                  MOC:long_name = "Meridional Overturning Circulation" ;
>  >                  MOC:units = "Sverdrups" ;
>  >                  MOC:coordinates = "lat_aux_grid moc_z moc_components
>  > transport_regions time" ;
>  >                  MOC:_FillValue = 9.96921e+36f ;
>  >                  MOC:missing_value = 9.96921e+36f ;
>  >          float lat_aux_grid(lat_aux_grid) ;
>  >                  lat_aux_grid:long_name = "latitude grid for transport
>  > diagnostics" ;
>  >                  lat_aux_grid:units = "degrees_north" ;
>  >                  lat_aux_grid:valid_min = -9.96921e+36f ;
>  >          float moc_z(moc_z) ;
>  >                  moc_z:long_name = "depth from surface to top of layer" ;
>  >                  moc_z:units = "centimeters" ;
>  >                  moc_z:positive = "down" ;
>  >                  moc_z:valid_min = 0.f ;
>  >                  moc_z:valid_max = 549999.9f ;
>  >          double time(time) ;
>  >                  time:long_name = "time" ;
>  >                  time:units = "days since 0000-01-01 00:00:00" ;
>  >                  time:bounds = "time_bound" ;
>  >                  time:calendar = "noleap" ;
>
>  Any idea how to solve this problem ?
>
>  Gabriel
>
>
>
>