from: "Tim Osborn" <t.osbornatXYZxyz.ac.uk>
subject: CRU TS 3.0
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
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
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
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!