date: Wed, 23 Apr 2008 07:59:26 +0100 (BST) from: P.Jones@uea.ac.uk subject: Re: CRU TS 3.0 to: t.osborn@uea.ac.uk Tim, Thanks again for all your efforts. Maybe you'll be able to write the paper as well! I did start 9 months ago, so have a few pages. I always thought this ought to have been much easier than it seems to have been. Very good that Douglas will do the DTR/Cloud work if you can get the support. I just wish that Harry had more of a feel for what he's been doing. I should have gotten Harry to produce more results as he was doing the original work. I assumed he'd gotten things right, as I thought it was just a matter of getting Tim M's programs to work. He ought to have looked at the fortran rather than Tim M's comment lines. Cheers Phil > Hi Harry, > > thanks for the email re. the VAP data. Yes, go ahead and delete those 3 > stations and recreate. That should, I hope, solve the main problems... > and more minor problems can wait for some future time when we actually > have time to worry about more minor things! > > Regarding the extensive and strange banding problems found in the new > variable (wetdays), I think I may have found the cause. As I mentioned > earlier, it is the synthetic wetdays that have the banding in them. > > Looking at the rd0_gts program in > > /cru/cruts/version_3_0/BADC_AREA/programs/idl/rd0_gts_tdm.pro > > which is what you used to produce the synthetic wetdays, it seems to be > reading (see lines 19 and 22) gridded normals for precipitation and for > wetdays from files > > ../norms_05_binary/glo.pre.norm > > and > > ../norms_05_binary/glo.rd0.norm > > Now, from the directory name (the '05') and from the code (the 720*360 on > lines 18 and 21) and from the size of the files it's reading, my guess is > that these are normals on a 0.5 degree grid. But the precip anomalies > that you're reading (from ../prebin/) are on a 2.5 degree grid (following > Tim M.'s instructions for synthetic data), and the output it produces is > on a 2.5 degree grid. > > What will happen, therefore, is that when rd0_gts attempts to extract pre > and wet (rd0) normals for all the 2.5-degree land boxes from the > 0.5-degree arrays of normals, it will pick up chunks of data from just the > first 1/25th part of the arrays, sometimes picking up bands of land with > non-missing values, and sometimes picking up bands of ocean with missing > values. That would explain the banding. > > The solution seems to be to alter this program to read normals on the 2.5 > degree grid, assuming you have these. Presumably you do, in > ../norms_25_binary/ > > There may be a similar problem with frost days, since frs_gts_tdm.pro > seems to be reading frostday normals from ../norm_05_binary/ too. However > I haven't checked the frostday data you have made, since I don't need that > variable -- please don't redo frostdays (at least until you have redone > vap and wetdays), I'm just noting that the current file is likely to be > wrong and hence not suitable for distribution. > > It looks like you already read 2.5 degree normals when making synthetic > vap, which is why that doesn't show this problem. > > The other thing to note is that the final output from rd0_gts is > fractional anomalies * 100 -- i.e. (wet-wetnorm)/wetnorm) -- or you could > call them percentage anomalies. I'm not sure, therefore, what you need to > set synthfac to when you read these synthetic anomalies... maybe > synthfac=100 rather than synthfac=10? It depends what units > quick_interp_tdm2 wants to be working in. If it wants to work in > percentage anomalies, then synthfac=1 (or omit synthfac) instead of 100. > Presumably it needs the synthetic and actual wetday anomalies to be in the > same units... looking at anomdtb.f90 (which I presume is how you made the > actual station wetday anomalies) it seems (lines 490 or 504) to be > multiplying fractional anomalies by 1000, which would result in percentage > anomalies * 10! Not sure if this is actually what is happening since this > is the first time I've looked at anomdtb.f90 and it seems fairly > complicated! But it implies synthfac=0.1 might be needed! I guess we may > need to use trial and error to find the right value for synthfac. I'd > start with synthfac=100 since I think the values showed too little > variability with synthfac=10 -- however this may all change when the > banding problem is solved! > > Basically... good luck! > > Cheers > > Tim > > > >