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
>
> <bryan.lawrence at stfc.ac.uk> 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
Received on Mon Jun 28 2010 - 06:29:36 BST
