date: Wed, 23 Apr 2008 07:59:26 +0100 (BST)
from: P.Jones@uea.ac.uk
subject: Re: CRU TS 3.0
to: t.osborn@uea.ac.uk


 Tim,
   Thanks again for all your efforts. Maybe you'll be able to write
 the paper as well!  I did start 9 months ago, so have a few
 pages.
   I always thought this ought to have been much easier than
 it seems to have been. Very good that Douglas will do the
 DTR/Cloud work if you can get the support.

   I just wish that Harry had more of a feel for what he's been
 doing. I should have gotten Harry to produce more results as
 he was doing the original work. I assumed he'd gotten things right,
 as I thought it was just a matter of getting Tim M's programs to work.
 He ought to have looked at the fortran rather than Tim M's comment
 lines.

 Cheers
 Phil


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