[Go-essp-tech] Fwd: Handling missing data in the CMIP5 archive

[Frank Toussaint]

Hi Ag,

we classified a missing time step in the exception category "Error", 
which means that the QC manager can decide to assign QC level 2 for the 
data. For QC L3 / DOI data publication we rely on the results of QC L2, 
thus we would follow the decision of the QC manager.

The assignment procedure is documented in: 
https://redmine.dkrz.de/collaboration/projects/cmip5-qc/wiki/Qcl2_criteria
The exceptions and their categories are documented in: 
http://www.leuchtturm-atlas.de/SCR/qc2list.html

Our view is nearly the same as yours, just a few precisions:
*1. ok
*2a1. If the QC manager decides to reject this data in total and not 
assign QC L2. -> stop; data remains on QC level 1.
*2a2. For other cases: Only part of the data, a few variables, do not 
meet the QC L2 requirements: Publish a new dataset version in the ESG 
publisher excluding these variables and rerun the QC L2
*2b. ok
*2c. If the QC manager decides to accept the data then it is assigned QC 
level 2 and can get a DOI. The QC manager should add a comment during QC 
L2 assignment for that, which is stored in the metadata and is needed by 
the WDCC for the DOI process.
*3. We do not see a difference between 2b and 3. If the data provider 
decides to create new data than this is published as a new version and 
the QC L2 tool is restarted.

*A provider probably will not be able to only create the missing months, 
as the last time step of them should fit to the following step (which is 
the first step after the gap). This normally is not the case as most 
progtrammes do not run two times the same way in parameter space.
So to avoid discontinuities at end of gap after this has been filled:
*the data after the gap will be dumped,
*the programme restart will be initialised with the last step before the 
gap and has to run until normal ending,
*old data before the gap and new data (from start of gap on) may be 
glued - new version... and so on!

The assignment of a new version in the ESG publisher for newly delivered 
data is important.

Thanks for bringing up this discussion.

Best wishes,
Martina and Frank


-------- Original Message --------
Subject: 	[Go-essp-tech] Handling missing data in the CMIP5 archive
Date: 	Thu, 28 Apr 2011 10:12:51 +0000
From: 	<ag.stephens at stfc.ac.uk>
To: 	<go-essp-tech at ucar.edu>, <taylor13 at llnl.gov>



Dear all,

At BADC we have come across our first "missing data" issue in the CMIP5 datasets we are ingesting. We have an example of some missing months for a particular set of variables that was revealed when running the QC code from DKRZ.

It would be very useful for the CMIP5 archive managers to make an authoritative statement about how we should handle missing data time steps in the archive.

I propose the following response when a Data Node receives a dataset in which time steps are missing:

  1. QC manager (i.e. whoever runs the QC code) informs Data Provider that there is missing data in a dataset (specifying full DRS structure and date range missing).

  2a. If Data Provider says "no, cannot provide this data" then the affected datasets cannot get a DOI and cannot be part of the "crystallised archive". STOP

  2b. Data Provider re-generates files, data is re-ingested, new version is generated, QC is re-run, all is good. STOP

  2c. Data Provider cannot re-generate but wants to pass QC - so needs to create the required files full of missing data.

  3. Data Provider creates missing data files and sends, data re-ingested, new version is generated, QC re-run, all good. STOP

In cases 2a and 2c it would also be very useful if the dataset is annotated to inform the user which dates have been FILLED with missing data. This would, I believe, be in the QC logs but we might want a more prominent record of this if possible.

Cheers,

Ag
BADC--
Scanned by iCritical.
_______________________________________________
GO-ESSP-TECH mailing list
GO-ESSP-TECH at ucar.edu
http://mailman.ucar.edu/mailman/listinfo/go-essp-tech

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ucar.edu/pipermail/go-essp-tech/attachments/20110428/07b12740/attachment.html