On 30/09/15 23:33, Jonathan Gregory wrote:
> Dear Maarten
>
>> ultraviolet_aerosol_index
>
>> I've asked several specialists in the field to
>> come up with a description of this parameter, and they warned: "Here
>> is my attempt at defining a quantity that is far from clear". The
>> description does cover what is in the parameter, and the name is
>> easily found in literature.
>
> OK. In that case I agree we can't make the name self-explanatory. If the
> definition in the standard_name table could give an online literature ref
> for how it is computed, that would help.
I think that
DOI:10.1029/98JD00900, O. Torres, P. K. Bhartia, J. R. Herman, Z. Ahmad and J.
Gleason, Derivation of aerosol properties from satellite measurements of
backscattered ultraviolet radiation: Theoretical basis, JGR, 103, D14, 1998, pp.
17099-17110.
is quite suitable (and close to the source), although there are more recent articles
that explain the index more clearly.
There is one issue left: the two wavelengths used in the derivation of the 'residue'
(older, even more vague name than ultraviolet_aerosol_index) must somehow be attached
to the variable. We can stipulate that the anciliary_variables link to a variable
with standard_name radiation_wavelength to indicate these two wavelengths. I think
something similar have been done before.
>>>> Name: cloud_area_fraction_assuming_fixed_cloud_albedo
>>>
>> Yes, you do change the resulting cloud fraction if you assume a
>> different cloud albedo. :-)
>>
>> It is frequently called an unhelpful 'effective cloud fraction'.
>> many algorithms have taken a different approach, fix the cloud
>> albedo to a fairly high value (0.8) and fit just two parameters:
>> cloud_area_fraction_assuming_fixed_cloud_albedo and
>> air_pressure_at_cloud_optical_centroid. Obviously if you assume a
>> lower cloud albedo you will end up with a higher cloud fraction,
>> most likely at a different pressure level.
>
> Thanks for the explanation. I'm feeling uncomfortable about it because it's not
> a real cloud area fraction, just an "effective" one to get the right answer.
> By contrast, radiative fluxes assuming clear sky, for instance, are really the
> output of radiative transfer calculations, with special conditions as input. I
> agree that "effective" by itself is not informative, but we do use that word
> in effective_radius for cloud particles, where it has the same purpose as in
> your case. Would you mind including it here as well?
> effective_cloud_area_fraction_assuming_fixed_cloud_albedo
> There is an existing standard name with "fixed" in it in this sense. If you
> specify the value in a coordinate or scalar coordinate variable, I suggest
> that it could have the existing standard_name of cloud_albedo, rather than
> defining a new one.
This fitting is also the result of radiative transfer calculations (usually through a
lookup table). I have no objection against the use of 'effective'.
I somehow forget about scalar variables, using attributes for closely related
parameters seems to imply a stronger connection - is this something to address in
CF-2.0? But, yes, it is a standard mechanism.
>> 1 is the only one we're interested in.
>
>> There is a clear_sky label that is frequently used, but I haven't
>> come across the opposite. What do you suggest?
>> cloud_albedo_assuming_full_cloud_cover
>
> Yes, that would make sense, I think, or it could be assuming_complete_cloud_
> cover, or maybe assuming_completely_cloudy_sky, with is more like assuming_
> clear_sky - what do you think? I expect that it will be useful in future to
> have a phrase for this, which we currently lack, as you say.
I'm not a native speaker, so I don't think I'm the one to pass judgement on matters
of the English language. "assuming_complete_cloud_cover" has my slight preference.
Best,
Maarten Sneep
--
KNMI
T: 030 2206747
E: maarten.sneep at knmi.nl
R: A2.14
Received on Thu Oct 01 2015 - 05:14:36 BST
