⇐ ⇒

[CF-metadata] standard_name for coordinate variable corresponding to complex parts (real and imaginary)

From: Brian Eaton <eaton>
Date: Thu, 17 Jun 2010 08:05:25 -0600

Hi Jonathan,

I'm wondering about this statement:

> I don't think it's misleading. This is a consistent rule in CF standard
> names: quantities with different canonical units must have different standard
> names.

Isn't the use of "cell_methods" with a value of "variance" an example where
we don't require a different standard_name even though the units are
different? I would have said that standard names need to match and units
need to be conformable in order for quantities to be comparable.

Brian



On Thu, Jun 17, 2010 at 09:03:47AM +0100, Jonathan Gregory wrote:
> Dear Benno
>
> I think our arguments are all reasonable and clearly stated. The conclusion
> is not clear. Other points of view would be useful.
>
> > 1) Fourier transform is a change of basis, not physical variable -- it
> > is invertible as a matter of fact, as long as you keep the real and
> > imaginary parts. Because it is a change of basis, it is much more
> > analagous to a projection transformation than a transformation of the
> > physical variable.
> >
> > There is a change of units, you are right, but that is misleading if
> > it leads you to think that more than a change of basis has occured.
>
> I don't think it's misleading. This is a consistent rule in CF standard
> names: quantities with different canonical units must have different standard
> names. Actually that's not because the units are somehow of magical
> significance, but different units do imply some significant difference in
> definition. A quantity and its Fourier transform are clearly not comparable
> in the sense that you could, for instance, try to calculate their difference.
> If the standard name is the same there is no distinction in CF metadata
> between them except inspection of their coordinate dimensions, which is not
> where a generic application would expect to look. It might search a file for
> a variable of air_pressure and find a Fourier transform of air pressure by
> looking at the standard names, and that's not what it would want.
>
> I take your point that this is the same kind of situation as a change of
> spatial grid of a given quantity e.g. by interpolation, where the only
> distinction is that the spatial coordinate variables have changed. Still I
> think that is a smaller change than a Fourier transform. After a grid-mapping
> operation, you do still have horizontal spatial coordinate variables. After
> a Fourier transform, one of the spatiotemporal coordinate variables has
> disappeared altogether and been replaced with a different coordinate. I would
> guess that the average scientific user of the data would be more likely to
> regard air_pressure on two different horizontal grids as the "same geophysical
> quantity", but air_pressure and its Fourier transform wrt time as "different
> geophysical quantities". That may sound arbitrary and hence the change of
> units is a useful practical guide to deciding.
>
> > 2) Software that manipulates complex numbers, (including FFT), needs
> > both the real and imaginary parts -- putting them in separate
> > variables is a highly artificial reconstruction of the data which has
> > to be undone in order to proceed with any manipulation that treats it
> > as complex numbers. Also, the software needs to detect the components
> > of the complex numbers -- you are making it much more difficult. The
> > point of metadata is to make the necessary information available
> > clearly and unambiguously -- having a dimension clearly labelled as
> > corresponding to real and imaginary is much closer to the information
> > needed to write software to correctly handle complex data.
>
> Again, I understand that point. It could be a bit less convenient, but surely
> it's not *that* bad, is it? It's no harder to look for two different standard
> names than two different values of a coordinate variable. The labelling of real
> and imaginary in the standard name would be just as clear and unambiguous as
> putting it in a coordinate variable - possibly more obvious, in fact.
>
> My argument for doing it this way is that it's simpler i.e. it just needs the
> standard name, no more machinery, and because it's what we do in other cases
> where there are a small number of components - usually two (xy) or three (xyz).
>
> > 3) CF should handle spectral harmonics as well.
> Yes, when it is requested to do so. I'd probably agree with you that in that
> case we would have a coordinate dimension, because it would be multivalued and
> the number and identity of the components would depend on the spectral
> resolution.
>
> Best wishes
>
> Jonathan
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Thu Jun 17 2010 - 08:05:25 BST

This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:41 BST

⇐ ⇒