From christiane.textor at lsce.ipsl.fr Mon Jan 14 07:00:36 2008 From: christiane.textor at lsce.ipsl.fr (Christiane Textor) Date: Mon, 14 Jan 2008 15:00:36 +0100 Subject: [CF-metadata] [Fwd: RE: Air Quality/Chemistry Naming Conventions] Message-ID: <478B6B04.2020304@lsce.ipsl.fr> Dear CFs, Below is an email from Bill Sukloff from the NARSTO Quality Systems Science Center. He is interested in the chemistry and aerosol activities of CF. See is email below for information, this might be an opportunity to follow up on our activities in this area. Best regards, Christiane -------- Original-Nachricht -------- Betreff: RE: Air Quality/Chemistry Naming Conventions Datum: Mon, 14 Jan 2008 08:56:02 -0500 Von: Sukloff,Bill [Ontario] An: Referenzen: <35204.90.46.131.36.1200294573.squirrel at mailhost.lsce.ipsl.fr> Hi Christiane: Thanks for your reply. Over the years we have worked with the NARSTO Quality Systems Science Center (http://cdiac.ornl.gov/programs/NARSTO/) developing a data standard for environmental measurements. One of the issues we tackled was chemical nomenclature. The results of our work can been seen on the page http://cdiac.ornl.gov/programs/NARSTO/epasupersites.html. We are always interested in feedback from others working in similar areas. Please feel free to share this with others in your group. Bill. -----Original Message----- From: Christiane.Textor at lsce.ipsl.fr [mailto:Christiane.Textor at lsce.ipsl.fr] Sent: January 14, 2008 2:10 AM To: Sukloff,Bill [Ontario] Subject: Re: Air Quality/Chemistry Naming Conventions Dear Bill, Thank you for your interest. I would say, this page is "sleeping", but could be woken up if needed. Most of the conceptual discussions for these first names for chemicals and aerosols have been settled, the discussion can be followed at the CF mailing list, see http://www.cgd.ucar.edu/pipermail/cf-metadata/ and search for aerosol/chemistry. Why are you interested? Best regards, Christiane Sukloff,Bill [Ontario] schrieb: > Hello: > I came across your wiki page and found it quite interesting. Is this > wiki still active? > Thanks. > > > Bill Sukloff > Scientific Analysis Developer > Science and Technology Branch > Environment Canada > 4905 Dufferin St. > Toronto, Ont. M3H 5T4 > ph: 416-739-5722 > Fax: 416-739-4281 > -- ====================================================================== Christiane Textor Laboratoire des Sciences du Climat et de l'Environnement Unite Mixte de Recherche CEA-CNRS-UVSQ LSCE/IPSL, CEA Saclay, Orme des Merisiers, Bat. 701, Piece 3b, Point Courrier 129 F-91191 Gif-sur-Yvette Cedex FRANCE mailto: christiane.textor at lsce.ipsl.fr Tel ++33 1 69 08 34 07 Fax ++33 1 69 08 77 16 GEOMON scientific project manager http://www.geomon.eu ====================================================================== -- ====================================================================== Christiane Textor Laboratoire des Sciences du Climat et de l'Environnement Unite Mixte de Recherche CEA-CNRS-UVSQ LSCE/IPSL, CEA Saclay, Orme des Merisiers, Bat. 701, Piece 3b, Point Courrier 129 F-91191 Gif-sur-Yvette Cedex FRANCE mailto: christiane.textor at lsce.ipsl.fr Tel ++33 1 69 08 34 07 Fax ++33 1 69 08 77 16 GEOMON scientific project manager http://www.geomon.eu ====================================================================== From christiane.textor at lsce.ipsl.fr Tue Jan 15 01:38:17 2008 From: christiane.textor at lsce.ipsl.fr (Christiane Textor) Date: Tue, 15 Jan 2008 09:38:17 +0100 Subject: [CF-metadata] various new standard names In-Reply-To: <20071227181352.GA1853@met.reading.ac.uk> References: <20071227181352.GA1853@met.reading.ac.uk> Message-ID: <478C70F9.5060502@lsce.ipsl.fr> Dear Jonathan, Here is my comment on humidity, sorry for the delay. I guess it should be humidity_ratio rather than humidity_mixing_ratio? This would solve the problem. Cheers (a happy new year!), Christiane >> > By analogy with humidity_mixing_ratio, noting that a mass mixing >> ratio > is not quite the same thing as a mass concentration: >> > mass_mixing_ratio_of_ozone_in_air (1) >> >> Yes, but "mass_fraction_of_ozone_in_air" exists and this is the same as >> mass_mixing_ratio > > It's not the same for water. Specific humidity is the ratio of mass of water to > mass of moist air, while humidity mixing ratio is the ratio of mass of water to > mass of dry air. I have been told in the past that the same distinction was > being made for other atmospheric constituents in our radiation scheme, but > looking at web definitions I agree with you that for other consituents MMR is > identical with mass fraction. Now I am puzzled which we actually use (of course > there is hardly any difference numerically) so I will check. From j.m.gregory at reading.ac.uk Tue Jan 15 02:14:32 2008 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Tue, 15 Jan 2008 09:14:32 +0000 Subject: [CF-metadata] various new standard names Message-ID: <20080115091432.GD12214@met.reading.ac.uk> Dear Christiane > I guess it should be humidity_ratio rather than humidity_mixing_ratio? Mixing ratio is a common term for humidity, so we should stick with that, I think. There is a distinction between humidity mixing ratio and specific humidity. However I agree with you about ozone. We don't need a mixing ratio term for ozone, as mass fraction is what is used and we have a name for that. Best wishes Jonathan From heinke.hoeck at zmaw.de Tue Jan 15 03:30:52 2008 From: heinke.hoeck at zmaw.de (Heinke Hoeck) Date: Tue, 15 Jan 2008 11:30:52 +0100 Subject: [CF-metadata] mass_fraction Message-ID: <478C8B5C.5000508@zmaw.de> mass_fraction description: Mass fraction is used in the construction mass_fraction_of_X_in_Y, where X is a material constituent of Y. It means the ratio of the mass of Y to the mass of X (including Y). Please check carefully the occurrence X and Y in the last sentence. Shouldn't it read: 'It means the ratio of the mass of X to the mass of Y (including X).' Best regards Heinke From j.m.gregory at reading.ac.uk Tue Jan 15 04:37:51 2008 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Tue, 15 Jan 2008 11:37:51 +0000 Subject: [CF-metadata] mass_fraction Message-ID: <20080115113751.GA20993@met.reading.ac.uk> > Mass fraction is used in the construction mass_fraction_of_X_in_Y, > where X is a material constituent of Y. It means the ratio of the > mass of Y to the mass of X (including Y). > > Please check carefully the occurrence X and Y in the last sentence. > Shouldn't it read: > 'It means the ratio of the > mass of X to the mass of Y (including X).' Yes, I agree. Jonathan From christiane.textor at lsce.ipsl.fr Tue Jan 15 05:18:33 2008 From: christiane.textor at lsce.ipsl.fr (Christiane Textor) Date: Tue, 15 Jan 2008 13:18:33 +0100 Subject: [CF-metadata] mass_fraction In-Reply-To: <478C8B5C.5000508@zmaw.de> References: <478C8B5C.5000508@zmaw.de> Message-ID: <478CA499.4070501@lsce.ipsl.fr> Bonjour, I have copied this sentence from the CF names list: Mass fraction is used in the construction mass_fraction_of_X_in_Y, where X is a material constituent of Y. It means the ratio of the mass of Y to the mass of X (including Y). And I agree that the last sentence should be It means the ratio of the mass of X to the mass of Y (including X). Best regards, Christiane Heinke Hoeck schrieb: > mass_fraction description: > > Mass fraction is used in the construction mass_fraction_of_X_in_Y, > where X is a material constituent of Y. It means the ratio of the > mass of Y to the mass of X (including Y). > > Please check carefully the occurrence X and Y in the last sentence. > Shouldn't it read: > 'It means the ratio of the > mass of X to the mass of Y (including X).' > > Best regards > Heinke > > > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- ====================================================================== Christiane Textor Laboratoire des Sciences du Climat et de l'Environnement Unite Mixte de Recherche CEA-CNRS-UVSQ LSCE/IPSL, CEA Saclay, Orme des Merisiers, Bat. 701, Piece 3b, Point Courrier 129 F-91191 Gif-sur-Yvette Cedex FRANCE mailto: christiane.textor at lsce.ipsl.fr Tel ++33 1 69 08 34 07 Fax ++33 1 69 08 77 16 GEOMON scientific project manager http://www.geomon.eu ====================================================================== From heinke.hoeck at zmaw.de Wed Jan 16 03:11:26 2008 From: heinke.hoeck at zmaw.de (Heinke Hoeck) Date: Wed, 16 Jan 2008 11:11:26 +0100 Subject: [CF-metadata] statistic indices In-Reply-To: <20071220183439.GA26338@met.reading.ac.uk> References: <20071220183439.GA26338@met.reading.ac.uk> Message-ID: <478DD84E.4010109@zmaw.de> Jonathan Gregory wrote: Dear Jonathan, this is a very good idea. I tried to include a sample of indices in this system and make some changes. I hope that I have used it the right way. I created the cdl with an example of my old proposed statistic indices list and add the cell_methods and standard_names for the rest of this kind of statistic indices. If this works well we could add the rest. > Dear Heinke > > To return to the discussion about thresholds. > > >>>> The percentile is not only a value for example 0 degC. It is not >>>> enough to say the percentile is a threshold with value '90 th' and period >>>> 1961-1990.' It is a field. The percentile depends on lat and lon. >>>> What can we do ? >>>> >>> In the general case, the air_temperature_threshold is simply a given field, and >>> the quantity you want is defined as the fraction of occasions which exceeded >>> this threshold field, which is a function of lat and lon. In that case the >>> air_temperature_threshold would not be given as a coordinate value; some other >>> method would be needed to point to the air_temperature_threshold variable. The >>> description of the statistic itself would be simpler, while the >>> air_temperature_threshold field would describe itself. That would be more >>> convenient, because the field would have its own coordinate variables and so on >>> and these could be used to specify the time-period, the percentile, etc. >>> >>> >> This looks good. Do you want to allow a link to the >> air_temperature_threshold >> file in the header. Is this possible ? >> > > I think that the air_temperature_threshold could be an auxiliary coordinate > variable. That would be consistent with using a scalar coordinate variable for > a constant threshold. For instance > > variables: > float n1(lat,lon); > n1:standard_name="number_of_days_with_air_temperature_above_threshold"; > n1:coordinates="c1 time"; > n1:cell_methods="time: minimum within days time: sum over days" > float c1; > c1:standard_name="air_temperature"; > c1:units="K"; > float n1(lat,lon); n1:standard_name="number_of_days_with_air_temperature_threshold"; n1:coordinates="c1 time"; n1:cell_methods="time: indicator of minimum above threshold within days time: sum over longer period" float c1; c1:standard_name="air_temperature"; c1:units="C"; /* threshold in C */ cell_methods="time: {minimum|maximum} {above|below} threshold within days time: sum over longer period" standard_names= number_of_days_with_air_temperature_threshold number_of_days_with_lwe_thickness_of_precipitation_amount_threshold number_of_days_with_wind_speed_threshold frost_days_index_per_time_period summer_daxs_index_per_time_period ice_days_index_per_time_period tropical_nights_index_per_time_period heavy_precipitation_days_index_per_time_period very_heavy_precipitation_days_index_per_time_period wet_days_index_per_time_period strong_breeze_days_index_per_time_period strong_gale_days_index_per_time_period hurricane_days_index_per_time_period > float n2(c2,lat,lon); > This is a 3-dim field. I don't understand. Do you have an example ? > n2:standard_name="number_of_days_with_air_temperature_above_threshold"; > n2:coordinates="time"; > n2:cell_methods="time: minimum within days time: sum over days" > float c2(c2); > c2:standard_name="air_temperature"; > c2:units="K"; > > float n3(lat,lon); > n3:standard_name="number_of_days_with_air_temperature_above_threshold"; > n3:coordinates="c3 time"; > n3:cell_methods="time: minimum within days time: sum over days" > float c3(lat,lon); > c3:standard_name="air_temperature"; > c3:units="K"; > double time; > time:units="days since 1960-1-1"; > float n3(lat,lon); n3:standard_name="fraction_of_days_with_air_temperature_percentile"; n3:coordinates="c3 time"; /* depends on field c3 and time */ n3:cell_methods="time: daily mean below c3 time: fraction over longer period" /* cell method fraction is not degree Celsius */ float c3(lat,lon); c3:standard_name="air_temperature"; c3:units="K"; c3:cell_methods="time: 5 days centered time: daily mean value: time: 10 th percentile over 1961-1990" double time; time:units="days since 1960-1-1"; cell_methods="time: {daily mean|daily minimum|daily maximum|daily sum} {above|below} [array]: fraction over longer period" cell_methods="time: 5 days centered time: {daily mean|daily minimum|daily maximum|daily sum} value: time: {values between 0 and 100} th percentile over {period i.e.1961-1990} " standard_names=fraction_of_days_with_air_temperature_percentile cold_days_percent_wrt_10th_percentile_of_reference_period warm_nights_percent_wrt_90th_percentile_of_reference_period very_warm_days_percent_wrt_90th_percentile_of_reference_period warm_days_percent_wrt_90th_percentile_of_reference_period cold_nights_percent_wrt_10th_percentile_of_reference_period very_cold_nights_percent_wrt_10th_percentile_of_reference_period > for specifying the number of days with minimum temperature above a single > threshold c1, a number of thresholds c2, or a geographically dependent > threshold c3. c3 could be described by further attributes. It could, for > example, be a data variable with its own scalar time coordinate and its own > cell_methods, describing a climatological mean. > > It would be a requirement of a quantity having the standard name > number_of_days_with_air_temperature_above_threshold that there must be a > coordinate variable, scalar coordinate variable or auxiliary coordinate > variable with standard name air_temperature to provide the threshold. It would > also be stated that a cell_methods entry for "within days" would indicate the > time-processing done on the air temperature before the threshold was > applied. It would be fine to provide a description in the long_name as well, > as you currently do. > > >> I am still waiting for the 'where' proposal. >> > That proposal is on the CF trac system at > http://cf-pcmdi.llnl.gov/trac/ticket/17 > and you are welcome to comment there. > I made a comment. Thank you and Best whishes Heinke > Best wishes > > Jonathan > From heinke.hoeck at zmaw.de Wed Jan 16 03:17:02 2008 From: heinke.hoeck at zmaw.de (Heinke Hoeck) Date: Wed, 16 Jan 2008 11:17:02 +0100 Subject: [CF-metadata] statistic indices In-Reply-To: <20071220183439.GA26338@met.reading.ac.uk> References: <20071220183439.GA26338@met.reading.ac.uk> Message-ID: <478DD99E.8020509@zmaw.de> Dear Jonathan, this is a very good idea. I tried to include a sample of indices in this system and make some changes. I hope that I have used it the right way. I created the cdl with an example of my old proposed statistic indices list and add the cell_methods and standard_names for the rest of this kind of statistic indices. If this works well we could add the rest. > Dear Heinke > > To return to the discussion about thresholds. > > >>>> The percentile is not only a value for example 0 degC. It is not >>>> enough to say the percentile is a threshold with value '90 th' and period >>>> 1961-1990.' It is a field. The percentile depends on lat and lon. >>>> What can we do ? >>>> >>> In the general case, the air_temperature_threshold is simply a given field, and >>> the quantity you want is defined as the fraction of occasions which exceeded >>> this threshold field, which is a function of lat and lon. In that case the >>> air_temperature_threshold would not be given as a coordinate value; some other >>> method would be needed to point to the air_temperature_threshold variable. The >>> description of the statistic itself would be simpler, while the >>> air_temperature_threshold field would describe itself. That would be more >>> convenient, because the field would have its own coordinate variables and so on >>> and these could be used to specify the time-period, the percentile, etc. >>> >>> >> This looks good. Do you want to allow a link to the >> air_temperature_threshold >> file in the header. Is this possible ? >> > > I think that the air_temperature_threshold could be an auxiliary coordinate > variable. That would be consistent with using a scalar coordinate variable for > a constant threshold. For instance > > variables: > float n1(lat,lon); > n1:standard_name="number_of_days_with_air_temperature_above_threshold"; > n1:coordinates="c1 time"; > n1:cell_methods="time: minimum within days time: sum over days" > float c1; > c1:standard_name="air_temperature"; > c1:units="K"; > float n1(lat,lon); n1:standard_name="number_of_days_with_air_temperature_threshold"; n1:coordinates="c1 time"; n1:cell_methods="time: indicator of minimum above threshold within days time: sum over longer period" float c1; c1:standard_name="air_temperature"; c1:units="C"; /* threshold in C */ cell_methods="time: {minimum|maximum} {above|below} threshold within days time: sum over longer period" standard_names= number_of_days_with_air_temperature_threshold number_of_days_with_lwe_thickness_of_precipitation_amount_threshold number_of_days_with_wind_speed_threshold frost_days_index_per_time_period summer_daxs_index_per_time_period ice_days_index_per_time_period tropical_nights_index_per_time_period heavy_precipitation_days_index_per_time_period very_heavy_precipitation_days_index_per_time_period wet_days_index_per_time_period strong_breeze_days_index_per_time_period strong_gale_days_index_per_time_period hurricane_days_index_per_time_period > float n2(c2,lat,lon); > This is a 3-dim field. I don't understand. Do you have an example ? > n2:standard_name="number_of_days_with_air_temperature_above_threshold"; > n2:coordinates="time"; > n2:cell_methods="time: minimum within days time: sum over days" > float c2(c2); > c2:standard_name="air_temperature"; > c2:units="K"; > > float n3(lat,lon); > n3:standard_name="number_of_days_with_air_temperature_above_threshold"; > n3:coordinates="c3 time"; > n3:cell_methods="time: minimum within days time: sum over days" > float c3(lat,lon); > c3:standard_name="air_temperature"; > c3:units="K"; > double time; > time:units="days since 1960-1-1"; > float n3(lat,lon); n3:standard_name="fraction_of_days_with_air_temperature_percentile"; n3:coordinates="c3 time"; /* depends on field c3 and time */ n3:cell_methods="time: daily mean below c3 time: fraction over longer period" /* cell method fraction is not degree Celsius */ float c3(lat,lon); c3:standard_name="air_temperature"; c3:units="K"; c3:cell_methods="time: 5 days centered time: daily mean value: time: 10 th percentile over 1961-1990" double time; time:units="days since 1960-1-1"; cell_methods="time: {daily mean|daily minimum|daily maximum|daily sum} {above|below} [array]: fraction over longer period" cell_methods="time: 5 days centered time: {daily mean|daily minimum|daily maximum|daily sum} value: time: {values between 0 and 100} th percentile over {period i.e.1961-1990} " standard_names=fraction_of_days_with_air_temperature_percentile cold_days_percent_wrt_10th_percentile_of_reference_period warm_nights_percent_wrt_90th_percentile_of_reference_period very_warm_days_percent_wrt_90th_percentile_of_reference_period warm_days_percent_wrt_90th_percentile_of_reference_period cold_nights_percent_wrt_10th_percentile_of_reference_period very_cold_nights_percent_wrt_10th_percentile_of_reference_period > for specifying the number of days with minimum temperature above a single > threshold c1, a number of thresholds c2, or a geographically dependent > threshold c3. c3 could be described by further attributes. It could, for > example, be a data variable with its own scalar time coordinate and its own > cell_methods, describing a climatological mean. > > It would be a requirement of a quantity having the standard name > number_of_days_with_air_temperature_above_threshold that there must be a > coordinate variable, scalar coordinate variable or auxiliary coordinate > variable with standard name air_temperature to provide the threshold. It would > also be stated that a cell_methods entry for "within days" would indicate the > time-processing done on the air temperature before the threshold was > applied. It would be fine to provide a description in the long_name as well, > as you currently do. > > >> I am still waiting for the 'where' proposal. >> > That proposal is on the CF trac system at > http://cf-pcmdi.llnl.gov/trac/ticket/17 > and you are welcome to comment there. > I made a comment. Thank you and best wishes Heinke > Best wishes > > Jonathan > From m.n.juckes at rl.ac.uk Mon Jan 21 02:21:12 2008 From: m.n.juckes at rl.ac.uk (Martin Juckes) Date: Mon, 21 Jan 2008 09:21:12 +0000 Subject: [CF-metadata] Fwd: standard name proposal for CCMVal Message-ID: <200801210921.13663.m.n.juckes@rl.ac.uk> Attached is a list of around 150 proposed standard names needed for the CCMVal project. CCMVal is the Chemistry Climate Model Validation exercise (http://www.pa.op.dlr.de/CCMVal/). The coupled chemistry-climate model data for the validation will be hosted by BADC, and the intention is that it should be CF compliant netcdf. In order to achieve this we need standard names fro around 150 quantities not yet covered in the standard name table. The proposed new names are listed in the attached word document, split into 4 tables. There has been some preliminary discussion, with the most controversy caused by the `age_of_stratospheric_air'. A couple of key quotes from the discussion between Darryn Waugh and Jonathan Gregory are given below. No real agreement was reached, so the decision is up to other members of the list. QUOTE from Darryn Waugh The age of stratospheric air is the time since last contact with the troposphere (just as age in the ocean is time since contact with atmosphere). There is a distribution of ages (i.e. not a single travel time) but we are concerned here with the mean of the times, hence the need for "mean age". It is not a residence time, and the use of "mean" is crucial. The term "mean age" is extensively used in stratospheric, oceanic, and groundwater communities (with "of water" added for latter two), so I think this counts as interdisciplinary, and again I am lost at the resistance to it. END QUOTE QUOTE from Jonathan Gregory I agree that "mean" is needed, but I think that in CF metadata it belongs in the cell_methods rather than in the standard_name. END QUOTE There was also substantial discussion between Jonathan and myself about the use of "_burden" to indicate a whole atmosphere integral. Jonathan favoured something of the form "area_integral_of......_content", but conceded that the area integral of a vertical integral was not the most natural of formulations. The term "burden" is widely used in the scientific literature with the meaning intended here. The original list from the CCMVal community included a number of annual loss variables, but these have been replaced with tendencies, the intention being to use the cell_methods attributes to express annual losses as summed tendencies. The gravity wave terms also caused some comment. E.g. upward_flux_of_eastward_momentum_due_to_nonorographic_eastward_gravity_waves eastward_momentum indicates the component of the momentum which is being transported, eastward_gravity_waves indicates the class of gravity waves included, with eastward referring to the phase speed of the waves. There is thus no obvious redundancy here, though there is a tendency in the specialist community to do away with one "eastward" when referring to this quantity, since gravity waves with eastward phase speeds only carry eastward momentum. I have submitted the longer version, as this level of knowledge should probably not be expected of standad name interpreters. Names such as the "dynamic_tropopause_potential_temperature" introduce the problem that the precise definition of the dynamic tropopause is not fixed. The intention is to use an attribute in the file to give a reasonably precise definition. The method will be used for "..middle_atmosphere_ ..._burden", which requires a specification of the definition used for "middle atmosphere". After discussion with Jonathan it was decided, however, that there was no need to get the method for doing this into CF at this time. sincerely, Martin Juckes ------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: cf-proposal_CCMVal_final_v2.pdf Type: application/pdf Size: 63641 bytes Desc: not available Url : http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20080121/6f750313/attachment-0001.pdf From cameronsmith1 at llnl.gov Wed Jan 23 18:47:44 2008 From: cameronsmith1 at llnl.gov (Philip J. Cameronsmith1) Date: Wed, 23 Jan 2008 17:47:44 -0800 (PST) Subject: [CF-metadata] Fwd: standard name proposal for CCMVal In-Reply-To: <200801210921.13663.m.n.juckes@rl.ac.uk> References: <200801210921.13663.m.n.juckes@rl.ac.uk> Message-ID: Hi Martin, et al., Overall I see no major problems :-) A few minor thoughts: In part 1: If chemical formulas are to be used in some documentation then I think they need to be capitalized appropriately to avoid possible ambiguity: eg, OCS/OCs, and HF/Hf. In part 2: Do you mean 'moles' rather than 'molecules' at the end of the preamble? In part 3: The first quantity (tendency_of_nitrous_oxide_mole_burden) seems to be missing a region qualification. How do you define 'middle atmosphere'? Is the middle world/lowermost stratosphere included? Also, how should a model report its data when it only has a partial stratosphere (eg a model top at 3 mbar)? Good luck with CCMVal :-), Philip On Mon, 21 Jan 2008, Martin Juckes wrote: > Attached is a list of around 150 proposed standard names needed for the CCMVal > project. > > CCMVal is the Chemistry Climate Model Validation exercise > (http://www.pa.op.dlr.de/CCMVal/). > > The coupled chemistry-climate model data for the validation will be hosted by > BADC, and the intention is that it should be CF compliant netcdf. In order to > achieve this we need standard names fro around 150 quantities not yet covered > in the standard name table. The proposed new names are listed in the attached > word document, split into 4 tables. > > There has been some preliminary discussion, with the most controversy caused > by the `age_of_stratospheric_air'. > > A couple of key quotes from the discussion between Darryn Waugh and Jonathan > Gregory are given below. No real agreement was reached, so the decision is up > to other members of the list. > > QUOTE from Darryn Waugh > The age of stratospheric air is the time since last contact with the > troposphere (just as age in the ocean is time since contact with atmosphere). > There is a distribution of ages (i.e. not a single travel time) but we are > concerned here with the mean of the times, hence the need for "mean age". > It is not a residence time, and the use of "mean" is crucial. > > The term "mean age" is extensively used in stratospheric, oceanic, and > groundwater communities (with "of water" added for latter two), so I think > this counts as interdisciplinary, and again I am lost at the resistance to > it. > END QUOTE > QUOTE from Jonathan Gregory > I agree that "mean" is needed, but I think that in CF metadata it belongs in > the cell_methods rather than in the standard_name. > END QUOTE > > There was also substantial discussion between Jonathan and myself about the > use of "_burden" to indicate a whole atmosphere integral. Jonathan favoured > something of the form "area_integral_of......_content", but conceded that the > area integral of a vertical integral was not the most natural of > formulations. The term "burden" is widely used in the scientific literature > with the meaning intended here. > > The original list from the CCMVal community included a number of annual loss > variables, but these have been replaced with tendencies, the intention being > to use the cell_methods attributes to express annual losses as summed > tendencies. > > The gravity wave terms also caused some comment. E.g. > upward_flux_of_eastward_momentum_due_to_nonorographic_eastward_gravity_waves > > eastward_momentum indicates the component of the momentum which is being > transported, eastward_gravity_waves indicates the class of gravity waves > included, with eastward referring to the phase speed of the waves. There is > thus no obvious redundancy here, though there is a tendency in the specialist > community to do away with one "eastward" when referring to this quantity, > since gravity waves with eastward phase speeds only carry eastward momentum. > I have submitted the longer version, as this level of knowledge should > probably not be expected of standad name interpreters. > > Names such as the "dynamic_tropopause_potential_temperature" introduce the > problem that the precise definition of the dynamic tropopause is not fixed. > The intention is to use an attribute in the file to give a reasonably precise > definition. The method will be used for "..middle_atmosphere_ ..._burden", > which requires a specification of the definition used for "middle atmosphere". > After discussion with Jonathan it was decided, however, that there was no need > to get the method for doing this into CF at this time. > > sincerely, > Martin Juckes > > > ------------------------------------------------------- > ------------------------------------------------------------------------ Dr Philip Cameron-Smith Energy & Environment Directorate pjc at llnl.gov Lawrence Livermore National Laboratory +1 925 4236634 7000 East Avenue, Livermore, CA94550, USA ------------------------------------------------------------------------ From Christiane.Textor at lsce.ipsl.fr Fri Jan 25 02:30:05 2008 From: Christiane.Textor at lsce.ipsl.fr (Christiane.Textor at lsce.ipsl.fr) Date: Fri, 25 Jan 2008 10:30:05 +0100 (CET) Subject: [CF-metadata] Fwd: standard name proposal for CCMVal In-Reply-To: <200801210921.13663.m.n.juckes@rl.ac.uk> References: <200801210921.13663.m.n.juckes@rl.ac.uk> Message-ID: <1235.81.67.54.182.1201253405.squirrel@mailhost.lsce.ipsl.fr> Dear all, Here are a few comments to the new list of names. - I would assume that all the CFC names must be spelled out according to the IUPAC nomenclature, even if the first is better known in the community. This was at least necessary done for e.g. PCB used in HTAP that is named hexachlorobiphenyl. See links at http://wiki.esipfed.org/index.php/Air_Quality/Chemistry_Naming_Resources - 'burden' is to my knowledge not a possible CF standard name syntax. It had been agreed on that 'content' is the word to be used for vertical column integrals. In addition, the sequence is mixed in the CCMVAL proposal when compared to existing names. atmosphere_X_mole_burden should be atmosphere_mole_content_of_X. tendency_of_X_mole_burden should be tendency_of_atmosphere_X_content_due_to_process? This structure would be consistent with e.g. tendency_of_atmosphere_mass_content_of_ozone_due_to_dry_deposition that has been recently defined for CF. Best regards, Christiane Martin Juckes schrieb: > > Attached is a list of around 150 proposed standard names needed for the CCMVal > project. > > CCMVal is the Chemistry Climate Model Validation exercise > (http://www.pa.op.dlr.de/CCMVal/). > > The coupled chemistry-climate model data for the validation will be hosted by > BADC, and the intention is that it should be CF compliant netcdf. In order to > achieve this we need standard names fro around 150 quantities not yet covered > in the standard name table. The proposed new names are listed in the attached > word document, split into 4 tables. > > There has been some preliminary discussion, with the most controversy caused > by the `age_of_stratospheric_air'. > > A couple of key quotes from the discussion between Darryn Waugh and Jonathan > Gregory are given below. No real agreement was reached, so the decision is up > to other members of the list. > > QUOTE from Darryn Waugh > The age of stratospheric air is the time since last contact with the troposphere (just as age in the ocean is time since contact with atmosphere). > There is a distribution of ages (i.e. not a single travel time) but we are > concerned here with the mean of the times, hence the need for "mean age". > It is not a residence time, and the use of "mean" is crucial. > > The term "mean age" is extensively used in stratospheric, oceanic, and groundwater communities (with "of water" added for latter two), so I think > this counts as interdisciplinary, and again I am lost at the resistance to > it. > END QUOTE > QUOTE from Jonathan Gregory > I agree that "mean" is needed, but I think that in CF metadata it belongs in > the cell_methods rather than in the standard_name. > END QUOTE > > There was also substantial discussion between Jonathan and myself about the > use of "_burden" to indicate a whole atmosphere integral. Jonathan favoured > something of the form "area_integral_of......_content", but conceded that the > area integral of a vertical integral was not the most natural of formulations. The term "burden" is widely used in the scientific literature > with the meaning intended here. > > The original list from the CCMVal community included a number of annual loss > variables, but these have been replaced with tendencies, the intention being > to use the cell_methods attributes to express annual losses as summed tendencies. > > The gravity wave terms also caused some comment. E.g. > upward_flux_of_eastward_momentum_due_to_nonorographic_eastward_gravity_waves > > eastward_momentum indicates the component of the momentum which is being > transported, eastward_gravity_waves indicates the class of gravity waves > included, with eastward referring to the phase speed of the waves. There is > thus no obvious redundancy here, though there is a tendency in the specialist > community to do away with one "eastward" when referring to this quantity, > since gravity waves with eastward phase speeds only carry eastward momentum. > I have submitted the longer version, as this level of knowledge should probably not be expected of standad name interpreters. > > Names such as the "dynamic_tropopause_potential_temperature" introduce the > problem that the precise definition of the dynamic tropopause is not fixed. > The intention is to use an attribute in the file to give a reasonably precise > definition. The method will be used for "..middle_atmosphere_ ..._burden", > which requires a specification of the definition used for "middle atmosphere". > After discussion with Jonathan it was decided, however, that there was no need > to get the method for doing this into CF at this time. > > sincerely, > Martin Juckes > > > ------------------------------------------------------- > > > ------------------------------------------------------------------------ > > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- ====================================================================== Christiane Textor Laboratoire des Sciences du Climat et de l'Environnement Unite Mixte de Recherche CEA-CNRS-UVSQ LSCE/IPSL, CEA Saclay, Orme des Merisiers, Bat. 701, Piece 3b, Point Courrier 129 F-91191 Gif-sur-Yvette Cedex FRANCE mailto: christiane.textor at lsce.ipsl.fr Tel ++33 1 69 08 34 07 Fax ++33 1 69 08 77 16 GEOMON scientific project manager http://www.geomon.eu ====================================================================== From m.n.juckes at rl.ac.uk Fri Jan 25 02:49:58 2008 From: m.n.juckes at rl.ac.uk (Martin Juckes) Date: Fri, 25 Jan 2008 09:49:58 +0000 Subject: [CF-metadata] Fwd: standard name proposal for CCMVal In-Reply-To: References: <200801210921.13663.m.n.juckes@rl.ac.uk> Message-ID: <200801250950.00097.m.n.juckes@rl.ac.uk> Thanks for those comments. > > In part 1: If chemical formulas are to be used in some documentation > then I think they need to be capitalized appropriately to avoid possible > ambiguity: eg, OCS/OCs, and HF/Hf. > OK, we should improve that. > In part 2: Do you mean 'moles' rather than 'molecules' at the end of > the preamble? > Yes, I'll correct that. > In part 3: The first quantity (tendency_of_nitrous_oxide_mole_burden) > seems to be missing a region qualification. > yes, it should be tendency_of_atmosphere_nitrous_oxide_mole_burden > How do you define 'middle atmosphere'? Is the middle world/lowermost > stratosphere included? > There is an issue here, also in the definition of `tropopause'. Our intention is to have a human readable definition included in the global attributes of the file. It would be good to have a broader agreement on how to do this, but that may take longer than the CCMVal project. > Also, how should a model report its data when it only has a partial > stratosphere (eg a model top at 3 mbar)? > This problem is would also have to be addressed with existing `_content' standard names, so I imagine any resolution found there would apply to `_burden' and partial contents and burdens. sincerely, Martin Juckes From Christiane.Textor at lsce.ipsl.fr Fri Jan 25 03:17:23 2008 From: Christiane.Textor at lsce.ipsl.fr (Christiane.Textor at lsce.ipsl.fr) Date: Fri, 25 Jan 2008 11:17:23 +0100 (CET) Subject: [CF-metadata] [Fwd: Re: Fwd: standard name proposal for CCMVal] Message-ID: <1313.81.67.54.182.1201256243.squirrel@mailhost.lsce.ipsl.fr> forwarded for information ------------------------ Urspr?ngliche Nachricht ------------------------ Betreff: Re: [CF-metadata] Fwd: standard name proposal for CCMVal Von: "Martin Juckes" Datum: Fr, 25.01.2008, 11:01 An: christiane.textor at lsce.ipsl.fr -------------------------------------------------------------------------- Thanks for the comments. > - I would assume that all the CFC names must be spelled out according to > the IUPAC nomenclature, even if the first is better known in the > community. This was at least necessary done for e.g. PCB used in HTAP that > is named hexachlorobiphenyl. See links at > http://wiki.esipfed.org/index.php/Air_Quality/Chemistry_Naming_Resources > We have used names adopted by the WMO/UNEP Scientific Assessment of Ozone Depletion. As you say, IUPAC would be an alternative. Consider: mole_fraction_of_cfc113_in_air The IUPAC based version would, I think, be either: mole_fraction_of_1,1,2-trichlorotrifluoroethane_in_air Or: mole_fraction_of_112trichlorotrifluoroethane_in_air The second may lead to possible ambiguities by leaving out the IUPAC punctuation. The first may upset software by including punctuation in the name. My preference is to stay with cfc113, but if there is a general preference for another formulaton we can change it. > - 'burden' is to my knowledge not a possible CF standard name syntax. It > had been agreed on that 'content' is the word to be used for vertical > column integrals. In addition, the sequence is mixed in the CCMVAL > proposal when compared to existing names. > > atmosphere_X_mole_burden should be atmosphere_mole_content_of_X. > > tendency_of_X_mole_burden should be > tendency_of_atmosphere_X_content_due_to_process? > > This structure would be consistent with e.g. > tendency_of_atmosphere_mass_content_of_ozone_due_to_dry_deposition that > has been recently defined for CF. > Whereas `_content' indicates a column integral, we are suggesting `_burden' to indicate a global integral. sincerely, Martin Juckes From Christiane.Textor at lsce.ipsl.fr Fri Jan 25 03:17:37 2008 From: Christiane.Textor at lsce.ipsl.fr (Christiane.Textor at lsce.ipsl.fr) Date: Fri, 25 Jan 2008 11:17:37 +0100 (CET) Subject: [CF-metadata] Fwd: standard name proposal for CCMVal In-Reply-To: <200801251001.53165.m.n.juckes@rl.ac.uk> References: <200801210921.13663.m.n.juckes@rl.ac.uk> <1235.81.67.54.182.1201253405.squirrel@mailhost.lsce.ipsl.fr> <200801251001.53165.m.n.juckes@rl.ac.uk> Message-ID: <1318.81.67.54.182.1201256257.squirrel@mailhost.lsce.ipsl.fr> Hello again, To persue the discussion, I directly comment on your statements below: "As you say, IUPAC would be an alternative." I agree that the short names are much more convenient, but was told that IUPAC nomenclature is obligatory in CF. If ambiguities arise, this should be generally be clarified, but I do not see the difficulty when omitting the punctuation, as the position 112 does not exist in ethane ( in mole_fraction_of_112trichlorotrifluoroethane_in_air) "we are suggesting `_burden' to > indicate a global integral" I am sorry, I realize that I did not read your previous emails carefully enough. But my comment shows that the use of burden is ambigous, as it is also used in the community for the column integral. I would suggest to call it global_integral if this is what you want. Best regards, Christiane From j.m.gregory at reading.ac.uk Fri Jan 25 04:36:03 2008 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Fri, 25 Jan 2008 11:36:03 +0000 Subject: [CF-metadata] Fwd: standard name proposal for CCMVal Message-ID: <20080125113602.GE27133@met.reading.ac.uk> Dear Christiane and Martin > "As you say, IUPAC would be an alternative." > I agree that the short names are much more convenient, but was told that > IUPAC nomenclature is obligatory in CF. I don't think we have decided IUPAC is obligatory. I did ask Christiane whether IUPAC could be used during early discussions, and it turned out that IUPAC names were generally OK. But we also have to be pragmatic, as when we followed Christiane's proposal to give names to aerosol size classes. There are certainly advantages in using IUPAC names: they are unambiguous and an existing standard. However names like CFC11 could be accepted if the IUPAC name were given in the definition, I should think, if those names are always preferred to the IUPAC ones. Best wishes Jonathan From m.n.juckes at rl.ac.uk Fri Jan 25 04:30:54 2008 From: m.n.juckes at rl.ac.uk (Martin Juckes) Date: Fri, 25 Jan 2008 11:30:54 +0000 Subject: [CF-metadata] Fwd: standard name proposal for CCMVal In-Reply-To: <1318.81.67.54.182.1201256257.squirrel@mailhost.lsce.ipsl.fr> References: <200801210921.13663.m.n.juckes@rl.ac.uk> <200801251001.53165.m.n.juckes@rl.ac.uk> <1318.81.67.54.182.1201256257.squirrel@mailhost.lsce.ipsl.fr> Message-ID: <200801251130.55104.m.n.juckes@rl.ac.uk> On Friday 25 January 2008 10:17, Christiane.Textor at lsce.ipsl.fr wrote: > Hello again, > > To persue the discussion, I directly comment on your statements below: > > "As you say, IUPAC would be an alternative." > I agree that the short names are much more convenient, but was told that > IUPAC nomenclature is obligatory in CF. If ambiguities arise, this should > be generally be clarified, but I do not see the difficulty when omitting > the punctuation, as the position 112 does not exist in ethane ( in > mole_fraction_of_112trichlorotrifluoroethane_in_air) > > If IUPAC is compulsory we will of course follow it. I would suggest, however, that something along the lines of `IUPAC is compulsory' should be placed in the CF conventions document. > "we are suggesting `_burden' to > indicate a global integral" > I am sorry, I realize that I did not read your previous emails carefully > enough. But my comment shows that the use of burden is ambigous, as it is > also used in the community for the column integral. I would suggest to > call it global_integral if this is what you want. > If approved, it should be clear to users that `_content' and `_burden' are related but different. `_content' is certainly not unambiguous in itself, it only becomes unambiguous by being part of the convention. My feeling is that the two concepts, the existing `_content' and the proposed `_burden' are sufficiently close that there is significant benefit in keeping to the same name structure, rather than introducing '...integral..'. I was not following the discussion when `_content' was adopted, but it appears that it has been settled that it is appropiate to use this structure rather than `column_integral', which would be the obvious analogue of `global_integral'. Hence, in order to have a consistent syntax within CF I'd prefer to stick with '_burden', cheers, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20080125/04608802/attachment.html From Christiane.Textor at lsce.ipsl.fr Fri Jan 25 06:05:39 2008 From: Christiane.Textor at lsce.ipsl.fr (Christiane.Textor at lsce.ipsl.fr) Date: Fri, 25 Jan 2008 14:05:39 +0100 (CET) Subject: [CF-metadata] Fwd: standard name proposal for CCMVal In-Reply-To: <20080125113602.GE27133@met.reading.ac.uk> References: <20080125113602.GE27133@met.reading.ac.uk> Message-ID: <1519.81.67.54.182.1201266339.squirrel@mailhost.lsce.ipsl.fr> Dear Jonathan, Yes, we did not finally decide on the IUPAC nomenclature, but it seems to me that we agreed that they should be used in principle. Therefore the long names are used instead of the more convenient ones for HTAP: PCB-153 HEXACHLOROBIPHENYL (without the positions of the chloratoms...) a-HCH alpha-Hexachlorocyclohexane If I had misinterpreted the IUPAC issue, then the shorter names should be included for the two existing compounds as well (especially for the first, which is not exact as it is). Regards, Christiane > Dear Christiane and Martin > >> "As you say, IUPAC would be an alternative." >> I agree that the short names are much more convenient, but was told that >> IUPAC nomenclature is obligatory in CF. > > I don't think we have decided IUPAC is obligatory. I did ask Christiane > whether > IUPAC could be used during early discussions, and it turned out that IUPAC > names were generally OK. But we also have to be pragmatic, as when we > followed Christiane's proposal to give names to aerosol size classes. > There > are certainly advantages in using IUPAC names: they are unambiguous and an > existing standard. However names like CFC11 could be accepted if the IUPAC > name were given in the definition, I should think, if those names are > always > preferred to the IUPAC ones. > > Best wishes > > Jonathan > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > From j.m.gregory at reading.ac.uk Fri Jan 25 06:13:35 2008 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Fri, 25 Jan 2008 13:13:35 +0000 Subject: [CF-metadata] standard name proposal for CCMVal Message-ID: <20080125131335.GA1818@met.reading.ac.uk> Dear Christiane > Yes, we did not finally decide on the IUPAC nomenclature, but it seems to > me that we agreed that they should be used in principle. Therefore the > long names are used instead of the more convenient ones for HTAP: > > PCB-153 HEXACHLOROBIPHENYL (without the positions of the chloratoms...) > a-HCH alpha-Hexachlorocyclohexane Good point. I think the IUPAC names are preferable in principle because they are standard, and I don't see why you shouldn't include the position of the chlorine atoms in the standard name. Since you adopted IUPAC names, what has been the experience of the HTAP community with using your standard names? Cheers Jonathan From m.n.juckes at rl.ac.uk Fri Jan 25 10:35:44 2008 From: m.n.juckes at rl.ac.uk (Martin Juckes) Date: Fri, 25 Jan 2008 17:35:44 +0000 Subject: [CF-metadata] CF-metadata Digest, Vol 58, Issue 4: CCMVAL request In-Reply-To: References: Message-ID: <200801251735.45498.m.n.juckes@rl.ac.uk> We would certainly be happy to include IUPAC names in the definitions. I think there is a strong case to be made that names like CFC11 are common usage and so should be preferred. They are also an accepted standard, though not as comprehensive as the IUPAC standard. cheers, Martin PS: I'll be away next week, so will not be able to respond to further comments until returning on Feb. 5th. On Friday 25 January 2008 12:16, cf-metadata-request at cgd.ucar.edu wrote: > Dear Christiane and Martin > > > "As you say, IUPAC would be an alternative." > > I agree that the short names are much more convenient, but was told that > > IUPAC nomenclature is obligatory in CF. > > I don't think we have decided IUPAC is obligatory. I did ask Christiane whether > IUPAC could be used during early discussions, and it turned out that IUPAC > names were generally OK. But we also have to be pragmatic, as when we > followed Christiane's proposal to give names to aerosol size classes. There > are certainly advantages in using IUPAC names: they are unambiguous and an > existing standard. However names like CFC11 could be accepted if the IUPAC > name were given in the definition, I should think, if those names are always > preferred to the IUPAC ones. > > Best wishes > > Jonathan > From taylor13 at llnl.gov Fri Jan 25 10:37:27 2008 From: taylor13 at llnl.gov (Karl Taylor) Date: Fri, 25 Jan 2008 09:37:27 -0800 Subject: [CF-metadata] Fwd: standard name proposal for CCMVal In-Reply-To: <200801251130.55104.m.n.juckes@rl.ac.uk> References: <200801210921.13663.m.n.juckes@rl.ac.uk> <200801251001.53165.m.n.juckes@rl.ac.uk> <1318.81.67.54.182.1201256257.squirrel@mailhost.lsce.ipsl.fr> <200801251130.55104.m.n.juckes@rl.ac.uk> Message-ID: <479A1E57.5090800@llnl.gov> Martin Juckes wrote: Dear Martin, If "burden" is simply the global integral of "content", then I think there is no need for it. The standard name allows us to distinguish among different quantities we want to measure, and if an integral, average, or standard deviation of the quantity is computed, then that is normally indicated in the cell_methods attribute. [I'm not absolutely positive about the following, but I think I've got it right.] Normally you would simply define scalar dimensions for longitude and latitude and indicae the range of values (in your case the global domain) in a cell_bounds attribute. Alternatively, in the case of longitude and latitude for the global domain, As I understand it, the bounds attribute is not required but implied as described in the paragraph at the end of http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.1/cf-conventions.html#cell-methods I would appreciate Jonathan or someone confirming the above. It is true that we have adopted special standard names to indicate vertically integrated quantities ("content"), and so one could argue why not also adopt a special name ("burden") to integrate global amounts? I don't have a good answer, but my preference would be to avoid a new standard name for the integral of a quantity defined by another standard name unless we can come up with a compelling argument against this. Best regards, Karl > > "we are suggesting `_burden' to > indicate a global integral" > > > I am sorry, I realize that I did not read your previous emails carefully > > > enough. But my comment shows that the use of burden is ambigous, as it is > > > also used in the community for the column integral. I would suggest to > > > call it global_integral if this is what you want. > > > > > If approved, it should be clear to users that `_content' and `_burden' > are related but different. `_content' is certainly not unambiguous in > itself, it only becomes unambiguous by being part of the convention. My > feeling is that the two concepts, the existing `_content' and the > proposed `_burden' are sufficiently close that there is significant > benefit in keeping to the same name structure, rather than introducing > '...integral..'. > > I was not following the discussion when `_content' was adopted, but it > appears that it has been settled that it is appropiate to use this > structure rather than `column_integral', which would be the obvious > analogue of `global_integral'. Hence, in order to have a consistent > syntax within CF I'd prefer to stick with '_burden', > > cheers, > > Martin > > > ------------------------------------------------------------------------ > > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata From m.n.juckes at rl.ac.uk Fri Jan 25 10:51:46 2008 From: m.n.juckes at rl.ac.uk (Martin Juckes) Date: Fri, 25 Jan 2008 17:51:46 +0000 Subject: [CF-metadata] Fwd: standard name proposal for CCMVal In-Reply-To: <479A1E57.5090800@llnl.gov> References: <200801210921.13663.m.n.juckes@rl.ac.uk> <200801251130.55104.m.n.juckes@rl.ac.uk> <479A1E57.5090800@llnl.gov> Message-ID: <200801251751.49157.m.n.juckes@rl.ac.uk> On Friday 25 January 2008 17:37, you wrote: > Martin Juckes wrote: > > Dear Martin, > > If "burden" is simply the global integral of "content", then I think > there is no need for it. The standard name allows us to distinguish > among different quantities we want to measure, and if an integral, > average, or standard deviation of the quantity is computed, then that is > normally indicated in the cell_methods attribute. > > [I'm not absolutely positive about the following, but I think I've got > it right.] > > Normally you would simply define scalar dimensions for longitude and > latitude and indicae the range of values (in your case the global > domain) in a cell_bounds attribute. Alternatively, in the case of > longitude and latitude for the global domain, As I understand it, the > bounds attribute is not required but implied as described in the > paragraph at the end of > http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.1/cf-conventions.html#cell-methods > > I would appreciate Jonathan or someone confirming the above. > Jonathan did suggest something along these lines in an earlier discussion, though I'm not sure if it was exactly equivalent. My main objection is that the total amount of the substance in the atmosphere is independent of the coordinates used. It appears to me to be asking rather a lot of the software which will interpret the attributes to work out that a quantity defined in terms of latitude and longitude is not in anyway dependent on them. > It is true that we have adopted special standard names to indicate > vertically integrated quantities ("content"), and so one could argue why > not also adopt a special name ("burden") to integrate global amounts? I > don't have a good answer, but my preference would be to avoid a new > standard name for the integral of a quantity defined by another standard > name unless we can come up with a compelling argument against this. > I certainly would not define burden as an integral of content. It should be defined as the total amount in the atmosphere (sorry if this was misleading in the submitted document). It's relationship to content is through the area integral, but it is rather misses the point to define it that way. We should also think a little of the user who is looking for atmospheric budens as defined by the IPCC reports, i.e. global amounts. Such a user does not want to check the metadata of gobal variables to find out whether the data has been globally integrated or not. Of course, this problem will disappear eventually, we hope, when all users search through intelligent interfaces which know that a global integral indicated in the cell_methods corresponds ot a common usage of burden -- but that may take some time. cheers, Martin > Best regards, > Karl > > > > > > "we are suggesting `_burden' to > indicate a global integral" > > > > > I am sorry, I realize that I did not read your previous emails carefully > > > > > enough. But my comment shows that the use of burden is ambigous, as it is > > > > > also used in the community for the column integral. I would suggest to > > > > > call it global_integral if this is what you want. > > > > > > > > > If approved, it should be clear to users that `_content' and `_burden' > > are related but different. `_content' is certainly not unambiguous in > > itself, it only becomes unambiguous by being part of the convention. My > > feeling is that the two concepts, the existing `_content' and the > > proposed `_burden' are sufficiently close that there is significant > > benefit in keeping to the same name structure, rather than introducing > > '...integral..'. > > > > I was not following the discussion when `_content' was adopted, but it > > appears that it has been settled that it is appropiate to use this > > structure rather than `column_integral', which would be the obvious > > analogue of `global_integral'. Hence, in order to have a consistent > > syntax within CF I'd prefer to stick with '_burden', > > > > cheers, > > > > Martin > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > CF-metadata mailing list > > CF-metadata at cgd.ucar.edu > > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > From cameronsmith1 at llnl.gov Fri Jan 25 11:20:37 2008 From: cameronsmith1 at llnl.gov (Philip J. Cameronsmith1) Date: Fri, 25 Jan 2008 10:20:37 -0800 (PST) Subject: [CF-metadata] standard name proposal for CCMVal In-Reply-To: <20080125131335.GA1818@met.reading.ac.uk> References: <20080125131335.GA1818@met.reading.ac.uk> Message-ID: Hi All, I think this discussion reopens the question of how the list of chemical names should grow in the future. As you may recall, there are potentially millions of chemicals used by master mechanisms for which names will be required at some point. When we get to that point, there are no common names for most of those species, whereas there will always be a unique IUPAC name. But, the IUPAC names are likely to get unreasonably long for CF (I shudder to think of the oxidation products of sesqui-terpenes). I think we should seriously consider using something like the SMILES system that Stephen Pascoe has proposed previously. (http://www.daylight.com/dayhtml/doc/theory/theory.smiles.html) Until then, I see strengths and weaknesses to both common and IUPAC names, and so am content to sit on the fence. Best wishes, Philip On Fri, 25 Jan 2008, Jonathan Gregory wrote: > Dear Christiane > >> Yes, we did not finally decide on the IUPAC nomenclature, but it seems to >> me that we agreed that they should be used in principle. Therefore the >> long names are used instead of the more convenient ones for HTAP: >> >> PCB-153 HEXACHLOROBIPHENYL (without the positions of the chloratoms...) >> a-HCH alpha-Hexachlorocyclohexane > > Good point. I think the IUPAC names are preferable in principle because they > are standard, and I don't see why you shouldn't include the position of the > chlorine atoms in the standard name. Since you adopted IUPAC names, what has > been the experience of the HTAP community with using your standard names? > > Cheers > > Jonathan > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > ------------------------------------------------------------------------ Dr Philip Cameron-Smith Energy & Environment Directorate pjc at llnl.gov Lawrence Livermore National Laboratory +1 925 4236634 7000 East Avenue, Livermore, CA94550, USA ------------------------------------------------------------------------ From j.m.gregory at reading.ac.uk Mon Jan 28 12:05:13 2008 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Mon, 28 Jan 2008 19:05:13 +0000 Subject: [CF-metadata] standard name proposal for CCMVal Message-ID: <20080128190513.GA6726@met.reading.ac.uk> Dear Karl and all I was convinced by Martin's argument before that a new term is needed, and I still think he is right. I don't like "burden" particularly, and would prefer area_integral_of_content (I think that's what I suggested before), but "burden" is a term in actual use, and I take Martin's point that it may not be natural to describe the quantity of something in the atmosphere as the global area-integral of a quantity per unit area! Doing an area-integral is not just a statistical operation that can be described by cell_methods, because it involves the product of the content and the area, before doing the sum. The units of the new quantity don't depend just on the units of the original quantity, as m2 are involved as well, so it does need its own standard name, I think. Best wishes Jonathan From christiane.textor at lsce.ipsl.fr Mon Jan 28 13:08:55 2008 From: christiane.textor at lsce.ipsl.fr (Christiane Textor) Date: Mon, 28 Jan 2008 21:08:55 +0100 Subject: [CF-metadata] standard name proposal for CCMVal - burden In-Reply-To: <20080128190513.GA6726@met.reading.ac.uk> References: <20080128190513.GA6726@met.reading.ac.uk> Message-ID: <479E3657.90901@lsce.ipsl.fr> Dear colleagues, I still think that burden is ambiguous as it is also used to indicate the column mass. In addition, the word burden evokes the idea of mass (I am a not an English native speaker, but the Winword Thesaurus gives load, weight as synonymes for burden.) Why not use 'total' as a new term? For the CCMVal names this would give atmosphere_X_mole_total, but could be changed to atmosphere_X_total_moles or total_atmosphere_X_moles. Just an idea... Best regards, Christiane Jonathan Gregory schrieb: > Dear Karl and all > > I was convinced by Martin's argument before that a new term is needed, and I > still think he is right. I don't like "burden" particularly, and would prefer > area_integral_of_content (I think that's what I suggested before), but > "burden" is a term in actual use, and I take Martin's point that it may not > be natural to describe the quantity of something in the atmosphere as the > global area-integral of a quantity per unit area! > > Doing an area-integral is not just a statistical operation that can be > described by cell_methods, because it involves the product of the content and > the area, before doing the sum. The units of the new quantity don't depend just > on the units of the original quantity, as m2 are involved as well, so it does > need its own standard name, I think. > > Best wishes > > Jonathan > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > -- ====================================================================== Christiane Textor Laboratoire des Sciences du Climat et de l'Environnement Unite Mixte de Recherche CEA-CNRS-UVSQ LSCE/IPSL, CEA Saclay, Orme des Merisiers, Bat. 701, Piece 3b, Point Courrier 129 F-91191 Gif-sur-Yvette Cedex FRANCE mailto: christiane.textor at lsce.ipsl.fr Tel ++33 1 69 08 34 07 Fax ++33 1 69 08 77 16 GEOMON scientific project manager http://www.geomon.eu ====================================================================== From j.m.gregory at reading.ac.uk Tue Jan 29 01:17:51 2008 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Tue, 29 Jan 2008 08:17:51 +0000 Subject: [CF-metadata] standard name proposal for CCMVal - burden Message-ID: <20080129081751.GB2258@met.reading.ac.uk> Dear Christiane and Martin > In addition, the word burden evokes the idea of mass I agree, and that's why I wasn't keen on it too, because we might wish to use this term for non-massive things in the atmosphere, for instance the integral of atmos energy content (J), and it would not be natural to call that an "energy burden", I feel. Your suggestion of "total" is a possibility. To keep the notion of "total" with "atmosphere" I would prefer atmosphere_total_moles_of_X. But perhaps we can omit the "total" and say simply atmosphere_moles_of_X? It would be fairly natural to say likewise atmosphere_mass_of_X (kg), I think (although in English "the atmospheric mass" or "the atmosphere's mass" would perhaps be more natural - but we are not designing a natural language!) Cheers Jonathan From dan.bernie at metoffice.gov.uk Tue Jan 29 02:19:47 2008 From: dan.bernie at metoffice.gov.uk (dan.bernie at metoffice.gov.uk) Date: Tue, 29 Jan 2008 09:19:47 +0000 Subject: [CF-metadata] (no subject) Message-ID: <1201598387.8567.34.camel@eld269.desktop.frd.metoffice.com> Hi, I am an occasional reader of this list and have a query/proposal about the CF description of partial cells in (ocean) models with z- coordinates. As it stands in the CF convention (as I understand it), when using partial cells the different volume of cells is accounted for by including a 3-D array of the size of the full grid to describe the volume of each cell as well as a cell measure attribute in the variable: dimensions: deptht = 301 ; y = 149 ; x = 182 ; variables: float deptht(deptht) ; deptht: long_name = ?depth? ; deptht: units = ?m? ; float lon(x,y) ; lon: long_name = ?longitude? ; lon: units = ?degrees_east? ; float lat(x,y) ; lat: long_name = ?latitude? ; lat: units = ?degrees_north? ; double volumet(y, x) ; volumet :units = "m3" ; volumet :long_name = "volume of grid cell" ; volumet :standard_name = "cell_volume?; float votemper(deptht, y, x) ; votemper:units = "degC" ; votemper:long_name = "Temperature" ; votemper:coordinates = "deptht lat lon" ; votemper:cell_measures = "volume: volumet" ; votemper:standard_name = "sea_water_potential_temperature" ; My query/suggestion is about the need for a 3-D array for the thickness of the partial cell. The information on the thickness of the partial cell is essentially 2-D and the "volumet" array in the example above is almost doubling the size of the file. It would be entirely possible to fully define grid cell volumes using level thickness, grid cell area and information on the level and thickness of the partial cell. In the below example the "deptht_bounds" is used to find level thickness while the grid cell area is given in the 2-D array "areat". These two can be used for volume of every cell except the partial cells. To deal with the volume of the partial cells a new cell_measure of "partial_cell_thickness" could be used. In such a case the thickness and level of the partial cell can be specifed in a single number. For example of if the 24th level was the partial cell and it was 0.4 of the original thickness a "partial_cell_thickness" of 23.4 would specify the levels and thickness, i.e 23 full levels and 0.4 of the 24th. The thickness of the partial cell being 0.4 of the thickness determined from the 24th levels of "deptht_bounds" which would act as a refference. This in combination with the "areat" array would describe the cell volumes. e.g. dimensions: deptht = 301 ; y = 149 ; x = 182 ; ndepth_bounds = 2 ; variables: float deptht(deptht) ; deptht: long_name = ?depth? ; deptht: units = ?m? ; deptht: bounds = ?deptht_bounds" ; float lon(x,y) ; lon: long_name = ?longitude? ; lon: units = ?degrees_east? ; float lat(x,y) ; lat: long_name = ?latitude? ; lat: units = ?degrees_north? ; double deptht_bounds(deptht, ndepth_bounds) ; deptht_bounds:units = "m" ; deptht_bounds:long_name = "depth boundaries of cells" ; double areat(y, x) ; areat:units = "m2" ; areat:long_name = "area of grid cell" ; I'm aware that this would require some extra processing to calculate a 3-D array of cell volumes whereas keeping the 3-D volume array is foolproof, but the calculation is simple and it would greatly reduce the over head if many files were stored at higher vertical resolutions as in the above example. I'd be keen to hear people opinions on this or possible alternatives if I've missed something about possible ways to deal with this that are already used. Regards -- Dan Bernie HadGEM Physical Processes and Coupling Scientist Met Office Hadley Centre, FitzRoy Road, Exeter, EX1 3PB Tel: +44 (0)1392 884862 Fax: +44 (0)1392 885681 E-mail: dan.bernie at metoffice.gov.uk http://www.metoffice.gov.uk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20080129/b0ddfa50/attachment.html From j.m.gregory at reading.ac.uk Mon Feb 4 02:42:05 2008 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Mon, 4 Feb 2008 09:42:05 +0000 Subject: [CF-metadata] hydrosphere Message-ID: <20080204094205.GA3746@met.reading.ac.uk> Dear Roy > I have been using the term 'water column' in our vocabularies to identify > any body of salt or fresh water. The term 'hydrosphere' has been used for > the same purpose elsewhere. > > I would welcome CF standard names embracing the concept of 'water column' > under any label as it would firm up the mappings between the BODC > vocabularies being used by SeaDataNet and CF (although it would weaken > mappings between CF and GCMD who clearly differentiate between salt and > fresh water). However, although using the word 'sea' for this concept > would overcome legacy issues I worry about the potential for confusion. I'm replying on the email list as I think this is principally a matter of naming rather than the subgrid convention. Yes, I think "hydrosphere" would be a possible word to use when we need to refer to properties of the whole mass of water, in the context where we currently use "ocean" e.g. for large-scale transports. We also need a word for the material, which we call sea_water, to refer to its properties such as salinity, density, velocity and so on. Is there a word which means ocean, sea, lake or river? In any language? Cheers Jonathan From cameronsmith1 at llnl.gov Mon Feb 4 15:57:37 2008 From: cameronsmith1 at llnl.gov (Philip J. Cameronsmith1) Date: Mon, 4 Feb 2008 14:57:37 -0800 (PST) Subject: [CF-metadata] hydrosphere In-Reply-To: <20080204094205.GA3746@met.reading.ac.uk> References: <20080204094205.GA3746@met.reading.ac.uk> Message-ID: On Mon, 4 Feb 2008, Jonathan Gregory wrote: > Dear Roy > >> I have been using the term 'water column' in our vocabularies to identify >> any body of salt or fresh water. The term 'hydrosphere' has been used for >> the same purpose elsewhere. >> >> I would welcome CF standard names embracing the concept of 'water column' >> under any label as it would firm up the mappings between the BODC >> vocabularies being used by SeaDataNet and CF (although it would weaken >> mappings between CF and GCMD who clearly differentiate between salt and >> fresh water). However, although using the word 'sea' for this concept >> would overcome legacy issues I worry about the potential for confusion. > > I'm replying on the email list as I think this is principally a matter of > naming rather than the subgrid convention. > > Yes, I think "hydrosphere" would be a possible word to use when we need to > refer to properties of the whole mass of water, in the context where we > currently use "ocean" e.g. for large-scale transports. We also need a word > for the material, which we call sea_water, to refer to its properties such > as salinity, density, velocity and so on. Is there a word which means ocean, > sea, lake or river? In any language? > > Cheers > > Jonathan Hi, FWIW, I think of 'hydrosphere' as including ground water, clouds, and ice. Is that what is intended here? Would 'water_bodies' work for ocean+sea+lakes+rivers ? Best wishes, Philip ------------------------------------------------------------------------ Dr Philip Cameron-Smith Energy & Environment Directorate pjc at llnl.gov Lawrence Livermore National Laboratory +1 925 4236634 7000 East Avenue, Livermore, CA94550, USA ------------------------------------------------------------------------ From j.m.gregory at reading.ac.uk Tue Feb 5 01:07:40 2008 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Tue, 5 Feb 2008 08:07:40 +0000 Subject: [CF-metadata] hydrosphere Message-ID: <20080205080740.GA23499@met.reading.ac.uk> Dear Philip > FWIW, I think of 'hydrosphere' as including ground water, clouds, and ice. Ah. > Is that what is intended here? No, it is not mean to include groundwater or clouds. Ice is included if it is frozen river, lake or sea water. > Would 'water_bodies' work for ocean+sea+lakes+rivers ? That's unfortunately not a phrase which would be obviously meaningful in water_bodies_density, I think. I fear this is a hopeless quest, which is why I suggested defining "sea" to include lake and river in the context of CF standard names. Best wishes Jonathan From b.n.lawrence at rl.ac.uk Tue Feb 5 02:03:40 2008 From: b.n.lawrence at rl.ac.uk (Bryan Lawrence) Date: Tue, 5 Feb 2008 09:03:40 +0000 Subject: [CF-metadata] hydrosphere In-Reply-To: <20080205080740.GA23499@met.reading.ac.uk> References: <20080205080740.GA23499@met.reading.ac.uk> Message-ID: <200802050903.40702.b.n.lawrence@rl.ac.uk> On Tuesday 05 February 2008 08:07:40 Jonathan Gregory wrote: > I fear this is a hopeless quest, which is why I suggested defining "sea" to > include lake and river in the context of CF standard names. I appreciate that I have nothing useful to say, but I'm sure that using sea in this way would end up with more harm than good ... Bryan From j.m.gregory at reading.ac.uk Tue Feb 5 03:08:35 2008 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Tue, 5 Feb 2008 10:08:35 +0000 Subject: [CF-metadata] hydrosphere Message-ID: <20080205100835.GB1167@met.reading.ac.uk> > I fear this is a hopeless quest, which is why I suggested defining "sea" to > include lake and river in the context of CF standard names. A solution which would work, but I think would be ugly, would be to define aliases with "lake_water" and "river_water" for all names containing "sea_water" so they could be used with equivalent meaning. Thus, you could use "river_water" to describe properties of water in the Pacific Ocean, and "sea_water" for the Thames, and that could be confusing as well, but it would allow people to use "sea", "lake" and "river" when appropriate. This would possibly be an abuse of aliases, which we introduced to allow us to correct mistakes, in effect i.e. when we subsequently decided names were wrong in some way, so that data which used superseded names was still valid. The purpose of standard names is to be standard! To introduce synonyms undermines that aim. Hence I'm not sure if it's a good idea, although it would get round this problem. Any views? Jonathan From bermudez at mbari.org Tue Feb 5 05:26:29 2008 From: bermudez at mbari.org (Luis Bermudez) Date: Tue, 5 Feb 2008 07:26:29 -0500 Subject: [CF-metadata] hydrosphere In-Reply-To: <20080205100835.GB1167@met.reading.ac.uk> References: <20080205100835.GB1167@met.reading.ac.uk> Message-ID: If the names could be expressed in a hierarchy some of them could be specialized ( different form creating an alias ). This will allow preserving the current name and allowing to be more specific when necessary. - Luis ___ Luis Bermudez Ph.D. Coastal Research Technical Manager Southeastern Universities Research Association (SURA) bermudez at sura.org - Office: (202) 408-8211 Mobile: (267) 481-4939 1201 New York Ave. NW Suite 430, Washington DC 20005 On Feb 5, 2008, at 5:08 AM, Jonathan Gregory wrote: >> I fear this is a hopeless quest, which is why I suggested defining >> "sea" to >> include lake and river in the context of CF standard names. > > A solution which would work, but I think would be ugly, would be to > define > aliases with "lake_water" and "river_water" for all names containing > "sea_water" so they could be used with equivalent meaning. Thus, you > could > use "river_water" to describe properties of water in the Pacific > Ocean, and > "sea_water" for the Thames, and that could be confusing as well, but > it would > allow people to use "sea", "lake" and "river" when appropriate. > > This would possibly be an abuse of aliases, which we introduced to > allow us > to correct mistakes, in effect i.e. when we subsequently decided > names were > wrong in some way, so that data which used superseded names was > still valid. > The purpose of standard names is to be standard! To introduce synonyms > undermines that aim. Hence I'm not sure if it's a good idea, > although it would > get round this problem. Any views? > > Jonathan > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata From j.m.gregory at reading.ac.uk Tue Feb 5 05:59:50 2008 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Tue, 5 Feb 2008 12:59:50 +0000 Subject: [CF-metadata] Fwd: Re: hydrosphere Message-ID: <20080205125950.GA8226@met.reading.ac.uk> Dear Luis > If the names could be expressed in a hierarchy some of them could be > specialized ( different form creating an alias ). This will allow > preserving the current name and allowing to be more specific when > necessary. I think the crucial question is: what word describes "sea", "lake" and "river" in general? The general name is the problem, not the specific one. Cheers Jonathan From ngalbraith at whoi.edu Tue Feb 5 08:44:03 2008 From: ngalbraith at whoi.edu (Nan Galbraith) Date: Tue, 05 Feb 2008 10:44:03 -0500 Subject: [CF-metadata] hydrosphere (or, water) In-Reply-To: <20080205100835.GB1167@met.reading.ac.uk> References: <20080205100835.GB1167@met.reading.ac.uk> Message-ID: <47A88443.1010001@whoi.edu> This issue has broadened from Roy's initial topic of a term for water column, and now includes water bodies and water itself. It seems like it would not be too difficult to use water_column to indicate a mass of water that's limited in x-y and includes the full depth, and water_body to indicate a river, lake, ocean, or other. It might be worthwhile to consider replacing the term "sea_water" with "water" in the standard name list, with sea_water aliased for backwards compatibility. This seems much more useful than adding *a lot* of new terms to the parameter list, and the addition of a water_body vocabulary would take care of the distinction; the default would be ocean for files that don't include a water_body, also for backwards compatibility. Classifying data from coastal estuaries makes it convenient to have more general terms - neither sea_water, river_water, or lake_water would be exactly correct. There are too many shades of gray in water body types and too many parameters involved to create standard names for them all. There is an existing GCMD keyword list - sorry, I can't find it on their site this morning - for "Bodies Of Water" types. Cheers - Nan > > I would welcome CF standard names embracing the concept of 'water column' > > under any label as it would firm up the mappings between the BODC > > vocabularies being used by SeaDataNet and CF (although it would weaken > > mappings between CF and GCMD who clearly differentiate between salt and > > fresh water). However, although using the word 'sea' for this concept > > would overcome legacy issues I worry about the potential for confusion. > Yes, I think "hydrosphere" would be a possible word to use when we need to > refer to properties of the whole mass of water, in the context where we > currently use "ocean" e.g. for large-scale transports. We also need a word > for the material, which we call sea_water, to refer to its properties such > as salinity, density, velocity and so on. Is there a word which means ocean, > sea, lake or river? In any language? > >> I fear this is a hopeless quest, which is why I suggested defining "sea" to >> include lake and river in the context of CF standard names. >> > > A solution which would work, but I think would be ugly, would be to define > aliases with "lake_water" and "river_water" for all names containing > "sea_water" so they could be used with equivalent meaning. Thus, you could > use "river_water" to describe properties of water in the Pacific Ocean, and > "sea_water" for the Thames, and that could be confusing as well, but it would > allow people to use "sea", "lake" and "river" when appropriate. > > This would possibly be an abuse of aliases, which we introduced to allow us > to correct mistakes, in effect i.e. when we subsequently decided names were > wrong in some way, so that data which used superseded names was still valid. > The purpose of standard names is to be standard! To introduce synonyms > undermines that aim. Hence I'm not sure if it's a good idea, although it would > get round this problem. Any views? > -- ******************************************************* * Nan Galbraith (508) 289-2444 * * Upper Ocean Processes Group Mail Stop 29 * * Woods Hole Oceanographic Institution * * Woods Hole, MA 02543 * ******************************************************* From graybeal at mbari.org Tue Feb 5 08:54:01 2008 From: graybeal at mbari.org (John Graybeal) Date: Tue, 5 Feb 2008 07:54:01 -0800 Subject: [CF-metadata] Fwd: Re: hydrosphere In-Reply-To: <20080205125950.GA8226@met.reading.ac.uk> References: <20080205125950.GA8226@met.reading.ac.uk> Message-ID: Why not 'surface_water' ? john At 12:59 PM +0000 2/5/08, Jonathan Gregory wrote: >Dear Luis > >> If the names could be expressed in a hierarchy some of them could be >> specialized ( different form creating an alias ). This will allow >> preserving the current name and allowing to be more specific when >> necessary. > >I think the crucial question is: what word describes "sea", "lake" and >"river" in general? The general name is the problem, not the specific one. > >Cheers > >Jonathan >_______________________________________________ >CF-metadata mailing list >CF-metadata at cgd.ucar.edu >http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- ---------- John Graybeal -- 831-775-1956 Monterey Bay Aquarium Research Institute Marine Metadata Initiative: http://marinemetadata.org || Shore Side Data System: http://www.mbari.org/ssds From j.m.gregory at reading.ac.uk Tue Feb 5 09:03:05 2008 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Tue, 5 Feb 2008 16:03:05 +0000 Subject: [CF-metadata] hydrosphere (or, water) Message-ID: <20080205160305.GB14849@met.reading.ac.uk> Dear Nan > It might be worthwhile to consider replacing the term "sea_water" with > "water" in the standard name list, with sea_water aliased for backwards > compatibility. The reason for not doing that is that "water" is too vague. Not all water is seas, rivers or lakes; some is cloud water, some groundwater, instance. What we need is a word for a body of water whose bottom is on the solid Earth. Maybe we should just make a up a word! I believe that the word "gas" was invented from nothing, and that has caught on. Cheers Jonathan From j.m.gregory at reading.ac.uk Tue Feb 5 09:04:05 2008 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Tue, 5 Feb 2008 16:04:05 +0000 Subject: [CF-metadata] Re: hydrosphere Message-ID: <20080205160405.GC14849@met.reading.ac.uk> > Why not 'surface_water' ? I don't think (myself) that "surface water" is an obvious description of an ocean, although it is true of course viewed from an appropriate perspective. Jonathan From russ at unidata.ucar.edu Tue Feb 5 09:14:10 2008 From: russ at unidata.ucar.edu (Russ Rew) Date: Tue, 05 Feb 2008 09:14:10 -0700 Subject: [CF-metadata] Fwd: Re: hydrosphere In-Reply-To: Message from Jonathan Gregory of "Tue, 05 Feb 2008 12:59:50 GMT." <20080205125950.GA8226@met.reading.ac.uk> Message-ID: <4178.1202228050@buddy.unidata.ucar.edu> Jonathan, > I think the crucial question is: what word describes "sea", "lake" and > "river" in general? The general name is the problem, not the specific one. This is probably naive, but how about just 'water'. The meaning of a cell_method value of 'area: mean over water' would seem to naturally include ocean, sea, lake, or river. --Russ From j.m.gregory at reading.ac.uk Tue Feb 5 10:00:08 2008 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Tue, 5 Feb 2008 17:00:08 +0000 Subject: [CF-metadata] Fwd: Re: hydrosphere Message-ID: <20080205170008.GC17201@met.reading.ac.uk> > This is probably naive, but how about just 'water'. The meaning of a > cell_method value of 'area: mean over water' would seem to naturally > include ocean, sea, lake, or river. That is the context where Roy raised it. I agree, as an area type it could be OK - more problematic to have just "water" in standard names, though, I feel. J From graybeal at mbari.org Tue Feb 5 13:30:33 2008 From: graybeal at mbari.org (John Graybeal) Date: Tue, 5 Feb 2008 12:30:33 -0800 Subject: [CF-metadata] hydrosphere (or, water) In-Reply-To: <20080205160305.GB14849@met.reading.ac.uk> References: <20080205160305.GB14849@met.reading.ac.uk> Message-ID: Questions and another suggestion or two: Is this name meant to include, or exclude, underground rivers? I infer icebergs are included, as they are frozen seawater, but ice over land is not? (As the number of subtled distinctions increases, so does the necessity of making up a word.) Other ideas, some along the lines of 'making up a word' (you provide separators as desired) - topwater - navwater (water in seas, rivers, lakes is nominally navigable by (small enough) craft -- even frozen, given mean enough icebreaker) - gwater (g for either 'grounded' or 'Gaia', neither of which is perfect either...; ground water has another meaning of course) - bedwater or beddedwater - swater (for surface water, which I still like notwithstanding the critiques :->) I promise not to provide any more ideas unless they are in fact great.... John At 4:03 PM +0000 2/5/08, Jonathan Gregory wrote: >Dear Nan > >> It might be worthwhile to consider replacing the term "sea_water" with >> "water" in the standard name list, with sea_water aliased for backwards >> compatibility. > >The reason for not doing that is that "water" is too vague. Not all water >is seas, rivers or lakes; some is cloud water, some groundwater, instance. >What we need is a word for a body of water whose bottom is on the solid >Earth. Maybe we should just make a up a word! I believe that the word "gas" >was invented from nothing, and that has caught on. > >Cheers > >Jonathan >_______________________________________________ >CF-metadata mailing list >CF-metadata at cgd.ucar.edu >http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- ---------- John Graybeal -- 831-775-1956 Monterey Bay Aquarium Research Institute Marine Metadata Initiative: http://marinemetadata.org || Shore Side Data System: http://www.mbari.org/ssds From anstett at ucar.edu Thu Feb 7 13:04:37 2008 From: anstett at ucar.edu (Janet Scannell) Date: Thu, 07 Feb 2008 13:04:37 -0700 Subject: [CF-metadata] standard names for flag/qc variables Message-ID: <47AB6455.1090209@ucar.edu> I have a flag/qc variable for each variable in my netcdf file. I have found standard names for all of the regular variables, but I couldn't find any information on whether there are standard names for flag variables. I saw _qc used in the section where flags_values was discussed, but using this doesn't allow my netcdf file to pass the cf-compliance-checker. It says that eastward_wind_qc is an invalid standard name. Any suggestions on what to name these flag/qc variables? Thanks, Janet From j.m.gregory at reading.ac.uk Thu Feb 7 13:59:12 2008 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Thu, 7 Feb 2008 20:59:12 +0000 Subject: [CF-metadata] standard names for flag/qc variables Message-ID: <20080207205912.GC16264@met.reading.ac.uk> Dear Janet > I have a flag/qc variable for each variable in my netcdf file. I have > found standard names for all of the regular variables, but I couldn't > find any information on whether there are standard names for flag > variables. I saw _qc used in the section where flags_values was > discussed, but using this doesn't allow my netcdf file to pass the > cf-compliance-checker. It says that eastward_wind_qc is an invalid > standard name. Any suggestions on what to name these flag/qc variables? Your quality flag variable is an ancillary data variable, and its standard_name attribute should be "eastward_wind status_flag". If you wish, you can point to it from the eastward_wind data variable using an ancillary_variables attribute. See CF 3.4. Best wishes Jonathan From denis.nadeau at nasa.gov Thu Feb 7 13:53:57 2008 From: denis.nadeau at nasa.gov (Denis Nadeau) Date: Thu, 07 Feb 2008 15:53:57 -0500 Subject: [CF-metadata] Difficulties to display Swath files form NetCDF. Message-ID: <47AB6FE5.3080404@nasa.gov> Hi, I am trying to convert a L2 Swath data file from HDF to NetCDF following CF-1 Convention. I order to do so, I have tried to follow this method: http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.0/cf-conventions.html#id2621732 I did not succeed to read back the NetCDF file properly into either: Ferret, Grads or IDV. (getting aggravated :-! ) I saw in the mailing list archive that "Jonathan Gregory" has tried to do something similar. Did he succeed? http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2004/000426.html So, is there a way to represent SWATH data using CF-1 Convention? If so, is there a "Application" that can read the metadata and display the image correctly (swath)? Here is a L2 Swath HDF file I am using. ftp://airspar1u.ecs.nasa.gov/data/s4pa//Aqua_AIRS_Level2/AIRX2RET.005/2008/019//AIRS.2008.01.19.001.L2.RetStd.v5.0.14.0.G08020192400.hdf Thanks for your help on this issue. Best Regards, Denis -- Denis Nadeau Goddard Earth Sciences Data & Information Services Center Code 610.2 NASA Goddard Space Flight Center, Greenbelt, MD 20771 Phone: (301) 614-5514 Fax: (301) 614-5268 email: dnadeau at pop600.gsfc.nasa.gov http://disc.gsfc.nasa.gov http://giovanni.gsfc.nasa.gov From craig.donlon at gmail.com Fri Feb 8 02:02:12 2008 From: craig.donlon at gmail.com (Craig Donlon) Date: Fri, 8 Feb 2008 09:02:12 +0000 Subject: [CF-metadata] Difficulties to display Swath files form NetCDF. In-Reply-To: <47AB6FE5.3080404@nasa.gov> References: <47AB6FE5.3080404@nasa.gov> Message-ID: <1f73fed70802080102x28e3e81ej75ea25689ad0fe55@mail.gmail.com> Hello Denis: the GHRSST-PP (http://www.ghrsst-pp.org) provides swath data in netCDF format. Dave Poulter and Jorge Vazquez can help you look through one of the GHRSST-PP L2P files from MODIS and several other sensors all the best craig On 07/02/2008, Denis Nadeau wrote: > Hi, > > I am trying to convert a L2 Swath data file from HDF to NetCDF following > CF-1 Convention. I order to do so, I have tried to follow this method: > http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.0/cf-conventions.html#id2621732 > > I did not succeed to read back the NetCDF file properly into either: > Ferret, Grads or IDV. (getting aggravated :-! ) > I saw in the mailing list archive that "Jonathan Gregory" has tried to > do something similar. Did he succeed? > > http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2004/000426.html > > So, is there a way to represent SWATH data using CF-1 Convention? > If so, is there a "Application" that can read the metadata and display > the image correctly (swath)? > > Here is a L2 Swath HDF file I am using. > ftp://airspar1u.ecs.nasa.gov/data/s4pa//Aqua_AIRS_Level2/AIRX2RET.005/2008/019//AIRS.2008.01.19.001.L2.RetStd.v5.0.14.0.G08020192400.hdf > > Thanks for your help on this issue. > > > Best Regards, > Denis > > -- > Denis Nadeau > Goddard Earth Sciences Data & Information Services Center > Code 610.2 > NASA Goddard Space Flight Center, Greenbelt, MD 20771 > Phone: (301) 614-5514 > Fax: (301) 614-5268 > email: dnadeau at pop600.gsfc.nasa.gov > http://disc.gsfc.nasa.gov > http://giovanni.gsfc.nasa.gov > > > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > -- Dr Craig Donlon Director of the International GODAE SST Pilot Project Office Met Office Hadley Centre, Fitzroy Road, Exeter, EX1 3PB United Kingdom Tel: +44 (0)1392 886622 Mob:07920 235750 Fax:+44 (0)1392 885681 Skype ID:crazit SkypeIn: +44 0141 416 0882 E-mail: craig.donlon at gmail.com http://www.ghrsst-pp.org From denis.nadeau at nasa.gov Wed Feb 13 10:03:08 2008 From: denis.nadeau at nasa.gov (Denis Nadeau) Date: Wed, 13 Feb 2008 12:03:08 -0500 Subject: [CF-metadata] Difficulties to display Swath files form NetCDF. In-Reply-To: <1f73fed70802080102x28e3e81ej75ea25689ad0fe55@mail.gmail.com> References: <47AB6FE5.3080404@nasa.gov> <1f73fed70802080102x28e3e81ej75ea25689ad0fe55@mail.gmail.com> Message-ID: <47B322CC.2080709@nasa.gov> Hi, I have looked at your L2P files and I am trying to do the same magic that would allow me to display L2 CF1 netcdf files into IDV. I copied almost all your medatadata in my netcdf file and I created a third dimention to my "test" variable called "time". I still cannot trigger my variable "test" as a grid. I don't know what more to copy in there. Any input from your part would be welcome. Here is what I have so far. dimensions: time = 1; // (has coord.var) nj = 45; ni = 30; variables: float lat(nj=45, ni=30); :long_name = "latitude"; :standard_name = "latitude"; :units = "degrees_south"; float lon(nj=45, ni=30); :long_name = "longitude"; :standard_name = "longitude"; :units = "degrees_west"; int time(time=1); :units = "seconds since 1981-01-01 00:00:00"; :long_name = "reference time of sst file"; :standard_name = "reference time of sst file"; :valid_min = "-1000"; :valid_man = "8000"; :scale_factor = 0.0050f; // float :add_offset = 273.15f; // float short test(time=1, nj=45, ni=30); :units = "kelvin"; :_FillValue = -32768s; // short :coordinates = "lon lat"; :long_name = "time131"; :valid_min = "-1000"; :valid_man = "8000"; :scale_factor = 0.0050f; // float :add_offset = 273.15f; // float "; :title = "MODIS Aqua L2P SST"; :DSD_entry_id = "JPL-L2P-MODIS_A"; :platform = "Aqua"; :sensor = "MODIS"; :Conventions = "CF-1.0"; :references = "GHRSST Data Processing Specification v1.6"; :institution = "NASA/JPL/OBPG/RSMAS"; :contact = "Ed Armstrong, JPL PO.DAAC, edward.m.armstrong at jpl.nasa.gov"; :GDS_version_id = "v1r1.5"; :netcdf_version_id = "3.5"; :creation_date = "Wed Jan 2 03:45:56 2008"; :history = "Quicklook MODIS L2P created at the GHRSST Global Data Assembly Center (GDAC)"; :product_version = "1"; :spatial_resolution = "1km"; :start_date = "2008-01-01 UTC"; :start_time = "00:00:07 UTC"; :stop_date = "2008-01-01 UTC"; :stop_time = "00:05:05 UTC"; :northernmost_latitude = -56.24939f; // float :southernmost_latitude = -80.19904f; // float :easternmost_longitude = 4.987639f; // float :westernmost_longitude = -73.76147f; // float :file_quality_index = 1.0f; // float :comment = "L2P Core without DT analysis or other ancillary fields; Night"; } Craig Donlon wrote: > Hello Denis: > the GHRSST-PP (http://www.ghrsst-pp.org) provides swath data in netCDF > format. Dave Poulter and Jorge Vazquez can help you look through one > of the GHRSST-PP L2P files from MODIS and several other sensors > > all the best > craig > > On 07/02/2008, Denis Nadeau wrote: > >> Hi, >> >> I am trying to convert a L2 Swath data file from HDF to NetCDF following >> CF-1 Convention. I order to do so, I have tried to follow this method: >> http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.0/cf-conventions.html#id2621732 >> >> I did not succeed to read back the NetCDF file properly into either: >> Ferret, Grads or IDV. (getting aggravated :-! ) >> I saw in the mailing list archive that "Jonathan Gregory" has tried to >> do something similar. Did he succeed? >> >> http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2004/000426.html >> >> So, is there a way to represent SWATH data using CF-1 Convention? >> If so, is there a "Application" that can read the metadata and display >> the image correctly (swath)? >> >> Here is a L2 Swath HDF file I am using. >> ftp://airspar1u.ecs.nasa.gov/data/s4pa//Aqua_AIRS_Level2/AIRX2RET.005/2008/019//AIRS.2008.01.19.001.L2.RetStd.v5.0.14.0.G08020192400.hdf >> >> Thanks for your help on this issue. >> >> >> Best Regards, >> Denis >> >> -- >> Denis Nadeau >> Goddard Earth Sciences Data & Information Services Center >> Code 610.2 >> NASA Goddard Space Flight Center, Greenbelt, MD 20771 >> Phone: (301) 614-5514 >> Fax: (301) 614-5268 >> email: dnadeau at pop600.gsfc.nasa.gov >> http://disc.gsfc.nasa.gov >> http://giovanni.gsfc.nasa.gov >> >> >> _______________________________________________ >> CF-metadata mailing list >> CF-metadata at cgd.ucar.edu >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >> >> > > > From veronika.eyring at dlr.de Thu Feb 14 07:32:24 2008 From: veronika.eyring at dlr.de (Eyring, Veronika) Date: Thu, 14 Feb 2008 15:32:24 +0100 Subject: [CF-metadata] standard name proposal for CCMVal In-Reply-To: <20080129081751.GB2258@met.reading.ac.uk> References: <20080129081751.GB2258@met.reading.ac.uk> Message-ID: <47B450F8.3050908@dlr.de> Dear colleagues, Thanks for your comments on the standard name proposal for CCMVal. 1. Regarding the suggested chemical names, I looked at the IUPAC names but have decided to follow the chemical formulae and nomenclature from the 2006 WMO/UNEP Scientific Assessment of Ozone Depletion as a first suggestion (see Appendix C in http://ozone.unep.org/Assessment_Panels/SAP/Scientific_Assessment_2006/11-Appendices.pdf) as obviously these are the names the modelling community, in particular the CCMVal community, are most familiar with. If there is no rule that we have to use IUPAC, I'd prefer keeping those. However, IUPAC based names (omitting commas and hyphens) could be used for the CFCs. They would be: cfc11: Trichlorofluoromethane cfc12: Dichlorodifluoromethane cfc113: 112trichloro122trifluoroethane cfc113a: 111trichloro222trifluoroethane cfc114: 12dichloro1122tetrafluoroethane cfc115: 11chloro11222pentafluoroethane (names adapted from http://en.wikipedia.org/wiki/Chlorofluorocarbon#Chloro_fluoro_compounds_.28CFC.2C_HCFC.29). I am not sure that the cfc113, cfc113a pair is really suitable. It is true that cfc113 and cfc113a only differ by one letter, but the differences in the IUPAC names appear likely to cause more confusion. There are also 4 halon compounds in our standard name proposal that could be replaced with the IUPAC names. Does anyone think that use of the longer names will promote clarity for CFCs and halons? Is anyone not ok with following WMO/UNEP nomenclature for all or all other species? 2. The use of 'burden' follows widespread scientific usage, though it is clear that it is not unambiguous on its own. The intention was to use 'burden' in the name and have an unambiguous definition in the definition. The alternative approach would be to build a definition into the standard name, but according to Martin Juckes that is a radical departure from the way the list has developed up to this point. It appears that no one on the list would support the use of '_content' in a standard name, since all the objections raised against 'burden' apply equally or more so to 'content'. Given that column totals are referred to as '_content' it appears reasonable to refer to global totals as '_burden'. So I would prefer we keep '_burden'. 3. On another note: I am already receiving emails from modelers asking for additional CF names for chemistry which have not yet been defined. Obviously the list we are proposing does not include all chemical species, in particular not for the troposphere. HTAP has to my knowledge also not yet specified the full list of species relevant for tropospheric chemistry, e.g. only mole_fraction_of_anthropogenic_nmvoc_in_air mole_fraction_of_biogenic_nmvoc_in_air but not the different nmvocs. Is there any attempt to provide CF standard names for other chemical species as part of HTAP, AEROCOM or other projects? Can I direct those requests to the discussion on names for chemistry and aerosol at http://wiki.esipfed.org/index.php/Air_Quality/Chemistry_Naming_Conventions? Best regards, Veronika Eyring ------------------------------------------------------------------ Dr. Veronika Eyring veronika.eyring at dlr.de Deutsches Zentrum fuer Luft- und Raumfahrt (DLR) DLR-Institut fuer Physik der Atmosphaere, Oberpfaffenhofen, D-82230 Wessling, Germany Phone: +49-8153-28-2533, Fax.: +49-8153-28-1841 http://www.pa.op.dlr.de/~VeronikaEyring/ ------------------------------------------------------------------ From Christiane.Textor at lsce.ipsl.fr Thu Feb 14 08:35:57 2008 From: Christiane.Textor at lsce.ipsl.fr (Christiane.Textor at lsce.ipsl.fr) Date: Thu, 14 Feb 2008 16:35:57 +0100 (CET) Subject: [CF-metadata] standard name proposal for CCMVal In-Reply-To: <47B450F8.3050908@dlr.de> References: <20080129081751.GB2258@met.reading.ac.uk> <47B450F8.3050908@dlr.de> Message-ID: <34536.90.46.139.56.1203003357.squirrel@mailhost.lsce.ipsl.fr> Dear Veronika, Let me just comment on your point 3: > Can I direct those requests to the discussion on names > for chemistry and aerosol at > http://wiki.esipfed.org/index.php/Air_Quality/Chemistry_Naming_Conventions? There is no discussion at this wiki anymore to my knowledge, it has been used in the beginning for the HTAP names, but the discussion shifted than to the CF mailing list. Some of the information on this site is out-dated, since I do not have the time anymore to moderate this. The wiki can however be re-activated I guess for internal discussions, just create an account and start working. Best regards, Christiane > > Best regards, > Veronika Eyring > > ------------------------------------------------------------------ > Dr. Veronika Eyring veronika.eyring at dlr.de > Deutsches Zentrum fuer Luft- und Raumfahrt (DLR) > DLR-Institut fuer Physik der Atmosphaere, > Oberpfaffenhofen, D-82230 Wessling, Germany > Phone: +49-8153-28-2533, Fax.: +49-8153-28-1841 > http://www.pa.op.dlr.de/~VeronikaEyring/ > ------------------------------------------------------------------ > > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- ====================================================================== Christiane Textor Laboratoire des Sciences du Climat et de l'Environnement Unite Mixte de Recherche CEA-CNRS-UVSQ LSCE/IPSL, CEA Saclay, Orme des Merisiers, Bat. 701, Piece 3b, Point Courrier 129 F-91191 Gif-sur-Yvette Cedex FRANCE mailto: christiane.textor at lsce.ipsl.fr Tel ++33 1 69 08 34 07 Fax ++33 1 69 08 77 16 GEOMON scientific project manager http://www.geomon.eu ====================================================================== From craig.donlon at gmail.com Thu Feb 14 09:20:57 2008 From: craig.donlon at gmail.com (Craig Donlon) Date: Thu, 14 Feb 2008 16:20:57 +0000 Subject: [CF-metadata] CF-1.0 registration of new names for SST In-Reply-To: <6.1.1.1.2.20070822113949.0256f560@pop.cls.fr> References: <6.1.1.1.2.20070822113949.0256f560@pop.cls.fr> Message-ID: <1f73fed70802140820w729069b4n54da13f7822af7e9@mail.gmail.com> Hi Olivier: Just to remind us all (we need to get this agreed if possible as the GHRSST-PP are working on a new set of documentation) and the large EU MyOcean project will be using CF as a the baseline for ocean products. My comments on your summary mail are in line below. also attached is the original proposal. Note that the operational GHRSST-PP community is moving some 25Gb SST data in netCDF _each day_ using GHRSST-PP definitions and that the World Meteorological Organisation has accepted the proposed terms already. I hope we can resolve these issues as quickly as possible now. Regards, Craig Summary of proposal so Far (from Oliveier Laurent mail) > *SSTint (GHRSST-PP): surface_temperature (CF) OK as we do not use this in operations but clarification on the interface may still be useful in a description. > *SSTskin (GHRSST-PP): > - sea_surface_temperature_in_skin_layer > - skin_sea_surface_temperature > - sea_skin_temperature? > - sea_water_temperature with a depth attribute ? We still propose skin_layer_sea_surface_temperature as in the GHRSST-PP proposal. > *SSTsubskin (GHRSST-PP): > - sea_surface_temperature_in_subskin_layer? > - subskin_sea_surface_temperature? > - sea_subskin_temperature? > - sea_water_temperature with a depth attribute ? > (same comments as for SSTskin) I accept subskin_sea_surface_temperature > *SSTdepth (GHRSST-PP): sea_water_temperature (CF) I'm happy with Alison and Nan suggestions regarding the use of sea_water_temperature followed by a depth attribute. Without the depth attribute the data are only of marginal use in data assimilation systems and for blending. Many of the problems we have in the satellite SST community today stem from the fact that depth was not included as an essential component of the measurement. Now that some satellite radiometers are providing more accurate and consistent measurements of SST than can be obtained in situ (O'Carroll et al JTECH, 2007) depth is essential!!) So to answer Alisons question "We already have the standard name sea_water_temperature which is defined as follows: "For the temperature of sea water at a particular depth or layer, a data variable of sea_water_temperature with a vertical coordinate axis should be used." Would this meet your needs?" The answer is YES it does and we will work on this within GHRSST-PP. but The need for the depth information needs to be mandatory can this be done? without depth it is somewhat meaningless... > > *SSTfnd (GHRSST-PP): > - sea_surface_temperature_at_diurnal_thermocline_base This is not correct. The main purpose of SSTfnd is to remove from the vocabulary of scientists the totally confusing and lazy term bulk SST which is meaningless in the context of modern measurements, for data assimilation and simply perpetuates confusion and erroneous assumptions (Bit harsh, I know, but essentially true!)). To answer Alison's question: "Does this mean that the foundation temperature is measured/modelled at the base of the thermocline so that the values are intrinsically free of diurnal variation [YES], or is the diurnal variation statistically removed from the data [it could be - especially when blending data for statistical analyses]?" The answer is yes in both cases. I hope that a new 'surface' and associated name can be introduced to represent this quantity which is the quantity that most global SST analysis systems produce today. There is a nice figure showing what SSTfnd is at https://www.ghrsst-pp.org/SST-Definitions.html So I would argue for foundation_sea_surface_temperature Original proposal========================================== For the benefit of everyone concerned, here are the full definitions (reported in Donlon et al., J Climate 2002 and updated and reported in BAMS this August). The following is taken from https://www.ghrsst-pp.org/SST-Definitions.html SST is a difficult parameter to define exactly because the upper ocean (~10 m) has a complex and variable vertical temperature structure that is related to ocean turbulence and the air-sea fluxes of heat, moisture and momentum. A framework is required to understand the information content and relationships between measurements of SST made by different satellite and in situ instruments, especially if these are to be merged together. The definitions of SST developed by the GHRSST-PP SST Science Team (agreed at the 2nd and 3rd GHRSST-PP workshops) achieve the closest possible coincidence between what is defined and what can be measured operationally, bearing in mind current scientific knowledge and understanding of how the near surface thermal structure of the ocean behaves in nature. The interface temperature (SSTint) At the exact air-sea interface a hypothetical temperature called the interface temperature (SSTint) is defined although this is of no practical use because it cannot be measured using current technology. (NOTE- this is probably not required but was included for completeness) [Proposed CF-names: SSTint, interface_SST, interface_sea_surface_temperature] The skin sea surface temperature (SSTskin) The skin temperature (SSTskin) is defined as the temperature measured by an infrared radiometer typically operating at wavelengths 3.7-12 ?m (chosen for consistency with the majority of infrared satellite measurements) that represents the temperature within the conductive diffusion-dominated sub-layer at a depth of ~10-20 ?m. SSTskin measurements are subject to a large potential diurnal cycle including cool skin layer effects (especially at night under clear skies and low wind speed conditions) and warm layer effects in the daytime. (NOTE: Discussion on frequency is of secondary importance here - the main issue is that the SSTskin is that retrieved using an infrared radiometer) [Proposed CF-names: SSTskin, skin_layer_SST, skin_layer_sea_surface_temperature] The sub-skin sea surface temperature (SSTsub-skin) The subskin temperature (SSTsubskin) represents the temperature at the base of the conductive laminar sub-layer of the ocean surface. For practical purposes, SSTsubskin can be well approximated to the measurement of surface temperature by a microwave radiometer operating in the 6-11 GHz frequency range, but the relationship is neither direct nor invariant to changing physical conditions or to the specific geometry of the microwave measurements. (NOTE: Discussion on frequency is of secondary importance here - the main issue is that the SSTsub-skin is that retrieved using a microwave radiometer) [Proposed CF-names: SSTsubskin, Sub-skin_SST, sub-skin_sea_surface_temperature] The surface temperature at depth (SSTz or SSTdepth) All measurements of water temperature beneath the SSTsubskin are referred to as depth temperatures (SSTdepth) measured using a wide variety of platforms and sensors such as drifting buoys, vertical profiling floats, or deep thermistor chains at depths ranging from 10-2 - 103m. These temperature observations are distinct from those obtained using remote sensing techniques (SSTskin and SSTsubskin) and must be qualified by a measurement depth in meters (e.g., or SST(z) e.g. SST5m). The foundation temperature (SSTfnd) (Please look at figure provided at https://www.ghrsst-pp.org/SST-Definitions.html to make sense of this) The foundation SST, SSTfnd, is defined as the temperature of the water column free of diurnal temperature variability (daytime warming or nocturnal cooling) and is considered equivalent to the SSTsubskin in the absence of any diurnal signal. It is named to indicate that it is the foundation temperature from which the growth of the diurnal thermocline develops each day (noting that on some occasions with a deep mixed layer there is no clear SSTfnd profile in the surface layer). Only in situ contact thermometry is able to measure SSTfnd and analysis procedures must be used to estimate the SSTfnd from radiometric satellite measurements of SSTskin and SSTsubskin. SSTfnd provides a connection with the historical concept of a "bulk" SST considered representative of the oceanic mixed layer temperature and represented by any SSTdepth measurement within the upper ocean over a depth range of 1-20+m. SSTfnd provides a more precise, well-defined quantity than previous loosely defined "bulk" SST and consequently, a better representation of the mixed layer temperature. In general, SSTfnd will be similar to a night time minimum or pre-dawn value at depths of ~1-5 m, but some differences could exist. Note that SSTfnd does not imply a constant depth mixed layer, but rather a surface layer of variable depth depending on the balance between stratification and turbulent energy and is expected to change slowly over the course of a day. [Proposed CF-names: SSTfnd, Foundation_Temperature, foundation_sea_surface_temperature] I should note that I had a small WMO/IOC JCOMM task team set up as part of the SOT to look at this a year or so ago which concluded at this years SOT. The definitions presented above above were adopted by the WMO CBS. I Hope this makes things clearer and more straight forward and I sense that the main concern is with the in situ folk regarding the details and not the principles behind SSTz. -- Dr Craig Donlon Director of the International GODAE SST Pilot Project Office Met Office Hadley Centre, Fitzroy Road, Exeter, EX1 3PB United Kingdom Tel: +44 (0)1392 886622 Mob:07920 235750 Fax:+44 (0)1392 885681 Skype ID:crazit SkypeIn: +44 0141 416 0882 E-mail: craig.donlon at gmail.com http://www.ghrsst-pp.org From j.m.gregory at reading.ac.uk Thu Feb 14 09:40:41 2008 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Thu, 14 Feb 2008 16:40:41 +0000 Subject: [CF-metadata] CF-1.0 registration of new names for SST Message-ID: <20080214164041.GB24573@met.reading.ac.uk> Dear Craig I would find sea_[sub]skin_temperature more obvious than [sub]skin_sea_surface_temperature because it feels like "surface" and "[sub]skin layer" are conflicting concepts. No problem with the surface or the temperature with a depth coord. I don't think CF can mandate the depth coord but obviously you can in your applications of CF. I am worried about the foundation temperature. I understand your wish to abolish the rather vague SST bulk temperature, but "foundation" seems vague to me in its own right. Alison's options > measured/modelled at the base of the thermocline so that the values are > intrinsically free of diurnal variation and > or is the diurnal variation statistically removed from the data strike me as different things, which should not have the same name. Statistically removing the variation could mean just calculating the daily mean, which is indicated by cell_methods, not the standard name, or it could mean filtering the data, which could be indicated in some other way to be devised. You write > Only in situ contact thermometry is able to measure SSTfnd ... > SSTfnd will be similar to a night time minimum or pre-dawn value at > depths of ~1-5 m, but some differences could exist. Note that SSTfnd > does not imply a constant depth mixed layer, but rather a surface > layer of variable depth depending on the balance between > stratification and turbulent energy and is expected to change slowly > over the course of a day. That sounds rather ill-defined to me. Could you not have different names for the results of different methods for evaluating it? best wishes Jonathan From graybeal at mbari.org Thu Feb 14 11:22:45 2008 From: graybeal at mbari.org (John Graybeal) Date: Thu, 14 Feb 2008 10:22:45 -0800 Subject: [CF-metadata] CF-1.0 registration of new names for SST In-Reply-To: <1f73fed70802140820w729069b4n54da13f7822af7e9@mail.gmail.com> References: <6.1.1.1.2.20070822113949.0256f560@pop.cls.fr> <1f73fed70802140820w729069b4n54da13f7822af7e9@mail.gmail.com> Message-ID: I've asked for some feedback internally, based on the definitions at the web site and in the enclosed email. A few concerns were raised, but I'm not sure what the terms and definitions now proposed for CF are. Can someone provide the summary list, or should I try to summarize myself, or should I describe concerns with respect to the definitions referenced below? By the way, "sea_water_temperature with a depth attribute" is fine; it is the other terms/definitions that may be a little confusing. John At 4:20 PM +0000 2/14/08, Craig Donlon wrote: >Hi Olivier: >Just to remind us all (we need to get this agreed if possible as the >GHRSST-PP are working on a new set of documentation) and the large EU >MyOcean project will be using CF as a the baseline for ocean products. > >My comments on your summary mail are in line below. also attached is >the original proposal. Note that the operational GHRSST-PP community >is moving some 25Gb SST data in netCDF _each day_ using GHRSST-PP >definitions and that the World Meteorological Organisation has >accepted the proposed terms already. > >I hope we can resolve these issues as quickly as possible now. > >Regards, >Craig > > >Summary of proposal so Far (from Oliveier Laurent mail) > >> *SSTint (GHRSST-PP): surface_temperature (CF) >OK as we do not use this in operations but clarification on the >interface may still be useful in a description. > >> *SSTskin (GHRSST-PP): >> - sea_surface_temperature_in_skin_layer >> - skin_sea_surface_temperature >> - sea_skin_temperature? >> - sea_water_temperature with a depth attribute ? >We still propose skin_layer_sea_surface_temperature as in the >GHRSST-PP proposal. > >> *SSTsubskin (GHRSST-PP): >> - sea_surface_temperature_in_subskin_layer? >> - subskin_sea_surface_temperature? >> - sea_subskin_temperature? >> - sea_water_temperature with a depth attribute ? >> (same comments as for SSTskin) >I accept subskin_sea_surface_temperature > > >> *SSTdepth (GHRSST-PP): sea_water_temperature (CF) > >I'm happy with Alison and Nan suggestions regarding the use of >sea_water_temperature followed by a depth attribute. Without the >depth attribute the data are only of marginal use in data assimilation >systems and for blending. Many of the problems we have in the >satellite SST community today stem from the fact that depth was not >included as an essential component of the measurement. Now that some >satellite radiometers are providing more accurate and consistent >measurements of SST than can be obtained in situ (O'Carroll et al >JTECH, 2007) depth is essential!!) So to answer Alisons question > >"We already have the standard name sea_water_temperature which is >defined as follows: "For the temperature of sea water at a particular >depth or layer, a data variable of sea_water_temperature with a >vertical coordinate axis should be used." Would this meet your >needs?" The answer is YES it does and we will work on this within >GHRSST-PP. but The need for the depth information needs to be >mandatory can this be done? without depth it is somewhat >meaningless... > >> >> *SSTfnd (GHRSST-PP): >> - sea_surface_temperature_at_diurnal_thermocline_base >This is not correct. The main purpose of SSTfnd is to remove from the >vocabulary of >scientists the totally confusing and lazy term bulk SST which is >meaningless in the context of modern measurements, for data >assimilation and simply perpetuates confusion and erroneous >assumptions (Bit harsh, I know, but essentially true!)). To answer >Alison's question: > >"Does this mean that the foundation temperature is measured/modelled >at the base of the thermocline so that the values are intrinsically >free of diurnal variation [YES], or is the diurnal variation >statistically removed from the data [it could be - especially when >blending data for statistical analyses]?" The answer is yes in both >cases. I hope that a new 'surface' and associated name can be >introduced to represent this quantity which is the quantity that most >global SST analysis systems produce today. There is a nice figure >showing what SSTfnd is at >https://www.ghrsst-pp.org/SST-Definitions.html >So I would argue for foundation_sea_surface_temperature > >Original proposal========================================== >For the benefit of everyone concerned, here are the full definitions >(reported in Donlon et al., J Climate 2002 and updated and reported in >BAMS this August). The following is taken from >https://www.ghrsst-pp.org/SST-Definitions.html > > >SST is a difficult parameter to define exactly because the upper ocean >(~10 m) has a complex and variable vertical temperature structure that >is related to ocean turbulence and the air-sea fluxes of heat, >moisture and momentum. A framework is required to understand the >information content and relationships between measurements of SST made >by different satellite and in situ instruments, especially if these >are to be merged together. The definitions of SST developed by the >GHRSST-PP SST Science Team (agreed at the 2nd and 3rd GHRSST-PP >workshops) achieve the closest possible coincidence between what is >defined and what can be measured operationally, bearing in mind >current scientific knowledge and understanding of how the near surface >thermal structure of the ocean behaves in nature. > >The interface temperature (SSTint) >At the exact air-sea interface a hypothetical temperature called the >interface temperature (SSTint) is defined although this is of no >practical use because it cannot be measured using current technology. >(NOTE- this is probably not required but was included for >completeness) >[Proposed CF-names: SSTint, interface_SST, interface_sea_surface_temperature] > >The skin sea surface temperature (SSTskin) >The skin temperature (SSTskin) is defined as the temperature measured >by an infrared radiometer typically operating at wavelengths 3.7-12 ?m >(chosen for consistency with the majority of infrared satellite >measurements) that represents the temperature within the conductive >diffusion-dominated sub-layer at a depth of ~10-20 ?m. SSTskin >measurements are subject to a large potential diurnal cycle including >cool skin layer effects (especially at night under clear skies and low >wind speed conditions) and warm layer effects in the daytime. (NOTE: >Discussion on frequency is of secondary importance here - the main >issue is that the SSTskin is that retrieved using an infrared >radiometer) >[Proposed CF-names: SSTskin, skin_layer_SST, skin_layer_sea_surface_temperature] > > >The sub-skin sea surface temperature (SSTsub-skin) >The subskin temperature (SSTsubskin) represents the temperature at the >base of the conductive laminar sub-layer of the ocean surface. For >practical purposes, SSTsubskin can be well approximated to the >measurement of surface temperature by a microwave radiometer operating >in the 6-11 GHz frequency range, but the relationship is neither >direct nor invariant to changing physical conditions or to the >specific geometry of the microwave measurements. (NOTE: Discussion on >frequency is of secondary importance here - the main issue is that the >SSTsub-skin is that retrieved using a microwave radiometer) >[Proposed CF-names: SSTsubskin, Sub-skin_SST, sub-skin_sea_surface_temperature] > > >The surface temperature at depth (SSTz or SSTdepth) >All measurements of water temperature beneath the SSTsubskin are >referred to as depth temperatures (SSTdepth) measured using a wide >variety of platforms and sensors such as drifting buoys, vertical >profiling floats, or deep thermistor chains at depths ranging from >10-2 - 103m. These temperature observations are distinct from those >obtained using remote sensing techniques (SSTskin and SSTsubskin) and >must be qualified by a measurement depth in meters (e.g., or SST(z) >e.g. SST5m). > > > >The foundation temperature (SSTfnd) (Please look at figure provided at >https://www.ghrsst-pp.org/SST-Definitions.html to make sense of this) > The foundation SST, SSTfnd, is defined as the temperature of the >water column free of diurnal temperature variability (daytime warming >or nocturnal cooling) and is considered equivalent to the SSTsubskin >in the absence of any diurnal signal. It is named to indicate that it >is the foundation temperature from which the growth of the diurnal >thermocline develops each day (noting that on some occasions with a >deep mixed layer there is no clear SSTfnd profile in the surface >layer). Only in situ contact thermometry is able to measure SSTfnd and >analysis procedures must be used to estimate the SSTfnd from >radiometric satellite measurements of SSTskin and SSTsubskin. SSTfnd >provides a connection with the historical concept of a "bulk" SST >considered representative of the oceanic mixed layer temperature and >represented by any SSTdepth measurement within the upper ocean over a >depth range of 1-20+m. SSTfnd provides a more precise, well-defined >quantity than previous loosely defined "bulk" SST and consequently, a >better representation of the mixed layer temperature. In general, >SSTfnd will be similar to a night time minimum or pre-dawn value at >depths of ~1-5 m, but some differences could exist. Note that SSTfnd >does not imply a constant depth mixed layer, but rather a surface >layer of variable depth depending on the balance between >stratification and turbulent energy and is expected to change slowly >over the course of a day. >[Proposed CF-names: SSTfnd, Foundation_Temperature, >foundation_sea_surface_temperature] > > > > >I should note that I had a small WMO/IOC JCOMM task team set up as >part of the SOT to look at this a year or so ago which concluded at >this years SOT. The definitions presented above above were adopted by >the WMO CBS. I Hope this makes things clearer and more straight >forward and I sense that the main concern is with the in situ folk >regarding the details and not the principles behind SSTz. > > >-- >Dr Craig Donlon >Director of the International GODAE SST Pilot Project Office >Met Office Hadley Centre, >Fitzroy Road, Exeter, EX1 3PB United Kingdom > >Tel: +44 (0)1392 886622 Mob:07920 235750 >Fax:+44 (0)1392 885681 >Skype ID:crazit >SkypeIn: +44 0141 416 0882 >E-mail: craig.donlon at gmail.com >http://www.ghrsst-pp.org > >_______________________________________________ >CF-metadata mailing list >CF-metadata at cgd.ucar.edu >http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- ---------- John Graybeal -- 831-775-1956 Monterey Bay Aquarium Research Institute Marine Metadata Initiative: http://marinemetadata.org || Shore Side Data System: http://www.mbari.org/ssds From Frank.Toussaint at zmaw.de Thu Feb 14 23:46:17 2008 From: Frank.Toussaint at zmaw.de (Frank Toussaint) Date: Fri, 15 Feb 2008 07:46:17 +0100 Subject: [CF-metadata] CF-1.0 registration of new names for SST In-Reply-To: References: <6.1.1.1.2.20070822113949.0256f560@pop.cls.fr> <1f73fed70802140820w729069b4n54da13f7822af7e9@mail.gmail.com> Message-ID: <47B53539.7040101@zmaw.de> Dear colleagues, John Graybeal wrote: ... > By the way, "sea_water_temperature with a depth attribute" is fine; > it is the other terms/definitions that may be a little confusing. does this also account for the cases where the temperature is the (weighted?) mean value of the first 5, 10, 100, or 1000 centimeters? Best regards, ... frank -- /** Dr. Frank Toussaint Max-Planck-Institut f?r Meteorologie * Pfitznerstr. 69 M&D / World Data Center - Climate * 22761 Hamburg Bundesstr.53 - 20146 Hamburg * priv.Tel.: 040-3861 9285 office phone: +49-40-41173-175 * www.Leuchtturm-Atlas.de e-mail: Frank.Toussaint at zmaw.de */ From j.m.gregory at reading.ac.uk Fri Feb 15 00:56:57 2008 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Fri, 15 Feb 2008 07:56:57 +0000 Subject: [CF-metadata] CF-1.0 registration of new names for SST Message-ID: <20080215075657.GB25731@met.reading.ac.uk> Dear Frank > > By the way, "sea_water_temperature with a depth attribute" is fine; > > does this also account for the cases where the temperature is > the (weighted?) mean value of the first 5, 10, 100, or 1000 > centimeters? That would be descripted by an entry in cell_methods indicating a mean over the vertical coordinate, with the thickness of the layer being indicated by the bounds of the vertical coordinate. Cheers Jonathan From olauret at cls.fr Fri Feb 15 09:20:07 2008 From: olauret at cls.fr (olivier lauret) Date: Fri, 15 Feb 2008 17:20:07 +0100 Subject: [CF-metadata] CF-1.0 registration of new names for SST In-Reply-To: <20080214164041.GB24573@met.reading.ac.uk> References: <20080214