Increase precision of impact parameters appearing in BUFR

[Ian Culverwell]

Christian Marquardt (EUM) reports:

Harald complained that in bufr files generated by eum2bufr, the  
impact parameters are only precise to 0.5 m (whereas the bufr spec  
seems to indicate that that it should be given at an accuracy of 
0.1  m). Having looked at a representative number of bufr products 
(well  - one), it looks like he's right - impact parameters seem to 
be  encoded as either <something>.0 or <something>.5 m.

By chance, do you have an idea where that accuracy / rounding 
takes  place? I haven't found anything in either 
ropp_io_read_ncdf_get.f90  (where the data is
read from the netcdf files) nor in the  ropp2bufr_mod.f90, where 
the data is packed into a long array before  written out as bufr.

I suggested

Well, assuming they're not rounded to +/- 0.5m in the input file, 
then I suspect it's the demotion to single precision effected by the 
use of the intrinsic function REAL without a 'KIND=dp' qualifier in 
ropp2bufr_mod.f90, eg lines 910ish:

      Values(IE+7) = REAL(ROdata%Lev1b%Impact_L1(in))  ! [007040] 
Impact parameter (m)
      IF ( Values(IE+7) < 6200000.0_dp .OR. &
           Values(IE+7) > 6600000.0_dp )    &
           Values(IE+7) = MISSING

Replacing this with

      Values(IE+7) = REAL(ROdata%Lev1b%Impact_L1(in), KIND=dp)  !
[007040] Impact parameter (m)

should generate higher precision Values. But I don't know how this 
would affect the BUFR output - maybe the resulting Values would be 
'too precise', and crash the output?

Chris confirms that this fixes it. (Email exchange attached.)

Agreed to

1) Fix IP issue at ROPP9.0. Chris and Stig will fix their respective versions likewise.

2) Revisit the whole issue of the Values(i) = REAL(x) structure of ropp2bufr_mod.f90 in the long term.

So the milestone of this ticket will change in due course.

[Ian Culverwell]

BUFR_IP_precision.txt

[Ian Culverwell]

Christian Marquardt (EUM) has sent a modified ropp2bufr_mod.f90 file, and a listing of the patches (some of these relate to #431). Both attached.

[Ian Culverwell]

ropp2bufr_mod.f90.30062016

[Ian Culverwell]

bufr-fixes.patch.30062016

[Ian Culverwell]

sp_vs_dp.png

[Ian Culverwell]

To spell it out, the problem is:

 KIND(ROdata%Lev1b%Impact_L2(in)) =            8
 ROdata%Lev1b%Impact_L2(in) =    6386311.83798631     
 KIND(REAL(ROdata%Lev1b%Impact_L2(in))) =            4
 REAL(ROdata%Lev1b%Impact_L2(in)) =    6386312.    
 KIND(REAL(ROdata%Lev1b%Impact_L2(in), KIND=dp)) =            8
 REAL(ROdata%Lev1b%Impact_L2(in), KIND=dp) =    6386311.83798631     

[Ian Culverwell]

When we apply the KIND=dp qualifier to the impact, impact_L1 and impact_L2 ROPP-to-BUFR translation statements in ropp2bufr_mod.f90 we find

IE+19, Impact(IE+19) =     56    6386311.838
IE+19, Impact(IE+19) =     79    6386429.508
IE+19, Impact(IE+19) =    102    6386547.678
IE+19, Impact(IE+19) =    125    6386667.308
IE+19, Impact(IE+19) =    148    6386786.938

cf

IE+19, Impact(IE+19) =     56    6386312.000
IE+19, Impact(IE+19) =     79    6386429.500
IE+19, Impact(IE+19) =    102    6386547.500
IE+19, Impact(IE+19) =    125    6386667.500
IE+19, Impact(IE+19) =    148    6386787.000

at ROPP8.1.

decbufr doesn't help with displaying these. it suggests

    56 007040    6386311.5
    79 007040    6386429.5
   102 007040    6386548.0
   125 007040    6386667.0
   148 007040    6386787.0

cf

    56 007040    6386312.0
    79 007040    6386429.5
   102 007040    6386547.5
   125 007040    6386667.5
   148 007040    6386787.0

at ROPP8.1. So it too appears to be doing some rounding.

But if we pass the BUFR output through bufr2ropp and print out the resulting netCDF impact values at high enough precision we find

ncks -H -Q -ddim_lev1b,0,4 -vimpact eum_test_cntl0_test.nc -s%15.3f\n
    6386311.800
    6386429.500
    6386547.700
    6386667.300
    6386786.900

at ROPP-9.0 and

ncks -H -Q -ddim_lev1b,0,4 -vimpact eum_test_cntl0_cntl.nc -s%15.3f\n
    6386312.000
    6386429.500
    6386547.500
    6386667.500
    6386787.000

at ROPP-8.1. The ROPP9.0 values are the correctly rounded (ie to +/- 0.1 m) versions of the input values (see above), whereas the ROPP8.1 values have been over-rounded (ie to +/- 0.5 m).

[Ian Culverwell]

Change committed at r4987.

[Ian Culverwell]

Now shifting milestone to whenever, as agreed with EUM.