Thursday, June 7, 2012


date: Fri, 25 Apr 2008 08:34:38 +0100
from: Ian Harris <>
subject: Re: cru ts 3.0 wetdays

<x-rich>Hi Tim,

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 and (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
and are

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.


As expected.

<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

this frequently.

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
being used?


See above

<excerpt>The prebin files definitely do not match requirement (iii),
since I've

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
within 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 (
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:

<fontfamily><param>Courier</param>DataA(XAYear,XMonth,XAStn) =
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 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
use. I

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.




No comments:

Post a Comment