Powered by Trac 1.5.4
By Edgewall Software
.
Visit the Trac open source project at
http://trac.edgewall.org/
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.
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.
There is no point trying to do the equivalent for GFZ files because:
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.
Testing revealed a fault inthe logic of ropp_io/bufr/ropp2bufr_mod.f90, which has been fixed at r4848.
Improved range-checking of the reference POD has been introduced at r4851.
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
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.
Powered by Trac 1.5.4
By Edgewall Software
.
Visit the Trac open source project at
http://trac.edgewall.org/
Set up https://trac.romsaf.org/ropp/browser/ropp_src/branches/dev/Share/ic_refpod to do this.