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 : [email protected] [mailto:[email protected]]
De la part de Alejandro Bodas-Salcedo
Envoyé : jeudi 12 février 2009 17:59
À : Jonathan Gregory
Cc : [email protected]; 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
