Hold 'reference' POD values away from level1a

[Ian Culverwell]

This is the issue that has been referred to in #431 and #433.

The basic point is that

ncks -H -v/data/occultation/position_rec_fixed eum_test.n4         
/data/occultation/position_rec_fixed
xyz[0] position_rec_fixed[0]=-4576838.62065 
xyz[1] position_rec_fixed[1]=4230563.95258 
xyz[2] position_rec_fixed[2]=-3612829.96993 

but

ncks -H -dt,0 -v/data/level_1a/closed_loop/r_receiver eum_test.n4  
/data/level_1a/closed_loop/r_receiver
t[0] xyz[0] r_receiver[0]=-3648067.50063 
t[0] xyz[1] r_receiver[1]=5056884.48351 
t[0] xyz[2] r_receiver[2]=-3607933.47362 

These are very different because the first are in ECF coordinates and the second are in ECI (J2000).

If we ask for some lev1a data, then data%lev1a%r_leo(:,1:3) becomes populated with the latter values, which is OK except when it comes to BUFR encoding, because this assumes ECF coords. On the other hand, if we don't want any lev1a data but we do ask for BUFR data, then the first variables are read into data%lev1a%r_leo(1,1:3) - ie, a lev1a substructure of length 1. This at least is in the right frame.

There are two inconsistencies in the BUFR files produced by the two methods. The first, which arises from the use of different frames of reference, could be fixed relatively easily by a call to eci2ecf. But the second, which arises from the fact that the prefered reference value is not equal to the first recorded satellite position, in any frame. (It's the satellite positions at SLTA=0, for the EUM-data.)

A better solution would be to hold the reference values away from the level1a data, so that we can keep both in the same file. Stig suggests the data%georef substructure, which seems sensible.

There may be lots of changes throughout ROPP (eg to copy/assign the new variables, and to not change existing behaviour or ucar2ropp and gfz2ropp), so it might be better to do this development in a branch.

[Ian Culverwell]

Set up https://trac.romsaf.org/ropp/browser/ropp_src/branches/dev/Share/ic_refpod to do this.

[Ian Culverwell]

First work lodged at r4840, r4843 and r4844.

[Ian Culverwell]

test.sh

[Ian Culverwell]

The codes are tested by test.sh (attached). The results (also attached) show that earlier versions of eum2ropp (with or without the now redundant -b) was putting the correct LEO positions (ie the ones from /data/occultation/position_rec_fixed, in ECF coords) in the netCDF file, and that these were correctly encoded in BUFR, either directly via eum2bufr or indirectly via eum2ropp | ropp2bufr. But if we asked for some lev1a data, via eum2ropp -l cl+rs, and then converted to BUFR using ropp2bufr, earlier versions of the code put the incorrect ECI coordinates in the BUFR file (because that's all they had), while newer versions (which store the reference POD as well as the lev1a POD), put the correct ECF coordinates in the BUFR file. These match the results of eum2bufr.

[Ian Culverwell]

eum_test_cntl0.out

[Ian Culverwell]

eum_test_cntl1.out

[Ian Culverwell]

eum_test_cntl2.out

[Ian Culverwell]

eum_test_test0.out

[Ian Culverwell]

eum_test_test1.out

[Ian Culverwell]

eum_test_test2.out

[Ian Culverwell]

The -b option to eum2ropp has been removed at r4846.

[Ian Culverwell]

There is no point trying to do the equivalent for GFZ files because:

• There is no information about satellite positions in the NRT files; and
• There is no equivalent 'reference' POD in the PD files. These contain the LEO and GNS positions and velocities, so we could (eg) use the first values, but these are in ECI coordinates (as for EUM) so would need converting to ECF coordinates anyway. The world has managed well enough so far without this information; it can wait a little longer.

[Ian Culverwell]

The same is true of ucar2ropp. The atmPrf files, like the GFZ NRT files, contain no POD info. The atmPhs files, like the GFZ PD files, contain r_leo and r_gns in ECI coords (which would need converting to ECF, even if we arbitrarily choose representative elements), but no 'reference' values.

[Ian Culverwell]

Testing revealed a fault inthe logic of ropp_io/bufr/ropp2bufr_mod.f90, which has been fixed at r4848.

[Ian Culverwell]

The ROPP9.0 UG documentation has been updated at r4850.

[Ian Culverwell]

Improved range-checking of the reference POD has been introduced at r4851.

[Ian Culverwell]

Further tidying up has been done at r4853.

[Ian Culverwell]

Some improvements to test2ropp.f90 have been implemented at r4855.

[Ian Culverwell]

Resulting light documentation changes have been made at r4856.

[Ian Culverwell]

All these code changes have been merged into the ROPP90_prototype branch at r4857. Any further work will take place on that branch, so this ticket is now closed.