Information is now being written to another page.

Contents

• Useful links
• Terminology
• Strategy for creating a combined file with all the data
• QC hierarchy
• What I'd like to know
• Julian days
• Matching Jim's flags with the DACs
• Notes
• Using all the data
• Using only the data when BMRC, Coriolis, FNMOC and MEDS are defined
• Ranking the QC flags

Useful links

• Robin's wiki
• Jim Cumming's readme
• Jim Cumming's data
• Indication of QC tests
• QC test for MEDS
• QC codes for MEDs
• Argo data management
• Rules for the WMO numbers
• CSIRO Quality Control Cookbook for XBT Data

Terminolgy

Let say:

• good data is what is deemed by the delayed mode to be good (because this is best indicated we have of the data being good).
• bad data is what is deemed by the delayed mode to be bad
• accepted data is the data accepted by observation centre
• rejected data is the data rejected by observation centre

For each field we want to know

	FIELD_QC
	Not done	Bad	Good
|FIELD_DIFF|>tolerance	DN (different-not done)	DB (different-bad)	DG (different-good)
|FIELD_DIFF|≤tolerance	SN (same-not done)	SB (same-bad)	SG (same-good)

where

• DN and SN are fine
• DB and SG suggest agreement between FIELD_QC and FIELD_DIFF
• DG and SB are worrying

Strategy for creating a combined file with all the data

