Opened 16 years ago

Closed 16 years ago

#146 closed defect (wontfix)

bufr2ropp output impact parameter data to nearest 0.5 m

Reported by: Huw Lewis Owned by: Huw Lewis
Priority: normal Milestone: 2.0
Component: ROPP (all) Version: 2.0beta
Keywords: Cc: dave.offiler@…

Description

Feedback from Stig indicates output from bufr2ropp has height data to nearest 0.5 m, although BUFR formatting should be able to handle heights to nearest 0.1 m.

Testing using ropp2bufr -> bufr2ropp confirms this is still a problem for v2.0 candidate release.

Investigation and fix required.

Change history (1)

comment:1 by Huw Lewis, 16 years ago

Resolution: wontfix
Status: newclosed

Truncation of impact parameter variables occurs within ropp2bufr (i.e. on creating the BUFR file). This is because the BUFR encoder requires REALs. The Values array is filled in ropp2bufr from the input ROdata structure with the REAL() conversion function.

e.g.

    Values(IE+19) = REAL(ROdata%Lev1b%Impact(in))      ! Impact parameter (m)
    IF ( Values(IE+19) < 6200000.0 .OR. &
         Values(IE+19) > 6600000.0 )    &
         Values(IE+19) = MISSING

Impact parameters in the range 6200000 m - 6600000 m have 7 significant figures, so these data are truncated (although the BUFR format could in principle hold values to nearest 0.1m). On decoding impact parameters are defined to nearest 0.5 m.

e.g.

in: 6399764.1 -> ropp2bufr -> 6399764 ...... bufr2ropp -> 6399764.0
    6400071.7 ->           -> 6400072                     6400071.5
    6408372.5                 6408372                     6408372.5

The output impact parameters are therefore only available to the nearest 0.5 m. Tests using ifort9, nag and pgf95 compilers gave same results.

This issue should be checked again if a different BUFR library (e.g. ECMWF) is used. Ticket closed as won't fix.

Note: See TracTickets for help on using tickets.