Forecast time and forecast length in bgr files

[Stig Syndergaard]

At DMI we have changed the NetCDF global attribute called processing_centre from 'DMI Copenhagen' to 'DMI (ROM SAF)'. This may have implications for what happens in ropp_fm_roprof2state.f90 where the forecast lenght is added to the forecast time if the processing_center is 'DMI Copenhagen'. This won't be done when processing_center is 'DMI (ROM SAF)'. Should the code be changed? Is the forecast time correct in our NetCDF files? Or should we add bg_fcperiod? This would have to be done in gras_retrieve (possibly using ropp_utils).

Related to this I noticed that using the ropp_fm_bg2ro_1d.f90 tool on files with 'DMI (ROM SAF)', the processing_center in the output file is changed back to 'DMI Copenhagen', so there is somewhere in ROPP that 'DMI (ROM SAF)' is not recognized and replaced with 'DMI Copenhagen'.

See also #253

[Johannes K. Nielsen]

There is an error in grib2bgrass.f90. Here is the wrong code: in SUBROUTINE extract_prof_from_GRIB the time section reads:

! 1.2 Read date/time info from GRIB file.

CALL grib_get(imess, 'dataDate', date) CALL grib_get(imess, 'dataTime', time) CALL grib_get(imess, 'stepRange', tlead_prf)

year_prf = date / 10000 mon_prf = (date - year_prf*10000) / 100 day_prf = date - year_prf*10000 - mon_prf*100 hour_prf = time / 100 min_prf = time - hour_prf*100 sec_prf = 0

The dataTime (format e.g. 1200 for 12:00) variable holds the analysis time and stepRange holds (validation time - analysis time). This happens to be the same number as "forecastTime", which maybe sounds more like the right number to use. As it is now virtually bg%hour = dataTime/100, which is interpreted as Verification time in ropp_fm_roprof2state.f90. bg%hour = dataTime/100+forecastTime would be my suggestion. I can insert it but I think maybe it should be up to Ian to decide where to put it in. Certainly, the way it is now gives wrong bg%hour value in bgr files. The fix should also include removal of the outdated hack in ropp_fm_roprof2state1d.f90: ! 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.

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

ELSE

CALL message(msg_warn, &

"Time data for background is out of range or missing.")

CALL message(msg_info, "Check input data and valid_range attributes") CALL message(msg_info, "Set status flag state%ok to FALSE") CALL message(msg_noin, ) x%state_ok = .FALSE.

ENDIF

this should be removed

[Johannes K. Nielsen]

List of instances where %time is used: ropp_fm_free.f90: var%time = ropp_MDFV ropp_fm_roprof2obs.f90: CALL TimeSince ( DT8, y%time, 1, Base="JS2000" ) ropp_fm_roprof2state.f90: CALL TimeSince ( DT8, x%time, 1, Base="JS2000" ) ropp_qc_genqc.f90: dtime = ABS(bg%time - obs%time) ! s ropp_fm_roprof2state.f90: x%time = x%time + 3600.0 * ro_data%bg%fcperiod ropp_fm_state2state.f90: to_state % time = from_state % time ropp_fm_obs2obs.f90: to_obs % time = from_obs % time In our current 1D-Var configurations we do not apply the colocation check: genqc_colocation_apply = .false. Thus this

IF(dtime > config%genqc_max_time_sep)THEN

is never checked and therefore our 1D-Var is not corrupted by the wrong bgr-time

[Johannes K. Nielsen]

The bug has been fixed in dmi_trunk version 6.1; bg_hour=verification time. It was decided on a GG telecon on April 1 2014 to stick to this convention. Task handed over to Met Office. jkn