date: Fri, 25 Apr 2008 08:34:38 +0100 from: Ian Harris subject: Re: cru ts 3.0 wetdays to: t.osborn@uea.ac.uk Hi Tim, On 25 Apr 2008, at 01:11, Tim Osborn wrote: Harry and Phil, More late-night checking! I know that feeling.. dangerous when combined with these programs, you could enter another dimension entirely! 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 They are (min 0, max 303). (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) They are undetermined at the present time, though the nearest guess is mm (min 0, max 391). (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. (iv) the output is 2.5 degree grid of: 100*(synth_wetday - wetdaynormal)/wetdaynormal i.e., percentage anomalies of synthetic wetdays. As expected. (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? See above 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. 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: CourierDataA(XAYear,XMonth,XAStn) = nint(1000.0*((real(DataA(XAYear,XMonth,XAStn)) / & real(NormMean(XMonth,XAStn)))-1.0)) 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 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