id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
522	Account for analysis/validity time issue in ROM SAF bgr files	Ian Culverwell	Ian Culverwell	"As discovered by Zhu / Julie Yang in Helpdesk enquiry 363 (http://www.romsaf.org/view_admin_enquiry.php?id=363), corresponding atm and bgr files from the ROM SAF archive (e.g. '''atm20170415_034828_M02_1200631416_N0023_XXXX.nc''' and '''bgr20170415_034828_M02_1200631416_N0023_XXXX.nc''') cannot be run through the ROPP 1DVAR code, because the forecast range has not been accounted for in the calculation of the validity time of the background field.  The quality control routines throw out the profile because
{{{
""ERROR (from ropp_qc_genqc): Temporal separation between 
observations and background profile exceeds upper limit: 1.08000E+04 s.""
}}}

The observation time is 03:48 on 15/04/2017:
{{{
ncks -H -Q -vday,hour,minute,msec atm20170415_034828_M02_1200631416_N0023_XXXX.nc

day[0]=15 
hour[0]=3 
minute[0]=48 
msec[0]=217 
}}}

The background comes from a T+18 forecast from an analysis time of 12Z 14/04/2017:
{{{
ncks -H -Q -vbg_day,bg_hour,bg_minute,bg_fcperiod bgr20170415_034828_M02_1200631416_N0023_XXXX.nc

bg_day[0]=14 
bg_fcperiod[0]=18 
bg_hour[0]=12 
bg_minute[0]=0 
}}}

So the background field is valid at 06Z 15/04/2017, which is within the usual 3 hours of the observation time. But {{{bg_fcperiod}}} has not been accounted for, which is why the code thinks the background fields are not recent enough to be used.

There is a note about this in '''ropp_fm/common/ropp_fm_roprof2state.f90''', the code that converts ROprof data into state vectors:
{{{
! Fix to sort out DMI variable labelling issue - VT time vs analysis time (cf.
! ROPP ticket #253). Also increased max. temporal separation to 3 hours.
! This should no longer (ROPP8.0, 2014) be needed, as DMI now set bg%hour etc to the validity time.
! IF ( isinrange(ro_data%bg%fcperiod, ro_data%bg%range%fcperiod) .AND. &
!   ro_data%processing_centre == 'DMI Copenhagen' .AND. &
!   ro_data%bg%source == 'ECMWF' ) THEN
!     x%time = x%time + 3600.0 * ro_data%bg%fcperiod
! ENDIF
}}}

DMI have confirmed that this change hasn't in fact been made to the bgr files yet, so we should temporarily reinstate it.  We will also need to change
{{{
ro_data%processing_centre == 'DMI Copenhagen'
}}}
to
{{{
(ro_data%processing_centre == 'DMI Copenhagen') .OR. (ro_data%processing_centre == 'DMI (ROM SAF)')
}}}
as apparently the latter change has been made (see #346).

When the bgr time has been changed in the files, we will need to revisit the problem to make sure that the code can cope with both bgr time conventions.  We might, for instance, use the {{{day}}},{{{hour}}} etc parameters in the background file, rather than the {{{bg_day}}}, {{{bg_hour}}} etc, because the former seem to match those in the atm file:
{{{
ncks -H -Q -vday,hour,minute,msec bgr20170415_034828_M02_1200631416_N0023_XXXX.nc

day[0]=15
hour[0]=3 
minute[0]=48 
msec[0]=217 
}}}

Why has this not been considered before?  (Perhaps the bgr times were only matched to the atm times recently?)

Ticket #253 also refers to this problem."	defect	closed	normal	10.0	ropp_1dvar	9.0	fixed