The HARRY_READ_ME.txt file

*** BACK AT CRU ***

Tried to compile makegrids.for on uealogin1 (as crua6 is being retired). Got an odd error:

ld: warning: file /usr/local/netcdf-3.6.1/lib/libnetcdf.a(fort-attio.o): wrong ELF class: ELFCLASS64

..which was cured with the addition of '-xarch=native64' to the compile statement:

f77 -xarch=native64 -I/usr/local/netcdf-3.6.1/include/ -o makegrids ../../BADC_AREA/programs/fortran/makegrids.for /usr/local/netcdf-3.6.1/lib/libnetcdf.a

Then had to play around to try and reduce the size of the NetCDF files - they were bigger than the uncompressedASCII ones! This
was because the variable was declared as DOUBLE, which is 64 bits, or 8 bytes, per datum. A waste, since we deal with the data
as integers and use factors to restore 'real' values. So redeclared as INT. Considering re-redeclaring as SHORT, which is 16
bits to INT's 32.. however, that only gives me signed -32,768 to 32,767 or unsigned 0 to 65,535. That's enough for our datasets
but only if precip has a positive missing value code, which I don't like the sound of.

Reproduced all primaries and secondaries with INT typing for the NetCDF component.

Simultaneously trying to work out why stncounts.for is apparently ignoring the South Pole station
(Amundsen-Scott) even though the rest of the output looks fine.. eventually realised that the land/sea mask is blobking it!!

Station counts work continues.. should the NetCDF files be written as INT to match the data files, or SHORT to save a lot of space?
In fact, should the station counts be in the same NetCDF files as their data?!!

Finished off the local regenration of VAP and FRS from the corrected dtrbin files:

DTR fix:
IDL> quick_interp_tdm2,1901,2006,'dtrbin/dtrbin',750,gs=2.5,dumpbin='dumpbin',pts_prefix='dtrtxt/dtr.'

VAP binary regen:
IDL> vap_gts_anom,dtr_prefix='dtrbin/dtrbin',tmp_prefix='tmpbin/tmpbin',1901,2006,outprefix='vapsyn/vapsyn.',dumpbin=1

Note that, as expected, results ARE different for synthetic vap!

First two lines of the CRUA6 run:

1901 vap (x,s2,<<,>>): 1.53894e-05 6.16462e-06 -0.160509 0.222662
1902 vap (x,s2,<<,>>): -0.000123921 3.46215e-05 -0.268891 0.0261302

First two lines of the damp.badc.rl.ac.uk run:

1901 vap (x,s2,<<,>>): 1.67770e-05 6.23626e-06 -0.160509 0.222689
1902 vap (x,s2,<<,>>): -0.000122533 3.46933e-05 -0.268891 0.0644855

Different compilers.. different architectures?.. different OS.. whichever.

IDL> quick_interp_tdm2,1901,2006,'vapglo/vap.',1000,gs=0.5,dumpglo='dumpglo',synth_prefix='vapsyn/vapsyn.',pts_prefix='vaptxt/vap.'

Paused here as waiting for completion of makegrids2.for (includes station counts in NetCDF files). One early ramification of this is
that glo2abs.for now saves filenames with year.month, rather than replicating the loopy month.year that quick_interp_tdm2.pro gives.
This will allow file lists to be compiled with 'ls >tmpfile', so that timespan and missing files can be detected at the start. Have
also had to amend (and re-run at great length!) stnounts.for to do the same.

Just realised I still haven't worked out how to do the station counts for the secondaries. I can't work out how Tim did it either,
since he worked out counts at the same stage I do. Did he let the primary parameter's counts override? Or backfill? Well we could
take the approach that the gridding routine takes, namely to use observed data and only refer to synthetic when that fails (and only
refer to normals when that fails, obviously).

So, stncounts will have to accept TWO sets of .txt files. At each timestep it will have to first count the secondary parameter's
stations, then the primary parameter(s) will be counted and fill in any zeros in the grid. However, we will need different information
for the paper - what use is the effective station count as some is of higher 'quality' than the rest? So will probably need the regular
observed-only count as well.. which could be a separate run of stncounts but faaar more sensible to be a side effect of this run.

Oh Gods.. I've got to modify another program. *cries*

I think the mods to stncounts will be the turning point for all the programs. So far, they have all been generic, but this is not
tenable if the system is to be automated - they need to be aware of the parameters and what they mean. Otherwise stncounts will have
to be told how many primaries produced the synthetic grids, etc, etc - stupid. So I need to devise a directory structure and file
naming schema that will support the entire update process. Eeeeeeeek.



** time passes.. other projects given higher priority.. **