| 1 | From: Christian Marquardt [Christian.Marquardt@eumetsat.int]
|
|---|
| 2 | Sent: 29 June 2016 10:14
|
|---|
| 3 | To: Stig Syndergaard
|
|---|
| 4 | Cc: Culverwell, Ian; Axel Von Engeln
|
|---|
| 5 | Subject: Re: eum2ropp/bufr odds and ends
|
|---|
| 6 |
|
|---|
| 7 | Hi,
|
|---|
| 8 |
|
|---|
| 9 | Sounds good to me. Axel send me a few fixes for the UCSR reading, I'll add
|
|---|
| 10 | them tonight and send you the patches then.
|
|---|
| 11 |
|
|---|
| 12 | Chris.
|
|---|
| 13 |
|
|---|
| 14 | --
|
|---|
| 15 |
|
|---|
| 16 | Christian Marquardt <christian.marquardt@eumetsat.int>
|
|---|
| 17 |
|
|---|
| 18 | > On 29 Jun 2016, at 09:31, Stig Syndergaard <ssy@dmi.dk> wrote:
|
|---|
| 19 | >
|
|---|
| 20 | > Hi Ian, Chris,
|
|---|
| 21 | >
|
|---|
| 22 | > We had this issue (IP to only 0.5 m precision) a long time ago when we
|
|---|
| 23 | started copying the EUM level1b to our BUFR. Back then the EUM IP were more
|
|---|
| 24 | precise (not sure why), ours were with the 0.5 m precision (using ROPP). At
|
|---|
| 25 | the time, as I recall it, it was thought to be platform dependent, I guess no
|
|---|
| 26 | one caught that it was a flaw in ropp2bufr_mod.f90. I'm happy that it can be
|
|---|
| 27 | solved.
|
|---|
| 28 | >
|
|---|
| 29 | > Ian's solution sounds good to me. We will do the same in our dmi_trunk.
|
|---|
| 30 | >
|
|---|
| 31 | > -Stig
|
|---|
| 32 | >
|
|---|
| 33 | >> On 2016-06-29 09:14, Culverwell, Ian wrote:
|
|---|
| 34 | >> Hi Chris,
|
|---|
| 35 | >>
|
|---|
| 36 | >> Lucky guess, I suppose! Thanks for checking it out.
|
|---|
| 37 | >>
|
|---|
| 38 | >> I don't know why we need the REAL conversion at all: Values(IE+7) is dp and
|
|---|
| 39 | so is ROdata%Lev1b%Impact_L1(in). Well, actually the latter is wp =>
|
|---|
| 40 | EightByteReal = dp. I suppose someone could be working on a machine/platform
|
|---|
| 41 | in which EightByteReal is, accidentally or deliberately, set to FourByteReal.
|
|---|
| 42 | But in that case the impacts would be useless anyway. Hmm.
|
|---|
| 43 | >>
|
|---|
| 44 | >> I was hoping you weren't going to ask which other variables need this
|
|---|
| 45 | treatment! As you will have seen, all the assignments in ropp2bufr_mod.f90
|
|---|
| 46 | use the Values(i) = REAL(x) formulation. Logically we ought to change them
|
|---|
| 47 | all, for consistency, but then we might change other things in the BUFR files,
|
|---|
| 48 | and then people don't like that, and then ... we have to screw the lid back on
|
|---|
| 49 | the can of worms that we've rashly opened.
|
|---|
| 50 | >>
|
|---|
| 51 | >> May I suggest:
|
|---|
| 52 | >>
|
|---|
| 53 | >> 1) You make this change for all the impact parameters (which is where it's
|
|---|
| 54 | likely to have the biggest, er, impact), and I do likewise for ROPP9.0.
|
|---|
| 55 | >>
|
|---|
| 56 | >> 2) I open a 'longterm' ticket to look at the implications of making
|
|---|
| 57 | >> this change throughout ropp2bufr_mod.f90. (This would include testing
|
|---|
| 58 | >> with the Met Office BUFR lib.)
|
|---|
| 59 | >>
|
|---|
| 60 | >> Sound OK?
|
|---|
| 61 | >>
|
|---|
| 62 | >> Ian.
|
|---|
| 63 | >>
|
|---|
| 64 | >>
|
|---|
| 65 | >>
|
|---|
| 66 | >> -----Original Message-----
|
|---|
| 67 | >> From: Christian Marquardt [mailto:Christian.Marquardt@eumetsat.int]
|
|---|
| 68 | >> Sent: 28 June 2016 16:30
|
|---|
| 69 | >> To: Culverwell, Ian; Axel Von Engeln
|
|---|
| 70 | >> Cc: 'Stig Syndergaard'
|
|---|
| 71 | >> Subject: RE: eum2ropp/bufr odds and ends
|
|---|
| 72 | >>
|
|---|
| 73 | >> Ahh...!
|
|---|
| 74 | >>
|
|---|
| 75 | >> How did you know that?
|
|---|
| 76 | >>
|
|---|
| 77 | >> Awesome! It works well with the ECMWF library; I can't test the MetO one.
|
|---|
| 78 | >>
|
|---|
| 79 | >> Now - should I do that KIND=dp for all impacts? And also the bending
|
|---|
| 80 | angles? Or..?
|
|---|
| 81 | >>
|
|---|
| 82 | >> Thanks,
|
|---|
| 83 | >>
|
|---|
| 84 | >> Chris.
|
|---|
| 85 | >>
|
|---|
| 86 | >>> -----Original Message-----
|
|---|
| 87 | >>> From: Culverwell, Ian [mailto:ian.culverwell@metoffice.gov.uk]
|
|---|
| 88 | >>> Sent: Tuesday, June 28, 2016 4:45 PM
|
|---|
| 89 | >>> To: Christian Marquardt; Axel Von Engeln
|
|---|
| 90 | >>> Cc: 'Stig Syndergaard'; Culverwell, Ian
|
|---|
| 91 | >>> Subject: RE: eum2ropp/bufr odds and ends
|
|---|
| 92 | >>>
|
|---|
| 93 | >>> Hi Chris,
|
|---|
| 94 | >>>
|
|---|
| 95 | >>> Well, assuming they're not rounded to +/- 0.5m in the input file,
|
|---|
| 96 | >>> then I suspect it's the demotion to single precision effected by the
|
|---|
| 97 | >>> use of the intrinsic function REAL without a 'KIND=dp' qualifier in
|
|---|
| 98 | >>> ropp2bufr_mod.f90, eg lines 910ish:
|
|---|
| 99 | >>>
|
|---|
| 100 | >>> Values(IE+7) = REAL(ROdata%Lev1b%Impact_L1(in)) ! [007040]
|
|---|
| 101 | >>> Impact parameter (m)
|
|---|
| 102 | >>> IF ( Values(IE+7) < 6200000.0_dp .OR. &
|
|---|
| 103 | >>> Values(IE+7) > 6600000.0_dp ) &
|
|---|
| 104 | >>> Values(IE+7) = MISSING
|
|---|
| 105 | >>>
|
|---|
| 106 | >>> Replacing this with
|
|---|
| 107 | >>>
|
|---|
| 108 | >>> Values(IE+7) = REAL(ROdata%Lev1b%Impact_L1(in), KIND=dp) !
|
|---|
| 109 | >>> [007040] Impact parameter (m)
|
|---|
| 110 | >>>
|
|---|
| 111 | >>> should generate higher precision Values. But I don't know how this
|
|---|
| 112 | >>> would affect the BUFR output - maybe the resulting Values would be
|
|---|
| 113 | >>> 'too precise', and crash the output?
|
|---|
| 114 | >>>
|
|---|
| 115 | >>> Ian.
|
|---|
| 116 | >>>
|
|---|
| 117 | >>> -----Original Message-----
|
|---|
| 118 | >>> From: Christian Marquardt [mailto:Christian.Marquardt@eumetsat.int]
|
|---|
| 119 | >>> Sent: 28 June 2016 15:18
|
|---|
| 120 | >>> To: Culverwell, Ian; Axel Von Engeln
|
|---|
| 121 | >>> Cc: 'Stig Syndergaard'
|
|---|
| 122 | >>> Subject: RE: eum2ropp/bufr odds and ends
|
|---|
| 123 | >>>
|
|---|
| 124 | >>> Hi Ian,
|
|---|
| 125 | >>>
|
|---|
| 126 | >>> Yes, I'll send the modifications as soon as I can.
|
|---|
| 127 | >>>
|
|---|
| 128 | >>> Before, I have another question...
|
|---|
| 129 | >>>
|
|---|
| 130 | >>> Harald complained that in bufr files generated by eum2bufr, the
|
|---|
| 131 | >>> impact parameters are only precise to 0.5 m (whereas the bufr spec
|
|---|
| 132 | >>> seems to indicate that that it should be given at an accuracy of 0.1
|
|---|
| 133 | >>> m). Having looked at a representative number of bufr products (well
|
|---|
| 134 | >>> - one), it looks like he's right - impact parameters seem to be
|
|---|
| 135 | >>> encoded as either
|
|---|
| 136 | >>> <something>.0 or <something>.5 m.
|
|---|
| 137 | >>>
|
|---|
| 138 | >>> By chance, do you have an idea where that accuracy / rounding takes
|
|---|
| 139 | >>> place? I haven't found anything in either ropp_io_read_ncdf_get.f90
|
|---|
| 140 | >>> (where the data is read from the netcdf files) nor in the
|
|---|
| 141 | >>> ropp2bufr_mod.f90, where the data is packed into a long array before
|
|---|
| 142 | >>> written out as bufr.
|
|---|
| 143 | >>>
|
|---|
| 144 | >>> Thanks,
|
|---|
| 145 | >>>
|
|---|
| 146 | >>> Chris.
|
|---|
| 147 | >>>
|
|---|
