Editing RT QC flag in delayed mode ?

Editing RT QC flag in delayed Editing RT QC flag in delayed mode ?mode ?

Virginie Thierry

DMQC 4

Toulouse, 28 septembre 2009

28 Septembre 2009 DMQC4 - Toulouse

Description of the problem

• RT QC flag attributed by automatic procedures and in some cases by an operator after visual inspection

• In “D” mode, DM operator control those flags and change them before correcting data for sensors drift or inertial thermal mass.

• When QC flags are re-examined and edited in DMQC, should these long and fastidious edits be made to the RAW QC fields or to the ADJUSTED QC fields ?

• Only data with a QC flag of 1, 2, 3 are used by the OW method (to detects of a conductivity sensor drift).


Example : 1900078 – cycle 44

• Near surface salinity data bad: should be flagged to 4

• Generic problem for the CTS3 PROVOR float: the last conductivity measurement between 0 and 5db is not good.Green = flag 1

TEMP SIGMA0PSAL


Example : 6900242 – Cycle 7

• Salinity offset for part of the profile. The data are not correctable : data should be flagged to 4 to not being considered by the OW method.

Green = flag 1 Orange = flag 3

TEMP PSAL SIGMA0


Example : 6900272 – Cycle 113

• Few bad salinity measurements with a RT QC flag set to 1, 3 or 4 : they all should be flagged to 4

Red = flag 4Orange = flag 3

TEMP PSAL SIGMA0

Green = flag 1


Other examples

• Density inversion incorrectly flagged

• The position QC are sometimes erroneously set to 4

• Hook at the base of the profiles

• Flag 4 assigned to good data

• Flag 3 assigned to suspicious data by an operator. After verification those data are good.

• Etc….


AST8 – March 2007

Most DACs followed Argo data policy of preserving the R/T QC flags on the raw fields and editing the QC flags in the adjusted fields. This practice may be inadequate in the long-term, as future efforts (say by an ARC or scientist) to revisit the drift adjustments will have to disentangle QC changes associated with poor R/T QC screening and QC flags associated with the quality of drift adjustments/thermal lag adjustments. We should consider changing the raw QC flags in DMQC so that this man-power intensive component (despiking, flagging deep hooks, correcting R/T QC errors) is made distinct from the other DMQC adjustments - thermal-lag and drift assessment. This practice could be implemented immediately.


Brian and Susan’ recommendation

When QC flags are re-examined and edited in DMQC, these edits should be made to the RAW QC fields and not the ADJUSTED QC fields.

RAW QC flags 1 & 2 should then be propagated to ADJUSTED, 3 and 4 should be set to 4 in ADJUSTED and filled with missing values as per the DMQC manual.


DMQC3 – September 2008

• A discussion was carried out on whether delayed-mode operators should adjust real-time qc flags. […] Opinion from workshop participants on this AST action item was mixed, with several operators supportive of this resolution, several operators strongly against it, and the majority of the operators feeling neutral or uncertain.

• The reasons that some operators are against this resolution include the fact that editing real-time qc flags by subjective judgement can lead to inconsistency and can potentially make the real-time qc flags worse. Also results from the real-time qc tests will be lost.

• Overall the workshop participants felt that more open discussions on the ramification of this action item were needed between the AST, the real-time DACs, and the delayed-mode operators. Annie Wong will compose a letter to the AST summarising the concerns of delayed-mode operators on editing real-time qc flags, so that this topic can be discussed further at the next AST meeting.

• Action 9.2.6: Annie Wong to compose a letter to the AST summarising the concerns of delayed-mode operators on editing real-time qc flags, so that this topic can be discussed further at the next AST meeting.


ADMT9 – November 2008

• Before starting DMQC, DM operators look at the real time flags and correct them when necessary before running the OW method. There is discussion within DM-operator whether or not these RT flags should be provided back to DACs and overwrite the automatic flags assigned in RT. This will be discussed on argo-dm-dm mailing list. The RT Dac operators recommend to transfer these corrected RT flags from DM operators to them to clean up this RT datasets.


AST10 – March 2009

Per the DMQC-3 workshop’s request, the AST provided guidance on the changing of real time flags when delayed mode correction is done.

Action item 11: AST recommends changing of RT flags with DM correction


Editing or not editing RT flag ? That is the question

• It’s time to take a decision !• Need an agreement on what to do and clear rules to ensure

consistency among DM operators• Adding new parameters is not the solution• Although some voices are against editing RT flags (e.g.

Greg Johnson), discussions on argo-dm-dm and past recommendations suggest that most of the people agree with the necessity of editing RT QC flags.


New definition of PARAM and PARAM_QC ?

• Definition of PARAM (=RT data) and PARAM_QC (= RT QC flag) are misleading

• New definition:

– PARAM contains the raw values transmitted from the floats or data converted from the raw transmitted values (DOXY for instance)

– PARAM_QC contains qc flags that pertain to the values in PARAM

• Values in PARAM_QC are set initially in 'R' and 'A' modes by the automatic real-time tests. They are later modified in 'D' mode at levels where the qc flags are set incorrectly by the real-time procedures, and where erroneous data are not detected by the real-time procedures.

• PARAM_QC should reflect the best knowledge we have at a given time on the quality of PARAM


Rules for bad/uncorrectable data and QC flag of 4

• Edits of the PARAM_QC flags should be made to affect a QC flag of 4 to bad and non correctable data that were not detected by the real time tests

• Edits of the PARAM_QC flags should be made to affect a QC flag of 1 or 2 to good data that were identified as bad or probably bad data by the real time tests


Case of the bad but correctable data• And when a drift is detected and corrected in the adjusted fields ?

What shall we do for the raw data and the associated QC ?

• Definition of flag 3 in R mode according to the User’s manual

– Meaning: Bad data that are potentially correctable

– RT comments: Test 15 (greylist) or Test 16 (gross sensor drift) or Test 17 (visual inspection) failed and all other real-time QC tests passed. These data are not to be used without scientific correction. A flag ‘3’ may be assigned by an operator during additional visual QC for bad data that may be corrected in delayed mode.


Rules for setting PARAM_QC TO 3

• My suggestion: Set PARAM_QC to 3 when the data are corrected in delayed mode

– Drift or offset: the entire profile is flagged to 3; flags greater than 3 are left unchanged spikes, hooks, density inversion identified during the first step are still flagged with a QC = 4

– Thermal mass: only the corrected level are concerned ?

• Ensure consistency with other procedures (grey list, gross drift test, visual inspection by RT operator) and QC definition

• Inform users that the raw data are bad but correctable and corrected if the data are in “D” mode.


Need to review Brian and Susan’ recommendations

• When QC flags are re-examined and edited in DMQC, these edits should be made to the RAW QC fields and not the ADJUSTED QC fields.

• RAW QC flags 1 & 2 should then be propagated to ADJUSTED

• New: RAW QC flags 3 should be set to 1 or 2 in ADJUSTED and associated ADJUSTED fields should be corrected for sensor drift or thermal mass.

• RAW QC flags 4 should be set to 4 in ADJUSTED and filled with missing values as per the DMQC manual.

Date post:	06-Jan-2016
Category:	Documents
Upload:	jovan
View:	31 times
Download:	0 times

Editing RT QC flag in delayed mode ?

Documents