Qc2 Flag Analysis and Discussion

This is an old revision of the document!

Note: a number of Qc2 useinfo changes are coded in lib/kvalobs/kvDataFlag.cc but are all commented out and inactive. For development and reflectedin the examples provided below, the Qc2 items are all turned on. Please see below for details.

A general guide to setting values in Qc2 Control Flags is described in the following set of slides from Lars. The current algorithms and proposals for new algorithms are based on this:

Flags in Qc2

Controlflag Setting:	fd=7
Condition:	The algorithm is considered successful
Cfailed:	Updated to include algorithm name and type of interpolation used to generate the correction

Examples

An example of the redistribution of accumulated precipitation. Where successful estimation of corrected values occurs, the controlinfo(12), fd is set to 7. The useinfo is then updated in accordance with the updated routine above.

BEFORE Qc2

 stationid |       obstime       | original | paramid |       tbtime        | typeid | sensor | level | corrected |   controlinfo    |     useinfo      |                  cfailed                  
-----------+---------------------+----------+---------+---------------------+--------+--------+-------+-----------+------------------+------------------+-------------------------------------------
     53950 | 2007-12-07 06:00:00 |        9 |     110 | 2007-12-07 12:10:30 |    302 | 0      |     0 |         9 | 1140000000001000 | 7020400000000001 | QC1-2-72.b12:1,QC1-2-72.c12:1
     53950 | 2007-12-08 06:00:00 |   -32767 |     110 | 2007-12-09 00:36:39 |    302 | 0      |     0 |    -32767 | 1000003000002000 | 7899900000000000 | QC1-7-110:1
     53950 | 2007-12-09 06:00:00 |   -32767 |     110 | 2007-12-10 00:40:02 |    302 | 0      |     0 |    -32767 | 1000003000002000 | 7899900000000000 | QC1-7-110:1
     53950 | 2007-12-10 06:00:00 |      1.5 |     110 | 2007-12-10 11:25:20 |    302 | 0      |     0 |       1.5 | 1140000000002000 | 7330900000000001 | QC1-2-72.b12:1,QC1-2-72.c12:1,QC1-7-110:1
(4 rows)

AFTER Qc2

kvalobs=# select * from data where stationid=53950 and obstime>'2007-12-07' and obstime<'2007-12-11' and paramid=110;
 stationid |       obstime       | original | paramid |       tbtime        | typeid | sensor | level | corrected |   controlinfo    |     useinfo      |                                cfailed                                
-----------+---------------------+----------+---------+---------------------+--------+--------+-------+-----------+------------------+------------------+-----------------------------------------------------------------------
     53950 | 2007-12-07 06:00:00 |        9 |     110 | 2007-12-07 12:10:30 |    302 | 0      |     0 |         9 | 1140000000001000 | 7020400000000001 | QC1-2-72.b12:1,QC1-2-72.c12:1
     53950 | 2007-12-08 06:00:00 |   -32767 |     110 | 2007-12-09 00:36:39 |    302 | 0      |     0 |       0.1 | 1000003000007000 | 5899900000000000 | QC1-7-110:1 Qc2 Redis corrected was:-32767
     53950 | 2007-12-09 06:00:00 |   -32767 |     110 | 2007-12-10 00:40:02 |    302 | 0      |     0 |         0 | 1000003000007000 | 5899900000000000 | QC1-7-110:1 Qc2 Redis corrected was:-32767
     53950 | 2007-12-10 06:00:00 |      1.5 |     110 | 2007-12-10 11:25:20 |    302 | 0      |     0 |       1.4 | 1140000000007000 | 5336900000000001 | QC1-2-72.b12:1,QC1-2-72.c12:1,QC1-7-110:1 Qc2 Redis corrected was:1.5
(4 rows)

NOTES:

The operational deployed version of Qc2 will not state “Redis corrected was XX” in cfailed. This is just a convenience for ongoing testing.
More examples of the control- and useinfo- behaviour are available in the Prototype Report. The only difference is that at the time of the protoype report fd=8 was used as the controlinfo flag value.

Controlflag Setting:	ftime=1
Condition:	The algorithm is considered successful
Cfailed:	Algorithm method recorded.

Examples

Sample data before Qc2

59680|2008-03-19 05:00:00|-1.7  |211|2008-03-19 04:54:05|311|0|0|-1.7|1111100000000010|7000000000000000| 
59680|2008-03-19 06:00:00|-32767|211|2008-03-19 06:32:48|311|0|0|-1.7|1000601000000007|3891900000000021|QC1-4-211:1,hqc
59680|2008-03-19 07:00:00|-0.6  |211|2008-03-19 06:54:00|311|0|0|-0.6|1110100000000010|7000000000000000|

After the Qc2 algorithm the row with the missing line is updated as follows:

59680|2020-03-19 06:00:00|-32767|211|2020-03-19 06:32:48|311|0|0|-0.7|1000601100000007|1891900000000021|QC1-4-211:1,hqc Qc2 UnitT corrected was:-1.7

Discussion (a summary of inputs from many different people, identities removed since this is the public wiki)

ftime should influence useinfo(3) and useinfo(4), propose the useinfo algorithms need a complete redraft once we have an overview of the QC2 features.

ftime is part of the useinfo(4) requirements but needs to be checked/tested

