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 Thu Feb 12 2009 - 09:58:32 GMT
