All,
I agree with Brian's assessment of formula_terms, but nevertheless, I think
they may provide the better solution. In the example below, I find myself
asking, "difference from what", when looking at the tanom specification.
With a little insight and experience, most users of the data could figure out
the meaning of the data if only this file were available. But, I think the
solution adopted for this situation is going to be challenged by the next
level of complexity a user experiences.
For example, with observational ocean profiles, you frequently encounter
different reference pressures for different levels in the water column. In
the upper 500 meters one may use pref=0 to calculate potential temperature
and potential density frequently called sigma-zero in the literature. Then
between z=500m and z=1500m pref=1000 is used to deriv sigma-one etc. So, one
ends up with a formula which differs in its parameters based on values of the
independent variables. This could be solved but next, we'll see neutral
density (commonly called gamma) which is defined with respect to an
independent set of 3d data, not just a formula. Sooner or later, it will
require just pointing to a URL with a description as was suggested for "terms
of use" information a few weeks ago.
I guess my question is, where is the practical division between relying on a
user's intuition or knowledge and creating "fully self describing" data sets?
Analogously, what is required in order to claim that a data file is CF-1.0
compliant and what is recommended?
Anyone care to comment?
Best Regards,
Derrick Snowden
On Fri October 22 2004 11:51 am, Brian Eaton wrote:
> Hi Jonathan,
>
> I find this use of formula_terms confusing.
>
> The problem you describe seems like a good candidate for the
> ancillary_variables attribute and the standard_name modifiers.
> Your example might be expressed like this:
>
> variables:
> float ild(time,lat,lon)
>
> ild:standard_name="ocean_mixed_layer_thickness_diagnosed_from_temperature";
> ild:units="m";
> ild:ancillary_variables = "tanom";
> float pottem(time,level,lat,lon);
> pottem:standard_name = "sea_water_potential_temperature";
> pottem:units = "degC" ;
> pottem:ancillary_variables = "pref";
> float tanom;
> tanom:units="degC";
> tanom:standard_name="sea_water_temperature difference";
> float pref;
> pref:units="dbar";
> pref:standard_name="air_pressure reference";
> data:
> tanom=0.5;
> pref=2000;
>
> and then we'd only need to add "difference" and "reference" to the modifier
> list in appendix C.
>
> Brian
>
> On Fri, Oct 22, 2004 at 03:12:33PM +0100, Jonathan Gregory wrote:
> > Dear All
> >
> > Some quantities cannot be fully defined by a standard name because their
> > definition includes a numeric parameter. If we included numeric
> > parameters in the name, the standard name table would become
> > (uncountably) infinitely long. For example, air and sea water potential
> > temperature have a reference pressure, usually assumed to be 1
> > atmosphere, but not necessarily so (especially in the ocean). The ocean
> > mixed layer thickness is often defined as being the depth at which the
> > temperature differs by some amount from the surface temperature, and
> > there are various choices for this number.
> >
> > One option would be to store the reference pressure and the temperature
> > difference as scalar coordinate variables or coordinate variables with a
> > size of unity, and identify them with standard names. I think this is the
> > right approach in some cases. For example, the depth of the 20 degC
> > isotherm in the ocean can be given a standard name of depth and a scalar
> > coordinate of 20 degC. For the two examples above, however, it doesn't
> > seem so good to me because "reference pressure for potential temperature"
> > and "temperature anomaly from surface in mixed layer definition" aren't
> > physical quantities that you'd like to have standard names for. They are
> > literally just parameters in a formula.
> >
> > Another approach would be to define attributes for these numbers. I don't
> > like that idea very much either because it would lead to a lot of new
> > attributes being necessary.
> >
> > My proposal is that we should extend the use of the formula_terms
> > attribute to cover this situation. At present formula_terms is used to
> > supply variables for computing dimensional vertical coordinates from
> > dimensionless ones. It can be an attribute only of a variable containing
> > coordinate information, and the contents it can have depend on the
> > standard_name of the variable it is attached to. I propose that we should
> > allow formula_terms also to be attached to data variables as well. In the
> > same way, the contents it could have would depend on the standard_name of
> > the variable. Hence my two examples would become
> >
> > variables:
> > float ild(time,lat,lon)
> >
> > ild:standard_name="ocean_mixed_layer_thickness_diagnosed_from_temperature
> >"; ild:units="m";
> > ild:formula_terms="temperature_difference: tanom";
> > float pottem(time,level,lat,lon);
> > pottem:standard_name = "sea_water_potential_temperature";
> > pottem:units = "degC" ;
> > pottem:formula_terms="reference_pressure: pref";
> > float tanom;
> > tanom:units="degC";
> > float pref;
> > pref:units="dbar";
> > data:
> > tanom=0.5;
> > pref=2000;
> >
> > Any views?
> >
> > Best wishes
> >
> > Jonathan
> > _______________________________________________
> > CF-metadata mailing list
> > CF-metadata at cgd.ucar.edu
> > http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
Derrick Snowden
PhOD/AOML/NOAA
4301 Rickenbacker Causeway
Miami, FL 33149
Office: 305.361.4322 Fax: 305.361.4392
Received on Fri Oct 22 2004 - 11:10:25 BST
