Hi All,
This is mostly a "hold the train" message to indicate that this sounds important,
but I don't have time in my schedule to get fully engaged. Unfortunately, I'm
under the gun for some tight schedule, Christmas is around the corner, etc., etc.
So this is shoot-from-the-hip ...
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.
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.
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
- steve
=============================================
Rich Signell wrote:
> Jonathan,
>
> I used the name "generalized sigmal coordinate" because that's what the
> SYMPHONIE Model Description
> (http://www.aero.obs-mip.fr/activite_scientifique/oceano/symphonie_web.htm)
> called it. Perhaps they call
>
> z(n,k,j,i) = eta(n,j,i) + sigma(k,j,i)*(depth(j,i)+eta(n,j,i))
>
> a "generalized sigma coordinate" because at each (i,j) location the
> vertical levels are at a fixed (time invariant) fraction of the *total*
> water depth (depth + eta).
>
> If the community feels there is something better to call it, lets hear
> some options!
>
> The real problem is that in today's ocean models, we actually have cases
> of increasing complexity for stretched vertical coordinates.
>
> Defining the level "s" as a fraction of the total water depth
> (depth+eta), we have:
>
> Case 1. s(k): levels do not vary with lon,lat or time
> ("ocean_sigma_coordinate")
> Case 2. s(k,j,i): levels vary with lon,lat, but in a way specified by a
> simple formula (e.g. "ocean_s_coordinate")
> Case 3. s(k,j,i): levels vary with lon,lat, but in a way *not*
> specified by a simple formula
> Case 4. s(n,k,j,i): levels vary with lon,lat and time, but in a way
> *not* specified by a simple formula
>
> Right now, CF-1.0 covers only Case 1 and *one type* of Case 2
> ("ocean_s_coordinate")
>
> I was proposing that the next version of CF allow specification of Case
> 3, but CF really needs to cover both Case 3 and Case 4.
>
> Case 3 would cover situations where the levels are invariant in time,
> but vary in lon,lat (i,j), and are either not defined according to a
> simple formula or defined by a simple formula not specifically
> recognized by CF. This would allow the SYMPOHNIE modeling community
> and people who are doing specialized work with "S coordinate" models
> like ROMS to meet the CF conventions.
>
> Case 4 would allow CF to include HYCOM and other hybrid/generalized
> coordinate models (see:
> http://oceanmodeling.rsmas.miami.edu/hycom/documentation.html,
> http://tinyurl.com/58nvu) to meet the CF convention. In these models
> the number of vertical levels is still fixed, but the levels themselves
> can change according to the density field or even the dynamics, and
> therefore the whole 4D field of "s" positions must be saved. At this
> point, we might just as well specify the 4D field of z values directly,
> as there is no savings in the dimensionless vertical coordinate. But
> does CF allow the depth variable to be specified as a 4D field?
> Perhaps this is still best handled through the "dimensionless vertical
> coordinate" mechanism?
>
> If so, perhaps we could have this in the next release of CF:
>
> Case 3:
> "ocean_generalized_sigma_coordinate" (Case 3)
>
> z(n,k,j,i) = eta(n,j,i) + sigma(k,j,i)*(depth(j,i)+eta(n,j,i))
>
> Case 4:
> "ocean_generalized_coordinate"
> z(n,k,j,i) = eta(n,j,i) + s(n,k,j,i)*(depth(j,i)+eta(n,j,i))
> or simply
> z(n,k,j,i)=z(n,k,j,i)
>
> -Rich
>
> Jonathan Gregory wrote:
>
> >Dear Rich
> >
> >If sigma is a function of position (j,i) as well as level k, it will no longer
> >trace out levels at a fixed fraction of the distance between the surface and
> >the floor. In that case, what is the point of it as a sigma coordinate?
> >Obviously we could generalise its definition in the way you suggest, but this
> >is apparently equivalent to
> >
> >z(n,k,j,i) = A(n,j,i)*eta(n,j,i) + B(k,j,i)
> >
> >i.e. you specify the gridpoint vertical coordinates as the sum of a time-
> >invariant set of depths B, plus some fraction A of the time-variation of the
> >surface height. I wouldn't call that a sigma coordinate. This kind of
> >construction doesn't seem to have any surfaces at all, unless there is some
> >constraint on the smoothness of B(k,j,i) for each k. How do they construct
> >their grid, in fact?
> >
> >Cheers
> >
> >Jonathan
> >_______________________________________________
> >CF-metadata mailing list
> >CF-metadata at cgd.ucar.edu
> >http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
> >
> >
>
> --
> 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
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
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 - 10:49:31 GMT
