Opened 13 years ago
Closed 13 years ago
#253 closed defect (fixed)
Temporal separation error in 1dvar produced when times are identical
Reported by: | cburrows | Owned by: | cburrows |
---|---|---|---|
Priority: | normal | Milestone: | 6.0 |
Component: | ROPP (all) | Version: | 5.0 |
Keywords: | Cc: | Ian Culverwell |
Description
ropp_1dvar_bangle rejects an observation/background pair if the temporal separation between them is greater than 2 hours. The error message is:
ERROR (from ropp_qc_genqc): Temporal separation between observations and background profile exceeds upper limit
The background time currently used in the comparison is the "VT" time, and for ECMWF backgrounds (from the GARF server), this is always 00Z or 12Z. Hence, all occultations occurring between 02Z and 10Z, and between 14Z and 22Z are currently being rejected by ROPP.
The order of key operations is here:
- ropp_1dvar_bangle calls ropp_io_read for both the observation and background file
- For the observation file, the date/time is read into obs_data%DTocc%Hour (and Day, Min etc). For the background file, the "VT" time is read into bg_data%BG%Hour etc.
- For the observation, ropp_fm_roprof2obs is called and obs%time is calculated based on obs_data%DTocc%Hour etc.
- For the background, ropp_fm_roprof2state is called and bg%time is calculated based on bg_data%BG%Hour etc.
- Back at the ropp_1dvar_bangle level, ropp_qc_genqc is called for QC. At line 180 and onwards (rev2511), the temporal separation is calculated as follows: dtime = ABS(bg%time - obs%time), i.e. the occultation time is being compared to the time of the background cycle and hence is often failing.
The fix would be to replace bg%time with the variable describing the time the background is calculated for.
Note that this problem applies to refractivity calculations also
Change history (2)
comment:1 by , 13 years ago
comment:2 by , 13 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
These changes have been implemented in the prototype branch. Ticket is being closed. This will, need to be monitored in case the definitions used at DMI change.
From speaking to Joe Nielsen, it appears that the "VT" time provided in the BGR files is the time the ECMWF analysis is valid for. For each analysis, 6, 12 and 18 hour forecasts are provided and no temporal interpolation is carried out, so the nearest of the forecasts is used (the corresponding fcperiod is 6, 12 or 18).
Two fixes are required in ROPP. The first is that in the case that an ECMWF profile is provided by DMI, the State1dFM structure should have it's 'time' variable modified to be VT_time+fcperiod. This is done in ropp_fm_roprof2state. The other fix is to change the maximum temporal separation to 10800s in ropp_1dvar/config/default_1dvar.cf and ropp_1dvar/common/ropp_1dvar_types.f90
Joe has said that the definitions in the data files may change in the future, so this needs to be monitored.