Issue with time_offset > 240s

[Stig Syndergaard]

For some occultations, e.g., with ionospheric tracking (so far only uploaded to Metop-A, but to come also for Metop-B and C), it can happen that dtime > 240s, which is the default limit in ROPP. If rangecheck is .TRUE. when running ropp_pp_occ_tool, it becomes a missing value with the result that the lowest part of occultations are cut off (it is mostly a problem for setting occultations). This problem has been solved in #696. However, also the variable called time_offset may occasionally become larger than 240s. The problem here is that time_offset is written to BUFR (there called 'time increment', descriptor 0 04 016), and the BUFR template does not allow a larger time_offset (time increment becomes a missing value and there is seemingly no way to avoid that, not even by increasing the allowed limit in ROPP). How can we solve that?

One solution would be to follow the IROWG BUFR discussions recommendations (Recommendation 2) in the document on proposed changes to the BUFR that can be found here: ​https://irowg.org/workshops/irowg-4/bufr-discussions-at-and-following-irowg-4/. There the following is recommended:

• It is recommended to set the data field “time increment” to zero.

• The occultation reference time shall become a “nominal reporting time”. In turn, the data field “time significance” (descriptor 0 08 021) shall be changed from currently 17 (=”time of occultation start”) to 25 (="nominal reporting time").

This would solve the problem. However, we are not allowed to change descriptor 0 08 021 to say 25 instead of 17 before a change to the BUFR template is formally adopted. This became clear from email correspondence on 11/27/2018 with Harald Anlauf (DWD) and others. EUMETSAT has set 'time increment' to zero in their BUFR without changing the value for 'time significance'. Doing that with ropp2bufr would require some code changes to get the correct date and time for the 'start of occultation' into the BUFR. There is a drawback in that information about the true start time would be thrown away, an issue that both Ian and I were not entirely happy about (back in 2018). Another drawback is that the time in the BUFR filenames would become different than the time in the netCDF filenames. This is how it currently is with EUMETSAT BUFR vs L1B files. This could (as the easiest solution) be done differently in ROM SAF processing such that the start time in the filename is preserved, although the 'start time' in the BUFR field would be different. That doesn't solve the general problem for general ROPP users though, and perhaps it is not a good idea.

Another possible solution would be to shift all times upon reading in files with eum2ropp, such that the dtime at some altitude (e.g., 100 km for setting occs) is always zero. This would require changes to eum2ropp subroutines, and would require more thought about whether that is a good idea.

The practical problem is rather small. In ROM SAF Offline processing, for the whole month of August (~10000 setting occs for Metop-A), time_offset was larger than 240s only in 20 cases (if dtime had allowed values larger then 240s), and none for Metop-B or C (as expected). Thus, with ionospheric tracking on Metop, 'time increment' in BUFR in ROM SAF Offline and ICDR processing is a missing value in about 0.2% of the cases. On the other hand, during the ionospheric tracking tests on Metop-A in June-September 2020, there were periods where it was much more often. As these data will undergo reprocessing at the ROM SAF at some point, the problem (if left unresolved) will be larger in those periods.

[Stig Syndergaard]

Three email threads from November 2018 discussed the 'time significance' issue (among other issues). The date and subject of the last emails in these threads are:

11/22/2018 - Re: Question about differences in bending angle data

11/23/2018 - RE: Time significance and time increment octets in EUMETSAT RO BUFR files

11/29/2018 - Re: Status of IROWG-4 BUFR recommendations

Given the discussions there, perhaps the 'Another possible solution...' above would be the one to pursue in order to solve the problem at hand, thus still allowing a non-zero time_offset but ensuring that it is less than 240s.