I'd really like to wrap up the discussion of canonical units for practical
salinity, since the oceansites people are writing data sets on a daily
basis and don't want to be creating files where the data will be mis-
interpreted, or non-compliant with CF. I know there are side issues
having to do with absolute salinity and 'old salinity' but I think we may
be somewhere near consensus on practical salinity.
confused by what everyone thinks units of '0.001' is supposed to mean
> ... Neither 1, 0.001, nor percent are dimensional units, are they?
The problem is that with a dimensionless variable, a dataset may contain
'scaled data' ; e.g. for Beaufort wind scale, where the value is between 1
and 12, the stored data value could be between 1 and 1200 and the unit
would be .001, instead of 1). The user will divide the data values by 1000
before using them.
It seems that we agree that since PS is non-dimensional, so its canonical
unit should be '1', not '.001'. Oceansites would like to use '1', and to
not
have to expect anyone to multiply the PS data values by 1000.
Are we actually close enough to a decision to move on this, or am I being
overly optimistic?
Thanks!
Nan
On 6/3/15 10:39 AM, Lowry, Roy K. wrote:
Hi Jim,
I think you and Dan are trying to apply logic to set of conventions
that a domain developed to get out of a mess caused by loose labelling
conventions in the past. 'Old salinity' units are described as part
per thousand, which is represented by the notation '0.001'. What this
actually meant was 'parts of salt per thousand parts of water' which
because chemistry was volumetric meant grams per litre, not grams per
kilogram. At the time ppt was in widespread use salinity accuracy was
such that the error resulting from assuming seawater had a density of
1 kg/l was insignificant. These days it is extremely significant.
The physical oceanographic community has adopted the unit notation
practice of 'parts per thousand' for 'old' salinity, 'dimensionless'
for practical salinity and grams per kilogram for absolute salinity.
The current debate is the result of trying to map this convention into
the SI-based logic of UDUNITS - a square peg into a hole that is
decidedly round.
Cheers, Roy.
*From:*Jim Biard [mailto:[email protected]]
*Sent:* 03 June 2015 14:01
*To:* [email protected]
*Subject:* Re: [CF-metadata] FW: Salinity units
Hi.
I'm with Dan on this. I'm also feeling more and more confused by what
everyone thinks units of '0.001' is supposed to mean. A number of the
people writing on this topic appear to be asserting that this is some
sort of dimensional unit. Neither 1, 0.001, nor percent are
dimensional units, are they? They are all ways of referencing pure
number quantities, as far as I can tell. When playing with the
UDUNITS2 software, they are all considered as simple variations in
scale factor.
So, what are you intending for me to understand when you tell me that
'older' salinity has units of 0.001 and Practical Salinity has units of 1?
Grace and peace,
Jim
On 6/3/15 6:03 AM, Hollis, Dan wrote:
Hi all,
I'm not a user of salinity data, nor am I an expert on CF. However
my impression of this discussion is that the problem lies with the
fact that the canonical units appear to be used to represent two
different properties i.e. the dimensions and the units.
I would say that there are two classes of dimensionless quantity:
Those that genuinely have no units e.g. beaufort_wind_force
Those obtained by taking the ratio of other quantities that do
have dimensions, such that the dimensions cancel out in the result
My feeling is that in both cases the canonical unit should always
be '1'
However for the second category the user still needs to know what
units the data are in (so that they can convert to other units,
compare with other datasets etc) i.e. the user needs to know if the
values are in g/kg or kg/kg. Surely this is the job of the units
attribute, not the canonical units.
Note that this distinction applies to, and is more obvious for,
dimensional quantities. As I understand it, if the canonical units are
m/s this does not stop me from storing my data in km per hour or miles
per second (or anything else understood by udunits), I just need to
indicate the actual units via the units attribute.
So, I think we just need to extend this same thinking to
dimensionless quantities.
Apologies if I've misunderstood the issues...
Dan
--
*******************************************************
* Nan Galbraith Information Systems Specialist *
* Upper Ocean Processes Group Mail Stop 29 *
* Woods Hole Oceanographic Institution *
* Woods Hole, MA 02543 (508) 289-2444 *
*******************************************************
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