• The delayed mode data (I've relaxed this to be data in the argo file) is seen as the truth
• Loop through the DACs
  1. Match the platform IDs
  2. Try to match each of the times
     • anything within a day is considered a match, store JULD_DIFF (=DAC JULD - ARGO JULD).
     • JULD and JULD_QC is undefined if there is no match, along with subseqent variables
  3. Try to match the latitude-longitude, store LAT_DIFF and LON_DIFF
  4. Try to match the levels. If DAC depth is in metres, need to convert the pressure into metres. Let D_k be the pressure levels in the argo files and D'_k the pressure levels for DAC.
     • For each D_l find the nearest D'_k, which we'll refer to as D'_m.
     • If the nearest D_k to D'_m is D_l, match D_l to D'_m. Otherwise no match has been found for D_l.

QC hierachy

The QC hierachy is

1. Time
2. Lat-lon. If we get this far, we can test
   1. PRESS_QC_PRF
   2. TMP_QC_PRF
   3. SAL_QC_PRF
3. Depth. If we get this far, we can test
   1. TMP_QC_LVL
   2. SAL_QC_LVL

Matching Jim's flags with the DACs

BMRC

The profile data (looking at a file, 4901152.2010.nc, when Data Mode is "A" throughout - A is `real time with adjusted values').

• JULD_QC: Jim's seems to have more data available for BMRC than can found in the BMRC files (all Jim's data is 1 or 0)
• POS_QC: All Jim's data seems to be 2s (probably good data, when its JULD_QC is 1) or undefined (when its JULD_QC is 0). as BMRC equal its JULD_QC value - either 0 (no QC) or 1 (good data).
• Apart from undefined values, PRESS_QC for argo and BMRC data match. No values for Jim's data.
• TMP_QC:
  • argo data = 1 when BMRC = 1 and Jim's data = 8
  • argo data = 0 when BMRC = 0 or undefined and Jim's data = 7
• Same for SAL_QC

What I'd like to know

I want to be sure that the DACs aren't simply throwing out data that is clearly wrong and not storing it in their files. If so, we're in danger of not giving them credit for throwing out bad data.

• For each DAC
  • What proportion of the platforms do they have for each year (for instance, are they neglecting all the argos on the grey list?)
  • For the platforms they have, what proportion of the profiles and levels do they have of the argo data (for instance, do they not store any data that has a dodgy time).

Julian days

Notes

I'm only looking at data where all 5 Data Centres are defined and we have delayed mode QC that is 100% accepted or 100% rejected.

Excluding -999, the profiles take the following values

• bmrc_tmp_qc only takes values between 7 and 12 (9 and 12 are bad). Except there are seven values of 1 in 2006.
• Except for one value of 15, coriolis_tmp_qc is only 9, 10 or 11.
• meds_tmp_qc takes the values 1, 3, 4 or 5 (3 and 4 are bad).
• ukmo_tmp_qc takes the values 0, 1, 3, 4, 5, 70 and 90 (odd numbers are bad).

Data centres are

• BMRC - Bureau of Meteorology Research Centre, Australia
• Coriolis - Ifremer, France
• FNMOC - the Fleet Numerical Meteorology and Oceangraphy Center, US
• MEDS - Marine Environmental Data Service, Canada

Before 2009, coriolis_tmp_qc is always 9.

Using all the data

Using all the profiles defined by both the delayed mode and the Data Centres. Only considering delayed mode profile where all the levels are either accepted or rejected.

	Bad-reject	Bad-accept	Good-reject	Good-accept	Total	ETS	Bias	FoM
BMRC	2103 (1.106%)	2442 (1.284%)	833 (0.438%)	184823 (97.172%)	190201	0.3830	1.55	0.649
FNMOC	2243 (0.861%)	31875 (12.229%)	4732 (1.815%)	221798 (85.095%)	260648	0.0351	4.89
MEDS	1195 (0.551%)	12792 (5.900%)	4092 (1.887%)	198743 (91.662%)	216822	0.0481	2.65
UKMO	115 (0.128%)	6288 (7.025%)	256 (0.286%)	82844 (92.560%)	89503	0.0133	17.26

Using all the levels defined by both the delayed mode and the Data Centres

	Bad-reject	Bad-accept	Good-reject	Good-accept	Total	ETS	Bias	FoM
BMRC	32,767 (0.237%)	156,742 (1.136%)	49,444 (0.358%)	13,560,006 (98.268%)	13,798,959	0.1330	2.31	0.546
Coriolis	285,257 (1.674%)	1,659,197 (9.735%)	88,162 (0.517%)	15,011,658 (88.074%)	17,044,274	0.1219	5.21
FNMOC	55,623 (0.309%)	1,981,459 (10.997%)	183,518 (1.018%)	15,797,903 (87.676%)	18,018,503	0.0130	8.52
MEDS	10,325 (0.069%)	877,361 (5.883%)	7,614 (0.051%)	14,019,228 (93.997%)	14,914,528	0.0104	49.48
UKMO	24,648 (0.330%)	407,955 (5.466%)	1,883,760 (25.240%)	5,146,907 (68.963%)	7,463,270	-0.0390	0.23

Using only the data when BMRC, Coriolis, FNMOC and MEDS are defined

For all levels

	Bad-reject	Bad-accept	Good-reject	Good-accept	Total	ETS	Bias
bmrc	4,356 (0.037%)	89,960 (0.771%)	23,796 (0.204%)	11,548,575 (98.988%)	11,666,687	0.0350	3.35
coriolis	11029 (0.095%)	83411 (0.715%)	44980 (0.386%)	11527018 (98.805%)	11666438	0.0761	1.69
fnmoc	8540 (0.073%)	86086 (0.738%)	150541 (1.290%)	11423068 (97.899%)	11668235	0.0297	0.59
meds	3459 (0.030%)	91167 (0.781%)	5135 (0.044%)	11568471 (99.145%)	11668232	0.0340	11.01

Ranking the QC flags

BMRC

Profiles

QC flag (Jim's class)	% of bad	% of good
7 (accept)	0.77	99.23
8 (accept)	7.7	92.3
11 (accept)	22	78
10 (accept, only 71 values)	80	20
9 (reject, only 197 values)	65	35
12 (reject, only 45 values)	75	25

According to this table, we should switch the QC for 9 and 10 around. However, since a QC of 9 is suppose to be reject and QC of 10 is suppose to be accept, I've put 10 above 9 and assumed the small sample for these has an influence.

However, putting a QC of 10 into reject does improve the skill

	QC=10 is accept	QC=10 is reject
ETS	0.383	0.430
Bias	1.55	1.34
FoM	0.649	0.680

Ranking for levels

QC flag (Jim's class)	% of bad	% of good
2 (accept)	0.89	99.11
5 (accept, 53,096 values)	65.9	34.1
4 (reject, 82,211 values)	39.9	60.1

This is weird! Supposedly, a QC of 5 - which we should accept according to Jim - has more bad data than the QC of 4 - which we should reject according to Jim. Not surprisingly making a QC of 5 a rejection improves the skill scores

	QC=5 is accept	QC=5 is reject
ETS	0.133	0.258
Bias	2.31	1.40
FoM	0.546	0.608

Coriolis

For levels

QC flag (Jim's class)	% of bad	% of good
1 (accept)	10	90
3 (reject)	75	25
4 (reject)	79	21

We can't improve the skill because the Bias is much greater than 1, yet we only have one flag (QC = 1) for accepting data.

FNMOC

For profiles

QC flag (Jim's class)	% of bad	% of good
94 (accept)	17.5	82.5
95 (accept)	19.8	80.2
96 (reject)	20.4	79.6
97 (reject)	21.5	78.5
98 (reject)	27.3	72.7
99 (reject)	29.1	70.9
100 (reject)	43.8	56.3

Trying to improve the skill scores

	QC > 95 is rejected	QC > 94 is rejected	QC > 93 is rejected	QC > 91 is rejected	QC > 90 is rejected	QC > 89 is rejected
ETS	0.0351	0.0362	0.0366	0.0370	0.0372	0.0368
Bias	4.89	4.29	3.82	3.13	2.85	2.61
FoM	0.512	0.512	0.513	0.514	0.514	0.514

Best ETS score is for rejecting all QC > 90.

For levels

QC flag (Jim's class)	% of bad	% of good
98 (accept)	10.4	89.6
99 (accept)	11.5	88.5
100 (reject)	23.3	76.7

There are 10 values where the QC is greater than 100 (all for ArgoId 5901503 on 20821, which also one of two argos to give delayed mode QC above 100) - so looks like dodgy data.

Despite the bias being very high (8.52, so accepting too much data), we can't improve this (ETS and FoM are decrease if we reject QC of 99).

MEDS

Profiles

QC flag (Jim's class)	% of bad	% of good
5 (accept)	5.41	94.6
1 (accept)	6.05	93.95
4 (reject)	24.3	75.7
3 (reject)	15.0	85.0

Changing a QC of 1 to reject will not improve this.

Levels

QC flag (Jim's class)	% of bad	% of good
1 (accept)	5.89	94.1
3 (reject)	45.7	54.3
4 (reject)	59.2	40.8

Only 30 values above 4 and these are for the same time (juld=20139) and probably the same ArgoId. Changing what is accepting and rejected isn't going to help here.

Summary

For the four data centres where we have a lot of data, the bias values are all greater than 1 - indicating that they're accepting more data than there is good data. This suggests that we might be able to improve the skill scores for the observation centres if they rejected more data. The obvious data to reject would be those data where the QC flags suggests the data is only sufficiently OK to keep, and is considered doubtful.

This has been possbile for BMRC where the skill scores have been significantly increased by rejecting profiles with a QC of 10 and rejecting levels with a QC of 5. A slight improvement to the skill scores for the profiles for FNMOC can be made by increasing the amount of data that is rejected. But changing the accept/reject criteria can't improve the skill scores for Coriolis and MEDS.

Where the data comes from