Re: [CF-metadata] standard_name modifiers
Dear Jonathan et al., maybe I am fighting a lost battle here, but let me try to argue once more for a generalized solution, i.e. the addition of anomaly as a standard name modifier. I don't like the idea of adding a new standard name for each new anomaly: i) this seems illogical and new users will ask why is there an anomaly defined for temperature, but nor for precipitation?, ii) past experience has shown that it takes time to get new standard names adopted, and if new use cases come up (as they are bound to be for something as essential as anomalies) it may discourage people to even go for standard names for these variables. Why not try to make the system as systematic as possible? I don't want to argue against a pragmatic approach, but if you decide to change the anomalies from individual standard names to a modifier in three years, the effort might be much larger, the confusion will be greater and other operators with similar problems will come along. So, my suggestion would be to de precate the use of air_pressure_anomaly, air_temperature_anomaly, geopotential_height_anomaly and surface_temperature_anomaly now and introduce anomaly as a modifier. It's only replacing an underescore by a blank anyhow ;-) As we just developed some tools to compute multi-model means and model anomalies for the TFHTAP data sets, I would otherwise have to come up with a list of ~20 new _anomaly standard names. So, besides what I see a rational argument (above), I have a personal reason for arguing so vehemently. Cheers, Martin Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] standard_name modifiers
Hi Martin, ' It's only replacing an underescore by a blank anyhow ;-)' This isn't strictly true. As the semantics infrastructure stands at the moment the deprecation procedure is to label the deprecated Standard Name as an 'alias' with another Standard Name specified as its replacement. I don't know about you, but I would feel a little uneasy about a Standard Names list that has 'surface_temperature_anomaly' aliased to 'surface_temperature'. Cheers, Roy. -Original Message- From: cf-metadata-boun...@cgd.ucar.edu [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Schultz, Martin Sent: 28 February 2011 08:14 To: Jonathan Gregory Cc: cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] standard_name modifiers Dear Jonathan et al., maybe I am fighting a lost battle here, but let me try to argue once more for a generalized solution, i.e. the addition of anomaly as a standard name modifier. I don't like the idea of adding a new standard name for each new anomaly: i) this seems illogical and new users will ask why is there an anomaly defined for temperature, but nor for precipitation?, ii) past experience has shown that it takes time to get new standard names adopted, and if new use cases come up (as they are bound to be for something as essential as anomalies) it may discourage people to even go for standard names for these variables. Why not try to make the system as systematic as possible? I don't want to argue against a pragmatic approach, but if you decide to change the anomalies from individual standard names to a modifier in three years, the effort might be much larger, the confusion will be greater and other operators with similar problems will come along. So, my suggestion would be to de precate the use of air_pressure_anomaly, air_temperature_anomaly, geopotential_height_anomaly and surface_temperature_anomaly now and introduce anomaly as a modifier. It's only replacing an underescore by a blank anyhow ;-) As we just developed some tools to compute multi-model means and model anomalies for the TFHTAP data sets, I would otherwise have to come up with a list of ~20 new _anomaly standard names. So, besides what I see a rational argument (above), I have a personal reason for arguing so vehemently. Cheers, Martin Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ___ 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] standard_name modifiers -- units problem
I agree units should be set to 1 and I am currently in the process of fixing the error in the CF Checker. Regards, Ros. On 27/02/11 17:27, Steven Emmerson wrote: Cristina, I recommend the unit 1 for that use. If the CF checker doesn't like that unit, then it should be fixed, IMO, because that unit is supported by both the US NIST and the BIPM. Regards, Steve Emmerson UDUNITS developer On 2/26/2011 12:30 PM, cristina.tronc...@artov.isac.cnr.it wrote: Dear Roy, Our variable chlorophyll count as is understandable by CF is the number of individual measurements used to determine a chlorophyll value. I do need to know what to put at units attribute for that variable. I undestood by the CF convention 1.4 (appendix C) that I have to put units=1 as the chlorophyll count is a dimensionless variable...but the CF checker found it as an error. I try not to put the Unit attribute ...but again i get an error by che cf chcker...so. my question is: what unit shoudl I set for my chlorophyll count variable? thanks for your help. cristina --- Cristina Tronconi Istituto di Scienze dell'Atmosfera e del Clima - sezione di Roma Consiglio Nazionale delle Ricerche Via Fosso del Cavaliere 100 00133 Roma, Italy Tel: +39 06 49934342 cell: '39 349 1242954 Fax: +39 06 20660291 e-mail: cristina.tronc...@artov.isac.cnr.it ___ 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 -- Rosalyn Hatcher NCAS Computational Modelling Services Dept. of Meteorology, University of Reading, Earley Gate, Reading. RG6 6BB Email: r.s.hatc...@reading.ac.uk Tel: +44 (0) 118 378 6016 ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] standard_name modifiers -- units problem
Dear Rosalyn, thanks so much for your reply and your works that is so important for me. Infact my data are produced within MYOCEAN (european) project and thay are going to test them! so it is important they do not failed the CF checker test. Best regards. cristina p.s. Sorry if sometime I miss some e-mails and I didin't answer to them. This is a very caotic working timeand I'm receiving so many e-mails. Thanks to all the cf-metadata group to their help! Citando Rosalyn Hatcher r.s.hatc...@reading.ac.uk: I agree units should be set to 1 and I am currently in the process of fixing the error in the CF Checker. Regards, Ros. On 27/02/11 17:27, Steven Emmerson wrote: Cristina, I recommend the unit 1 for that use. If the CF checker doesn't like that unit, then it should be fixed, IMO, because that unit is supported by both the US NIST and the BIPM. Regards, Steve Emmerson UDUNITS developer On 2/26/2011 12:30 PM, cristina.tronc...@artov.isac.cnr.it wrote: Dear Roy, Our variable chlorophyll count as is understandable by CF is the number of individual measurements used to determine a chlorophyll value. I do need to know what to put at units attribute for that variable. I undestood by the CF convention 1.4 (appendix C) that I have to put units=1 as the chlorophyll count is a dimensionless variable...but the CF checker found it as an error. I try not to put the Unit attribute ...but again i get an error by che cf chcker...so. my question is: what unit shoudl I set for my chlorophyll count variable? thanks for your help. cristina --- Cristina Tronconi Istituto di Scienze dell'Atmosfera e del Clima - sezione di Roma Consiglio Nazionale delle Ricerche Via Fosso del Cavaliere 100 00133 Roma, Italy Tel: +39 06 49934342 cell: '39 349 1242954 Fax: +39 06 20660291 e-mail: cristina.tronc...@artov.isac.cnr.it ___ 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 -- Rosalyn Hatcher NCAS Computational Modelling Services Dept. of Meteorology, University of Reading, Earley Gate, Reading. RG6 6BB Email: r.s.hatc...@reading.ac.uk Tel: +44 (0) 118 378 6016 --- Cristina Tronconi Istituto di Scienze dell'Atmosfera e del Clima - sezione di Roma Consiglio Nazionale delle Ricerche Via Fosso del Cavaliere 100 00133 Roma, Italy Tel: +39 06 49934342 cell: '39 349 1242954 Fax: +39 06 20660291 e-mail: cristina.tronc...@artov.isac.cnr.it ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] standard_name modifiers
+1 This is a case where clearly the pragmatic approach is to do the systematic approach. Probably can't formally deprecate the terms as Roy points out, but one could put in all of their definitions a pointer to the currently recommended practice. John On Feb 28, 2011, at 00:14, Schultz, Martin wrote: Dear Jonathan et al., maybe I am fighting a lost battle here, but let me try to argue once more for a generalized solution, i.e. the addition of anomaly as a standard name modifier. I don't like the idea of adding a new standard name for each new anomaly: i) this seems illogical and new users will ask why is there an anomaly defined for temperature, but nor for precipitation?, ii) past experience has shown that it takes time to get new standard names adopted, and if new use cases come up (as they are bound to be for something as essential as anomalies) it may discourage people to even go for standard names for these variables. Why not try to make the system as systematic as possible? I don't want to argue against a pragmatic approach, but if you decide to change the anomalies from individual standard names to a modifier in three years, the effort might be much larger, the confusion will be greater and other operators with similar problems will come along. So, my suggestion would be to d e precate the use of air_pressure_anomaly, air_temperature_anomaly, geopotential_height_anomaly and surface_temperature_anomaly now and introduce anomaly as a modifier. It's only replacing an underescore by a blank anyhow ;-) As we just developed some tools to compute multi-model means and model anomalies for the TFHTAP data sets, I would otherwise have to come up with a list of ~20 new _anomaly standard names. So, besides what I see a rational argument (above), I have a personal reason for arguing so vehemently. Cheers, Martin Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata John Graybeal mailto:jgrayb...@ucsd.edu phone: 858-534-2162 Product Manager Ocean Observatories Initiative Cyberinfrastructure Project: http://ci.oceanobservatories.org Marine Metadata Interoperability Project: http://marinemetadata.org ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] standard_name modifiers -- units problem
Dear Rosalyn, I assume the checker will also not complain if the units attribute is simply omitted when the variable is unitless (i.e., either units=1 or the attribute is omitted result in the same behavior by the checker). best regards, Karl On 2/28/11 4:28 AM, cristina.tronc...@artov.isac.cnr.it wrote: Dear Rosalyn, thanks so much for your reply and your works that is so important for me. Infact my data are produced within MYOCEAN (european) project and thay are going to test them! so it is important they do not failed the CF checker test. Best regards. cristina p.s. Sorry if sometime I miss some e-mails and I didin't answer to them. This is a very caotic working timeand I'm receiving so many e-mails. Thanks to all the cf-metadata group to their help! Citando Rosalyn Hatcherr.s.hatc...@reading.ac.uk: I agree units should be set to 1 and I am currently in the process of fixing the error in the CF Checker. Regards, Ros. On 27/02/11 17:27, Steven Emmerson wrote: Cristina, I recommend the unit 1 for that use. If the CF checker doesn't like that unit, then it should be fixed, IMO, because that unit is supported by both the US NIST and the BIPM. Regards, Steve Emmerson UDUNITS developer On 2/26/2011 12:30 PM, cristina.tronc...@artov.isac.cnr.it wrote: Dear Roy, Our variable chlorophyll count as is understandable by CF is the number of individual measurements used to determine a chlorophyll value. I do need to know what to put at units attribute for that variable. I undestood by the CF convention 1.4 (appendix C) that I have to put units=1 as the chlorophyll count is a dimensionless variable...but the CF checker found it as an error. I try not to put the Unit attribute ...but again i get an error by che cf chcker...so. my question is: what unit shoudl I set for my chlorophyll count variable? thanks for your help. cristina --- Cristina Tronconi Istituto di Scienze dell'Atmosfera e del Clima - sezione di Roma Consiglio Nazionale delle Ricerche Via Fosso del Cavaliere 100 00133 Roma, Italy Tel: +39 06 49934342 cell: '39 349 1242954 Fax: +39 06 20660291 e-mail: cristina.tronc...@artov.isac.cnr.it ___ 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 -- Rosalyn Hatcher NCAS Computational Modelling Services Dept. of Meteorology, University of Reading, Earley Gate, Reading. RG6 6BB Email: r.s.hatc...@reading.ac.uk Tel: +44 (0) 118 378 6016 --- Cristina Tronconi Istituto di Scienze dell'Atmosfera e del Clima - sezione di Roma Consiglio Nazionale delle Ricerche Via Fosso del Cavaliere 100 00133 Roma, Italy Tel: +39 06 49934342 cell: '39 349 1242954 Fax: +39 06 20660291 e-mail: cristina.tronc...@artov.isac.cnr.it ___ 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 modifiers
Dear Martin Even 24 such cases wouldn't be really a problem. However, I don't feel strongly about this myself. This is not quite the original use of standard_name modifiers, which is to describe variables containing ancillary quantities. However, it seems to be a reasonable use of the mechanism, since it's a derived quantity. (A combination of quantities would be more difficult to deal with, as we have discussed.) I feel that opinions from others on whether we should make this change would be helpful. Best wishes Jonathan On Mon, Feb 28, 2011 at 09:14:18AM +0100, Schultz, Martin wrote: maybe I am fighting a lost battle here, but let me try to argue once more for a generalized solution, i.e. the addition of anomaly as a standard name modifier. I don't like the idea of adding a new standard name for each new anomaly: i) this seems illogical and new users will ask why is there an anomaly defined for temperature, but nor for precipitation?, ii) past experience has shown that it takes time to get new standard names adopted, and if new use cases come up (as they are bound to be for something as essential as anomalies) it may discourage people to even go for standard names for these variables. Why not try to make the system as systematic as possible? I don't want to argue against a pragmatic approach, but if you decide to change the anomalies from individual standard names to a modifier in three years, the effort might be much larger, the confusion will be greater and other operators with similar problems will come along. So, my suggestion would be to deprecate the use of air_pressure_anomaly, air_temperature_anomaly, geopotential_height_anomaly and surface_temperature_anomaly now and introduce anomaly as a modifier. It's only replacing an underescore by a blank anyhow ;-) As we just developed some tools to compute multi-model means and model anomalies for the TFHTAP data sets, I would otherwise have to come up with a list of ~20 new _anomaly standard names. So, besides what I see a rational argument (above), I have a personal reason for arguing so vehemently. ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] standard_name modifiers -- units problem
Dear Karl, That is correct. If the variable is deemed unitless, then the checker will not flag an error if either units=1 or the units attribute is omitted. If the units attribute is missing, it will, however, produce an information message suggesting that the units attribute is added for completeness. Eg. -- Checking variable: CHL_count -- INFO (3.1): No units attribute set. Please consider adding a units attribute for completeness. I introduced the INFO category of message a while ago, for instances where the checker couldn't be sure of an error (E.g. where an attribute is being used in a non-standard way), to prompt the user to double check that what they've put is actually what they meant. I'll hopefully have a fixed version of the checker available tomorrow for testing. Regards, Ros. On 28/02/11 16:44, Karl Taylor wrote: Dear Rosalyn, I assume the checker will also not complain if the units attribute is simply omitted when the variable is unitless (i.e., either units=1 or the attribute is omitted result in the same behavior by the checker). best regards, Karl On 2/28/11 4:28 AM, cristina.tronc...@artov.isac.cnr.it wrote: Dear Rosalyn, thanks so much for your reply and your works that is so important for me. Infact my data are produced within MYOCEAN (european) project and thay are going to test them! so it is important they do not failed the CF checker test. Best regards. cristina p.s. Sorry if sometime I miss some e-mails and I didin't answer to them. This is a very caotic working timeand I'm receiving so many e-mails. Thanks to all the cf-metadata group to their help! Citando Rosalyn Hatcherr.s.hatc...@reading.ac.uk: I agree units should be set to 1 and I am currently in the process of fixing the error in the CF Checker. Regards, Ros. On 27/02/11 17:27, Steven Emmerson wrote: Cristina, I recommend the unit 1 for that use. If the CF checker doesn't like that unit, then it should be fixed, IMO, because that unit is supported by both the US NIST and the BIPM. Regards, Steve Emmerson UDUNITS developer On 2/26/2011 12:30 PM,cristina.tronc...@artov.isac.cnr.it wrote: Dear Roy, Our variable chlorophyll count as is understandable by CF is the number of individual measurements used to determine a chlorophyll value. I do need to know what to put at units attribute for that variable. I undestood by the CF convention 1.4 (appendix C) that I have to put units=1 as the chlorophyll count is a dimensionless variable...but the CF checker found it as an error. I try not to put the Unit attribute ...but again i get an error by che cf chcker...so. my question is: what unit shoudl I set for my chlorophyll count variable? thanks for your help. cristina --- Cristina Tronconi Istituto di Scienze dell'Atmosfera e del Clima - sezione di Roma Consiglio Nazionale delle Ricerche Via Fosso del Cavaliere 100 00133 Roma, Italy Tel: +39 06 49934342 cell: '39 349 1242954 Fax: +39 06 20660291 e-mail:cristina.tronc...@artov.isac.cnr.it ___ 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 -- Rosalyn Hatcher NCAS Computational Modelling Services Dept. of Meteorology, University of Reading, Earley Gate, Reading. RG6 6BB Email:r.s.hatc...@reading.ac.uk Tel: +44 (0) 118 378 6016 --- Cristina Tronconi Istituto di Scienze dell'Atmosfera e del Clima - sezione di Roma Consiglio Nazionale delle Ricerche Via Fosso del Cavaliere 100 00133 Roma, Italy Tel: +39 06 49934342 cell: '39 349 1242954 Fax: +39 06 20660291 e-mail:cristina.tronc...@artov.isac.cnr.it ___ 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 -- Rosalyn Hatcher NCAS Computational Modelling Services Dept. of Meteorology, University of Reading, Earley Gate, Reading. RG6 6BB Email: r.s.hatc...@reading.ac.uk Tel: +44 (0) 118 378 6016 ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] Proposal for new standard names
Dear Philip and Tomoo Philip's comments provide evidence that sedimentation indeed needs to be clarified. Following these comments, would Tomoo's proposals be better as tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_ due_to_precipitation_of_cloud_liquid_water . tendency_of_mass_fraction_of_stratiform_cloud_condensed_water_in_air_ due_to_precipitation_of_cloud_liquid_water ? 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 new standard names
Dear Jonathan and Philip Cc: Jen, Many thanks for your comments. My understanding of the issue is as follows (please correct me if I'm wrong). The tendencies of cloud liquid (condensed) water represented by the proposed standard names refer to the slow falling process of cloud liquid water. They have typical terminal fall speeds of less than 1 [m/s]. The fallen cloud liquid doesn't always reach the ground ; it often evaporates in the air. There are fast falling processes of cloud liquid water, but they are represented by other existing standard names. For example, (a) tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air _due_to_autoconversion and (b) tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air _due_to_accretion_to_rain both convert the slow-falling cloud liquid to fast-falling rain in GCMs. In this case, it appears to me that we need some distinction on the basis of fall speed. If precipitation implies that something falls to the earth's surface, then the slow falling process of cloud liquid may be represented by other words since it doesn't necessarily reach the surface - does this make sense? Best wishes Tomoo ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
