id summary reporter owner description type status priority milestone component version resolution keywords cc 470 Increase precision of impact parameters appearing in BUFR Ian Culverwell 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 .0 or .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. " defect new normal Whenever ropp_io 8.0 BUFR