Incorrect POD in BUFR files

[Dave Offiler]

Testing of the beta 0.9 BUFR encoder at DMI has revealed a problem in incorrectly initialising ROPP arrays or incorrect BUFR encoding (or decoding) of POD information. Martin Sorensen reports:

Hi Dave 

Just hopefully a very stupid question
looking on some print stuff (below)
I'not quite sure what is meant by
the text..
from the text it seems like I'm putting
in things wrong instead of taking xyz
components it takes sample 1 2 and 3
- but then looking at the ropp txt file
it seems to be ok1! (?) so I'm a bit
confused... - do you have a hint here?

regards
Martin


 printout from the asigned ropp arrays
 ropp rleo 1  -3848581.57800000     
 ropp rleo 2   505815.154000000     
 ropp rleo 3   5554355.32400000     
 ropp vleo 1   6134.01599000000     
 ropp vleo 2  -1453.70266000000     
 ropp vleo 3   4369.62105000000     
 ropp rgps 1  -18313275.4810000     
 ropp rgps 2  -14258272.3820000     
 ropp rgps 3  -12758140.7160000     
 ropp vgps 1   2669.45075000000     
 ropp vgps 2  -1125.90513000000     
 ropp vgps 3  -2588.43324000000     
 ropp leoh   6776303.72679562     
 ropp leov   7670.26673003422     
 ropp gnsh   26484798.3698490     
 ropp gnsv   3885.05036085413     

  IN DIRECTION OF 0 DEGREES LONGITUDE, DISTANCE FROM EARM
-3848581.50
  IN DIRECTION 90 DEGREES EAST, DISTANCE FROM THE EARTH'M
-3848459.00
  IN DIRECTION OF THE NORTH POLE, DISTANCE FROM THE EARTM
-3848336.25
  ABSOLUTE PLATFORM VELOCITY - FIRST COMPONENT (SEE NOTEM S-1
6134.01611
  ABSOLUTE PLATFORM VELOCITY - SECOND COMPONENT (SEE NOTM S-1
6134.11426
  ABSOLUTE PLATFORM VELOCITY - THIRD COMPONENT (SEE NOTEM S-1
6134.21240
  SATELLITE CLASSIFICATION                              Code 002020
401
  PLATFORM TRANSMITTER ID NUMBER                        NUMERIC
29
  IN DIRECTION OF 0 DEGREES LONGITUDE, DISTANCE FROM EARM
-18313276.0
  IN DIRECTION 90 DEGREES EAST, DISTANCE FROM THE EARTH'M
-18313222.0
  IN DIRECTION OF THE NORTH POLE, DISTANCE FROM THE EARTM
-18313168.0
  ABSOLUTE PLATFORM VELOCITY - FIRST COMPONENT (SEE NOTEM S-1
2669.45068
  ABSOLUTE PLATFORM VELOCITY - SECOND COMPONENT (SEE NOTM S-1
2669.45850
  ABSOLUTE PLATFORM VELOCITY - THIRD COMPONENT (SEE NOTEM S-1
2669.46655
  TIME INCREMENT                                        SECOND
86.380
  LATITUDE (HIGH ACCURACY)                              DEGREE
43.03900
  LONGITUDE (HIGH ACCURACY)                             DEGREE
106.49900
  IN DIRECTION OF 0 DEGREES LONGITUDE, DISTANCE FROM EARM
-4114.00
  IN DIRECTION 90 DEGREES EAST, DISTANCE FROM THE EARTH'M
13495.00
  IN DIRECTION OF THE NORTH POLE, DISTANCE FROM THE EARTM
-15983.00
  EARTH'S LOCAL RADIUS OF CURVATURE                     M
6368781.0

Here, the netCDF looks to have valid POD X,Y,Z component triplets (for LEO and GNSS positions and velocities), but the decoded BUFR X,Y,Z triplest are almost (but not quite) identical.

[Dave Offiler]

BUFR encoder & decoder were origianlly written to interface with ROPP and CLIMAP tets-based files in which the natural array dimension order was ARRAY(1:3,1:nsamp). With the netCDF interface, the dimension order was changed to ARRAY(n,3) - see ROPP User Guide Table 5.2, footnote (b). The BUFR encoder/decoder had not caught up with this change.

Since the encoder-decoder pair had the same bug, the cycle tests were always succesful when checking the output file against the original.

The solution is simply to swap the dimension order in both ropp2bufr and bufr2ropp routines which convert between the ROPP structure and BUFR 1-d interface array.

Modified code files returned to Martin for re-making the tools and to re-generate a sample BUFR file. Modified files commeitted as [991]. Leaving this ticket open pending confirmation fro Martin that the mods completely solve the observed problem.

[Dave Offiler]

Problem confirmed as corrected.