From: Dennis Shea <shea_at_nyahnyahspammersnyahnyah>

Date: Mon, 10 Jul 2006 22:29:46 -0600 (MDT)

Date: Mon, 10 Jul 2006 22:29:46 -0600 (MDT)

Hello,

*> I having problems with the EVAL attribute of the EOFUNC funtion. The
*

*> eigenvalues are different from those computed with the EOFCOV
*

*> function, which are correct. The % explained variance given by the PCVAR
*

*> attribute, which had a problem in NCL 4.2.0.a032, are correct. Note that I'm
*

*> now running NCL a033 which fixed the @pcvar bug.
*

[1] There was more than a @pcvar bug.

FYI: We were never able to find the bug with a032 eofunc.

[2] It is quite possible that the eigenvalues calculated by

eofcov and eofunc could be different.

X(S,T) where S indicates Spatial dimensions an T the time dimension.

eofcov always computed the spatial covariance matrix: [SxS]

Using an LAPACK routine it computes S eigenvalues and returns

the user specified number of eigenvalues. Note: this means that

the system variance is spread over all S eigenvalues.

Historically, people have derived EOFs directly from [SxS].

However, as the spatial grids became larger, the time

to derive the EOFs became much longer.

eofunc uses a different approach. There is a theorem [Eckhart-Young]

that states that the number of unique eigenvalues is the

min(S,T). eofunc solves the smaller covariance matrix

[SxS] or [TxT]. Generally, T<S so, I speculate, eofunc

solved the [TxT] matrix and then did a transformation

to get the sppatial EOFs. Note ... this means the

variance is spread over T rather than S eigenvalues.

note1: eofunc is usually much faster than eofcov

because (often) it uses a much smaller covariance matrix.

note2: NCL uses symmetric storrage mode for the covariance

matrix to save space.

[3] eofcov eigenvalues "which are correct".

Based on [2] both could be correct but different! :-)

eofcov solve SxS, eofunc likely solved TxT

The thing that 'saves-the-day' is that for geophysical data

the eigenvalue spectrum is "red". Often they drop off quickly.

*>
*

*> I'm also getting errors with the PCVAR_VARIMAX attribute of the EOFUNC_VARIMAX
*

*> function: the variances have absurd results and do not sum to 100% (when I
*

*> compute all the EOFs). Interestingly, when I rescale the EOFs, prior to the
*

*> rotation operation, they do sum to 100% but they are not in decreasing
*

*> order. (The scaling used is the one that results in EOF loadings equal to the
*

*> correlations between the data and the PC, that is, each EOF loading is
*

*> multiplied by the square root of the eigenvalue and, if the covariance matrix
*

*> was used, divided by the standard deviation of the data.)
*

*>
*

*> The EOFUN_VARIMAX documentation about the % explained variance is
*

*> contradictable: in the RETURN VALUE part it is said that it is "returned as
*

*> an attribute of the returned value called pcvar_varimax" and in the
*

*> DESCRIPTION part it is said that it "is not returned".
*

I think there is a documentation error.

The variamax functions have never returned % variance.

I will check tomorrow.

--- D _______________________________________________ ncl-talk mailing list ncl-talk_at_ucar.edu http://mailman.ucar.edu/mailman/listinfo/ncl-talkReceived on Mon Jul 10 2006 - 22:29:46 MDT

*
This archive was generated by hypermail 2.2.0
: Tue Jul 11 2006 - 08:13:14 MDT
*