ftime is not yet included in the requirements for useinfo(3). This needs to be done

In this particular example fhqc=7 “Korrigert manuelt” which must is a bug, since original value is missing (fhqc=5: “Interpolert manuelt” might have been an appropriate setting). So the misleading value useinfo(3)=1: “Original verdi er manuelt korrigert” is because of this mistake in fhqc.

Currently for the operational configuration the condition set is “DO NOT OVERWRITE A VALUE ALREADY CORRECTED BY HQC”. For development/testing this condition is sometimes relaxed.

since HQC has put in a value in the corrected field (or possibly confirmed the value already inserted there by QC1-4): should it really be possible for QC2 to change that later?

Reasons for “no” include: that elsewhere setting up the criteria for useinfo(3) will be that much harder - it is no longer enough to check controlinfo, we also need to know which control was performed last (we would have useino(3) = 4 or 2 depending on HQC was performed before or after QC2).

Scheduling

Whereas the default operation is that Qc2 shall not overwrite HQC results the need that this is ever considered shall be minimised by always having Qc2 before HQC. Even so there may be situations that new data is available and Qc2 is being rerun that Qc2 may overwrite HQC. When this case arises the rules to be followed have to specified.

Also in the case when Qc2 is delayed this may happen:

06 observation is missing. fmis=3 changes to fmis=1 when QC1 puts in model value, Tmod, and we get fnum=6 and fhqc=0. ftime=0 and useinfo=78947.
HQC changes model value from Tmod to -1.7. fmis=1, fnum=6 (unchanged), fhqc=5 (manual interpolation). ftime=0 and useinfo=38929.
QC2 changes “HQC-value” to -0.8 (or -0.75?). We must discuss if we will allow this. But if we do, fmis and fnum are unchanged. fhqc is disregarded. Then fhqc=0. But fhqc should always be the last control. In this case it will stay as 0 (if no HQC) or be changed to 1 (probably, but 5 is also possible, if HQC). At this stage ftime=1 and useinfo=58946.

Controlflag Setting:	fnum=0-6	fnum=7-A
Condition:	As already defined for numerical model runs.	Qc2 Values For Space Check
Cfailed:	Specific details of the SpaceCheck performed, e.g. type of check and interpolation method etc.
–oo0oo–
fnum=7	Controlled. Deviation between observed value and SpaceCheck estimate higher than high test value
fnum=8	Controlled. Deviation between observed value and SpaceCheck estimate lower than low test value
fnum=9	Controlled. Deviation between observed value and SpaceCheck estimate higher than highest test value
fnum=A	Controlled. Deviation between observed value and SpaceCheck estimate lower than lowest test value

Algorithm or Control	Expected Control flags to change	Condition	Cfailed Change
Other time interpolations	ftime=1	NB only corrected updated if algorithm considered successful	Algorithm method recorded.

The kvalobs library has a built in function which sets useinfo based on controlinfo settings.

 <key> bool setUseFlags(const kvControlInfo& cinfo); </key>

that is located in … src/lib/kvalobs/kvDataFlag.cc

The setUseFlags already anticipates the setting of user flags in response to QC2 controls. However, most of the logic is commented out in the operational code, as indicated below:

bool kvControlInfo::qc2dDone() const
{
  return false;//flag( f_fs ) or flag( f_ftime ) or flag( f_fw ) or flag( f_fstat );
}

...

bool kvControlInfo::qc2mDone() const
{
  return false;//flag( f_fclim ) or flag( f_fd );
}

...

  ui[2]= 9;
  //if ( cinfo.qc1Done() or cinfo.qc2Done() or cinfo.hqcDone() )

...

ui[ 3 ] = 9;
  //if ( cinfo.qc1Done() or cinfo.qc2Done() or cinfo.hqcDone() )

...

ui[ 4 ] = 9;
  // NB: After useinfo[2]
  //if ( cinfo.qc1Done() or cinfo.qc2Done() or cinfo.hqcDone() )

Implications:

Need for regression testing when change in kvalobs base libraries is propagated to QC1
Further need to investigate/test effect on reduced set of use info flags in the downstream data warehouses.

In the ProcessUnitT example below the effect of turning on the Qc2 useinfo is visible; i.e.

bool kvControlInfo::qc2dDone() const
{
  return flag( f_fs ) or flag( f_ftime ) or flag( f_fw ) or flag( f_fstat );
}

...

bool kvControlInfo::qc2mDone() const
{
  return flag( f_fclim ) or flag( f_fd );
}

...

  ui[2]= 9;
  if ( cinfo.qc1Done() or cinfo.qc2Done() or cinfo.hqcDone() )

...

ui[ 3 ] = 9;
  if ( cinfo.qc1Done() or cinfo.qc2Done() or cinfo.hqcDone() )

...

ui[ 4 ] = 9;
  // NB: After useinfo[2]
  if ( cinfo.qc1Done() or cinfo.qc2Done() or cinfo.hqcDone() )

OPEN-ISSUEShall src/lib/kvalobs/Qc2_kvDataFlag.cc be updated to include the Qc2 elements. This is part of the standard Qc1 software and this change would therefore require regression testing. Who is reposnsible for this decision and to carry out the Qc1 regression testing?

TODO

N.B. controlflags