[CF-metadata] Proposal for spherical harmonics

From: jonathan.gregory at metoffice.com <jonathan.gregory>
Date: Mon, 17 Mar 2003 19:58:00 +0000

Dear Luis

Thank you for making your spherical harmonics proposal. It is useful to have
the requirements stated. I am wondering whether we could generalise it in a
couple of respects.

(1) Your proposal specifies a particular ordering for the complex coefficients
Fmn. I am afraid I am not familiar with the use of spectral data, so I don't
know whether this ordering is universally used, or if there are alternatives.
Could you (or others) comment on this?

If there is more than one possibility in use, we could avoid adopting a
particular one by instead regarding the data as two-dimensional, and then
closing up the unused space resulting from the truncation by following the
convention for compression by gathering in CF section 8.2. Thus

  dimensions:
    sizem=3;
    sizen=3;
    complex=2;
    lpoly=9;
  variables:
    int lpoly(lpoly);
      lpoly:compress="sizem sizen";
    float fmn(lpoly,complex);
      fmn:standard_name="legendre_polynomial_coefficient";
    float m(sizem);
      m:standard_name="legendre_polynomial_zonal_wavenumber";
    float n(sizen);
      n:standard_name="legendre_polynomial_meridional_wavenumber";
  data:
    m=0, 1, 2;
    n=0, 1, 2;
    lpoly=0, 1, 2, 4, 5, 8;

The values of lpoly are indices into (m,n) (n varying fastest). Hence, the
lpoly array indicates that the lpoly index of fmn has the polynomial
coefficients with wavenumbers (0,0), (0,1), (0,2), (1,1), (1,2), (2,2). I
hope that is correct for the triangular truncation! (Your summation says that
m runs from -M to +M, but there is a later statement that coefficients are
stored only for m>=0.)

The point of doing this is that the coefficients could be put in any order,
and it can be worked out quite easily what wavenumbers they have without
adopting a convention. It implies an ordering for components of complex numbers
e.g. 0=real 1=imaginary.

(2) We could avoid your assumption that there is only kind of spectral data
in the file by using a grid mapping variable, of the kind just introduced, to
describe the truncation, instead of global attributes. To do that, we would
add an attribute e.g.

    fmn:grid_mapping="triangular";

and a variable

  char triangular;
    triangular:grid_mapping_name="spherical_harmonic";
    triangular:truncation_type="triangular";
    triangular:maximum_wavenumber=3;
    triangular:latitude=?; // number of latitudes
    triangular:longitude=?; // number of longitudes

If different attributes are allowed for the different truncations, perhaps
they can be given specific names (as here), rather than the general J, K?
Are the applications of the latitude and longitude dimensions unambiguous?

Of course, spectral transformation is not a grid mapping in the sense so far
used. I am hijacking the mechanism, because the need seems similar.

What do you think?

Best wishes

Jonathan
Received on Mon Mar 17 2003 - 12:58:00 GMT