From: Christian Marquardt [Christian.Marquardt@eumetsat.int] Sent: 29 June 2016 10:14 To: Stig Syndergaard Cc: Culverwell, Ian; Axel Von Engeln Subject: Re: eum2ropp/bufr odds and ends Hi, Sounds good to me. Axel send me a few fixes for the UCSR reading, I'll add them tonight and send you the patches then. Chris. -- Christian Marquardt > On 29 Jun 2016, at 09:31, Stig Syndergaard wrote: > > Hi Ian, Chris, > > We had this issue (IP to only 0.5 m precision) a long time ago when we started copying the EUM level1b to our BUFR. Back then the EUM IP were more precise (not sure why), ours were with the 0.5 m precision (using ROPP). At the time, as I recall it, it was thought to be platform dependent, I guess no one caught that it was a flaw in ropp2bufr_mod.f90. I'm happy that it can be solved. > > Ian's solution sounds good to me. We will do the same in our dmi_trunk. > > -Stig > >> On 2016-06-29 09:14, Culverwell, Ian wrote: >> Hi Chris, >> >> Lucky guess, I suppose! Thanks for checking it out. >> >> I don't know why we need the REAL conversion at all: Values(IE+7) is dp and so is ROdata%Lev1b%Impact_L1(in). Well, actually the latter is wp => EightByteReal = dp. I suppose someone could be working on a machine/platform in which EightByteReal is, accidentally or deliberately, set to FourByteReal. But in that case the impacts would be useless anyway. Hmm. >> >> I was hoping you weren't going to ask which other variables need this treatment! As you will have seen, all the assignments in ropp2bufr_mod.f90 use the Values(i) = REAL(x) formulation. Logically we ought to change them all, for consistency, but then we might change other things in the BUFR files, and then people don't like that, and then ... we have to screw the lid back on the can of worms that we've rashly opened. >> >> May I suggest: >> >> 1) You make this change for all the impact parameters (which is where it's likely to have the biggest, er, impact), and I do likewise for ROPP9.0. >> >> 2) I open a 'longterm' ticket to look at the implications of making >> this change throughout ropp2bufr_mod.f90. (This would include testing >> with the Met Office BUFR lib.) >> >> Sound OK? >> >> Ian. >> >> >> >> -----Original Message----- >> From: Christian Marquardt [mailto:Christian.Marquardt@eumetsat.int] >> Sent: 28 June 2016 16:30 >> To: Culverwell, Ian; Axel Von Engeln >> Cc: 'Stig Syndergaard' >> Subject: RE: eum2ropp/bufr odds and ends >> >> Ahh...! >> >> How did you know that? >> >> Awesome! It works well with the ECMWF library; I can't test the MetO one. >> >> Now - should I do that KIND=dp for all impacts? And also the bending angles? Or..? >> >> Thanks, >> >> Chris. >> >>> -----Original Message----- >>> From: Culverwell, Ian [mailto:ian.culverwell@metoffice.gov.uk] >>> Sent: Tuesday, June 28, 2016 4:45 PM >>> To: Christian Marquardt; Axel Von Engeln >>> Cc: 'Stig Syndergaard'; Culverwell, Ian >>> Subject: RE: eum2ropp/bufr odds and ends >>> >>> Hi Chris, >>> >>> 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? >>> >>> Ian. >>> >>> -----Original Message----- >>> From: Christian Marquardt [mailto:Christian.Marquardt@eumetsat.int] >>> Sent: 28 June 2016 15:18 >>> To: Culverwell, Ian; Axel Von Engeln >>> Cc: 'Stig Syndergaard' >>> Subject: RE: eum2ropp/bufr odds and ends >>> >>> Hi Ian, >>> >>> Yes, I'll send the modifications as soon as I can. >>> >>> Before, I have another question... >>> >>> 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. >>> >>> Thanks, >>> >>> Chris. >>>