Ticket #283: RE_ROPP_Start_Time_Accuracy.mail

File RE_ROPP_Start_Time_Accuracy.mail, 5.5 KB (added by Ian Culverwell, 11 years ago)
Line 
1From: Culverwell, Ian
2Sent: 01 February 2012 08:07
3To: 'Axel Von Engeln'
4Cc: Culverwell, Ian
5Subject: RE: ROPP Start Time Accuracy
6
7Hi Axel,
8
9You're welcome.
10
11Yes, inconsistency is always a risk when the same info appears in two different ways, and ROPP should probably check they agree.
12
13I've opened ROPP ticket https://trac.grassaf.org/ropp/ticket/283 on it.
14
15Regards,
16Ian.
17
18
19
20--------------------------------------------------------------------------------
21
22From: Axel Von Engeln [mailto:Axel.VonEngeln@eumetsat.int]
23Sent: 31 January 2012 16:58
24To: Culverwell, Ian
25Subject: RE: ROPP Start Time Accuracy
26
27
28 Hi Ian,
29
30
31
32 That actually explains it, I am accidently setting the milliseconds to zero in my conversion, but do keep the full accuracy in the start_time entry. So I need to update my script there. But it is a bit inconsistent, I agree. We in our format have actually moved away from having 2 entries essentially saying the same, thus we avoid these inconsistencies.
33
34
35
36 To avoid these kind of issues in ROPP it might be best to check that start_time and the individual entries are consistent, and not use another command line switch.
37
38
39
40 Thanks for finding this so quickly!
41
42
43
44 Axel
45
46
47
48 ---
49
50 Axel von Engeln, Radio Occultation Mission Scientist
51
52 EUMETSAT, Am Kavalleriesand 31, D-64295 Darmstadt, Germany
53
54 Tel: +49-6151-8076130, Fax: +49-6151-8078380
55
56 Email: Axel.vonEngeln@eumetsat.int, Web: http://www.eumetsat.int
57
58
59
60
61
62
63
64 From: Culverwell, Ian [mailto:ian.culverwell@metoffice.gov.uk]
65 Sent: Tuesday, January 31, 2012 5:49 PM
66 To: Axel Von Engeln
67 Cc: Culverwell, Ian
68 Subject: RE: ROPP Start Time Accuracy
69
70
71
72 Hi Axel,
73
74
75
76 No need to open a ticket on your brain: I confirm that with my ROPP6.0 I find:
77
78
79
80 idculv@eld037:> ncks -H -vstart_time yaros2ropp.nc
81 dim_unlim[0] start_time[0]=381283627.06
82
83 and after ropp2bufr and bufr2ropp:
84
85
86
87 idculv@eld037:> ncks -H -vstart_time yaros2ropp_2.nc
88 dim_unlim[0] start_time[0]=381283627
89
90
91
92 I think this is because ropp2bufr uses the hour,month,day etc variables, not the start_time, and these aren't quite consistent for this file:
93
94
95
96 idculv@eld037:> ncks -H -vstart_time,year,month,day,hour,minute,second,msec yaros2ropp.nc
97 dim_unlim[0] day[0]=31
98
99
100
101 dim_unlim[0] hour[0]=0
102
103
104
105 dim_unlim[0] minute[0]=7
106
107
108
109 dim_unlim[0] month[0]=1
110
111
112
113 dim_unlim[0] msec[0]=0
114
115
116
117 dim_unlim[0] second[0]=7
118
119
120
121 dim_unlim[0] start_time[0]=381283627.06
122
123
124
125 dim_unlim[0] year[0]=2012
126
127
128
129 NB: msec is 0, not 60, as it would need to be to match start_time.
130
131
132
133 ropp2bufr evidently uses the year,month,..,..,msec values, because the resulting BUFR file says:
134
135
136
137 YEAR YEAR 2012
138 MONTH MONTH 1
139 DAY DAY 31
140 HOUR HOUR 0
141 MINUTE MINUTE 7
142 SECOND SECOND 7.000
143
144 which obviously feeds back to the ropp nc file.
145
146
147
148 I've tried it with msec=60 in the original file (ncap2 -s"msec=msec+60" yaros2ropp.nc yaros2ropp1.nc), and it all works OK: start_date is preserved.
149
150
151
152 Is this a problem with the data or ROPP? Ideally, I suppose there should be a switch in ROPP to "use start_date" or "use year,month,day,..." What do you think?
153
154
155
156 Regards,
157
158 Ian.
159
160
161
162 PS: I think "mantissa" may be the word you want:
163
164 http://mathworld.wolfram.com/Mantissa.html
165
166
167
168 However, this seems a bit ambiguous (eg also used for the .*** part of the _log_ of the number). Maybe "fractional part" would do.
169
170
171----------------------------------------------------------------------------
172
173 From: Axel Von Engeln [mailto:Axel.VonEngeln@eumetsat.int]
174 Sent: 31 January 2012 16:06
175 To: Culverwell, Ian
176 Subject: ROPP Start Time Accuracy
177
178 Hi Ian,
179
180
181
182 I was just running some tests with my eum2bufr converter, comparing it to the ropp behaviour. There I noticed some differences in the start_time entry. When running a ropp2bufr on a ROPP netCDF3 file, and then converting it back to netCDF3 with bufr2ropp, the numbers behind the . are missing (there is probably a proper English term for this, which just escapes me). I noticed this since I also ran a eum2buf on the netCDF4 file, and then a bufr2ropp, where I seem to be able to keep the full accuracy. So it cannot be the bufr resolution.
183
184
185
186 Any ideas? File is attached, run this through ropp2bufr, and then through bufr2ropp. Or did I screw up something in my version? I currently don’t have a running original 5.1 or 6 version.
187
188
189
190 If this is confirmed, then you might want to open a ticket. If it is not, then open a ticket on fixing Axels’ brain.
191
192
193
194 Cheers,
195
196
197
198 Axel
199
200
201
202 ---
203
204 Axel von Engeln, Radio Occultation Mission Scientist
205
206 EUMETSAT, Am Kavalleriesand 31, D-64295 Darmstadt, Germany
207
208 Tel: +49-6151-8076130, Fax: +49-6151-8078380
209
210 Email: Axel.vonEngeln@eumetsat.int, Web: http://www.eumetsat.int
211
212
213
214
215
216