Hi Bryan,
Thanks for your comments. Within the framework of CFMIP2, part of CMIP5,
we are asking for cloud fraction as computed from instrument simulators.
Following the CF standard names, we will have several diagnostics of
cloud_area_fraction_in_atmosphere_layer. They will be monthly means from
the same experiments. In some cases they will differ in the vertical
grid, but not always, being the source the only difference.
As the filename conventions for CMIP5 are very different from CMIP3, I'm
not sure if these cases can be easily handled in CMIP5. I'm forwarding
you another e-mail regarding this so that you have more information.
Regards,
Alejandro
On Tue, 2009-02-17 at 09:33 +0000, Bryan Lawrence wrote:
> HI Alejandro
>
> I haven't read the previous thread, but I don't understand this:
>
> > Thanks for your comment. I am afraid that any solution based only on
> > metadata will not be feasible, as the filenames of the same variable
> > from different sources in the CMIP5 archive will clash.
>
> The draft filename convention for the CMIP5 archive has other components of the filename to indicate source. Are you saying that one model, in one experiment/scenario, with one time averaging, will be producing multiple variables with the same CF standard name? That seems unlikely.
>
> Bryan
>
> > This is outside
> > the scope of CF conventions, so the solution you propose using the
> > 'source' attribute as variable attribute should be enough for general
> > purposes.
> > We are currently analysing a couple of possible solutions that can be
> > applied to the specific case of CMIP5 filenames.
> >
> >
> > Best wishes,
> >
> > Alejandro
> >
> >
> >
> >
> > On Thu, 2009-02-12 at 18:17 +0100, olivier lauret wrote:
> > > Dear Alejandro,
> > >
> > > I tend to agree with Jonathan, as some of the standard names you are suggesting could be useful to other peoples (like me!) that have the same geophysical parameters but not measured by CALIPSO, for example.
> > > What we are doing here in case of 'the same geophysical parameter estimated by two different kind of sources' is using 'source' attribute in variable attribute, not in global attributes. Maybe it could work in your case?
> > >
> > > Kind regards,
> > >
> > > Olivier.
> > >
> > > -----Message d'origine-----
> > > De : cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu] De la part de Alejandro Bodas-Salcedo
> > > Envoy? : jeudi 12 f?vrier 2009 17:59
> > > ? : Jonathan Gregory
> > > Cc : cf-metadata at cgd.ucar.edu; Sandrine Bony; Webb, Mark
> > > Objet : Re: [CF-metadata] Proposal for new standard names
> > >
> > > Hello Jonathan,
> > >
> > > Many thanks for your comments.
> > >
> > > > > height_of_full_levels_above_reference_ellipsoid [m]
> > > > > height_of_half_levels_above_reference_ellipsoid [m]
> > > > standard names do not indicate coordinate variables, so the standard name for
> > > > these is height_above_reference_ellipsoid, which is already in the table, and
> > > > the variable should have a vertical coordinate variable of model_level_number.
> > > >
> > > > > air_pressure_at_full_levels [Pa]
> > > > > air_pressure_at_half_levels [Pa]
> > > > Likewise. The standard name is air_pressure.
> > > >
> > > That's a fair point. In practical terms, how can we disambiguate them?
> > > The only way I can think of is by staggering them, with the coordinate
> > > model_level_number coordinate having 2*model_levels elements
> > >
> > >
> > > > > b) Cloud condensate mixing ratios [1]
> > > > > mixing_ratio_large_scale_cloud_liquid
> > > > > mixing_ratio_large_scale_cloud_ice
> > > > > mixing_ratio_convective_cloud_liquid
> > > > > mixing_ratio_convective_cloud_ice
> > > > > mixing_ratio_of_ozone_in_air [1]
> > > > Are these the same as
> > > > mass_fraction_of_stratiform_cloud_liquid_water_in_air
> > > > mass_fraction_of_stratiform_cloud_ice_in_air
> > > > mass_fraction_of_convective_cloud_liquid_water_in_air
> > > > mass_fraction_of_convective_cloud_ice_in_air
> > > > mass_fraction_of_ozone_in_air
> > > > which are in the table, or are you intending to draw a precise distinction
> > > > between mixing_ratio and mass_fraction? There have been lengthy discussions on
> > > > the email list with the outcome that a distinction is not made except for the
> > > > case of water vapour in air.
> > > Sorry, but I just joined this list and I wasn't aware of these
> > > discussions. I'm happy with mass_fraction.
> > >
> > > > > d) Radiative properties of clouds. Optical depths at 0.67 micron and
> > > > > emissivities at 10.5 micron.
> > > > The wavelengths should be specified with a scalar coordinate variable
> > > > of radiation_wavelength.
> > > >
> > > > > large_scale_cloud_optical_depth [1]
> > > > > convective_cloud_optical_depth [1]
> > > > For consistency with the existing optical depth standard names, I suggest
> > > > these should be
> > > > atmosphere_optical_thickness_due_to_large_scale|convective_cloud
> > > >
> > > OK. I guess we should use "stratiform" instead of "large_scale", as with
> > > the mass_fractions:
> > > atmosphere_optical_thickness_due_to_stratiform_cloud
> > > atmosphere_optical_thickness_due_to_convective_cloud
> > >
> > > > > large_scale_cloud_emissivity [1]
> > > > > convective_cloud_emissivity [1]
> > > > If the variable does specify the wavelength, I think it is OK just to say
> > > > emissivity. Young-In Wong has recently proposed surface_longwave_emissivity,
> > > > which does not specify a precise wavelength.
> > > >
> > > If longwave_emissivity is going to be used elsewhere, I think we should
> > > use the same terminology here, just to be consistent. I any case, I
> > > think the radiation_wavelength coordinate information is still needed
> > > for our application (10.5 micron). I'd propose then
> > > stratiform_cloud_longwave_emissivity
> > > convective_cloud_longwave_emissivity
> > >
> > > > > e) Surface variables. Emissivity at 10.5 micron.
> > > > > skin_temperature [K]
> > > > The variable called surface_temperature is the temperature at the interface.
> > > > Is that what you mean?
> > > >
> > > Yes. I'll drop this from the list and use surface_temperature.
> > >
> > > > > h) Cloud fractions from CALIPSO/CLOUDSAT simulators. Units: 1.
> > > > > calipso_total_cloud_fraction
> > > > Should be calipso_cloud_area_fraction like isccp_cloud_area_fraction
> > > > (but see also below).
> > > >
> > > > > calipso_low_level_cloud_fraction
> > > > > calipso_mid_level_cloud_fraction
> > > > > calipso_high_level_cloud_fraction
> > > > I'd say low, mid and high are coordinates. They should be specified as
> > > > coordinate variables, rather than in the standard name. We have not so far
> > > > named cloud layers in this way.
> > > >
> > > These quantities are cloud area fractions defined on four different
> > > different layers, defined by pressure surfaces (in hPa):
> > > total: 0 < p
> > > high : 0 < p < 440
> > > mid : 440 <= p < 680
> > > low : 680 <= p
> > >
> > > If I understand correctly, you are proposing to bundle these four
> > > quantities under calipso_cloud_area_fraction, with a vertical coordinate
> > > that will allow to distinguish between them. I think this is doable.
> > >
> > > > > calipso_cloud_fraction
> > > > > calipsonocloudsat_cloud_fraction
> > > > > calipso_and_cloudsat_total_cloud_fraction
> > > > I'm not sure what these mean.
> > > >
> > > calipso_cloud_fraction is the same as above, but with high vertical
> > > resolution, like model layers.
> > > Following the current convention on cloud fractions, I'd propose to
> > > change
> > > calipso_total_cloud_fraction
> > > to
> > > lidar_cloud_area_fraction
> > > and
> > > calipso_low/mid/high_level_cloud_fraction
> > > calipso_cloud_fraction
> > > to
> > > lidar_cloud_area_fraction_in_atmosphere_layer
> > > I've also replaced calipso by lidar to make it more general (it can
> > > include radiation_wavelength as scalar coordinate variable).
> > > lidar_cloud_area_fraction will be requested in CMIP5 on several vertical
> > > grids. Then the disambiguation will have to be done by defining the
> > > different vertical grids in separate MIP tables.
> > >
> > >
> > > calipsonocloudsat_cloud_fraction is similar, but it will include only
> > > those clouds detected by Calipso but not CloudSat (e.g. thin cirrus).
> > > calipso_and_cloudsat_total_cloud_fraction is like
> > > lidar_cloud_area_fraction, but including clouds detected by both
> > > instruments.
> > > I guess we can clarify these once we get an agreement on the general
> > > discussion below regarding the inclusion of names like isccp in variable
> > > names.
> > >
> > >
> > > > > i.1 CloudSat Radar Reflectivity Factor (94 GHz)
> > > > > cloudsat_radar_reflectivity_94 [dBZ]
> > > > The frequency should be specified as a scalar coordinate variable of
> > > > radiation_frequency, which is not in the table at present but could be
> > > > proposed. The name can then be just cloudsat_radar_reflectivity. Is it
> > > > necessary to name "cloudsat" in this? I tend to think it would be better to
> > > > be more generic i.e. just radar_reflectivity.
> > > >
> > > That sounds ok, although I'd suggest to use
> > > equivalent_radar_reflectivity_factor
> > > which is more accurate and then use radiation_frequency as a scalar
> > > coordinate variable.
> > >
> > > > > i.2 CALIPSO Lidar Attenuated Total Backscatter (532 nm)
> > > > > calipso_atb_532 [1]
> > > > Again, the wavelength is a coordinate and should not be in the name. Could
> > > > "total" be omitted? Usually we assume that unqualified concepts are inclusive.
> > > > Thus
> > > > lidar_attenuated_backscatter
> > > Ok.
> > > > But I'm not familiar with this so I don't know what the relationship is between
> > > > this quantity and the next one
> > > > > calipso_molecular_backscatter_532 [m-1 sr-1]
> > > > Perhaps you or someone else could clarify. As they don't have the same units
> > > > the names should distinguish them more. Are they analogous to these quantities
> > > > in the table?
> > > > surface_backwards_scattering_coefficient_of_radar_wave: 1
> > > > volume_backwards_scattering_coefficient_of_radiative_flux_in_sea_water:m-1
> > > > volume_scattering_coefficient_of_radiative_flux_in_sea_water:m-1
> > > > volume_scattering_function_of_radiative_flux_in_sea_water:m-1 sr-1
> > > > If so, similar names should be adopted.
> > > >
> > > They are not exactly analogous, as they include the effects of
> > > attenuation. That is, the don't only depend on the radiative properties
> > > of the layer, but also on those of the atmosphere above. The units are
> > > the same, although calipso_atb_532 was expressed in logarithmic units.
> > > Both can be expressed in [m-1 sr-1]. The names would then be:
> > > lidar_attenuated_backscatter [m-1 sr-1]
> > > lidar_attenuated_molecular_backscatter [m-1 sr-1]
> > > with radiation_wavelength as a coordinate.
> > >
> > >
> > > > > k) Outputs from ISCCP simulator. Units are [1] otherwise stated.
> > > > > isccp_total_cloud_area_fraction
> > > > We already have
> > > > isccp_cloud_area_fraction
> > > Ok. This is similar to the discussion above on the lidar_cloud_fraction.
> > > We can drop this one and distinguish between them by means of the
> > > vertical grid/MIP table.
> > >
> > > > > isccp_mean_cloud_albedo
> > > > Could this be simply
> > > > cloud_albedo
> > > > > isccp_mean_cloud_top_pressure [Pa]
> > > > air_pressure_at_cloud_top
> > > > is already in the table.
> > > > > isccp_mean_brightness_temperature_assuming_clear_sky [K]
> > > > > isccp_mean_brightness_temperature [K]
> > > > > isccp_mean_optical_depth
> > > > With these variables, is isccp necessary? Standard names are intended to
> > > > name geophysical quantities. If ISCCP is estimating geophysical quantities,
> > > > they do not need isccp in their names. For instance, we don't have a quantity
> > > > called hadisst_sea_surface_temperature. The quantity is just SST, and HadISST
> > > > is one estimate of it. ISCCP could be identified in one of the global
> > > > attributes of the file. I am not sure why we included a standard name for
> > > > ISCCP cloud area fraction and whether we should do so for CALIPSO or this one
> > > > > misr_cloud_area_fraction
> > > > >
> > > The intention of the retrievals is to estimate geophysical quantities,
> > > but they are obviously limited by the technology used. This introduces
> > > biases that have to be accounted for. One way of doing it is by forward
> > > modelling from model variables. Although in principle it would be
> > > possible to label these variables with the analogous geophysical
> > > quantities, this can be a potential source for confusion.
> > > The main issue is how to disambiguate these variables in the CMIP
> > > archive. For instance, let's assume that monthly means of misr, isccp,
> > > and calipso total cloud area fractions are requested. As they all are 2D
> > > fields, they will clash in the same MIP table. A global attribute will
> > > be of no help in that case. Perhaps, the best option is to avoid
> > > isccp/calipso/misr etc in the variable names an add them as suffixes in
> > > the CFMIP filenames, along with global attributes and other metadata
> > > that help the user. For instance, for the example above, the filemanes
> > > would be:
> > > clt_A1_isccp
> > > clt_A1_misr
> > > clt_A1_calipso
> > > With this approach, the lidar cloud fractions could also be treated this
> > > way.
> > >
> > > > > m) PARASOL-like mono-directional reflectance. Units: 1.
> > > > > parasol_reflectance
> > > > Could you explain what that means?
> > > >
> > > This is the reflectance (the reflected radiance divided by the incident
> > > irradiance from a single direction). Parasol refers to a particular
> > > instrument.
> > >
> > >
> > > Regards,
> > >
> > > Alejandro
> > >
>
>
>
--
------------------------------------------------------------------
Dr Alejandro Bodas-Salcedo Earth Observation Research Scientist
Met Office Hadley Centre
FitzRoy Rd Exeter EX1 3PB United Kingdom
Tel: +44 (0)1392 886113 Fax: +44 (0)1392 885681
E-mail: alejandro.bodas at metoffice.gov.uk http://www.metoffice.gov.uk
Met Office climate change predictions can now be viewed on Google Earth
http://www.metoffice.gov.uk/research/hadleycentre/google/
------------------------------------------------------------------
Received on Tue Feb 17 2009 - 02:58:56 GMT
