Thursday, June 7, 2012

4920.txt

date: Fri, 25 Apr 2008 08:34:38 +0100
from: Ian Harris <i.harrisatXYZxyz.ac.uk>
subject: Re: cru ts 3.0 wetdays
to: t.osbornatXYZxyz.ac.uk

<x-rich>Hi Tim,


On 25 Apr 2008, at 01:11, Tim Osborn wrote:

<excerpt>Harry and Phil,


More late-night checking!

</excerpt>

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
rd0_gts_tdm.pro and

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

</excerpt>

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

mm/month)

</excerpt>

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).

</excerpt>

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>

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
is

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
completely

dry month, it will incorrectly estimate that the wetdays are the same
as

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
in

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
mean

values, that the 2.5 degree precip normals are wrong. But I haven't
had

time to check yet.


So... in terms of units, do (i) and (ii) match the files that are
being used?

</excerpt>

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
absolute

monthly precipitation. Since we are also reading in the precip normals

(though see note above re. concern over whether the 2.5 degree normals
are

wrong/right!), we could convert the prebin anomalies into absolutes
within

rd0_gts_tdm.pro. But we would need to know what units the prebin

anomalies are in. Are they:


(p-pnorm)/pnorm


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.

</excerpt>

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:


<fontfamily><param>Courier</param>DataA(XAYear,XMonth,XAStn) =
nint(1000.0*((real(DataA(XAYear,XMonth,XAStn)) / &


real(NormMean(XMonth,XAStn)))-1.0))

</fontfamily>

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.


Cheers


Harry


<excerpt>

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.
Perhaps

Tim M. had a different version hidden away somewhere?!


I have a better formula for making synthetic wetdays from precip than
that

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
answers

to the above questions re. the units of the various files that we're
using

though, so the next task is to answer them.


Cheers


Tim








</excerpt>
</x-rich>

No comments:

Post a Comment