Rich Signell wrote:
> Steve Hankin wrote:
>
> >As Rich says, getting this "right" is very important to the HYCOM modeling
> >community and others. Outputting the Z field as a 4-dimensional variable has nasty
> >consequences in file sizes, access demands, etc.
> >
> >
> Don't you need to specify Z as a 4D variable in a model like HYCOM,
> where the vertical coordinate depends on density information that may
> not even be saved in the output file? This isn't that nasty, is it?
> The Z field just becomes the same size as other 4D fields like
> potential temperature, salinity, etc.
Hi Rich,
Ah, the hazard of hasty responses -- trying to do several things at the same time. What
I said was full of baloney. Thank you for quickly pointing it out. For HYCOM we *do*
encode the sigma information in a 3D variable already. And it is in addition
time-dependent, so it is actually 4-dimensional Z coordinate information.
I'm afraid that I have injected confusion into the conversation. My regrets. My goal
was to leave the door open for conversation at a later time, when there would be a
chance to think about the issues. I withdraw the garbled thoughts I entered into the
discussion -- please "strike my last message from the record".
- steve
> >My gut sense is that we're conflating two issues here. One is the idea of
> >time-dependent sigma levels -- as are used in HYCOM. I have not been aware that we
> >were abusing the CF conventions by allowing the sigma levels to be time-dependent.
> >Doing so seemed to be completely in the spirit of CF and netCDF. (I haven't gone
> >back just now to review the actual words from the CF document.) No mods are
> >necessary; the time dimension is self-explanatory.
> >
> >
> This seems to be agreeing with Brian's earlier statement that saving 4D
> fields of Z are allowed already, enabled by the "coordinates"
> attribute. Can one of you guys give an example of how this would be
> done? I have only seen the "coordinates" attribute used to specify
> two-dimensional longitude and latitude fields.
>
> >The second idea is of "generalized sigma coordinates", where sigma levels are a
> >fraction of (depth+eta). If one asserts (true?, false?) that such coordinate
> >systems represent a significant class of models, then there should be a serious
> >discussion of whether CF should support them. It **sounds** as if support would
> >require only the addition of a single attribute,
> >
> > sigma: fraction_of = depth
> >or
> > sigma: fraction_of = depthPlusFreeSurface
> >
> >
> All sigma models I am aware of represent layers as fractions of the
> total_water_depth = depth + eta, never just the depth.
>
> -Rich
>
> --
> Richard P. Signell rsignell at usgs.gov
> U.S. Geological Survey Phone: (508) 457-2229
> 384 Woods Hole Road Fax: (508) 457-2310
> Woods Hole, MA 02543-1598
--
Steve Hankin, NOAA/PMEL -- Steven.C.Hankin at noaa.gov
7600 Sand Point Way NE, Seattle, WA 98115-0070
ph. (206) 526-6080, FAX (206) 526-6744
Received on Wed Dec 22 2004 - 13:30:40 GMT
