[CF-metadata] standard names for aerosols and chemistry
Dear Christiane
> But how to distinguish jargon from real definitions?
I don't think there is a general answer to this. For our purposes, if we have
a wide range of fields represented among CF users, the terms are clear enough
if everyone finds them to be adequately described.
> surface_emission_mass_flux
> what is wrong with this?
> it means the mass flux of emissions at the surface... ?
I understood it to mean the mass flux from surface into atmos. In fact that is
often pollution/anthropogenic input (which it implies to Roy), depending what
species it is. Roy, is "surface emission" used with a different sense in
oceanographic quantities i.e. not surface into atmos?
> Their is a clear definition of what aerosol is:
> A gaseous suspension of fine solid or liquid particles.
> So it can be both, dependent on the environmental conditions.
Yes, that was my understanding too, and we already have standard names with
"aerosol" in them.
> >* The construction X_as_Y seems fine to me, to indicate that you mean X
> >when it
> >comes as a constituent of Y. But it some cases I wonder if it is really
> >necessary. What is meant by ammonium_as_ammonium?
> In our community, the mass of molecules like NH4 (or SO4) are sometimes
> given as N (or S). To avoid this ambiguity, I have added
> ammonium_as_ammonium or sulfate_as_sulfate.
Ah, I see. So to be consistent, we should always use this construction in
mass fluxes of molecules, I suppose? Are there other categories of quantity
where the ambiguity also applies?
> >* I don't understand aerosol_water_ambient_aerosol.
>
> Aerosol takes up ambient water depending the relative humidity and its
> composition, this is known hygroscopic growth. Dry_aerosol means aerosol
> without water.... and aerosol_water is the water contained in aerosol.
> The suffix _ambient_aerosol is added to be consistent with the suffix
> _dry_aerosol elsewhere.
So this name is for the water content of the ambient aerosol? In that case
perhaps the name should be the other way round.
> The source_regions have specific
> spatial extensions, which might be different for different experiments.
Yes. If the regions can be described with coordinates, as polygons, then
region names would not be needed; you could have a 1D index of regions, with
auxiliary lat and lon coord variables having polygonal bounds. Still, you
might want to give them names as well. But the names are valuable when you
can't describe the region as a precise polygon or want to be vague about it.
Perhaps you might compare stuff from "Europe" between two different experiments
even if they had different shapes for Europe. The point of giving them the
same region name would indeed be to indicate that they should be compared.
> (I do not understand, why 'region' has the
> dimension 'strlen' in your examples, it seems redundant to me, or is it
> necessary for netcdf?
Yes. NetCDF does not have arrays of strings (yet).
> However, in the context of HTAP it would be better to specify a
> coordinate variable for
> mole_fraction_of_CO_in_air
Yes. Anything can be a coordinate variable.
> Yes, I know that the cell_measures exist, but it is convenient to have
> the grid information stored in variables. It would be nice if these
> names could be added.
I see. Yes, I wonder whether we need standard names for cell metrics, rather
than more "generic" quantities like plain "area".
> >* atmosphere_mass_content_of_air. I think we agreed this would be named in
> >the
> >more obvious way atmosphere_mass_per_unit_area, since it seems strange to
> >give something a "content" name for its entire content!
>
> it should then be atmosphere_mass_of_air_per_unit_area to exclude
> preciptation etc. or other particles (or planes?)
OK! You are of course more precise than atmos modellers generally are, since
they don't care much what the atmos is made of.
In that case, perhaps atmosphere_air_content (kg m-2), to be analogous with
atmosphere_water_content and other existing names.
I'll reply in a different email about the coordinate issue.
Best wishes
Jonathan
Received on Wed Sep 27 2006 - 08:48:02 BST
This archive was generated by hypermail 2.3.0
: Tue Sep 13 2022 - 23:02:40 BST