ajdawson / eofs

EOF analysis in Python

Home Page:http://ajdawson.github.io/eofs/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

EOFs not quite orthogonal? PCs rigorously are.

brianmapes opened this issue · comments

Here's a notebook I used in class with your package. It uses OpenDAP data for reproducibility. No weighting, a simple SST gridpoints analysis.

In the cell numbered 70-71 I checked orthogonality with simple np.corrcoef(). Poor for eofs, great for pcs. Any thoughts on why?

np.corrcoef(eofs[0,:,:].ravel(), eofs[1,:,:].ravel())
array([[ 1. , -0.07549177],
[-0.07549177, 1. ]])

np.corrcoef(pcs[:,0], pcs[:,1])
array([[1.00000000e+00, 1.87961874e-08],
[1.87961874e-08, 1.00000000e+00]])

http://nbviewer.jupyter.org/github/MPOcanes/MPO624-2018/blob/master/assignments/module3-empiricaldecomp/EOF_ERSSTmap.ipynb

Hi Brian

The dot product of the leading EOFs is quite close to zero at 1.7691211e-07. If I first cast your input values to double precision this is reduced to 1.7813441693936838e-16 which I'd say is pretty close to orthogonal (although this does not change the result from corrcoef by an appreicable amount). I also noticed the dot product of the leading 2 PCs is one order of magnitude smaller than for the leading EOFs in both double and single precision.

I'm guessing this is just a numerical accuracy issue. Since the dot product is small I'm fairly satisfied that the EOFs are as expected. Does that seem reasonable to you?

(On a side note, way back in 2005 I took ATM305 at UM when you were teaching it, nice to cross paths again!)

Yes it must be a problem with the EOFs having nonzero mean. Interesting that the PCs don't have that problem. Anyway, closed.