Re: [CF-metadata] udunits corresponding to Forel-Ule, milliequivalent
Hi Upendra, The Forel-Ule is another example where parameter semantics have been off-loaded in the units of measure, such as 'milligrams per gram of dry sediment'. I have been working to eliminate this by moving the semantics into the parameter description to leave a UDUNITS-compatible UoM. In BODC we have an equivalent to a Standard Name of 'Colour of the water body by visual estimation and conversion to a number on the Forel-Ule scale' which has units of dimensionless. This would require a new Standard Name were this approach to be used in CF. I'm guessing you want milliequivalents for total alkalinity data. Previously in CF the standard name 'sea_water_alkalinity_expressed_as_mole_equivalent' has been used with the canonical unit 'Moles per cubic metre', which is a pragmatic solution to your problem that works in the oceanographic domain because alkalinity is the only thing we encounter in Equivalents and luckily for us the chemistry is such that 1 Mole = 1 Equivalent. Cheers, Roy. -Original Message- From: cf-metadata-boun...@cgd.ucar.edu [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Steve Emmerson Sent: 08 December 2011 23:58 To: Upendra Dadi Cc: cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] udunits corresponding to Forel-Ule, milliequivalent Upendra, From the perspective of the UDUNITS unit-packages, the unit Forel-Ule is the unit Forel multiplied by the unit Ule -- neither, of which, is known by the UDUNITS or UDUNITS2 packages. I suggest you contact the author. Regards, Steve Emmerson On 12/08/2011 09:05 AM, Upendra Dadi wrote: Hi, I have some data which has Forel-Ule for the units used. Is there a udunits corresponding to this? Also, what should I use for milliequivalent ? Thanks for the help. Upendra ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system. ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] udunits corresponding to Forel-Ule, milliequivalent
hi: I think I would also advocate adding another standard attribute, something like units_label which would be a label for the units in a plot, not necessarily udunit compliant. eg: var : units = ; var : units_label = milligrams per gram of dry sediment; john On 12/9/2011 2:09 AM, Lowry, Roy K. wrote: Hi Upendra, The Forel-Ule is another example where parameter semantics have been off-loaded in the units of measure, such as 'milligrams per gram of dry sediment'. I have been working to eliminate this by moving the semantics into the parameter description to leave a UDUNITS-compatible UoM. In BODC we have an equivalent to a Standard Name of 'Colour of the water body by visual estimation and conversion to a number on the Forel-Ule scale' which has units of dimensionless. This would require a new Standard Name were this approach to be used in CF. I'm guessing you want milliequivalents for total alkalinity data. Previously in CF the standard name 'sea_water_alkalinity_expressed_as_mole_equivalent' has been used with the canonical unit 'Moles per cubic metre', which is a pragmatic solution to your problem that works in the oceanographic domain because alkalinity is the only thing we encounter in Equivalents and luckily for us the chemistry is such that 1 Mole = 1 Equivalent. Cheers, Roy. -Original Message- From: cf-metadata-boun...@cgd.ucar.edu [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Steve Emmerson Sent: 08 December 2011 23:58 To: Upendra Dadi Cc: cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] udunits corresponding to Forel-Ule, milliequivalent Upendra, From the perspective of the UDUNITS unit-packages, the unit Forel-Ule is the unit Forel multiplied by the unit Ule -- neither, of which, is known by the UDUNITS or UDUNITS2 packages. I suggest you contact the author. Regards, Steve Emmerson On 12/08/2011 09:05 AM, Upendra Dadi wrote: Hi, I have some data which has Forel-Ule for the units used. Is there a udunits corresponding to this? Also, what should I use for milliequivalent ? Thanks for the help. Upendra ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] udunits corresponding to Forel-Ule, milliequivalent
Thanks all for your replies. That was very helpful. Upendra On 12/9/2011 4:09 AM, Lowry, Roy K. wrote: Hi Upendra, The Forel-Ule is another example where parameter semantics have been off-loaded in the units of measure, such as 'milligrams per gram of dry sediment'. I have been working to eliminate this by moving the semantics into the parameter description to leave a UDUNITS-compatible UoM. In BODC we have an equivalent to a Standard Name of 'Colour of the water body by visual estimation and conversion to a number on the Forel-Ule scale' which has units of dimensionless. This would require a new Standard Name were this approach to be used in CF. I'm guessing you want milliequivalents for total alkalinity data. Previously in CF the standard name 'sea_water_alkalinity_expressed_as_mole_equivalent' has been used with the canonical unit 'Moles per cubic metre', which is a pragmatic solution to your problem that works in the oceanographic domain because alkalinity is the only thing we encounter in Equivalents and luckily for us the chemistry is such that 1 Mole = 1 Equivalent. Cheers, Roy. -Original Message- From: cf-metadata-boun...@cgd.ucar.edu [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Steve Emmerson Sent: 08 December 2011 23:58 To: Upendra Dadi Cc: cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] udunits corresponding to Forel-Ule, milliequivalent Upendra, From the perspective of the UDUNITS unit-packages, the unit Forel-Ule is the unit Forel multiplied by the unit Ule -- neither, of which, is known by the UDUNITS or UDUNITS2 packages. I suggest you contact the author. Regards, Steve Emmerson On 12/08/2011 09:05 AM, Upendra Dadi wrote: Hi, I have some data which has Forel-Ule for the units used. Is there a udunits corresponding to this? Also, what should I use for milliequivalent ? Thanks for the help. Upendra ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] standard name for sea water ph without
Thank you Jonathan and John for your emails. I went through your earlier emails. One of the things that occurred to me is that these discussions that you had are as much a part of the standard as the names themselves. I think it would be great if there is better connection between your email conversation and the standard name tables. Often the short summary given in the standard name table, while useful, is not sufficient to understand what the name stands for. Coming to the problem of coming up with a standard name for pH accurately, I can see the issue here. Though I am still not sure why not all five standard names were included. If there is an analogy between sea water pH and sea water temperature, as mentioned in one of the emails, why not have sea_water_pH just as we have sea_water_temperature? Upendra On 12/8/2011 1:39 PM, John Graybeal wrote: Hi Upendra, The reason the reporting scale is attached to this name is that the fundamental measurement, or property, to which it refers produces numbers that are not comparable to pH derived using other techniques. (They are actually measuring different quantities, not just a different offset/scale value.) From what I (not a scientist!) understand, it is often the case that pH that doesn't mention its scale has been measured in a way that is not an effective indicator of pH in sea water. So it is very important to understand the way the pH was measured, in order that the values be reported compatibly with others. I am not knowledgeable enough to know the right answer to your two questions, but the above may be useful input. John On Dec 8, 2011, at 08:35, Upendra Dadi wrote: Hi All, The standard name table has an entry called sea_water_ph_reported_on_total_scale. I have some data which does not mention the scale used for the measurement of ph. Should there be an another entry which does not mention the scale? Most of the standard names I have seen doesn't mention the scale used|. Is it common to attach within standard name, the scale used for the measurement? Upendra | ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu mailto:CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] new TEOS-10 standard names
Sea_surface_salinity is missing from your list; I don't have time to edit the doc, sorry. This should really have been a trac ticket - that would have eliminated the need for the word document. Cheers - Nan On 12/7/11 7:34 PM, Durack, Paul J. wrote: Thanks for all this work Alison.. For clarity and to ensure that it's easier to capture and finalise these edits I am attaching a word doc with the suggested new standard names, their definitions etc.. I am appending these below as a reminder for those who don't want to download and read the attached *.doc: sea_water_practical_salinity sea_water_cox_salinity sea_water_knudsen_salinity sea_water_reference_salinity sea_water_absolute_salinity sea_water_preformed_salinity sea_water_conservative_temperature sea_water_specific_potential_enthalpy change_over_time_in_sea_water_practical_salinity change_over_time_in_sea_water_absolute_salinity change_over_time_in_sea_water_preformed_salinity change_over_time_in_sea_water_conservative_temperature change_over_time_in_sea_water_specific_potential_enthalpy And update to the following names is also proposed: sea_water_salinity sea_water_temperature If you have any edits to these, please edit the *.doc file and resubmit to the mailing list. Apologies for resorting to this format, however it's been difficult to capture all the comments that have been made, particularly since there is quite a lot of text buried in the definitions for these new names.. Once again, thanks to Alison for your efforts it getting this close to the line.. Cheers, P -Original Message- From: alison.pamm...@stfc.ac.ukalison.pamm...@stfc.ac.uk Date: Wed, 7 Dec 2011 06:18:22 -0800 To: cf-metadata@cgd.ucar.educf-metadata@cgd.ucar.edu, Durack, Paul J.dura...@llnl.gov Cc: trevor.mcdoug...@csiro.autrevor.mcdoug...@csiro.au, sabine.feis...@io-warnemuende.desabine.feis...@io-warnemuende.de, r...@eos.ubc.car...@eos.ubc.ca, b...@noc.soton.ac.uk b...@noc.soton.ac.uk, paul.bar...@csiro.aupaul.bar...@csiro.au, paul.dur...@csiro.aupaul.dur...@csiro.au, susanne.feis...@io-warnemuende.desusanne.feis...@io-warnemuende.de, rainer.feis...@io-warnemuende.derainer.feis...@io-warnemuende.de, steffen.b...@io-warnemuende.desteffen.b...@io-warnemuende.de, guenther.nau...@io-warnemuende.deguenther.nau...@io-warnemuende.de, j.m.greg...@reading.ac.ukj.m.greg...@reading.ac.uk, stephen.griff...@noaa.govstephen.griff...@noaa.gov Subject: Re: [CF-metadata] new TEOS-10 standard names Dear All, Thank you to everyone who has submitted comments about these names. Rather than send lots of separate replies I am using this message to respond to everyone in turn. 1. sea_water_temperature John Graybeal wrote: (b) sea_water_temperature There is agreement to retain the standard name sea_water_temperature as this is useful particularly for observations. It currently has no explanatory text. In response to the discussion I propose to add the following sentence: 'Sea temperature is the in situ (bulk) temperature of the sea water, not the surface or skin temperature.' In the proposed definition, do you mean to say 'Sea water temperature is ...' ? Yes, I agree that is much better. Craig Donlon wrote: Please do not use the word bulk when referring to sst. The correct term is SSTdepth. This was extensively discussed previously The word bulk crept in because I had based the text on the definition of air_temperature. The only significance of the word, I think, is to make the distinction from skin temperature and in the case of sea_water_temperature I don't think it's needed, so I will remove it. Roy Lowry wrote: I have a concern with your exclusion of the surface from the term sea_water_temperature. What Standard Name would you use for the temperature data stream in a CTD profile that extends from the surface to depth? I'm more comfortable with the idea of keeping sea_water_temperature vague so it can include a mixture of surface and within water body measurements, but making the SST terms explicitly exclude temperatures within the water body. Jonathan Gregory wrote: Since this is a very general term, maybe we can leave it vague (and thus sidestep the need to define surfaces). It is the in-situ temperature of sea water. SST is a species of sea_water_temperature. It is analogous to air_temperature. Thanks to both of you for pointing this out - I hadn't intended to exclude surface/near surface values from profiles but I can see how my explanation might have been interpreted to mean that. Following all the comments, I propose that the text for sea_water_temperature should be: ' Sea water temperature is the in situ temperature of the sea water. To specify the depth at which the temperature applies use a vertical coordinate variable or scalar coordinate variable. There are standard names for sea_surface_temperature, sea_surface_skin_temperature, sea_surface_subskin_temperature and sea_surface_foundation_temperature which can be used to describe data
Re: [CF-metadata] standard name for sea water ph without
Dear Upendra Coming to the problem of coming up with a standard name for pH accurately, I can see the issue here. Though I am still not sure why not all five standard names were included. If there is an analogy between sea water pH and sea water temperature, as mentioned in one of the emails, why not have sea_water_pH just as we have sea_water_temperature? I think the reason not all five were added is that only one of them was requested at the time. I believe that was the right decision, because it's generally only when we have a real use-case that the expertise is at hand i.e. the proposer to explain what is required. My understand was that, unlike for sea water temperature, sea water pH would not be meaningful without the scale specified. That is, it's not a matter of technique, but a matter of definition. A better analogy would be that sea_water_temperature and sea_water_salinity are distinct quantities that can't both be described by a generic standard name. I can imagine that if a model had pH, it might possibly need a generic sort, because it might not represent the chemistry properly. However, that hasn't been proposed. Best wishes Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] Proposal for better handling vector quantities in CF
Dear John I prefer the idea that Thomas has put forward of an umbrella, rather than containing the vector/tensor components in one data variable, because * I really don't like the idea of units being mixed within a data variable. I think things with different units must certainly be different quantities and could not be regarded as the same field. You can get away with it if they are all m s-1, for instance, but not so easily if the vertical one is orders of magnitude different from the horizontal, and not at all if the vector is expressed in polar coordinates. * I think it would be very inconvenient, and would break a lot of existing software, if the coordinates were not what they appeared to be, because an offset had to be added. Also, in general, the component fields of a staggered grid do not have the same dimensions, as well as differing in the coordinates. * It avoids the need to define a convention for labelling vector/tensor components. * It is completely backwards-compatible as regards the component fields, which are exactly as before; we're just adding some separate information linking them. This seems neat to me. Best wishes Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] Proposal for better handling vector quantities in CF
On 12/9/2011 11:37 AM, Jonathan Gregory wrote: Dear John I prefer the idea that Thomas has put forward of an umbrella, rather than containing the vector/tensor components in one data variable, because * I really don't like the idea of units being mixed within a data variable. I think things with different units must certainly be different quantities and could not be regarded as the same field. You can get away with it if they are all m s-1, for instance, but not so easily if the vertical one is orders of magnitude different from the horizontal, and not at all if the vector is expressed in polar coordinates. I think the common case is that the vector components have the same unit. One could restrict to that case. * I think it would be very inconvenient, and would break a lot of existing software, if the coordinates were not what they appeared to be, because an offset had to be added. Also, in general, the component fields of a staggered grid do not have the same dimensions, as well as differing in the coordinates. Im not sure what an offset had to be added means. I think the common case of staggered grids could be handled with a convention defining the staggering, rather than seperate dimensions. I pull out the one Rich Signell and I cam up with a long time ago, for its own sake. * It avoids the need to define a convention for labelling vector/tensor components. I think this convention would be about as complex as the one you will need for Thomas' proposal. * It is completely backwards-compatible as regards the component fields, which are exactly as before; we're just adding some separate information linking them. This seems neat to me. I agree thats a strong reason for Thomas' method. OTOH, if we start thinking in terms of the extended model, a Structure (compound type in HDF5 parlance) might be useful. What do you think about starting to think about possible uses of extended data model? Thanks for your thoughts, as always, interesting. John ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] standard name for sea water ph without
Hi Upendra, It comes down to the significance of the difference between parameters according to tha application for which they are used. There ae two temperature scales - IPTS68 and ITS90. However, pragamatically for the period of time when IPTS68 was used the measurement uncertaintyfor sea temperature was significantly greater than the difference between the two scales. Assuming that sea temperature = ITS90 worked in practice (I hope everybody remembered to convert their post-90 high accuracy data to IPTS68 prior to input to the PSS78 algorithms:-)). According to the expert carbonate system chemists, the difference between the pH scales is critical to their science - talk to the guys at CDIAC for more information. Hence the conclusion from the 2009 discussion. Cheers, Roy. From: cf-metadata-boun...@cgd.ucar.edu [cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Upendra Dadi [upendra.d...@noaa.gov] Sent: 09 December 2011 15:58 To: cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] standard name for sea water ph without Thank you Jonathan and John for your emails. I went through your earlier emails. One of the things that occurred to me is that these discussions that you had are as much a part of the standard as the names themselves. I think it would be great if there is better connection between your email conversation and the standard name tables. Often the short summary given in the standard name table, while useful, is not sufficient to understand what the name stands for. Coming to the problem of coming up with a standard name for pH accurately, I can see the issue here. Though I am still not sure why not all five standard names were included. If there is an analogy between sea water pH and sea water temperature, as mentioned in one of the emails, why not have sea_water_pH just as we have sea_water_temperature? Upendra On 12/8/2011 1:39 PM, John Graybeal wrote: Hi Upendra, The reason the reporting scale is attached to this name is that the fundamental measurement, or property, to which it refers produces numbers that are not comparable to pH derived using other techniques. (They are actually measuring different quantities, not just a different offset/scale value.) From what I (not a scientist!) understand, it is often the case that pH that doesn't mention its scale has been measured in a way that is not an effective indicator of pH in sea water. So it is very important to understand the way the pH was measured, in order that the values be reported compatibly with others. I am not knowledgeable enough to know the right answer to your two questions, but the above may be useful input. John On Dec 8, 2011, at 08:35, Upendra Dadi wrote: Hi All, The standard name table has an entry called sea_water_ph_reported_on_total_scale. I have some data which does not mention the scale used for the measurement of ph. Should there be an another entry which does not mention the scale? Most of the standard names I have seen doesn't mention the scale used. Is it common to attach within standard name, the scale used for the measurement? Upendra ___ CF-metadata mailing list CF-metadata@cgd.ucar.edumailto:CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system.___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
