date: Fri, 25 Apr 2008 08:34:38 +0100
from: Ian Harris <i.harrisatXYZxyz.ac.uk>
subject: Re: cru ts 3.0 wetdays
On 25 Apr 2008, at 01:11, Tim Osborn wrote:
<excerpt>Harry and Phil,
More late-night checking!
I know that feeling.. dangerous when combined with these programs, you
could enter another dimension entirely!
<excerpt>although it is not commented to say so, my checking of
rd0cal.pro (both from /cru/cruts/version_3_0/BADC_AREA/) against New et
al. (2000) strongly suggests that:
(i) the 2.5 degree rainday normals are needed in units of days*10
They are (min 0, max 303).
<excerpt>(ii) the 2.5 degree precip normals are needed in units of mm
(I prefer to
say mm/month, but since these are monthly totals, mm is the same as
They are undetermined at the present time, though the nearest guess is
mm (min 0, max 391).
<excerpt>(iii) the 2.5 degree precip timeseries must NOT BE ANOMALIES
expected to be in units of mm (I prefer to say mm/month).
Now here we enter the Twilight Zone� :-)
The grid program reads the precip timeseries in a format peculiar to
anomdtb.f90, the anomalising program. However, I've found an option in
the original version of anomdtb that looks like it might dump the raw
values.. I'll try it out.
<excerpt>(iv) the output is 2.5 degree grid of:
100*(synth_wetday - wetdaynormal)/wetdaynormal
i.e., percentage anomalies of synthetic wetdays.
<excerpt>(iv) there is a error in the programming logic that means
that any months
in the time series with zero precip will be assigned a zero percentage
anomaly for wetdays, which is clearly wrong (unless the wetday normal
zero). If you have a location / month of the year with non-zero normal
precip and non-zero normal wetdays, and you happen to get one
dry month, it will incorrectly estimate that the wetdays are the same
normal (i.e., wetday anomaly is zero). How can there be normal wetdays
when there is no precipitation! No idea how often you get zero precip
regions with non-zero normals, but surely some arid-ish areas must have
In addition to this, I still think, from your calculations Harry of
values, that the 2.5 degree precip normals are wrong. But I haven't
time to check yet.
So... in terms of units, do (i) and (ii) match the files that are
<excerpt>The prebin files definitely do not match requirement (iii),
inspected them and they are anomalies while the program requires
monthly precipitation. Since we are also reading in the precip normals
(though see note above re. concern over whether the 2.5 degree normals
wrong/right!), we could convert the prebin anomalies into absolutes
rd0_gts_tdm.pro. But we would need to know what units the prebin
anomalies are in. Are they:
or 10 times this, or 100 times this, or something different? I've
inspected the files and it's rather hard to tell! Better is to work it
out from the program that produced them.
They're produced by the IDL gridding suite (quick_interp_tdm2.pro).
This reads the precip anomalies (output from anomdtb.f90 and the same
ones used when creating the precip grids). They are multiplied by
'anomfac' on the way in, and 'binfac' on the way out (when gridded).
We've been running with no anomfac and binfac=10.
So, let's backtrack to anomdtb. This prompts the user for the
3-character parameter code, then looks it up with CheckVariSuffix to
get the appropriate 'Factor'. If you look in the tail end of
grimfiles.f90 you'll see the list, the Factor for 'pre' is 0.1. It
also checks for 'pre' or 'wet' and invokes percentage anomalies for
them, setting the flag QAnomPercent to 1. Then, later in the program
it uses the Factor - but divides by it! So units are then mm*100? We
then get the percentage anomaly calculation that threw me before:
nint(1000.0*((real(DataA(XAYear,XMonth,XAStn)) / &
So the anomalies at this stage are in mm*1000? The final writing of
the data invokes Factor again, this time as a multiplier! So I would
say the end result is percentage anomalies of mm*100. But this is very
confusing, (a) because percentage anomalies ARE very confusing, and
(b) because of the labyrinthine nature of these program suites.
Taking all the above, I'd have to say the precip gridded binary
anomalies are in mm*1000! Which can't be right.
meh.. going for a shower, more later.
So we're still someway off with getting wetdays done. I'm not certain
that rd0_gts_tdm.pro ever worked, given our earlier finding that it was
reading the wrong resolution normals and now the problems above.
Tim M. had a different version hidden away somewhere?!
I have a better formula for making synthetic wetdays from precip than
which Mark New came up with and which Tim's programs are trying to
had thought, given time constraints, to leave implementing that till a
later time, but now I wonder whether to scrap the current synthetic
wetdays and use the improved formula! We'd still need to know the
to the above questions re. the units of the various files that we're
though, so the next task is to answer them.