From aruane at ieng9.ucsd.edu Fri Jan 6 11:18:27 2006 From: aruane at ieng9.ucsd.edu (Alexander C Ruane) Date: Fri Jan 6 17:04:23 2006 Subject: [CF-metadata] New standard names proposal for ECPC CEOP data Message-ID: Hello, For ECPC-model-variables I (in discussion with Beate Geyer) propose the following new standard names: key: standard_name, ECPC_long_name; units surface_snow_sublimation_heat_flux, Snow Sublimation Heat Flux, W m-2 horizotal_enthalpy_transport_in_air, Enthalpy Flux Divergence, W m-2 horizotal_geopotential_energy_transport_in_air, Geopotential Flux Divergence, W m-2 horizotal_kinetic_energy_transport_in_air, Kinetic Energy Flux Divergence, W m-2 tendency_of_atmosphere_water_vapor_content_due_to_advection, Water Vapor Flux Divergence, kg m-2 s-1 enthalpy_content_of_atmosphere_layer, Mass Weighted Enthalpy, J m-2 potential_energy_of_atmosphere_layer, Geopotential Energy, J m-2 energy_of_atmosphere_layer, Total Mass Weighted Energy, J m-2 horizontal_energy_transport_in_air, Total Energy Flux Divergence, W m-2 horizontal_atmosphere_enthalpy_transport, Mass Weighted Enthalpy Flux Divergence, W m-2 horizontal_atmosphere_geopotential_energy_transport, Mass Weighted Geopot. Flux Div., W m-2 horizontal_atmosphere_kinetic_energy_transport, Kinetic Energy Flux Divergence, W m-2 tendency_of_atmosphere_water_vapor_content_due_to_advection, Water Vapor Flux Divergence, kg m-2 s-1 horizontal_atmosphere_energy_transport, Total Energy Flux Divergence, W m-2 atmosphere_rate_of_absorption_of_shortwave_energy, Shortwave heating rate, W m-2 atmosphere_rate_of_absorption_of_longwave_energy, Longwave heating rate, W m-2 eastward_atmosphere_water_vapor_transport_across_unit_distance, Water Vapor Zonal Flux, kg m-1 s-1 northward_atmosphere_water_vapor_transport_across_unit_distance, Water Vapor Meridional Flux, kg m-1 s-1 water_vapor_content_of_atmosphere_layer, specific humidity, kg m-2 kinetic_energy_content_of_atmosphere_layer, Mass Weighted Kinetic Energy, J m-2 baseflow_amount, surface runoff plus layer runoff minus baseflow, kg m-2 runoff_excluding_baseflow_amount, total runoff, kg m-2 rate_of_absorption_of_shortwave_energy, layer mean shortwave heating rate, W m-2 rate_of_absorption_of_longwave_energy, layer mean longwave heating rate, W m-2 eastward_water_vapor_transport_across_unit_distance_in_atmosphere_layer, Water Vapor Zonal Flux, kg m-1 s-1 northward_water_vapor_transport_across_unit_distance_in_atmosphere_layer, Water Vapor Meridional Flux, kg m-1 s-1 atmosphere_phis, Phis: energy resulting from shift in sigma-layer-definition with changing PS, J m-2 phis, Phis: energy resulting from shift in sigma-layer-definition with changing PS, J m-2 - 'total mass' means dry and moist and aerosols horizontal_total_mass_transport, Mass Flux Divergence, kg m-2 s-1 horizontal_atmosphere_total_mass_transport, Mass Flux Divergence, kg m-2 s-1 atmosphere_total_mass_content, Total Mass, kg m-2 rate_of_energy_released_by_deep_convection, Deep Convective Latent Heating Rate, W m-2 atmosphere_rate_of_energy_released_by_deep_convection, Deep Convective Latent Heating Rate, W m-2 rate_of_energy_released_by_shallow_convection, Shallow Convective Latent Heating Rate, W m-2 atmosphere_rate_of_energy_released_by_shallow_convection, Shallow Convective Latent Heating Rate, W m-2 rate_of_energy_released_by_large_scale_condensation, Stable Latent Heating Rate, W m-2 atmosphere_rate_of_energy_released_by_large_scale_condensation, Stable Latent Heating Rate, W m-2 tendency_of_air_temperature_due_to_turbulent_heating, Turbulent Heating Rate, W m-2 atmosphere_tendency_of_air_temperature_due_toturbulent_heating, Turbulent Heating Rate, W m-2 tendency_of_water_vapor_content_due_to_deep_convection, Deep Convective Moistening Rate, kg m-2 s-1 atmosphere_tendency_of_water_vapor_content_due_to_deep_convection, Deep Convective Moistening Rate, kg m-2 s-1 tendency_of_water_vapor_content_due_to_shallow_convection, Shallow Convective Moistening Rate, kg m-2 s-1 atmosphere_tendency_of_water_vapor_content_due_to_shallow_convection, Shallow Convective Moistening Rate, kg m-2 s-1 tendency_of_water_vapor_content_due_to_stable_convection, Stable Moistening Rate, kg m-2 s-1 atmosphere_tendency_of_water_vapor_content_due_to_stable_convection, Stable Moistening Rate, kg m-2 s-1 tendency_of_water_vapor_content_due_to_trubulence, Turbulent Moistening Rate, kg m-2 s-1 atmosphere_tendency_of_water_vapor_content_due_to_trubulence, Turbulent Moistening Rate, kg m-2 s-1 Please let me know if I can clear up any confusion or if there is anything further that I need to do. Thank you for your assistance! Sincerely, Alex Ruane From b.n.lawrence at rl.ac.uk Tue Jan 10 09:27:36 2006 From: b.n.lawrence at rl.ac.uk (Bryan Lawrence) Date: Tue Jan 10 09:27:48 2006 Subject: [CF-metadata] cf2 progress Message-ID: <200601101627.36339.b.n.lawrence@rl.ac.uk> Hi Folks I thought I should report that I hope to summarise the feedback on the whitepaper very shortly ... Meanwhile, the BADC is taking a few steps forward: Alison Pamment will be taking responsibility here for the CF name management (to try and relieve Jonathan). She'll be beginning one day a week from February, working up to three days a week in April. Her first activities will be: * Educating herself on CF, * Understanding how Jonathan has managed CF standard name evolution and in March we will move the standard name part of CF to the BADC (unless anyone has violent objections). Cheers Bryan -- Bryan Lawrence Director of Environmental Archival and Associated Research Head of the NCAS/British Atmospheric Data Centre CCLRC, Rutherford Appleton Laboratory Phone +44 1235 445012; Fax ... 5848; Web: home.badc.rl.ac.uk/lawrence From Steven.C.Hankin at noaa.gov Tue Jan 10 10:45:41 2006 From: Steven.C.Hankin at noaa.gov (Steve Hankin) Date: Tue Jan 10 10:44:57 2006 Subject: [CF-metadata] cf2 progress In-Reply-To: <200601101627.36339.b.n.lawrence@rl.ac.uk> References: <200601101627.36339.b.n.lawrence@rl.ac.uk> Message-ID: <43C3F2C5.1080107@noaa.gov> Hi Bryan, Congratulations! (Or should it be "Thanks"?) Anyway -- nice job moving this forward. Jonathan will enjoy his well deserved relief, I'm sure. - steve ==================================== Bryan Lawrence wrote: >Hi Folks > >I thought I should report that I hope to summarise the feedback on the >whitepaper very shortly ... > >Meanwhile, the BADC is taking a few steps forward: Alison Pamment will be >taking responsibility here for the CF name management (to try and relieve >Jonathan). She'll be beginning one day a week from February, working up to >three days a week in April. > >Her first activities will be: >* Educating herself on CF, >* Understanding how Jonathan has managed CF standard name evolution > >and in March we will move the standard name part of CF to the BADC (unless >anyone has violent objections). > >Cheers >Bryan > > > -- -- Steve Hankin, NOAA/PMEL -- Steven.C.Hankin@noaa.gov 7600 Sand Point Way NE, Seattle, WA 98115-0070 ph. (206) 526-6080, FAX (206) 526-6744 From j.m.gregory at reading.ac.uk Wed Jan 11 00:16:28 2006 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Wed Jan 11 00:20:19 2006 Subject: [CF-metadata] cf2 progress In-Reply-To: <43C3F2C5.1080107@noaa.gov> References: <200601101627.36339.b.n.lawrence@rl.ac.uk> <43C3F2C5.1080107@noaa.gov> Message-ID: <20060111071628.GA24777@met.reading.ac.uk> Dear Bryan > Anyway -- nice job moving this forward. Jonathan will enjoy his well > deserved relief, I'm sure. Indeed - and the users will enjoy faster response once Alison finds her feet! I'm glad she can start to work on it soon - thanks. Cheers Jonathan From j.m.gregory at reading.ac.uk Sun Jan 15 02:24:10 2006 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Sun Jan 15 02:24:30 2006 Subject: [CF-metadata] standard names to be added Message-ID: <20060115092410.GA2235@met.reading.ac.uk> Dear all The following proposed standard names result from email threads in November and December, initiated by Knut Lisaeter, Tony Jolibois and Keith Dixon. They will be added next week (Monday 23rd) unless anyone has further comments. Cheers Jonathan sea_ice_x_velocity:m s-1 sea_ice_y_velocity:m s-1 surface_downward_x_stress:Pa surface_downward_y_stress:Pa downward_x_stress_at_sea_ice_base:Pa downward_y_stress_at_sea_ice_base:Pa ocean_mixed_layer_thickness_defined_by_mixing_scheme:m ocean_mixed_layer_thickness_defined_by_temperature:m ocean_mixed_layer_thickness_defined_by_sigma_t:m ocean_mixed_layer_thickness_defined_by_sigma_theta:m integral_of_air_temperature_excess_wrt_time:K s integral_of_air_temperature_deficit_wrt_time:K s air_temperature_threshold:K From j.m.gregory at reading.ac.uk Sun Jan 15 06:02:43 2006 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Sun Jan 15 06:03:17 2006 Subject: [CF-metadata] New standard names proposal for ECPC CEOP data In-Reply-To: References: Message-ID: <20060115130243.GA4605@met.reading.ac.uk> Dear Alex Thanks for your proposals. We still have some outstanding issus from Beate's CEOP names, which have not been added to the standard name table yet. Can you help with my questions in my posting of 1st December on "standard names for CEOP"? We already have: water_vapor_content_of_atmosphere_layer:kg m-2 OK to add: surface_snow_sublimation_heat_flux:W m-2 tendency_of_atmosphere_water_vapor_content_due_to_advection:kg m-2 s-1 enthalpy_content_of_atmosphere_layer:J m-2 kinetic_energy_content_of_atmosphere_layer:J m-2 eastward_atmosphere_water_vapor_transport_across_unit_distance:kg m-1 s-1 northward_atmosphere_water_vapor_transport_across_unit_distance:kg m-1 s-1 eastward_water_vapor_transport_across_unit_distance_in_atmosphere_layer:kg m-1 s-1 northward_water_vapor_transport_across_unit_distance_in_atmosphere_layer:kg m-1 s-1 For these horizontal_enthalpy_transport_in_air:W m-2 horizontal_geopotential_energy_transport_in_air:W m-2 horizontal_kinetic_energy_transport_in_air:W m-2 we already have tendency_of_atmosphere_enthalpy_content_due_to_advection:W m-2 tendency_of_atmosphere_potential_energy_content_due_to_advection:W m-2 tendency_of_atmosphere_kinetic_energy_content_due_to_advection:W m-2 Are they what you want? If so, what is the difference between these and the set horizontal_atmosphere_enthalpy_transport:W m-2 horizontal_atmosphere_geopotential_energy_transport:W m-2 horizontal_atmosphere_kinetic_energy_transport:W m-2 You describe this set as "mass weighted" but I am unclear what distinction is being made. Modify potential_energy_of_atmosphere_layer:J m-2 to potential_energy_content_of_atmosphere_layer:J m-2 I'm not clear which "energy" is referred to in energy_of_atmosphere_layer:J m-2 horizontal_energy_transport_in_air:W m-2 horizontal_atmosphere_energy_transport:W m-2 Is it the moist energy? (See 1st December posting.) The following come in pairs. Is the first in each pair for an atmosphere layer? Is the shortwave absorption for upwelling or downwelling or both, the last being the difference between incoming and outgoing TOA SW? How do you define the longwave absorption, given that the atmosphere emits as well as absorbing? By the energy released by convection do you mean the latent heat released by condensation during convection (corresponding to large-scale)? In condensation do you include freezing? rate_of_absorption_of_shortwave_energy:W m-2 atmosphere_rate_of_absorption_of_shortwave_energy:W m-2 rate_of_absorption_of_longwave_energy:W m-2 atmosphere_rate_of_absorption_of_longwave_energy:W m-2 rate_of_energy_released_by_deep_convection:W m-2 atmosphere_rate_of_energy_released_by_deep_convection:W m-2 rate_of_energy_released_by_shallow_convection:W m-2 atmosphere_rate_of_energy_released_by_shallow_convection:W m-2 rate_of_energy_released_by_large_scale_condensation:W m-2 atmosphere_rate_of_energy_released_by_large_scale_condensation:W m-2 I am wondering whether we can use the word "power" in names for these quantities instead of "rate of X" where X is a kind of energy conversion. Power (strictly per unit area) is the correct physical term, of course, but not often used in meteorology. In these quantities baseflow_amount:kg m-2 runoff_excluding_baseflow_amount:kg m-2 does "baseflow" mean the flow in rivers which comes from groundwater? You define baseflow as "surface runoff plus layer runoff minus baseflow", which seems contradictory, and the second quantity appears to exclude baseflow a second time. I haven't grasped the distinctions you are making - could you clarify, please? You define both these quantities as "energy resulting from shift in sigma-layer-definition with changing PS". What is the distinction between the two of them? Perhaps the second is in a layer? atmosphere_phis:J m-2 phis:J m-2 Is this a commonly used quantity that needs a standard name? It is obviously a model quantity, not an observational one, but it should have a name if it is being compared among models. However, we would need to give it a more self-explanatory name than "phi_s". Could you please describe it in some more detail? You suggest "total mass" to mean the sum of dry and moist and aerosols. I think we could call this "mass". No doubt some models will attribute mass to the water and aerosols and others will not, but this vagueness could be useful. Although it is consistent with other names, it doesn't sound right to refer to the (total) mass as a "mass content". Instead of atmosphere_total_mass_content:kg m-2 I would propose the unusual atmosphere_mass_per_unit_area:kg m-2 Following other standard names, we would then have tendency_of_atmosphere_mass_per_unit_area_due_to_advection:kg m-2 s-1 instead of horizontal_total_mass_transport:kg m-2 s-1 horizontal_atmosphere_total_mass_transport:kg m-2 s-1 What is the difference between these last two? You define them both as "mass flux divergence". Perhaps the first is for a layer? tendency_of_air_temperature should be in K s-1, not W m-2. We don't need a pair of air_temperature tendency quantities to come in pairs, one with atmosphere_ and one without, since this is an intensive quantity, measured at a certain level or averaged through a layer. I would modify your proposals to tendency_of_air_temperature_due_to_turbulence:K s-1 tendency_of_atmosphere_water_vapor_content_due_to_deep_convection:kg m-2 s-1 tendency_of_atmosphere_water_vapor_content_due_to_shallow_convection:kg m-2 s-1 tendency_of_atmosphere_water_vapor_content_due_to_stable_convection:kg m-2 s-1 tendency_of_atmosphere_water_vapor_content_due_to_turbulence:kg m-2 s-1 tendency_of_water_vapor_content_of_atmosphere_layer_due_to_deep_convection:kg m-2 s-1 tendency_of_water_vapor_content_of_atmosphere_layer_due_to_shallow_convection:kg m-2 s-1 tendency_of_water_vapor_content_of_atmosphere_layer_due_to_stable_convection:kg m-2 s-1 tendency_of_water_vapor_content_of_atmosphere_layer_due_to_turbulence:kg m-2 s-1 Could you define what "turbulence" and "stable convection" mean, please? Thanks for your help. Best wishes Jonathan From Beate.Geyer at gkss.de Tue Jan 17 01:17:47 2006 From: Beate.Geyer at gkss.de (Beate.Geyer@gkss.de) Date: Tue Jan 17 01:16:20 2006 Subject: [CF-metadata] cell methods: interval differs from interval given by time bounds Message-ID: Dear cf-community, I want to write 2m Maximum Temperature which is given hourly into cf-standard. The maximum is calculated taking the last 3 hours into account. 'cell_methods' time: 3h maximum is not accepted by the compliance checker - what would be the correct way? Thanks for your help, Beat Geyer ==================================================== Dr. Beate Geyer GKSS Research Centre Institute for Coastal Research Max-Planck-Str. D-21502 Geesthacht, Germany E-Mail: Beate.Geyer@gkss.de ==================================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.cgd.ucar.edu/pipermail/cf-metadata/attachments/20060117/061b998c/attachment.html From j.m.gregory at reading.ac.uk Tue Jan 17 01:51:38 2006 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Tue Jan 17 01:51:43 2006 Subject: [CF-metadata] cell methods: interval differs from interval given by time bounds Message-ID: <20060117085138.GC3412@met.reading.ac.uk> Dear Beat This is described in CF 7.3. The format of cell_methods is time: maximum (interval: 1 h) to record the original temporal resolution of the data, and the cell bounds should indicate intervals of 3 h over which the maximum has been calculated. Cheers Jonathan > I want to write 2m Maximum Temperature which is given hourly into > cf-standard. The maximum is calculated taking the last 3 hours into > account. > 'cell_methods' time: 3h maximum > is not accepted by the compliance checker - what would be the correct way? From b.n.lawrence at rl.ac.uk Wed Jan 18 04:45:43 2006 From: b.n.lawrence at rl.ac.uk (Bryan Lawrence) Date: Wed Jan 18 04:45:49 2006 Subject: [CF-metadata] cf2 progress In-Reply-To: <200601101627.36339.b.n.lawrence@rl.ac.uk> References: <200601101627.36339.b.n.lawrence@rl.ac.uk> Message-ID: <200601181145.43219.b.n.lawrence@rl.ac.uk> On Tuesday 10 January 2006 16:27, Bryan Lawrence wrote: > Hi Folks > > I thought I should report that I hope to summarise the feedback on the > whitepaper very shortly ... Rather than summarise feedback, i've put it (nearly) verbatim on my wiki at http://home.badc.rl.ac.uk/lawrence/cf2responses (Obviously we'll copy this stuff onto a CF wiki/forum at some future time). Any further feedback, either via email, or as comments on that page, are welcome, but formally now, the CF authors should decide whether these existing responses require any change of tack. We're slightly behind our timetable (step one has taken two months, thanks to my tardiness). My take on the responses is that the major issues are to - nail down governance expectations - make best use of external structures and there are a number of useful specific suggestions to think about, but there is no show-stopping feedback. Cheers Bryan -- Bryan Lawrence Director of Environmental Archival and Associated Research Head of the NCAS/British Atmospheric Data Centre CCLRC, Rutherford Appleton Laboratory Phone +44 1235 445012; Fax ... 5848; Web: home.badc.rl.ac.uk/lawrence From Beate.Geyer at gkss.de Thu Jan 19 02:59:55 2006 From: Beate.Geyer at gkss.de (Beate.Geyer@gkss.de) Date: Thu Jan 19 02:59:00 2006 Subject: [CF-metadata] proposals for new standard names for soil and vegetation parameters Message-ID: Dear cf-metadata, I propose following new standard names for soil and vegetation parameters (standard_name; long_name; unit): soil_suction_at_saturation; Saturation soil suction; m soil_hydraulic_conductivity_at_saturation; Saturation hydraulic conductivity; m s-1 soil_texture; fraction of sand, clay and silt; 1 stomatal resistance depends on vegetation type, it is not clear to me, how to include min and max into standard name: stomatal_resistance; Maximum stomatal resistance; s m-1 stomatal_resistance; Minimum stomatal resistance; s m-1 Thanks for your help, Beate ==================================================== Dr. Beate Geyer GKSS Research Centre Institute for Coastal Research Max-Planck-Str. D-21502 Geesthacht, Germany E-Mail: Beate.Geyer@gkss.de ==================================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.cgd.ucar.edu/pipermail/cf-metadata/attachments/20060119/5cbc5547/attachment.html From j.m.gregory at reading.ac.uk Wed Jan 25 08:42:08 2006 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Wed Jan 25 08:42:23 2006 Subject: Fwd: [CF-metadata] proposals for new standard names for soil and vegetation parameters Message-ID: <20060125154208.GA11263@met.reading.ac.uk> Dear Beat > soil_suction_at_saturation; Saturation soil suction; m I am not sufficiently expert to define this. Could you please supply a definition of soil suction? > soil_hydraulic_conductivity_at_saturation; Saturation hydraulic > conductivity; m s-1 OK. > soil_texture; fraction of sand, clay and silt; 1 We have recently added a string-valued quantity soil_type to identify types such as you list. It looks as if you would like to specify some parameter as a function of soil type. Is it the mass fraction of the soil? > stomatal resistance depends on vegetation type, it is not clear to me, how > to include min and max into standard name: > stomatal_resistance; Maximum stomatal resistance; s m-1 > stomatal_resistance; Minimum stomatal resistance; s m-1 I suppose this could be indicated by cell_methods "vegetation_type: maximum". We have not got standard names for stomatal resistance and vegetation type. Are you proposing these? Cheers Jonathan From Burkhardt.Rockel at gkss.de Fri Jan 27 02:56:53 2006 From: Burkhardt.Rockel at gkss.de (Burkhardt.Rockel@gkss.de) Date: Fri Jan 27 02:57:54 2006 Subject: [CF-metadata] snow temperature Message-ID: Dear All, I need to define the surface temperature (i.e. the temperature at the interface between snow and atmosphere, this is NOT the bulk snow temperature) for the part of the model grid box covered by snow. I propose a the following standard name for it: surface_temperature_where_snow (K) is this ok? Regards Burkhardt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.cgd.ucar.edu/pipermail/cf-metadata/attachments/20060127/79aa5117/attachment-0001.html From taylor13 at llnl.gov Fri Jan 27 09:58:10 2006 From: taylor13 at llnl.gov (Karl Taylor) Date: Fri Jan 27 09:58:14 2006 Subject: [CF-metadata] snow temperature In-Reply-To: References: Message-ID: <43DA5122.1050201@llnl.gov> Dear all, Actually, the standard name "surface_temperature" refers, I believe, to the "skin" temperature at the interface between the atmosphere, and whatever solid or liquid surface underlies it (i.e., sea ice, ocean, snow, glacial ice, bare land, vegetated land, etc), so surface_temperature and surface_temperature_where_snow would be identical if an entire region were snow covered. If you have a grid-cell (or a larger region) over which you want to characterize a snow surface temperature, distinct from the temperature of the snow-free portion, then we do indeed need a new name. I note that we define sea_surface_temperature, so that we can characterize ocean surface temperature distinct from surface temperature where there is seaice or land. Actually, I am not absolutely sure whether sea_surface_temperature should be an average of the surface temperature of the ocean only in areas where it is in direct contact with the atmosphere, or if the surface of the ocean under sea ice (presumably at the freezing point) should also contribute. I would vote for the first definition. regards, Karl Burkhardt.Rockel@gkss.de wrote: > > Dear All, > > I need to define the surface temperature (i.e. the temperature at the > interface between snow and atmosphere, this is NOT the bulk snow > temperature) for the part of the model grid box covered by snow. > I propose a the following standard name for it: > > surface_temperature_where_snow (K) > > is this ok? > > Regards > Burkhardt > > > > ------------------------------------------------------------------------ > > _______________________________________________ > CF-metadata mailing list > CF-metadata@cgd.ucar.edu > http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata From Burkhardt.Rockel at gkss.de Fri Jan 27 10:46:14 2006 From: Burkhardt.Rockel at gkss.de (Burkhardt.Rockel@gkss.de) Date: Fri Jan 27 10:46:37 2006 Subject: Antwort: Re: [CF-metadata] snow temperature In-Reply-To: <43DA5122.1050201@llnl.gov> Message-ID: Karl, thank you for the prompt reply. > If you have a > grid-cell (or a larger region) over which you want to characterize a > snow surface temperature, distinct from the temperature of the snow-free > portion, then we do indeed need a new name. exactly that is why I proposed the name. I constructed it similar to already existing standard names, for example: "surface_snow_thickness_where_sea_ice The surface called "surface" means the lower boundary of the atmosphere; over sea areas this is taken to be mean sea level. Unless indicated, a quantity is assumed to apply to the whole area of each horizontal grid box. The qualifier where_type specifies instead that the quantity applies only to the part of the grid box of the named type." Regards, Burkhardt Karl Taylor schrieb am 27.01.2006 17:58:10: > Dear all, > > Actually, the standard name "surface_temperature" refers, I believe, to > the "skin" temperature at the interface between the atmosphere, and > whatever solid or liquid surface underlies it (i.e., sea ice, ocean, > snow, glacial ice, bare land, vegetated land, etc), so > surface_temperature and surface_temperature_where_snow would be > identical if an entire region were snow covered. If you have a > grid-cell (or a larger region) over which you want to characterize a > snow surface temperature, distinct from the temperature of the snow-free > portion, then we do indeed need a new name. > > I note that we define sea_surface_temperature, so that we can > characterize ocean surface temperature distinct from surface temperature > where there is seaice or land. Actually, I am not absolutely sure > whether sea_surface_temperature should be an average of the surface > temperature of the ocean only in areas where it is in direct contact > with the atmosphere, or if the surface of the ocean under sea ice > (presumably at the freezing point) should also contribute. I would vote > for the first definition. > > regards, > Karl > > Burkhardt.Rockel@gkss.de wrote: > > > > Dear All, > > > > I need to define the surface temperature (i.e. the temperature at the > > interface between snow and atmosphere, this is NOT the bulk snow > > temperature) for the part of the model grid box covered by snow. > > I propose a the following standard name for it: > > > > surface_temperature_where_snow (K) > > > > is this ok? > > > > Regards > > Burkhardt > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > CF-metadata mailing list > > CF-metadata@cgd.ucar.edu > > http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.cgd.ucar.edu/pipermail/cf-metadata/attachments/20060127/1bfe9f80/attachment.html From taylor13 at llnl.gov Fri Jan 27 11:11:10 2006 From: taylor13 at llnl.gov (Karl Taylor) Date: Fri Jan 27 11:11:13 2006 Subject: Antwort: Re: [CF-metadata] snow temperature In-Reply-To: References: Message-ID: <43DA623E.2070509@llnl.gov> Burkhardt, yes, makes sense to me. I'm sure Jonathan Gregory will weigh in on this too. I just noticed in the description of "surface" you quoted below, it says "over sea areas this is taken to be the mean sea level". This should perhaps read "over *ice-free* sea areas this is taken to be the mean sea level". Karl Burkhardt.Rockel@gkss.de wrote: > > Karl, thank you for the prompt reply. > > > If you have a > > grid-cell (or a larger region) over which you want to characterize a > > snow surface temperature, distinct from the temperature of the snow-free > > portion, then we do indeed need a new name. > > exactly that is why I proposed the name. > I constructed it similar to already existing standard names, for example: > > "surface_snow_thickness_where_sea_ice > The surface called "surface" means the lower boundary of the atmosphere; > over sea areas this is taken to be mean sea level. Unless indicated, a > quantity is assumed to apply to the whole area of each horizontal grid > box. The qualifier where_/type/ specifies instead that the quantity > applies only to the part of the grid box of the named /type/." > > Regards, > Burkhardt > > > Karl Taylor schrieb am 27.01.2006 17:58:10: > > > Dear all, > > > > Actually, the standard name "surface_temperature" refers, I believe, to > > the "skin" temperature at the interface between the atmosphere, and > > whatever solid or liquid surface underlies it (i.e., sea ice, ocean, > > snow, glacial ice, bare land, vegetated land, etc), so > > surface_temperature and surface_temperature_where_snow would be > > identical if an entire region were snow covered. If you have a > > grid-cell (or a larger region) over which you want to characterize a > > snow surface temperature, distinct from the temperature of the snow-free > > portion, then we do indeed need a new name. > > > > I note that we define sea_surface_temperature, so that we can > > characterize ocean surface temperature distinct from surface temperature > > where there is seaice or land. Actually, I am not absolutely sure > > whether sea_surface_temperature should be an average of the surface > > temperature of the ocean only in areas where it is in direct contact > > with the atmosphere, or if the surface of the ocean under sea ice > > (presumably at the freezing point) should also contribute. I would vote > > for the first definition. > > > > regards, > > Karl > > > > Burkhardt.Rockel@gkss.de wrote: > > > > > > Dear All, > > > > > > I need to define the surface temperature (i.e. the temperature at the > > > interface between snow and atmosphere, this is NOT the bulk snow > > > temperature) for the part of the model grid box covered by snow. > > > I propose a the following standard name for it: > > > > > > surface_temperature_where_snow (K) > > > > > > is this ok? > > > > > > Regards > > > Burkhardt > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > CF-metadata mailing list > > > CF-metadata@cgd.ucar.edu > > > http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > CF-metadata mailing list > CF-metadata@cgd.ucar.edu > http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata From j.m.gregory at reading.ac.uk Tue Jan 31 08:57:39 2006 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Tue Jan 31 09:26:01 2006 Subject: [CF-metadata] snow temperature Message-ID: <20060131155739.GB9298@met.reading.ac.uk> Dear Burkhardt and Karl (1) Yes, I agree that surface_temperature_where_snow should be the name for the quantity you describe. I will add it to the list. (2) "Sea surface" temperature is a special name, which we retained because it is the customary name for this observational quantity, even though it is not the temperature at the surface, but that of some rather poorly defined level where ships measure it (usually through cooling water intake). The skin temperature at the surface of the sea is surface_temperature (same as snow and any other surface). (3) "Mean sea level" means a particular geodetic surface, regardless of sea ice. Best wishes Jonathan From j.m.gregory at reading.ac.uk Sun Feb 5 17:26:36 2006 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Sun Feb 5 17:26:44 2006 Subject: [CF-metadata] standard names added Message-ID: <20060206002636.GA17995@met.reading.ac.uk> The following standard names have been added to the table, following requests from Knut Lisaeter, Tony Jolibois, Keith Dixon and Burkhardt Rockel, and corrections have been made to some equivalences with ECMWF GRIB codes, thanks to Martin Koehler. Jonathan sea_ice_x_velocity:m s-1 sea_ice_y_velocity:m s-1 surface_downward_x_stress:Pa surface_downward_y_stress:Pa downward_x_stress_at_sea_ice_base:Pa downward_y_stress_at_sea_ice_base:Pa ocean_mixed_layer_thickness_defined_by_mixing_scheme:m ocean_mixed_layer_thickness_defined_by_temperature:m ocean_mixed_layer_thickness_defined_by_sigma_t:m ocean_mixed_layer_thickness_defined_by_sigma_theta:m integral_of_air_temperature_excess_wrt_time:K s integral_of_air_temperature_deficit_wrt_time:K s air_temperature_threshold:K surface_temperature_where_snow:K From Beate.Geyer at gkss.de Tue Feb 7 00:51:34 2006 From: Beate.Geyer at gkss.de (Beate.Geyer@gkss.de) Date: Tue Feb 7 00:49:40 2006 Subject: [CF-metadata] proposals for new standard names (ECMWF-GCM) Message-ID: Dear cf-metadata, I propose following new standard names (for ECMWF-GCM-data, discussed with Martin Koehler): standard name, long name, units dry_static_energy_flux_due_to_diffusion, T flux: Vert diffusion, W m-2 specific_humidity_flux_due_to_diffusion, Q flux: Vert diffusion, kg m-2 s-1 eastward_momentum_flux_due_to_diffusion, U flux: Vert diffusion, Pa northward_momentum_flux_due_to_diffusion, V flux: Vert diffusion, Pa water_evaporation_amount_from_canopy, Intercepted water evap, kg m-2 liquid_water_content_of_soil_layer, Soil water, kg m-2 surface_roughness_length_of_momentum, surface roughness length momentum, 1 surface_roughness_length_of_heat, surface roughness length heat, 1 snow_basal_heat_flux, Snow basal heat flux, W m-2 surface_snow_melt_and_sublimation_heat_flux,Snow phase change energy, W m-2 for evaporation from Snow (not Ice) surface_snow_sublimation_amount, Snow evaporation, kg m-2 Thanks for your help, Beate Geyer ==================================================== Dr. Beate Geyer GKSS Research Centre Institute for Coastal Research Max-Planck-Str. D-21502 Geesthacht, Germany E-Mail: Beate.Geyer@gkss.de Phone: 04152-871871 ==================================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.cgd.ucar.edu/pipermail/cf-metadata/attachments/20060207/ec6ad313/attachment-0001.html From j.m.gregory at reading.ac.uk Tue Feb 7 02:47:26 2006 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Tue Feb 7 02:47:30 2006 Subject: [CF-metadata] proposals for new standard names (ECMWF-GCM) Message-ID: <20060207094726.GB14634@met.reading.ac.uk> Dear Beate > dry_static_energy_flux_due_to_diffusion, T flux: Vert diffusion, W m-2 needs upward_ or downward_ as a prefix. We can include both. > specific_humidity_flux_due_to_diffusion, Q flux: Vert diffusion, kg m-2 > s-1 We already have upward_water_vapor_flux_in_air, so I think this new quantity should be upward_water_vapor_flux_in_air_due_to_diffusion. (It doesn't have the right units to be a "specific humidity flux"; since specific humidity is dimensionless, so a flux of it would have units m-2 s-1.) We can add both upward_ and downward_. > eastward_momentum_flux_due_to_diffusion, U flux: Vert diffusion, Pa > northward_momentum_flux_due_to_diffusion, V flux: Vert diffusion, Pa A momentum flux is called a stress in existing standard names. We have names of atmosphere_eastward|northward_stress_due_to_gravity_wave_drag, so these new quantities could be atmosphere_eastward|northward_stress_due_to_diffusion, correspondingly. OK > water_evaporation_amount_from_canopy, Intercepted water evap, kg m-2 > liquid_water_content_of_soil_layer, Soil water, kg m-2 > surface_snow_melt_and_sublimation_heat_flux,Snow phase change energy, W > m-2 > for evaporation from Snow (not Ice) > surface_snow_sublimation_amount, Snow evaporation, kg m-2 I wish I could think of a single word for "melt and sublimation"! OK except I think we should have _for_ instead of _of_. I propose that the roughness length names ought similarly to have _for_. > surface_roughness_length_of_momentum, surface roughness length momentum, > 1 > surface_roughness_length_of_heat, surface roughness length heat, 1 > snow_basal_heat_flux, Snow basal heat flux, W m-2 Is this the heat flux into or out of the ground? That is, does it relate specifically to snow? If not, we could relate this to the existing name downward_heat_flux_in_soil. I would propose upward|downward_heat_flux_at_ground_level_in_snow|soil with the _in_ part indicating whether measured/calculated on the snow or the soil side of the interface. Best wishes Jonathan From caron at unidata.ucar.edu Tue Feb 7 08:05:46 2006 From: caron at unidata.ucar.edu (John Caron) Date: Tue Feb 7 08:05:53 2006 Subject: [CF-metadata] Announce: Common Data Model Coordinate System validation Message-ID: <43E8B74A.60900@unidata.ucar.edu> An experimental web service is available that examines NetCDF files and tries to validate their use of Conventions such as CF-1.0 for gridded data. We will be improving this in the future based on user experience and feedback, and we will make it a part of the THREDDS Data Server. Please have a look and send any comments to me (or to this list): http://motherlode.ucar.edu:9080/thredds/cdmValidate.html Thanks! From caron at unidata.ucar.edu Tue Feb 7 11:38:22 2006 From: caron at unidata.ucar.edu (John Caron) Date: Tue Feb 7 11:38:27 2006 Subject: [CF-metadata] Announce: Common Data Model Coordinate System validation Message-ID: <43E8E91E.6000401@unidata.ucar.edu> Sorry, the original seems to have been munged: An experimental web service is available that examines NetCDF files and tries to validate their use of Conventions such as CF-1.0 for gridded data. We will be improving this in the future based on user experience and feedback, and we will make it a part of the THREDDS Data Server. Please have a look and send any comments to me (or to this list): http://motherlode.ucar.edu:9080/thredds/cdmValidate.html Thanks! From Bert.Jagers at wldelft.nl Tue Feb 7 12:17:25 2006 From: Bert.Jagers at wldelft.nl (Bert Jagers) Date: Tue Feb 7 12:17:32 2006 Subject: [CF-metadata] CF2 and standard names References: <20060207094726.GB14634@met.reading.ac.uk> Message-ID: <010201c62c1b$214c8580$ebe20991@wl06377> Dear CF-metadata list members, Recently I have been looking into the usage of netCDF for storing model output. Although we have agreed that netCDF4 will be the most appropriate file format around for output of civil engineering/environmental models, there still remain a lot of issues to resolve for storing output data of an integrated 1D,2D,3D modelling system using staggered (possibly multiple interconnected, structured or unstructured) grids/meshes. So, I'm very interested in the developments regarding CF2 conventions that seem to address most of these issues. For the time being we focus on netCDF3.6 and CF1.0 conventions as far as they allow us to standardise. However, when it comes to the use of standard names, I'm still not certain what to do. Although I do understand that some kind of standardisation can be helpful for users to understand model output from various sources and as such it may be a valuable source of information when setting up a coupling between model components of different origin, I feel a bit uneasy about introducing the standard name "sea_surface_height_above_sea_level" in the output of modelling systems that have so far been using "water level" or similarly simple looking phrasings. So far, I have come up with two reasons against it. The first (I admit, subjective) reason is that as a river engineer I don't think of the water level in a river at some distance from the coast as the "sea_surface_height_above_sea_level"; let alone when it comes to the water level in rural channels, flood levels in urban areas, and water levels in sewer systems. I have seen a recent discussion on the use of the name "lake" as an alternative for "sea" for some particular applications, but the output of one continuous integrated model from river via estuary to sea should have one unique name as it is one data set; we cannot differentiate between river_surface_height and sea_surface_height. Neither should it be model run dependent (no different name for model output depending on modelled area or user). I expect that this subjective reason may also work the other way: you may not want to introduce such "pollution" in the usage of the existing names (but I am not sure about that). The second reason is that the reference level is not everywhere the same: a river in Tibet may be modelled using a completely different reference level than a lowland river like the Rhine or the Mississippi. This issues is still relevant for coastal areas as different countries tend to use different reference levels as mean sea level, there is still a few centimetres difference between the Dutch NAP and the German NN. Similar differences occur in the horizontal direction when it comes to coordinate systems and conversions. One may thus suggest to introduce a quantity like "water_surface_height_above_reference_level" and require some specification of the reference level. However, the question can be extended to other related quantities like sea_water_x_velocity and other similar quantities. So, in the end my questions are: (1) what are the main reasons for using standard names (2) does it make sense to use such naming conventions for an integrated 1D,2D,3D modelling system that is used from urban areas to coastal seas and beyond (coupled to hydrological, groundwater and/or meteorological models). (3) or, wouldn't it be better to define a name space and some mapping as has been suggested in relation to CF2 standards I would be very interested in your ideas in this matter either via a reply to this list or via a direct reply to me if you prefer. Best regards, Bert Jagers technical coordinator Delft3D & SOBEK software development WL | Delft Hydraulics The Netherlands http://www.wldelft.nl From j.m.gregory at reading.ac.uk Tue Feb 7 12:47:01 2006 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Tue Feb 7 12:47:05 2006 Subject: [CF-metadata] CF2 and standard names Message-ID: <20060207194701.GA2624@met.reading.ac.uk> Dear Bert Thanks for your questions. > when it comes to the use of standard names, I'm still not certain what to do. Standard names, like most features of CF, are optional. You don't have to use them if you don't think they will help you. > some kind of standardisation can > be helpful for users to understand model output from various sources and as > such it may be a valuable source of information when setting up a coupling > between model components of different origin That is the first reason to your question > (1) what are the main reasons for using standard names It's not only for coupling, but for any activity where data from different sources is to be brought together, for example in the comparative analysis of data from various climate models. The second reason is that within a data source, standard names may be a convenient and precise help in distinguishing among quantities. > I feel a bit uneasy about > introducing the standard name "sea_surface_height_above_sea_level" in the > output of modelling systems that have so far been using "water level" or > similarly simple looking phrasings. You know what you mean by "water level" in the context of your own model, but the standard name is a more precise description of a particular quantity. However, it may not be the quantity you want, or precise enough for your purposes. We should introduce further standard names which are more appropriate for other kinds of application, as they arise. There is an awkwardness about "lake", "sea" and "river" which we haven't properly dealt with yet. The choice of "sea" reflects the origin of the standard names. Some word was needed to distinguish water in the atmosphere (as cloud or vapour) from water in the ocean. > reference level is not everywhere the same: a > river in Tibet may be modelled using a completely different reference level > than a lowland river like the Rhine or the Mississippi. Quite right. It has previously been proposed that we should have a facility, via a standard name parameter, to specify the reference surface. This is not necessary in all applications (for instance in climate models, which have idealised Earth geometry), so it should be optional. Different kinds of application require different levels of precision, so standard naming has to offer such levels. > (3) or, wouldn't it be better to define a name space and some mapping as has > been suggested in relation to CF2 standards If sufficiently precise names exist in other domains, we could devise some way of mapping them into the standard name space. This would save effort and duplication in the community. However we have to be careful that in doing this we don't accidentally allow different domains to give alternative names to the same quantity without the equivalence being noted, because if that happened the names would not be useful for their original purpose of indicating which data are comparable. Best wishes Jonathan From caron at unidata.ucar.edu Tue Feb 7 18:03:56 2006 From: caron at unidata.ucar.edu (John Caron) Date: Tue Feb 7 18:04:10 2006 Subject: [CF-metadata] Announce: Common Data Model Coordinate System validation In-Reply-To: <20060207152908.GA28367@met.reading.ac.uk> References: <43E8B74A.60900@unidata.ucar.edu> <20060207152908.GA28367@met.reading.ac.uk> Message-ID: <43E9437C.9020903@unidata.ucar.edu> Jonathan Gregory wrote: > Dear John > > >>An experimental web service is available that examines NetCDF files and >>tries to validate their use of Conventions such as CF-1.0 for gridded data. >>We will be improving this in the future based on user experience and >>feedback, and we will make it a part of the THREDDS Data Server. > > > Does this do the same kind of job as the CF checker (on the CF website) i.e. > verify the adherence to the CF conformance document (also on the CF website)? > Judging from the amount of feedback we get, the CF checker is pretty well used. Hi Jonathan: Thats a good question. The CF checker (http://titania.badc.rl.ac.uk/cgi-bin/cf-checker.pl) is much improved since I last looked, and I will add a link to it from my page. The TDS tool is not a general-purpose CF-1.0 compliance checker, but more of a practical tool that identifies the variables for which it can identify georefrencing coordinate systems, using CF-1.0 or other Conventions that it knows about (COARDS, etc). This accurately indicates what will be viewable in applications like the IDV that use the Netcdf-Java library. It currently only works on griddded data. My goal is to add better messages to indicate how to fix any problems, but that's a long way off. I would expect the two tools to be complementary, and I will be comparing the output with the CF checker to try to improve my tool. Regards, John From grosst at si.edu Wed Feb 8 08:30:18 2006 From: grosst at si.edu (Gross, Tom) Date: Wed Feb 8 08:30:24 2006 Subject: [CF-metadata] CF2 and standard names Message-ID: At the NOAA Coast Survey Development Laboratory, we have been developing a tool to transform between different vertical datums such as Sea Level, Mean Lower Low Water, NAD-83, NAVD 88 etc. etc. http://nauticalcharts.noaa.gov/csdl/Vdatum.htm Given the wealth of datums available, I am of the opinion that a surface such as, "sea_surface_height", should not include the datum in the standard name. It is an attribute of the variable. I would much rather have a codified attribute sea_surface_height:Datum="sea_level" . This affords the ability to include the datum transformation variable to be included elsewhere in the netcdf file Variable ZETA(time,nx,ny) ZETA:Datum="sea_level" Variable MLLW(nx,ny) MLLW:Standard_Name="Mean_Lower_Low_Water" MLLW:Datum="sea_level" Variable NAD83(nx,ny) NAD83:Standard_Name="NAD_83" NAD83:Datum="sea_level" This allows the user to transform ZETA out of "sea_level" to MLLW or NAD_83 by a subtraction. PS It is a very important fact that the MLLW datum is not spatially constant. This is the whole problem with creating coherent digital elevation models that join the NOAA/OCS hydrography with USGS topography data. Tom Gross Chesapeake Community Model Program ccmp.chesapeake.org Chesapeake Research Consortium P.O. Box 28 645 Contees Wharf Road Edgewater, MD temporary Phone: 443 482 2200 x2490 410-798-1283 or on Monday and Tuesdays tom.gross@noaa.gov NOAA/NOS/Coast Survey Development Lab. Silver Spring, MD (301) 713-2809 x139 -----Original Message----- From: cf-metadata-bounces@cgd.ucar.edu [mailto:cf-metadata-bounces@cgd.ucar.edu] On Behalf Of Jonathan Gregory Sent: Tuesday, February 07, 2006 2:47 PM To: cf-metadata@cgd.ucar.edu Subject: [CF-metadata] CF2 and standard names Dear Bert Thanks for your questions. > when it comes to the use of standard names, I'm still not certain what to do. Standard names, like most features of CF, are optional. You don't have to use them if you don't think they will help you. > some kind of standardisation can > be helpful for users to understand model output from various sources and as > such it may be a valuable source of information when setting up a coupling > between model components of different origin That is the first reason to your question > (1) what are the main reasons for using standard names It's not only for coupling, but for any activity where data from different sources is to be brought together, for example in the comparative analysis of data from various climate models. The second reason is that within a data source, standard names may be a convenient and precise help in distinguishing among quantities. > I feel a bit uneasy about > introducing the standard name "sea_surface_height_above_sea_level" in the > output of modelling systems that have so far been using "water level" or > similarly simple looking phrasings. You know what you mean by "water level" in the context of your own model, but the standard name is a more precise description of a particular quantity. However, it may not be the quantity you want, or precise enough for your purposes. We should introduce further standard names which are more appropriate for other kinds of application, as they arise. There is an awkwardness about "lake", "sea" and "river" which we haven't properly dealt with yet. The choice of "sea" reflects the origin of the standard names. Some word was needed to distinguish water in the atmosphere (as cloud or vapour) from water in the ocean. > reference level is not everywhere the same: a > river in Tibet may be modelled using a completely different reference level > than a lowland river like the Rhine or the Mississippi. Quite right. It has previously been proposed that we should have a facility, via a standard name parameter, to specify the reference surface. This is not necessary in all applications (for instance in climate models, which have idealised Earth geometry), so it should be optional. Different kinds of application require different levels of precision, so standard naming has to offer such levels. > (3) or, wouldn't it be better to define a name space and some mapping as has > been suggested in relation to CF2 standards If sufficiently precise names exist in other domains, we could devise some way of mapping them into the standard name space. This would save effort and duplication in the community. However we have to be careful that in doing this we don't accidentally allow different domains to give alternative names to the same quantity without the equivalence being noted, because if that happened the names would not be useful for their original purpose of indicating which data are comparable. Best wishes Jonathan _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata From keup at dkrz.de Wed Feb 8 08:20:02 2006 From: keup at dkrz.de (Elke Keup) Date: Wed Feb 8 09:18:59 2006 Subject: [CF-metadata] request for new netCDF standart names Message-ID: <43EA0C22.5020206@dkrz.de> Dear colleagues, I want to make an application for a few more standart names I missed in the netCDF standart name table. 1. forest_area_fraction It describes the part of the grid volume covered with forest, MKS unit=1 2. skin_reservoir_content A part of this quantity is the canopy water amount but additionally this quantity contains the wetting of the bare soil. MKS unit=m 3. frozen_soil_fraction This quantity describes the part of the soil which is frozen, MKS unit=1 4. surface_snow_amount_change This quantity describes the change of the snow amount at the surface, MKS unit=kg/m**2 Please inform me wether it's possible for you to add these 4 quantities to the standart name table. Thank's a lot. Kindly Regards Elke Keup-Thiel o---o---o---o---o---o---o---o---o---o---o---o---o---o---o---o---o Dr. Elke Keup-Thiel Max-Planck-Institut fuer Meteorologie Bundesstrasse 53 D-20146 Hamburg Tel: +49 40 41173 406 Fax: +49 40 41173 476 E-mail: keup@dkrz.de sga@dkrz.de o---o---o---o---o---o---o---o---o---o---o---o---o---o---o---o---o From keup at dkrz.de Wed Feb 8 08:28:22 2006 From: keup at dkrz.de (Elke Keup) Date: Wed Feb 8 09:19:00 2006 Subject: [CF-metadata] request for new netCDF standart names Message-ID: <43EA0E16.5000203@dkrz.de> Dear colleagues, I want to make an application for a few more standart names I missed in the netCDF standart name table. 1. forest_area_fraction It describes the part of the grid volume covered with forest, MKS unit=1 2. skin_reservoir_content A part of this quantity is the canopy water amount but additionally this quantity contains the wetting of the bare soil. MKS unit=m 3. frozen_soil_fraction This quantity describes the part of the soil which is frozen, MKS unit=1 4. surface_snow_amount_change This quantity describes the change of the snow amount at the surface, MKS unit=kg/m**2 Please inform me wether it's possible for you to add these 4 quantities to the standart name table. Thank's a lot. Kindly Regards Elke Keup-Thiel o---o---o---o---o---o---o---o---o---o---o---o---o---o---o---o---o Dr. Elke Keup-Thiel Max-Planck-Institut fuer Meteorologie Bundesstrasse 53 D-20146 Hamburg Tel: +49 40 41173 406 Fax: +49 40 41173 476 E-mail: keup@dkrz.de sga@dkrz.de o---o---o---o---o---o---o---o---o---o---o---o---o---o---o---o---o From j.m.gregory at reading.ac.uk Wed Feb 8 10:31:02 2006 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Wed Feb 8 10:31:08 2006 Subject: [CF-metadata] CF2 and standard names Message-ID: <20060208173102.GC20686@met.reading.ac.uk> ----- Forwarded message from "Gross, Tom" ----- > Given the wealth of datums available, I am of the opinion that a surface > such as, "sea_surface_height", should not include the datum in the > standard name. It is an attribute of the variable. I agree with that. My posting may not have been clear. When I referred to a standard name parameter, I meant some extra piece of information, *not* in the standard name, which clarifies it. We have decided in principle that we need to be able to do this for some standard names, but not agreed the mechanism. Cheers Jonathan From b.n.lawrence at rl.ac.uk Wed Feb 8 11:31:09 2006 From: b.n.lawrence at rl.ac.uk (Bryan Lawrence) Date: Wed Feb 8 11:41:06 2006 Subject: [CF-metadata] request for new netCDF standart names In-Reply-To: <43EA0C22.5020206@dkrz.de> References: <43EA0C22.5020206@dkrz.de> Message-ID: <200602081831.09652.b.n.lawrence@rl.ac.uk> hi Elke I understand that the definition of forest is highly ambiguous (even in the forest cover community), and I guess in a simulation, the definition of forest will depend highly on the parameterisation. I also understand that such differences wont matter when one modeller wants to compare their parameterisation output with another, but it will matter when comparing with or between observations. This is not to say we shouldn't have the variable in the standard name table, but more as an aide to memory that this will be another variable where there ought (in the future) to have more metadata about what the variable actually is. (Perhaps referring to a uri for an authorative description of what it means in this case, which we can maintain in something approaching perpetuity ... ) Cheers Bryan On Wednesday 08 February 2006 15:20, Elke Keup wrote: > Dear colleagues, > > I want to make an application for a few more standart names I missed in the > netCDF standart name table. > > 1. forest_area_fraction > > It describes the part of the grid volume covered with forest, MKS unit=1 > > 2. skin_reservoir_content > > A part of this quantity is the canopy water amount but additionally this > quantity contains the wetting of the bare soil. MKS unit=m > > 3. frozen_soil_fraction > > This quantity describes the part of the soil which is frozen, MKS unit=1 > > 4. surface_snow_amount_change > > This quantity describes the change of the snow amount at the surface, > MKS unit=kg/m**2 > > Please inform me wether it's possible for you to add > these 4 quantities to the standart name table. > Thank's a lot. > > Kindly Regards > > Elke Keup-Thiel > > o---o---o---o---o---o---o---o---o---o---o---o---o---o---o---o---o > > > Dr. Elke Keup-Thiel > > Max-Planck-Institut fuer Meteorologie > Bundesstrasse 53 > D-20146 Hamburg > > Tel: +49 40 41173 406 > Fax: +49 40 41173 476 > E-mail: keup@dkrz.de > sga@dkrz.de > > o---o---o---o---o---o---o---o---o---o---o---o---o---o---o---o---o > > > > _______________________________________________ > CF-metadata mailing list > CF-metadata@cgd.ucar.edu > http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata -- Bryan Lawrence Director of Environmental Archival and Associated Research Head of the NCAS/British Atmospheric Data Centre CCLRC, Rutherford Appleton Laboratory Phone +44 1235 445012; Fax ... 5848; Web: home.badc.rl.ac.uk/lawrence From j.m.gregory at reading.ac.uk Thu Feb 9 14:45:41 2006 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Thu Feb 9 14:45:47 2006 Subject: [CF-metadata] request for new netCDF standart names Message-ID: <20060209214541.GA6191@met.reading.ac.uk> Dear Elke > 1. forest_area_fraction Obviously we could define a lot of names like this, for different types of vegetation, etc. I think therefore we should consider something more generic. I propose that we introduce a standard name of area_fraction, and require that a variable with this standard name should have a coordinate which specifies somehow what quantity is being given an area fraction. For your case you would use a string-valued coordinate variable of land_cover (recently defined). Your data variable of forest area fraction would therefore be described thus: variables: float area_fraction(land_cover,lat,lon); area_fraction:standard_name="area_fraction"; area_fraction:units="1"; // optional char land_cover(surface_cover,stringmaxlength); data: land_cover="forest"; A scalar coordinate variable could alternatively be used: variables: float area_fraction(lat,lon); area_fraction:standard_name="area_fraction"; area_fraction:units="1"; // optional area_fraction:coordinates="land_cover"; char land_cover(stringmaxlength); If you have fractional land coverage of grid boxes and wish to specify whether the forest fraction is expressed per unit area of land or per unit area of the whole grid box, this can be done with cell_methods="lat: lon: mean over land" or "lat: lon: mean" (this is a convention we agreed earlier in this list but have not added to the standard yet). What do you think? I agree with Bryan that strings such as the possible values of area_fraction should be tabulated and standardised eventually, as we have done for other lists such as region names. > 2. skin_reservoir_content > > A part of this quantity is the canopy water amount but additionally this > quantity contains the wetting of the bare soil. MKS unit=m By "wetting of the bare soil" do you mean liquid water standing on the surface (not soil moisture content)? > 3. frozen_soil_fraction > > This quantity describes the part of the soil which is frozen, MKS unit=1 We already have mass_fraction_of_frozen_water_in_soil_moisture. Is that what you mean? If not, could you describe more precisely what fraction you mean? > 4. surface_snow_amount_change > > This quantity describes the change of the snow amount at the surface, > MKS unit=kg/m**2 I don't think we should define such a name. We'd have to do that for every variable, potentially! But I can understand that you want to distinguish a change from an unchanged quantity. Perhaps it would be more informative to express the change as a rate of change in kg m-2 s-1. In that case you could also use the time bounds to show the time interval over which the change occurred; that information could be useful. If we need to provide special names for changes, I think we'll have to introduce a new mechanism for it. Comments welcome from everyone. Best wishes Jonathan From Beate.Geyer at gkss.de Fri Feb 10 01:42:37 2006 From: Beate.Geyer at gkss.de (Beate.Geyer@gkss.de) Date: Fri Feb 10 01:40:43 2006 Subject: [CF-metadata] cellmethods="lat: lon: mean over land" Message-ID: Dear Jonathan, one comment to cell_methods="lat: lon: mean over land" of point 1 from Elke Keup-Thiel: We have a similar example: two variables with standard name surface_snow_melt_amount SFSSMLT is value local to snow covered area SSSMLT is value is gridbox mean (multiplied with snow fraction) as you proposed for 'fractional land coverage' (cell_methods="lat: lon: mean over land" or "lat: lon: mean") we may use cell_methods="lat: lon: mean over snow" and cell_methods="lat: lon: mean" The second case is OK for me, but the first one assumes to know the variable 'land' (are_fraction of land) in your case and 'snow' (are_fraction of snow covered area) in my case. I think it would be better to define all variables that way that they are valid where really existent (snow melt valid where snow, forest fraction valid where land ...). In the definition-table of standard names should this part of definition be included as well as the hint 'cell_methods="lat: lon: mean" for gridbox mean' for all affected variables. e.g. presently we have in standard name table: surface_snow_melt_amount The surface called "surface" means the lower boundary of the atmosphere; over sea areas this is taken to be mean sea level. "Amount" means mass per unit area. This would become: surface_snow_melt_amount The surface called "surface" means the lower boundary of the atmosphere; over sea areas this is taken to be mean sea level. "Amount" means mass per unit area. Variable is valid for gridbox area fraction covered by snow. For total gridbox mean use cell_methods="lat: lon: mean" In case the variable exist over land and water we already have specific names as: surface_temperature_where_land The name 'water_evaporation_flux_from_canopy_where_land' should not be valid any more if one accept my definition above... For the special case of partial canopy cover at partial land area of gridbox your proposal (using cell_methods for specification) may be used: variables: float water_evaporation_flux_from_canopy(lat,lon); cellmethods="lat: lon: mean over land" float land(lat,lon); land:standard_name = "land_area_fraction" land:untis = "1" Regards, Beate ==================================================== Dr. Beate Geyer GKSS Research Centre Institute for Coastal Research Max-Planck-Str. D-21502 Geesthacht, Germany E-Mail: Beate.Geyer@gkss.de Phone: 04152-871871 ==================================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.cgd.ucar.edu/pipermail/cf-metadata/attachments/20060210/1a1c6460/attachment-0001.html From j.m.gregory at reading.ac.uk Fri Feb 10 03:20:53 2006 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Fri Feb 10 03:20:59 2006 Subject: [CF-metadata] cellmethods="lat: lon: mean over land" Message-ID: <20060210102053.GF9186@met.reading.ac.uk> Dear Beate Thanks for your comments on this. It is a tricky issue, and I didn't explain fully the conclusion of the previous discussion (which ought to be added to the standard, as soon as someone has time). > We have a similar example: two variables with standard name > surface_snow_melt_amount > > SFSSMLT is value local to snow covered area > SSSMLT is value is gridbox mean (multiplied with snow fraction) > > as you proposed for 'fractional land coverage' (cell_methods="lat: lon: > mean over land" or "lat: lon: mean") we may use > cell_methods="lat: lon: mean over snow" and cell_methods="lat: lon: mean" > The second case is OK for me Yes, I think the second choice would be right: mean over snow => total mass of snow melt (kg) divided by area of snow (m2) mean => total mass of snow melt divided by area of gridbox It is possible that you might need mean over land => total mass of snow melt divided by land area in gridbox because snow can also exist on top of sea ice i.e. in the sea area. As you say, that involves the land fraction as well. > I think it would be better to define all variables that way that they are > valid where really existent (snow melt valid where snow, forest fraction > valid where land ...). The conclusion we reached before was that this either requires too much meaning to be "built in" to the standard names i.e. defining snow to exist only on land, or the standard names become too awkward, because we have to add a _where to all of them. We decided that a simple solution is this: * Remember that the default interpretation of an intensive quantity is that it's a *point* measurement; that's what should be assumed if there is no cell_methods. A point measurement of snow_amount could be either missing_data or zero if there is no snow, but it doesn't really matter. If there is a valid non-zero value, it is well defined; a local measurement has an unambiguous meaning. * Use the _where distinctions for locally defined quantities in different parts of a gridbox. Thus, we might have surface_temperature_where_sea and surface_temperature_where_land. These are by default local measurements. If you don't need to distinguish them as point measurements, surface_temperature is OK without qualification. * Recognise that this _where distinction is not the same as the area over which averaging is done if it's a mean quantity rather than a point quantity. We use the cell_methods to define means. Thus we could have surface_upward_latent_heat_flux_where_snow with cell_methods="lat: lon: mean over snow" or "mean over land" or "mean". It's the same quantity in W in each case, divided by different areas. Does that make sense? > The name > 'water_evaporation_flux_from_canopy_where_land' should not be valid any > more if one accept my definition above... I agree, this name does not need _where_land since there is only a canopy over land, so I don't think the distinction is ever needed for a local quantity of this name. We should change it (and use an alias to keep the old name valid). As you say, the cell_methods will indicate, when it's a mean, whether is a mean over land or over all gridbox area. Best wishes Jonathan From caron at unidata.ucar.edu Fri Feb 10 13:42:45 2006 From: caron at unidata.ucar.edu (John Caron) Date: Fri Feb 10 13:42:51 2006 Subject: [CF-metadata] Announce: CDM Validator improvements Message-ID: <43ECFAC5.8060200@unidata.ucar.edu> A few improvements to the CDM Validator are at: http://motherlode.ucar.edu:9080/thredds/cdmValidate.html including ability to check files remotely. These can be files on an OPeNDAP server or on an HTTP 1.1 server that supports Byte Ranges. You can also get the output back as XML (format still evolving some). Comments are welcome. From tjolibois at cls.fr Mon Feb 13 06:24:30 2006 From: tjolibois at cls.fr (Tony Jolibois) Date: Mon Feb 13 06:24:56 2006 Subject: [CF-metadata] Announce: Common Data Model Coordinate System validation In-Reply-To: <43E8B74A.60900@unidata.ucar.edu> References: <43E8B74A.60900@unidata.ucar.edu> Message-ID: <43F0888E.20300@cls.fr> Hi, This is a great tool, thank you ! A technical question : how can I test an opendap dataset protected with http login/passwd ? I tested using the syntax http://login:passwd@url but did not succeed. Another thredds question : When the version 3 of thredds server will have aggregation functionnality ? Thanks in advance. Best, Tony John Caron wrote: > An experimental web service is available that examines NetCDF files > and tries to validate their use of Conventions such as CF-1.0 for > gridded data. We will be improving this in the future based on user > experience and feedback, and we will make it a part of the THREDDS > Data Server. > > Please have a look and send any comments to me (or to this list): > > http://motherlode.ucar.edu:9080/thredds/cdmValidate.html > > Thanks! > _______________________________________________ > CF-metadata mailing list > CF-metadata@cgd.ucar.edu > http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > > -- Tony Jolibois CLS - Direction Oc?anographie Spatiale 8-10 rue herm?s - 31520 Ramonville Saint-Agne tjolibois@cls.fr T?l : +33 (0) 561 393 797 Fax : +33 (0) 561 393 782 From taylor13 at llnl.gov Wed Feb 15 10:26:43 2006 From: taylor13 at llnl.gov (Karl Taylor) Date: Wed Feb 15 10:26:48 2006 Subject: [CF-metadata] cellmethods="lat: lon: mean over land" In-Reply-To: References: Message-ID: <43F36453.1020209@llnl.gov> Dear Beate and Jonathan, I don't have time to think about this right now, but are your conclusions consistent with what we decided to do for the AR4? In particular, we should check the definitions given in: http://www-pcmdi.llnl.gov/ipcc/standard_output.html The following variables may be particularly relevent to the discussion and are carefully defined there: soil_moisture_content: water in all phases summed over all soil layers, and averaged over the land portion of the grid cell (i.e., compute by dividing the total mass of water contained in the soil layer of the grid cell by the land area in the grid cell); report as "missing" or 0.0 where the land fraction is 0. surface_snow_thickness: this thickness when multiplied by the average area of the grid cell covered by snow yields the time-mean snow volume. Thus, for time means, compute as the weighted sum of thickness (averaged over the snow-covered portion of the grid cell) divided by the sum of the weights, with the weights equal to the area covered by snow. report as 0.0 in snow-free regions. soil_frozen_water_content: summed over all soil layers, and averaged over the land portion of the grid cell (i.e., compute by dividing the total mass of frozen water contained in the soil layer of the grid cell by the land area in the grid cell); report as "missing" or 0.0 where the land fraction is 0. surface_runoff_flux: compute as the total surface runoff leaving the land portion of the grid cell divided by the land area in the grid cell; report as "missing" or 0.0 where the land fraction is 0. surface_snow_amount_where_land: Compute as the mass of surface snow on the land portion of the grid cell divided by the land area in the grid cell; report as "missing" or 0.0 where the land fraction is 0; exclude snow on vegetation canopy or on sea ice. surface_snow_area_fraction_where_land: fraction of grid cell covered by snow that lies on land; exclude snow that lies on sea ice. surface_snow_melt_flux_where_land: compute as the total surface melt water on the land portion of the grid cell divided by the land area in the grid cell; report as 0.0 for snow-free land regions; report as 0.0 or "missing" where the land fraction is 0. soil_moisture_content_at_field_capacity: divide the total water holding capacity of all the soil in the grid cell by the land area in the grid cell; report as "missing" or 0.0 outside land areas. sea_ice_thickness: this thickness, when multiplied by the average area of the grid cell covered by sea ice, yields the time-mean sea ice volume. Thus, for time means, compute as the weighted sum of thickness (averaged over the sea ice-covered portion of the grid cell) divided by the sum of the weights, with the weights equal to the area covered by sea-ice; Report as 0.0 in regions free of sea ice. water_flux_into_ocean: precipitation minus evaporation, plus runoff, melting of sea ice and any water flux correction calculated considering only the ocean-portion of each grid cell heat_flux_correction_where_ocean: if applicable, should be positive down (i.e., added to ocean); the total flux correction entering the ocean portion of the grid cell should be divided by the ocean area in the grid cell (in this context, ocean includes sea ice); report only for a single year and a single run, assuming this field is the same from year to year and for all runs. water_evaporation_flux_where_sea_ice: Compute the average rate that water mass evaporates (or sublimates) from the sea ice surface (i.e., kg/s) divided by the average area of the grid cell covered by sea ice. This quantity multiplied both by the average area covered by sea ice and by the length of the month should yield the total mass of water evaporated (or sublimated) from the sea ice. Report as 0.0 in regions free of sea ice. upward_sea_ice_basal_heat_flux: Compute the average rate that heat flows up at the base of the sea ice (i.e., Watts) divided by the average area of the grid cell covered by sea ice. This quantity multiplied both by the average area covered by sea ice and by the length of the month should yield the total energy flowing into the ice from below. Report as 0.0 in regions free of sea ice. precipitation_flux_onto_canopy: Compute the average rate that salt mass flows down at the base of the sea ice (i.e., kg/s) divided by the average area of the grid cell covered by sea ice. This quantity multiplied both by the average area covered by sea ice and by the length of the month should yield the total salt mass flowing into the ocean at the base of the sea ice. Report as 0.0 in regions free of sea ice. best regards, Karl Beate.Geyer@gkss.de wrote: > > Dear Jonathan, > > one comment to cell_methods="lat: lon: mean over land" of point 1 from > Elke Keup-Thiel: > > We have a similar example: two variables with standard name > surface_snow_melt_amount > > SFSSMLT is value local to snow covered area > SSSMLT is value is gridbox mean (multiplied with snow fraction) > > as you proposed for 'fractional land coverage' (cell_methods="lat: lon: > mean over land" > or "lat: lon: mean") > we may use > cell_methods="lat: lon: mean over snow" and cell_methods="lat: lon: mean" > > The second case is OK for me, but the first one assumes to know the > variable 'land' (are_fraction of land) in your case and 'snow' > (are_fraction of snow covered area) in my case. > > I think it would be better to define all variables that way that they > are valid where really existent (snow melt valid where snow, forest > fraction valid where land ...). In the definition-table of standard > names should this part of definition be included as well as the hint > 'cell_methods="lat: lon: mean" for gridbox mean' for all affected > variables. > e.g. presently we have in standard name table: > surface_snow_melt_amount > The surface called "surface" means the lower boundary of the atmosphere; > over sea areas this is taken to be mean sea level. "Amount" means mass > per unit area. > > This would become: > surface_snow_melt_amount > The surface called "surface" means the lower boundary of the atmosphere; > over sea areas this is taken to be mean sea level. "Amount" means mass > per unit area. Variable is valid for gridbox area fraction covered by > snow. For total gridbox mean use cell_methods="lat: lon: mean" > > > In case the variable exist over land and water we already have specific > names as: > surface_temperature_where_land > > The name > 'water_evaporation_flux_from_canopy_where_land' should not be valid any > more if one accept my definition above... > For the special case of partial canopy cover at partial land area of > gridbox your proposal (using cell_methods for specification) may be used: > variables: > float water_evaporation_flux_from_canopy(lat,lon); > cellmethods="lat: lon: mean over land" > > float land(lat,lon); > land:standard_name = "land_area_fraction" > land:untis = "1" > > > Regards, > Beate > > ==================================================== > Dr. Beate Geyer > GKSS Research Centre > Institute for Coastal Research > Max-Planck-Str. > D-21502 Geesthacht, Germany > > E-Mail: Beate.Geyer@gkss.de > Phone: 04152-871871 > ==================================================== > > > ------------------------------------------------------------------------ > > _______________________________________________ > CF-metadata mailing list > CF-metadata@cgd.ucar.edu > http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata From j.m.gregory at reading.ac.uk Wed Feb 15 10:39:40 2006 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Wed Feb 15 10:39:44 2006 Subject: [CF-metadata] cellmethods="lat: lon: mean over land" Message-ID: <20060215173940.GA20476@met.reading.ac.uk> Dear Karl > I don't have time to think about this right now, but are your > conclusions consistent with what we decided to do for the AR4? In > particular, we should check the definitions given in: > http://www-pcmdi.llnl.gov/ipcc/standard_output.html Yes, I believe so. You and I agreed on this, in order to be consistent with the AR4. The point was to recognise that we had been vague about what the "mean" method means. That's why you had to be prescriptive in the AR4 diagnostic specification. Your spec amounts to deciding whether it is "mean over land/sea" or "mean". In future, the cell_methods should specify this correctly. Does CMOR generate cell_methods? Possibly some standard_names with _where_ in them don't actually need it. That's not a problem as we can alias them to new names without _where_. Best wishes Jonathan From taylor13 at llnl.gov Wed Feb 15 12:22:36 2006 From: taylor13 at llnl.gov (Karl Taylor) Date: Wed Feb 15 12:22:39 2006 Subject: [CF-metadata] cellmethods="lat: lon: mean over land" In-Reply-To: <20060215173940.GA20476@met.reading.ac.uk> References: <20060215173940.GA20476@met.reading.ac.uk> Message-ID: <43F37F7C.6080709@llnl.gov> Hi Jonathan, Yes, CMOR does output cell_methods, as specified by the CMOR input table. cheers, Karl Jonathan Gregory wrote: > Dear Karl > > >>I don't have time to think about this right now, but are your >>conclusions consistent with what we decided to do for the AR4? In >>particular, we should check the definitions given in: >>http://www-pcmdi.llnl.gov/ipcc/standard_output.html > > > Yes, I believe so. You and I agreed on this, in order to be consistent with > the AR4. The point was to recognise that we had been vague about what > the "mean" method means. That's why you had to be prescriptive in the AR4 > diagnostic specification. Your spec amounts to deciding whether it is > "mean over land/sea" or "mean". In future, the cell_methods should specify > this correctly. Does CMOR generate cell_methods? > > Possibly some standard_names with _where_ in them don't actually need it. > That's not a problem as we can alias them to new names without _where_. > > Best wishes > > Jonathan > _______________________________________________ > CF-metadata mailing list > CF-metadata@cgd.ucar.edu > http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata > From ngalbraith at whoi.edu Tue Feb 21 12:01:54 2006 From: ngalbraith at whoi.edu (Nan Galbraith) Date: Tue Feb 21 12:01:58 2006 Subject: [CF-metadata] accessory parameters In-Reply-To: <20051205144009.GA10952@met.reading.ac.uk> References: <20051205144009.GA10952@met.reading.ac.uk> Message-ID: <1140548514.43fb63a219956@webmail.whoi.edu> Hi All - Sorry if this has been covered, I'm at sea and don't have enough internet capability to search the archive. Is there a recommentdation for naming secondary parameters, for example the water temperature returned by an oxygen sensor? It would be a mistake to call this sea_water_temperature and risk having it used as a valid temp. By the way, it would be really useful if there *were* a search on the email archive, or even a web page concatenating it all, for the purpose of searching. Seems like it could be helpful; most subject lines don't contain enough info to help when you're trying to find or mine old discussions. Thanks - Nan ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From Burkhardt.Rockel at gkss.de Tue Feb 21 23:41:11 2006 From: Burkhardt.Rockel at gkss.de (Burkhardt.Rockel@gkss.de) Date: Tue Feb 21 23:41:50 2006 Subject: [CF-metadata] one new standard name Message-ID: Dear CFs we need a standard name for the advection of "atmosphere_water_content". I propose tendency_of_atmosphere_water_content_due_to_advection Is that ok? Regards Burkhardt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.cgd.ucar.edu/pipermail/cf-metadata/attachments/20060221/31301044/attachment.html From j.m.gregory at reading.ac.uk Thu Feb 23 14:04:19 2006 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Thu Feb 23 14:04:25 2006 Subject: [CF-metadata] one new standard name Message-ID: <20060223210419.GA6463@met.reading.ac.uk> Dear Burkhardt > we need a standard name for the advection of "atmosphere_water_content". > I propose > tendency_of_atmosphere_water_content_due_to_advection I think that would refer to water in all phases. That's OK, but maybe you need tendency_of_atmosphere_water_vapor_content_due_to_advection? Best wishes Jonathan From j.m.gregory at reading.ac.uk Thu Feb 23 14:12:47 2006 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Thu Feb 23 14:12:54 2006 Subject: [CF-metadata] accessory parameters Message-ID: <20060223211247.GA6515@met.reading.ac.uk> Dear Nan > Is there a recommentdation for naming secondary parameters, > for example the water temperature returned by an oxygen sensor? I don't recall a discussion previously about this. > It would be a mistake to call this sea_water_temperature > and risk having it used as a valid temp. Why would it be a mistake? Is it not a correct temperature? In general I suppose distinctions about how a quantity is measured ought to be made by other attributes than the standard name. We could do more work on this. > By the way, it would be really useful if there *were* a > search on the email archive, or even a web page concatenating > it all The archive page for the email list http://www.cgd.ucar.edu/pipermail/cf-metadata/ does allow you to download each year separately as a plain text file. Best wishes Jonathan From rkl at bodc.ac.uk Fri Feb 24 01:08:55 2006 From: rkl at bodc.ac.uk (Roy Lowry) Date: Fri Feb 24 01:09:31 2006 Subject: [CF-metadata] accessory parameters Message-ID: Hi Jon, Oxygen temperature sensors measure the temperature of the membrane inside the oxygen sensor, which is the best number for computation of oxygen concentration from current. This has significant thermal inertia so when the CTD is travelling at about 1 m/s through the water column it lags behind the true water tyemperature. The same problem is encountered with thermosalinoigraphs. These record conductivity plus two temperatures, one at the ship's hull (ambient sea temperature) plus one in the conductivity cell used to compute salinity (ambient laboratory temperature!). When we've hit this type of thing before, the response has been that the accessory parameters shouldn't be given standard names, but the way the oceanographic community is going the standard name is becoming mandatory. This is an unresolved issue that needs resolving. Cheers, Roy. >>> Jonathan Gregory 02/23/06 9:12 PM >>> Dear Nan > Is there a recommentdation for naming secondary parameters, > for example the water temperature returned by an oxygen sensor? I don't recall a discussion previously about this. > It would be a mistake to call this sea_water_temperature > and risk having it used as a valid temp. Why would it be a mistake? Is it not a correct temperature? In general I suppose distinctions about how a quantity is measured ought to be made by other attributes than the standard name. We could do more work on this. > By the way, it would be really useful if there *were* a > search on the email archive, or even a web page concatenating > it all The archive page for the email list http://www.cgd.ucar.edu/pipermail/cf-metadata/ does allow you to download each year separately as a plain text file. Best wishes Jonathan _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata -- This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system. From Burkhardt.Rockel at gkss.de Fri Feb 24 05:07:50 2006 From: Burkhardt.Rockel at gkss.de (Burkhardt.Rockel@gkss.de) Date: Fri Feb 24 05:08:02 2006 Subject: Antwort: [CF-metadata] one new standard name In-Reply-To: <20060223210419.GA6463@met.reading.ac.uk> Message-ID: Dear Jonathan, I need a standard name for water in all phases, thus tendency_of_atmosphere_water_content_due_to_advection (kg m-2) Regards Burkhardt cf-metadata-bounces@cgd.ucar.edu schrieb am 23.02.2006 22:04:19: > Dear Burkhardt > > > we need a standard name for the advection of "atmosphere_water_content". > > I propose > > tendency_of_atmosphere_water_content_due_to_advection > > I think that would refer to water in all phases. That's OK, but maybe you need > tendency_of_atmosphere_water_vapor_content_due_to_advection? > > Best wishes > > Jonathan > _______________________________________________ > CF-metadata mailing list > CF-metadata@cgd.ucar.edu > http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.cgd.ucar.edu/pipermail/cf-metadata/attachments/20060224/65c6417a/attachment.html From j.m.gregory at reading.ac.uk Fri Feb 24 05:12:58 2006 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Fri Feb 24 05:13:07 2006 Subject: [CF-metadata] one new standard name Message-ID: <20060224121258.GG11074@met.reading.ac.uk> Dear Burkhardt > I need a standard name for water in all phases, thus > tendency_of_atmosphere_water_content_due_to_advection (kg m-2) kg m-2 s-1, I think. Good! Please assume we will add this at the next convenient opportunity. Cheers Jonathan From j.m.gregory at reading.ac.uk Fri Feb 24 06:34:12 2006 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Fri Feb 24 06:34:18 2006 Subject: [CF-metadata] one new standard name Message-ID: <20060224133412.GA12687@met.reading.ac.uk> Dear Burkhardt > we need this parameter for atmospheric water budget studies where it > balances amongst others with the precipitation amount (given in kg m-2). > Therefore I am not sure if (kg m-2 s-1) is appropriate?? I see. This is related to Elke's request for change_in_X, I think; I might have been wrong to disagree with that proposal. You could do it with rates, couldn't you i.e. tendency_of_atmosphere_water_content and precipitation_flux are both in kg m-2 s-1 and could appear in the same budget ("tendency" means d/dt). But you want to use quantities which are extensive in time rather than intensive i.e. a change over a certain interval, rather than the average rate over that interval. In that case you want precipitation_amount and change in atmosphere water content, both in kg m-2, defining "change" to mean the difference in a quantity going from one time to another. I was concerned that we might have to add "change_in" to many quantities, potentially, in which case it might be better handled in another way. But perhaps it is not any more of a problem than tendency_in - so far there are not many of those. If it was seen as the time-integral of a tendency, this is quite a restrictive idea. We would not, for example, use "change in" to mean the difference of a quantity between two climates. Any comments? Best wishes Jonathan From j.m.gregory at reading.ac.uk Fri Feb 24 06:43:06 2006 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Fri Feb 24 06:43:11 2006 Subject: [CF-metadata] accessory parameters Message-ID: <20060224134306.GA12778@met.reading.ac.uk> Dear Roy I see, thanks for that explanation. I agree this needs resolution, and in fact it's an aspect of the general problem of giving names to things which are more related to measurements and observational techniques, rather than geophysical parameters which can be regarded as comparable across different methods of observation and simulation - would you agree? The latter was the original purpose of standard names. Nonetheless we already have standard names for quantities that exist only in models and couldn't be measured because they are abstractions or artefacts. It is therefore not inconsistent to have names for quantities which can be measured but aren't parameters of the "real world" i.e. they belong to the measurement, rather than being something measured. Are these kinds of quantities for the ocean systematically named in your dictionary? Best wishes Jonathan From sdj at tiscali.it Fri Feb 24 09:03:26 2006 From: sdj at tiscali.it (sdj@tiscali.it) Date: Fri Feb 24 09:05:23 2006 Subject: [CF-metadata] Specifying a wavelength for a standard_name Message-ID: <3369250.1140797006674.JavaMail.root@ps11> Dear All, In reference to a previuous discussion about the standard name "Diffuse Attenuation Coefficient", may I ask if the following notation is correct to represent Diffuse Attenuation Coefficient at 490nm ? float kd490 (x, y) kd490:standard_name = "volume_attenuation_coefficient_of_downwelling_radiative_flux_in_sea_water" ; kd490:long_name = "Mean Diffuse Attenuation Coefficient at 490nm" ; kd490:coordinate = "490nm" ; kd490:units = "m-1" ; Is this the correct way to specify the wavelength, or do I need to add a different/another attribute somewhere else ? Many thanks for your help. Regards, Pepe Tiscali ADSL 4 Mega Flat Naviga senza limiti con l'unica Adsl a 4 Mega di velocit? a soli 19,95 ? al mese! Attivala subito e hai GRATIS 2 MESI e l'ATTIVAZIONE. http://abbonati.tiscali.it/banner/middlepagetracking.html?c=webmailadsl&r=http://abbonati.tiscali.it/adsl/sa/4flat_tc/&a=webmail&z=webmail&t=14 From Burkhardt.Rockel at gkss.de Fri Feb 24 09:46:33 2006 From: Burkhardt.Rockel at gkss.de (Burkhardt.Rockel@gkss.de) Date: Fri Feb 24 09:46:42 2006 Subject: Antwort: [CF-metadata] one new standard name In-Reply-To: <20060224150414.GD12794@met.reading.ac.uk> Message-ID: Dear Jonathan I see, thank you for the clearification. Then there is no standard name presently, in case I want to use the integrated value (kg m-2) for the change in atmospheric water content due to advection? Any chance to get one in the next time? Regards Burkhardt Jonathan Gregory schrieb am 24.02.2006 16:04:14: > Dear Burkhardt > > I don't think you sent this one to the list, did you? I am replying to > you directly. > > > I propose to use (kg m-2 s-1) since the other tendencies in the standard > > name table are also in (s-1). > OK > > > I can use the cell_methods attribute with "time: sum" in case of (kg m-2 > > s-1). Actually this would also be the case for (kg m-2). > I don't think so, actually. The method "sum" doesn't imply an integral. If > you look in appendix D, you see it does not change the units. All it means > is that the quantity is a property of the whole box, rather than a point > value. That's the difference between precipitation_amount and precipitation_ > flux. The former usually has cell_methods of sum (which would be default) > and the latter usually cell_methods of mean (the default would be an > instantaneous measurement of the flux). > > > By the way, I just realized the units for large_scale_precipitation_flux > > in the standard name table is (kg m-2) but should be (kg m-2 s-1). > Thanks. > > Best wishes > > Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.cgd.ucar.edu/pipermail/cf-metadata/attachments/20060224/4e80fe04/attachment.html From j.m.gregory at reading.ac.uk Fri Feb 24 10:03:00 2006 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Fri Feb 24 10:03:05 2006 Subject: [CF-metadata] one new standard name Message-ID: <20060224170300.GA16192@met.reading.ac.uk> Dear Burkhardt > Then there is no standard name presently, in case I want to use the > integrated value (kg m-2) for the change in atmospheric water content due > to advection? > Any chance to get one in the next time? Of course, we could define change_in_atmospheric_water_content_due_to_ advection (kg m-2). This would set a precedent by introducing change_in, and I would very much welcome other people's views on whether this is a good idea. Best wishes Jonathan From j.m.gregory at reading.ac.uk Fri Feb 24 10:13:44 2006 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Fri Feb 24 10:13:49 2006 Subject: [CF-metadata] Specifying a wavelength for a standard_name Message-ID: <20060224171344.GD16192@met.reading.ac.uk> Dear Pepe You should add a size-one coordinate variable or a scalar coordinate variable of radiation_wavelength. float kd490(wavelength); kd490:standard_name = "volume_attenuation_coefficient_of_downwelling_radiative_flux_in_sea_water"; kd490:long_name = "Mean Diffuse Attenuation Coefficient at 490nm" ; kd490:units = "m-1" ; float wavelength(wavelength); wavelength:units="m"; wavelength:standard_name="radiation_wavelength"; or float kd490; kd490:standard_name = "volume_attenuation_coefficient_of_downwelling_radiative_flux_in_sea_water"; kd490:long_name = "Mean Diffuse Attenuation Coefficient at 490nm" ; kd490:units = "m-1" ; kd490:coordinates="wavelength"; float wavelength; wavelength:units="m"; wavelength:standard_name="radiation_wavelength"; Best wishes Jonathan From Bert.Jagers at wldelft.nl Fri Feb 24 10:37:03 2006 From: Bert.Jagers at wldelft.nl (Bert Jagers) Date: Fri Feb 24 10:37:11 2006 Subject: [CF-metadata] CF convention for vector quantities Message-ID: <01de01c63968$ec97a120$ebe20991@wl06377> Hi All, First of all thanks for your replies to my question about CF2 and standard names two/three weeks ago. Main conclusions from that discussion seem to be: * standardized Datum attribute needed for specifying a reference level (don't include reference level in standard name) * name spaces can be used to resolve perception issues related to standard naming conventions, e.g. sea_surface_height for water level in other water bodies than seas, but one must be carefull when mapping between such name spaces. Now I have some new questions related to vector quantities ... Over past the two days I had a brief discussion with Rich Signell with respect to the extension of CF convention to include some attributes for vector quantities. A plotting tool that I developed should automatically detect vector quantities and process and plot them accordingly. As far as I am aware there is currently no part in the CF convention that makes such automatic detection possible (except for implementing the standard names of all known vector quantities). Vector quantities include quantities such as: "eastward_sea_water_velocity" and "northward_sea_water_velocity" "sea_water_x_velocity" and "sea_water_y_velocity" "eastward_atmosphere_dry_static_energy_transport_across_unit_distance" "eastward_atmosphere_water_transport_across_unit_distance" "eastward_momentum_flux_correction" "eastward_sea_ice_velocity" "product_of_eastward_sea_water_velocity_and_temperature" "product_of_eastward_wind_and_air_temperature" "product_of_eastward_wind_and_geopotential_height" ... and on and on and on.... I would prefer not to have to implement all these names. I see two alternatives: 1) Introduce dummy quantity "sea_water_velocity" and refer to the associated components by means of an appropriate attribute, e.g. "Components". Alternatively both component could refer to the both components, e.g. Components : uflow vflow where variable standard_name uflow eastward_sea_water_velocity vflow northward_sea_water_velocity This solution does not yet resolve associated issue A (see below). 2) Introduce standard prefixes for vector components to e.g. "eastward_component_of_sea_water_velocity" and "northward_component_of_sea_water_velocity" and stick to these names, that is "product_of_eastward_sea_water_velocity_and_temperature" becomes "eastward_component_of_product_of_sea_water_velocity_and_temperature" ... or some equivalent postfix. However, two other issues are related to this question: A) Distinction between components in east and north direction and components in the two grid directions: in which direction are the two components defined? It seems that "sea_water_x_velocity" and "sea_water_y_velocity" are used for components in the grid direction although in local coordinate systems x and y are generally associated with the two main coordinate directions whereas the grid may be curvilinear. Most likely "direction_of_sea_water_velocity" and "sea_water_speed" should form together a vector quantity. Central question: which types of vector components are needed? B) Staggering of data. The ROMS and Delft3D applications that we are looking at work both with staggered numerical schemes. So, in fact the two velocity components are provided at two different location sets. Before we can deal with these vector quantities correctly we need some standardization on staggered data. I know there have been some preliminary discussions on this matter in the context of CF2, but what is a realistic time schedule for these discussions to continue and settle? Best regards, Bert From sdj at tiscali.it Mon Feb 27 10:08:24 2006 From: sdj at tiscali.it (sdj@tiscali.it) Date: Mon Feb 27 10:08:38 2006 Subject: [CF-metadata] Azimuthal Equidistant Projection Message-ID: <24071084.1141060104212.JavaMail.root@ps21> Dear All, Please accept my apologies for yet another querie. I have browsed through the documentation to find the way to represent data in Azimuthal Equidistant Projection, but unfortunately had no success. Considering I have two arrays which specifiy the values of my longitudes and latitudes, how do I represent my data ? With a simple equidistant cylindrical projection I had the following notation: dimensions: longitude = x ; latitude = y ; variables: float longitude(longitude) ; longitude:standard_name = "longitude" ; longitude:long_name = "Longitude" ; longitude:units = "degrees_east" ; longitude:step = "lon_delta" ; longitude:valid_min = "lon_min" ; longitude:valid_max = "lon_max" ; longitude:axis = "X" ; float latitude(latitude) ; latitude:standard_name = "latitude" ; latitude:long_name = "Latitude" ; latitude:units = "degrees_north" ; latitude:step = "lat_delta" ; latitude:valid_min = "lat_min" ; latitude:valid_max = "lat_max" ; latitude:axis = "Y" ; short variable_mean(latitude, longitude) ; variable:standard_name = "standard_name" ; variable:units = "units" ; variable:cell_method = "mean (interval: 1 month)" ; variable:scale_factor = "scale_factor" ; variable:add_offset = "offset" ; variable:valid_min = "valid_min" ; variable:valid_max = "valid_max" ; variable:missing_value = "missing_value" ; What do I need to do in order to construct a netCDF file following the CF conventions for data projected on an azimuthal equidistant projection. Many thanks for your help. Best Regards, Pepe Tiscali ADSL 4 Mega Flat Naviga senza limiti con l'unica Adsl a 4 Mega di velocit? a soli 19,95 ? al mese! Attivala subito e hai GRATIS 2 MESI e l'ATTIVAZIONE. http://abbonati.tiscali.it/banner/middlepagetracking.html?c=webmailadsl&r=http://abbonati.tiscali.it/adsl/sa/4flat_tc/&a=webmail&z=webmail&t=14 From eaton at ucar.edu Mon Feb 27 18:23:26 2006 From: eaton at ucar.edu (Brian Eaton) Date: Mon Feb 27 18:22:02 2006 Subject: [CF-metadata] Azimuthal Equidistant Projection In-Reply-To: <24071084.1141060104212.JavaMail.root@ps21> References: <24071084.1141060104212.JavaMail.root@ps21> Message-ID: <20060228012326.GB31544@ucar.edu> If the grid is not a rectangular lat/lon grid then the conventions described in section 5.2 need to be used. This provides for 2D lat/lon arrays. Section 5.6 also applies to your data, and the example for Lambert conformal projection is probably very close to what you need. The only thing missing is the definition for the Azimuthal Equidistant Projection which is not currently contained in Appendix F. I propose adding the following entry to Appendix F: --------------------------------------------------------------------------- Azimuthal equidistant grid_mapping_name = azimuthal_equidistant Map parameters: * longitude_of_projection_origin * latitude_of_projection_origin * false_easting * false_northing Map coordinates: The x (abscissa) and y (ordinate) rectangular coordinates are identified by the standard_name attribute values projection_x_coordinate and projection_y_coordinate respectively. Notes: Notes on using the PROJ.4 software package for computing the mapping may be found at http://www.remotesensing.org/geotiff/proj_list/azimuthal_equidistant.html --------------------------------------------------------------------------- Brian On Mon, Feb 27, 2006 at 06:08:24PM +0100, sdj@tiscali.it wrote: > Dear All, > > Please accept my apologies for yet another querie. > > I have browsed through the documentation to find the way to represent > data in Azimuthal Equidistant Projection, but unfortunately had no > success. > > Considering I have two arrays which specifiy the values of my > longitudes and latitudes, how do I represent my data ? > > With a simple equidistant cylindrical projection I had the following > notation: > > dimensions: > longitude = x ; > latitude = y ; > variables: > float longitude(longitude) ; > longitude:standard_name = "longitude" ; > longitude:long_name = "Longitude" ; > longitude:units = "degrees_east" ; > longitude:step = "lon_delta" ; > longitude:valid_min = "lon_min" ; > longitude:valid_max = "lon_max" ; > longitude:axis = "X" ; > float latitude(latitude) ; > latitude:standard_name = "latitude" ; > latitude:long_name = "Latitude" ; > latitude:units = "degrees_north" ; > latitude:step = "lat_delta" ; > latitude:valid_min = "lat_min" ; > latitude:valid_max = "lat_max" ; > latitude:axis = "Y" ; > short variable_mean(latitude, longitude) ; > variable:standard_name = "standard_name" ; > variable:units = "units" ; > variable:cell_method = "mean (interval: 1 month)" ; > variable:scale_factor = "scale_factor" ; > variable:add_offset = "offset" ; > variable:valid_min = "valid_min" ; > variable:valid_max = "valid_max" ; > variable:missing_value = "missing_value" ; > > What do I need to do in order to construct a netCDF file following the > CF conventions for data projected on an azimuthal equidistant > projection. > > Many thanks for your help. > > Best Regards, > Pepe > > > > > Tiscali ADSL 4 Mega Flat > Naviga senza limiti con l'unica Adsl a 4 Mega di velocit? a soli 19,95 ? al mese! > Attivala subito e hai GRATIS 2 MESI e l'ATTIVAZIONE. > http://abbonati.tiscali.it/banner/middlepagetracking.html?c=webmailadsl&r=http://abbonati.tiscali.it/adsl/sa/4flat_tc/&a=webmail&z=webmail&t=14 > > _______________________________________________ > CF-metadata mailing list > CF-metadata@cgd.ucar.edu > http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata From rkl at bodc.ac.uk Tue Feb 28 02:18:48 2006 From: rkl at bodc.ac.uk (Roy Lowry) Date: Tue Feb 28 02:19:22 2006 Subject: [CF-metadata] accessory parameters Message-ID: Hello Jonathan, I agree that these are definitely not geophysical parameters, but are something that need labelling so that users of the data know exactly what they are and don't use them for the wrong purpose. I have the following entries of this type: Temperature of oxygen probe membrane Temperature of pH determination Temperature of pCO2 determination Temperature of fluorometer sample by fluorometer temperature sensor Temperature of conductivity measurement by thermosalinograph Temperature of the instrument top of electronics tube by telemetry buoy systems monitor Temperature of the instrument middle of electronics tube by telemetry buoy systems monitor Temperature of the instrument bottom of electronics tube by telemetry buoy systems monitor These are linked to their own Parameter Discovery Vocabulary terms ('Engineering parameters' or 'Metadata parameters') to prevent their discovery by a search for environmental parameters. Cheers, Roy. >>> Jonathan Gregory 2/24/2006 1:43:06 pm >>> Dear Roy I see, thanks for that explanation. I agree this needs resolution, and in fact it's an aspect of the general problem of giving names to things which are more related to measurements and observational techniques, rather than geophysical parameters which can be regarded as comparable across different methods of observation and simulation - would you agree? The latter was the original purpose of standard names. Nonetheless we already have standard names for quantities that exist only in models and couldn't be measured because they are abstractions or artefacts. It is therefore not inconsistent to have names for quantities which can be measured but aren't parameters of the "real world" i.e. they belong to the measurement, rather than being something measured. Are these kinds of quantities for the ocean systematically named in your dictionary? Best wishes Jonathan _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata -- This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system. From j.m.gregory at reading.ac.uk Tue Feb 28 04:51:04 2006 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Tue Feb 28 04:51:09 2006 Subject: [CF-metadata] Azimuthal Equidistant Projection Message-ID: <20060228115104.GD18671@met.reading.ac.uk> Thanks, Brian. If this is a distinct projection we don't have, I agree with you that it should be added to the appendix. Jonathan From dem at acri-st.fr Wed Mar 8 08:03:58 2006 From: dem at acri-st.fr (Julien Demaria) Date: Wed Mar 8 08:04:18 2006 Subject: [CF-metadata] Integerized Sinusoidal Grid Message-ID: <440EF25E.8090309@acri-st.fr> Hi, We search to describe in CF netCDF convention a "integerized sinusoidal equal-area grid (ISIN grid)" as used in SEAWiFS/MODIS Level 3 HDF data. Its characteristics are that on each row of latitude there is an integer number of longitude bins. Poles always represented as 3 triangular bins. Bins aren't aligned between rows. In SEAWiFS/MODIS Level 3 HDF only bins (pixels) with data are stored, and the geolocation information for each bin is only its indice in the global integerized sinusoidal grid (first bin is on south, last on the north). The only mecanisms I see in CF to do that are: - "5.3 Reduced horizontal grid": but: Are bins always aligned ? How can I know/compute the coverage of each pixel (its vertex) ? Is this mechanism largely used ? Are there free tools to see this kind of CF files ? (FERRET ?) - "5.4 Timeseries of station data": but: I don't believe this mecanism is really appropriated... How can I know/compute the coverage of each pixel (its vertex) ? - "5.6 Grid mappings and projections": in fact I think we can't represent ISIN grids with that model ? The simpliest way I see is: " dimensions: Data_Bins = 5965 ; variables: int bin_num(Data_Bins) ; bin_num:long_name = "Index number of each bin in the global sinusoidal grid" ; short mean(Data_Bins) ; mean:long_name = "Arithmetic mean of the geophysical variable for each bin" ; mean:units = "mg.m-3" ; // global attributes: :Conventions = "CF-1.0" ; :Parameter_Code = "CHL1" ; :Parameter = "Chlorophyll A - case 1 water" ; " It is compliant with the CF checker..., but are there any tool who can use these files ? Many Thanks in advance for help, Julien From foster at hao.ucar.edu Wed Mar 8 14:42:29 2006 From: foster at hao.ucar.edu (Ben Foster) Date: Wed Mar 8 15:21:33 2006 Subject: [CF-metadata] proposed new vertical coordinate Message-ID: <200603082142.k28LgTU19925@jabba.hao.ucar.edu> To the CF conventions community: Over the past 25 years or so the High Altitude Observatory at NCAR has developed a series of Thermospheric GCM's for use in upper atmosphere research. We save simulation results in netCDF history files, which are read by post-processors and visualization software. We would like to conform to CF conventions, but are currently unable to do so because our vertical dimension coordinate is not recognized. The vertical coordinate is a log pressure scale, ln(p0/p), where p0 is a standard reference pressure. The resulting coordinate array "lev" is typically -17 at the lower boundary to +7 at the top in increments of 0.5 or 0.25, corresponding to about 30 to 500 km. Pressure in mb can be calculated with p(k)=p0*exp(-lev(k)). We would therefore like to propose a new dimensionless vertical coordinate for the CF convention as follows: double lev(lev) ; lev:long_name = "midpoint levels" ; lev:units = "" ; lev:positive = "up" ; lev:standard_name = "atmosphere_log_pressure_coordinate" ; lev:formula_terms = "p0: p0 lev: lev" ; lev:formula = "p(k) = p0 * exp(-lev(k))" ; If this acceptable, a new definition would be added to the atmosphere dimensionless vertical coordinate definitions in Appendix D, as follows: ========================================================================= Atmosphere log pressure coordinate standard_name = "atmosphere_log_pressure_coordinate" Definition: p(k) = p0 * exp(-lev(k)) where p(k) is the pressure at gridpoint (k), p0 is a reference pressure, and lev(k) is the dimensionless coordinate at vertical gridpoint (k). The format for the formula_terms attribute is formula_terms = "p0: var1 lev: var2" ========================================================================= Thanks for your consideration, --Ben Foster ----------------------------------------------------------------------- Ben Foster High Altitude Observatory (HAO) foster@ucar.edu phone: 303-497-1595 fax: 303-497-1589 Nat. Center for Atmos. Res. P.O. Box 3000 Boulder CO 80307 USA ----------------------------------------------------------------------- From taylor13 at llnl.gov Wed Mar 8 18:57:54 2006 From: taylor13 at llnl.gov (Karl Taylor) Date: Wed Mar 8 18:58:00 2006 Subject: [CF-metadata] proposed new vertical coordinate In-Reply-To: <200603082142.k28LgTU19925@jabba.hao.ucar.edu> References: <200603082142.k28LgTU19925@jabba.hao.ucar.edu> Message-ID: <440F8BA2.4090301@llnl.gov> Dear Ben, Thanks for the very thorough proposal, which I endorse. I have a question concerning notation, however. I presume "lev" is the name of the variable you use when programming, but what do you use when you publish a paper for this quantity? If this quantity is normally referred to as zprime or zstar or xi or whatever in the literature, it would probably be more consistent with the other coordinate definitions if we replaced "lev" in your description with that commonly used symbol. Note that "var2", in the case of your model, would be set to "lev". If there is no conventional symbol for this coordinate, also let us know. Finally, is this the most general form of this coordinate? Is it a special case or closely related to any others used strato, meso, thermosphere models? Thanks very much for your interest in CF. regards, Karl Karl Taylor (taylor13@llnl.gov) Ben Foster wrote: > To the CF conventions community: > > Over the past 25 years or so the High Altitude Observatory at NCAR > has developed a series of Thermospheric GCM's for use in upper atmosphere > research. We save simulation results in netCDF history files, which are > read by post-processors and visualization software. > > We would like to conform to CF conventions, but are currently unable > to do so because our vertical dimension coordinate is not recognized. > The vertical coordinate is a log pressure scale, ln(p0/p), where p0 is > a standard reference pressure. The resulting coordinate array "lev" > is typically -17 at the lower boundary to +7 at the top in increments > of 0.5 or 0.25, corresponding to about 30 to 500 km. Pressure in mb can > be calculated with p(k)=p0*exp(-lev(k)). > > We would therefore like to propose a new dimensionless vertical coordinate > for the CF convention as follows: > > double lev(lev) ; > lev:long_name = "midpoint levels" ; > lev:units = "" ; > lev:positive = "up" ; > lev:standard_name = "atmosphere_log_pressure_coordinate" ; > lev:formula_terms = "p0: p0 lev: lev" ; > lev:formula = "p(k) = p0 * exp(-lev(k))" ; > > If this acceptable, a new definition would be added to the atmosphere > dimensionless vertical coordinate definitions in Appendix D, as follows: > > ========================================================================= > Atmosphere log pressure coordinate > > standard_name = "atmosphere_log_pressure_coordinate" > > Definition: > > p(k) = p0 * exp(-lev(k)) > > where p(k) is the pressure at gridpoint (k), p0 is a reference pressure, > and lev(k) is the dimensionless coordinate at vertical gridpoint (k). > > The format for the formula_terms attribute is > > formula_terms = "p0: var1 lev: var2" > ========================================================================= > > Thanks for your consideration, > > --Ben Foster > > > > ----------------------------------------------------------------------- > Ben Foster High Altitude Observatory (HAO) > foster@ucar.edu phone: 303-497-1595 fax: 303-497-1589 > Nat. Center for Atmos. Res. P.O. Box 3000 Boulder CO 80307 USA > ----------------------------------------------------------------------- > > _______________________________________________ > CF-metadata mailing list > CF-metadata@cgd.ucar.edu > http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata > From j.m.gregory at reading.ac.uk Thu Mar 9 01:19:22 2006 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Thu Mar 9 01:19:34 2006 Subject: [CF-metadata] proposed new vertical coordinate In-Reply-To: <440F8BA2.4090301@llnl.gov> References: <200603082142.k28LgTU19925@jabba.hao.ucar.edu> <440F8BA2.4090301@llnl.gov> Message-ID: <20060309081922.GC26654@met.reading.ac.uk> Dear Ben I agree that the proposal is good - thanks. I would comment that the quantity ln(p0/p) could have a standard name which says what it is explicitly, rather than "atmosphere_log_pressure_coordinate". I suppose that it could be called "natural_logarithm_of_reciprocal_air_pressure", adding a note to the stdname definition about the reference pressure, since logs can only be taken of dimensionless quantities anyway. The other dimensionless coordinates have got stdnames of such-and-such coordinate because those quantities have no other purpose and they can't so easily be described. What do you think? Would that be awkward? Best wishes Jonathan From eaton at ucar.edu Thu Mar 9 08:41:05 2006 From: eaton at ucar.edu (Brian Eaton) Date: Thu Mar 9 08:39:42 2006 Subject: [CF-metadata] proposed new vertical coordinate Message-ID: <20060309154105.GB4569@ucar.edu> Hi Jonathan, Using the standard_name to connect the quantity to the definition of a dimensionless vertical coordinate has the side effect (via the formula_terms attribute) of indicating the name of the variable that contains the reference pressure. That's a necessary part of converting the dimensionless coordinate to a dimensional one. You wouldn't get that by simply using a standard_name to (partially) describe the quantity. Brian On Thu, Mar 09, 2006 at 08:19:22AM +0000, Jonathan Gregory wrote: > Dear Ben > > I agree that the proposal is good - thanks. I would comment that the quantity > ln(p0/p) could have a standard name which says what it is explicitly, rather > than "atmosphere_log_pressure_coordinate". I suppose that it could be called > "natural_logarithm_of_reciprocal_air_pressure", adding a note to the > stdname definition about the reference pressure, since logs can only be taken > of dimensionless quantities anyway. The other dimensionless coordinates have > got stdnames of such-and-such coordinate because those quantities have no other > purpose and they can't so easily be described. What do you think? Would that > be awkward? > > Best wishes > > Jonathan > _______________________________________________ > CF-metadata mailing list > CF-metadata@cgd.ucar.edu > http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata From j.m.gregory at reading.ac.uk Thu Mar 9 10:03:20 2006 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Thu Mar 9 10:03:27 2006 Subject: [CF-metadata] proposed new vertical coordinate Message-ID: <20060309170320.GA7204@met.reading.ac.uk> Dear Brian I agree with you. It should certainly be in the formula terms as usual. I was suggesting only that its standard_name could be more explicitly informative than many of coordinates are. Best wishes Jonathan From foster at hao.ucar.edu Thu Mar 9 10:14:50 2006 From: foster at hao.ucar.edu (Ben Foster) Date: Thu Mar 9 10:14:53 2006 Subject: [CF-metadata] proposed new vertical coordinate Message-ID: <200603091714.k29HEoU20277@jabba.hao.ucar.edu> Karl, Thanks for the endorsement. We use the coord name "lev" because several "generic" netCDF applications recognize this as a vertical coordinate array. In programming our own applications we typically use "zp" or "zplev". We also include another coord array "ilev" on the histories, which is the same as lev, except its at the cell interfaces rather than the midpoints (as reflected in the long_name). Most fields are calculated at the midpoints, with a few exceptions, such as geopotential height and electron density, which are calculated on interfaces. In publications, we sometimes use "ln(p0/p)" as a label for the vertical axis of plots, with a brief explanation in the figure caption or the text. This coordinate is analogous to the upper part of the atmosphere_hybrid_sigma_pressure_coordinate that is used by the NCAR CAM model, where ground topography sigma is no longer in play. We do not generally include ground effects because our model's lbc is in the upper stratosphere (except indirectly via gravity wave parameterization). --Ben > >Dear Ben, > >Thanks for the very thorough proposal, which I endorse. I have a >question concerning notation, however. I presume "lev" is the name of >the variable you use when programming, but what do you use when you >publish a paper for this quantity? If this quantity is normally >referred to as zprime or zstar or xi or whatever in the literature, it >would probably be more consistent with the other coordinate definitions >if we replaced "lev" in your description with that commonly used symbol. > >Note that "var2", in the case of your model, would be set to "lev". > >If there is no conventional symbol for this coordinate, also let us know. > >Finally, is this the most general form of this coordinate? Is it a >special case or closely related to any others used strato, meso, >thermosphere models? > >Thanks very much for your interest in CF. > >regards, >Karl > >Karl Taylor (taylor13@llnl.gov) > >Ben Foster wrote: >> To the CF conventions community: >> >> Over the past 25 years or so the High Altitude Observatory at NCAR >> has developed a series of Thermospheric GCM's for use in upper atmosphere >> research. We save simulation results in netCDF history files, which are >> read by post-processors and visualization software. >> >> We would like to conform to CF conventions, but are currently unable >> to do so because our vertical dimension coordinate is not recognized. >> The vertical coordinate is a log pressure scale, ln(p0/p), where p0 is >> a standard reference pressure. The resulting coordinate array "lev" >> is typically -17 at the lower boundary to +7 at the top in increments >> of 0.5 or 0.25, corresponding to about 30 to 500 km. Pressure in mb can >> be calculated with p(k)=p0*exp(-lev(k)). >> >> We would therefore like to propose a new dimensionless vertical coordinate >> for the CF convention as follows: >> >> double lev(lev) ; >> lev:long_name = "midpoint levels" ; >> lev:units = "" ; >> lev:positive = "up" ; >> lev:standard_name = "atmosphere_log_pressure_coordinate" ; >> lev:formula_terms = "p0: p0 lev: lev" ; >> lev:formula = "p(k) = p0 * exp(-lev(k))" ; >> >> If this acceptable, a new definition would be added to the atmosphere >> dimensionless vertical coordinate definitions in Appendix D, as follows: >> >> ========================================================================= >> Atmosphere log pressure coordinate >> >> standard_name = "atmosphere_log_pressure_coordinate" >> >> Definition: >> >> p(k) = p0 * exp(-lev(k)) >> >> where p(k) is the pressure at gridpoint (k), p0 is a reference pressure, >> and lev(k) is the dimensionless coordinate at vertical gridpoint (k). >> >> The format for the formula_terms attribute is >> >> formula_terms = "p0: var1 lev: var2" >> ========================================================================= >> >> Thanks for your consideration, >> >> --Ben Foster >> >> >> >> ----------------------------------------------------------------------- >> Ben Foster High Altitude Observatory (HAO) >> foster@ucar.edu phone: 303-497-1595 fax: 303-497-1589 >> Nat. Center for Atmos. Res. P.O. Box 3000 Boulder CO 80307 USA >> ----------------------------------------------------------------------- >> >> _______________________________________________ >> CF-metadata mailing list >> CF-metadata@cgd.ucar.edu >> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata >> > ----------------------------------------------------------------------- Ben Foster High Altitude Observatory (HAO) foster@ucar.edu phone: 303-497-1595 fax: 303-497-1589 Nat. Center for Atmos. Res. P.O. Box 3000 Boulder CO 80307 USA ----------------------------------------------------------------------- From Burkhardt.Rockel at gkss.de Wed Mar 15 01:42:20 2006 From: Burkhardt.Rockel at gkss.de (Burkhardt.Rockel@gkss.de) Date: Wed Mar 15 01:42:38 2006 Subject: Antwort: [CF-metadata] one new standard name In-Reply-To: <20060224170300.GA16192@met.reading.ac.uk> Message-ID: Dear Jonathan and others, is there any news or any decision on the "change_in_" issue? Regards Burkhardt cf-metadata-bounces@cgd.ucar.edu schrieb am 24.02.2006 18:03:00: > Dear Burkhardt > > > Then there is no standard name presently, in case I want to use the > > integrated value (kg m-2) for the change in atmospheric water content due > > to advection? > > Any chance to get one in the next time? > > Of course, we could define change_in_atmospheric_water_content_due_to_ > advection (kg m-2). This would set a precedent by introducing change_in, > and I would very much welcome other people's views on whether this is > a good idea. > > Best wishes > > Jonathan > _______________________________________________ > CF-metadata mailing list > CF-metadata@cgd.ucar.edu > http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.cgd.ucar.edu/pipermail/cf-metadata/attachments/20060315/ce45fb3a/attachment.html From edu_barandalla1 at yahoo.es Thu Mar 16 02:28:10 2006 From: edu_barandalla1 at yahoo.es (e baran) Date: Thu Mar 16 02:28:14 2006 Subject: [CF-metadata] matlab tool on CF convention? Message-ID: <20060316092810.61307.qmail@web25414.mail.ukl.yahoo.com> dear CF-community, I wonder if any of you use matlab tools on netcdf-CF convention to translate your files? Does it exist? thank you in advance, Edward Barandalla Remote sensing Dept. INTA, Spain ______________________________________________ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y m?viles desde 1 c?ntimo por minuto. http://es.voice.yahoo.com From j.m.gregory at reading.ac.uk Sat Mar 18 09:55:02 2006 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Sat Mar 18 09:55:11 2006 Subject: [CF-metadata] Geyer and Ruane standard names Message-ID: <20060318165502.GA351@met.reading.ac.uk> Dear Beate and Alex I've been through our emails and postings, and I think this is the current status. I hope I haven't missed anything! The following are already in the table and don't need to be added: soil_moisture_content:kg m-2 water_vapor_content_of_atmosphere_layer:kg m-2 soil_porosity:1 tendency_of_specific_humidity_due_to_advection:kg kg-1 sec-1 tendency_of_air_temperature_due_to_advection:K s-1 tendency_of_atmosphere_water_vapor_content_due_to_convection:kg m-2 s-1 tendency_of_atmosphere_water_vapor_content:kg m-2 s-1 The following are new names we have agreed on. In some cases you didn't respond to a minor change I suggested, and I have assumed there is no problem. I propose that these should be added next week (starting Monday 27th) if no-one objects. air_temperature_at_cloud_top:K atmosphere_dry_energy_content:J m-2 atmosphere_dry_static_energy_content:J m-2 atmosphere_mass_per_unit_area:kg m-2 convective_cloud_base_height:m convective_cloud_top_height:m downward_dry_static_energy_flux_due_to_diffusion:W m-2 downward_heat_flux_at_ground_level_in_snow:W m-2 downward_heat_flux_at_ground_level_in_soil:W m-2 downward_water_vapor_flux_in_air_due_to_diffusion:kg m-2 s-1 dry_energy_content_of_atmosphere_layer:J m-2 dry_static_energy_content_of_atmosphere_layer:J m-2 eastward_atmosphere_water_vapor_transport_across_unit_distance:kg m-1 s-1 eastward_mass_flux_of_air:kg m-2 s-1 eastward_water_vapor_flux:kg m-2 s-1 eastward_water_vapor_transport_across_unit_distance_in_atmosphere_layer:kg m-1 s-1 enthalpy_content_of_atmosphere_layer:J m-2 kinetic_energy_content_of_atmosphere_layer:J m-2 liquid_water_content_of_soil_layer:kg m-2 mass_fraction_of_cloud_condensed_water_in_air:1 northward_atmosphere_water_vapor_transport_across_unit_distance:kg m-1 s-1 northward_mass_flux_of_air:kg m-2 s-1 northward_water_vapor_flux:kg m-2 s-1 northward_wa