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
Received on Wed Dec 22 2004 - 07:18:22 GMT
