date: Wed, 23 Apr 2008 01:12:41 +0100 (BST) from: "Tim Osborn" subject: CRU TS 3.0 to: i.harris@uea.ac.uk 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