Hi Benno, Jonathan Ok, now I think you're both right :-) but I fancy muddying the water some.
I do *not* think it is appropriate to split the real and imaginary parts into two variables, since one almost never uses just one or the other, so it's a rather different case from splitting vector components. I do think that if you have taken the fourier transform, then it's not the same variable. I think in your example below, you've indicated that by not using a standard name but a long name for ssta. It would be wrong to store a FT of something with the same standard name as something that wasn't a FT. So, I'm inclined to agree that we need some sort of machinery to unambiguously define Fourier Transforms for storage, *and*, if desired, deal with the standard name implications. However, >float ssta(Y, X, F, C) ; Use of a new coordinate name, would have to say something about the order (I assume real followed by imaginary). Thought experiments follow: This would also allow me to think of/read the array as float ssta(Y,X,FC) where FC was a complex frequency array. Now, what about the spatial equivalent, a fourier transform over longitude? float ssta(t,Y,FC) or ssta=FT_x(ssta((t,y,x)) where now the coefficients are of a fourier transform in space. The problem is we have no standard name for 1/longitude ... but we could use your suggested machinery (complex parts) for the last part, and add a new standard name modifier (inverse_) to allow us to get around that. I think we would need to define somewhere what we had done with the twopi and the N, since there are various conventions for where one puts those. Complex parts alone would be ambiguous, so the definition would have to nail that. I don't have time right now, but it'd be worth spelling out what the consequence for more complex transformations of this sort of approach would look like. I would feel happier with this sort of approach if I knew what the next step(s) down this path would look like. (EOFs, PCs, Spherical Harmonics etc). Cheers Bryan On Friday 25 Jun 2010 21:52:52 Benno Blumenthal wrote: > Hi Bryan, > > Thanks for chiming in -- your comments are quite helpful. > > As for > > On Thu, Jun 24, 2010 at 6:45 AM, Bryan Lawrence > > <[email protected]> wrote: > > However, despite the discussion thus far, I'm not entirely sure I > > understand exactly what Benno is proposing, not least because there > > are different ways of arranging FT components in an array - or > > exactly what Jonathan is implying for spherical harmonics. > > My original proposal was > > Add a standard_name complex_parts to "tag" the dimension that > corresponds to complex parts. > > > so that we could tag a coordinate variable of a real-valued netcdf > variable as corresponding to the real/imaginary direction, e.g. > complex sst(C,X,Y,F) would have > > dimensions: > C = 2; > Y = 30 ; > X = 84 ; > F = 399 ; > variables: > integer C(C) ; > C:standard_name = "complex_parts" ; > float Y(Y) ; > Y:standard_name = "latitude" ; > Y:units = "degree_north" ; > float X(X) ; > X:standard_name = "longitude" ; > X:units = "degree_east" ; > float F(F) ; > F:standard_name = "frequency" ; > TFunits = "1/sec" ; > float ssta(Y, X, F, C) ; > ssta:long_name = "Sea Surface Temperature Anomaly" ; > > > The conversation then got rapidly more complicated. > -- Bryan Lawrence Director of Environmental Archival and Associated Research (NCAS/British Atmospheric Data Centre and NCEO/NERC NEODC) STFC, Rutherford Appleton Laboratory Phone +44 1235 445012; Fax ... 5848; Web: home.badc.rl.ac.uk/lawrence _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
