Interesting points Martin
1) I like this, I would support an explicit
units = "None"
to address this issue
2) I agree with this, I woudl like to see units mandatory, with an option for None, as above
3) I think '' is a functional alternative to None, but it reads poorly
4) I believe this is accepted, and used. You can define a unit of 'kg kg-1' and udunits works with it, representing it's definition as '1' to support operations. So., I think "kg/kg" and "mole/mole" are already accepted
all the best
mark
________________________________________
From: CF-metadata [cf-metadata-bounces at cgd.ucar.edu] on behalf of Schultz, Martin [m.schultz at fz-juelich.de]
Sent: 05 November 2014 07:57
To: 'cf-metadata at cgd.ucar.edu'
Subject: Re: [CF-metadata] string valued coordinates (unitless quantities)
Dear Mark and all,
thanks for this discussion and the motion to approach udunits to advance this issue. Reading through the posts on this, I have two comments, one question, and one afterthought:
1. Why "no_unit" and not simply "none"? "no_unit" could also be "no_units" (in fact the attribute name is unit*s*, so the missing "s" in "no_unit" may be confusing). Being a Python fan, I like Python's concept of None as a value that indicates that there is no value; just what we want here.
2. When you revise the respective section of the CF convention: in light of the "CF 2" discussions we should think about making the units attribute mandatory. Alternatively, I would suggest that a missing units attribute should mean "none" rather than "1" and/or the units attribute should become mandatory for numerical fields (a string array, for example of station names, may indeed not require a units attribute).
3. Would you regard "" (empty string) as a valid alternative to "none"? [I may have overlooked this in the previous discussions but wasn't sure if there was a consensus view]
4. Coming back to the old "kg/kg" or "mole/mole" discussion: I guess it would help if udunits would accept "terms that evaluate as '1' " with the understanding that they ae equivalent to "1" as unit. Many (most) atmospheric chemistry modelers are still operating in the grey zone with units attributes of "nmole mole-1" which are a lot more readable than "1.e-9" and make a lot of sense to them. Only if you enforce a CF checker on them they will abide, but keep grunting. If one doesn't want to be too generic here, at least "kg/kg" and "mole/mole" should be added to the udunits collection.
Best regards,
Martin
-----Original Message-----
From: CF-metadata [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of cf-metadata-request at cgd.ucar.edu
Sent: Tuesday, November 04, 2014 5:38 PM
To: cf-metadata at cgd.ucar.edu
Subject: CF-metadata Digest, Vol 139, Issue 4
Send CF-metadata mailing list submissions to
cf-metadata at cgd.ucar.edu
Message: 2
Date: Tue, 4 Nov 2014 16:38:12 +0000
From: "Hedley, Mark" <mark.hedley at metoffice.gov.uk>
To: Jim Biard <jbiard at cicsnc.org>, "cf-metadata at cgd.ucar.edu"
<cf-metadata at cgd.ucar.edu>
Subject: Re: [CF-metadata] string valued coordinates
Message-ID:
<7819C496F4E10E47BCEFBE74551AAC9606F401DA at EXXCMPD1DAG3.cmpd1.metoffice.gov.uk>
Content-Type: text/plain; charset="windows-1252"
Hello Jim
> A variable with no units attribute at all is also pretty unambiguously a marker for something that isn't intended to be a even a pure number.
If only this were the case. CF conventions state that:
Units are not required for dimensionless quantities. A variable with no units attribute is assumed to be dimensionless. However, a units attribute specifying a dimensionless unit may optionally be included.
http://cfconventions.org/Data/cf-conventions/cf-conventions-1.6/build/cf-conventions.html#units
Thus, the absence of a unit is to be interpreted identically to a statement that units = '1'
This is the current situation and it is likely that there is lots of data like this around.
> Do we really need something more than a disambiguation of units = '1' vs no units attribute present?
Yes, I think we do: this situation is not ambiguous in CF, they are the same thing.
What I believe we require is a udunits entity which is clearly 'there is no unit of measure here, this is not dimensioned and not dimensionless'
The udunits value
''
delivers this functionality (I think), but it does not read very well, hence my suggestion that we ask for a new entry in udunits, 'no_unit'
which is hopefully clear in its meaning and interpretation and which behaves the same as '' : failing all udunits processing attempts and operating as 'not a unit'
all the best
mark
________________________________
From: CF-metadata [cf-metadata-bounces at cgd.ucar.edu] on behalf of Jim Biard [jbiard at cicsnc.org]
Sent: 31 October 2014 15:18
To: cf-metadata at cgd.ucar.edu
Subject: Re: [CF-metadata] string valued coordinates
Mark,
I'm not clear on what you are suggesting that udunits do with 'no_unit' or '?'.
I had thought that the desire was to be able to differentiate between a pure number (as you mention below) and a value (whether a string or a bit pattern) that should not be interpreted as any number at all.
As the situation stands, a units value of '1' is pretty unambiguously a marker for a pure number. We may need to modify docs to make this clearer, but I don't think that poses a problem. A variable with no units attribute at all is also pretty unambiguously a marker for something that isn't intended to be a even a pure number. Again, we may need to modify docs to make this clearer. Because these two concepts are somewhat conflated in the current documentation and usage (area_type being an example), there is the issue of other places where cleanup would be good going forward, but even if you have a units value of '1' on a non-number, it doesn't hurt anything in practice.
Do we really need something more than a disambiguation of units = '1' vs no units attribute present?
Grace and peace,
Jim
On 10/31/14, 11:04 AM, Hedley, Mark wrote:
Thank you for all the responses, it sounds like 'all of the above' is the preferred response to my suggestions of plausible next steps. I will pursue all of these.
Eizi's point about having no_unit in udunits is sound; I suggest we request udunits use
'no_unit'
as a representation of
'?'
such that the behaviour is consistent; 'no_unit' should always raise an exception when used in the udunits processing rules, exactly as '?' does.
With regard to meaning, I have found the wikipedia entry useful:
http://en.wikipedia.org/wiki/Dimensionless_quantity
`In dimensional analysis<
http://en.wikipedia.org/wiki/Dimensional_analysis>, a dimensionless quantity or quantity of dimension one is a quantity<
http://en.wikipedia.org/wiki/Quantity> without an associated physical dimension<
http://en.wikipedia.org/wiki/Dimensional_analysis>. It is thus a "pure" number, and as such always has a dimension of 1.[1]<
http://en.wikipedia.org/wiki/Dimensionless_quantity#cite_note-1>'
which it has sourced from
"1.8 (1.6) quantity of dimension one dimensionless quantity"<
http://www.iso.org/sites/JCGM/VIM/JCGM_200e_FILES/MAIN_JCGM_200e/01_e.html#L_1_8>. International vocabulary of metrology ? Basic and general concepts and associated terms (VIM). ISO<
http://en.wikipedia.org/wiki/International_Organization_for_Standardization>. 2008. Retrieved 2011-03-22.
This is a good enough source for me.
I will wait to give space for more comments, then, if people are content, I will raise a change request with udunits.
Assuming this is accepted and processed I will raise a change request for CF to add some text to 3.1.
Finally I will request a change for any standard_names which appear not to follow this approach (I have only 'area_type' so far).
I hope this seems like a reasonable response.
[...]
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
_______________________________________________
CF-metadata mailing list
CF-metadata at cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Thu Nov 06 2014 - 04:59:38 GMT
