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

From: Jonathan Gregory <j.m.gregory>
Date: Thu, 17 Jun 2010 09:03:47 +0100

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
Received on Thu Jun 17 2010 - 02:03:47 BST