[Go-essp-tech] Out-of-bounds data and QC level 1 checks

martin.juckes at stfc.ac.uk martin.juckes at stfc.ac.uk
Mon Jun 28 06:09:01 MDT 2010


Hello Philip,

 

I believe (though I can't find any documentary evidence) that QCL1 is
CMOR (as opposed to being equivalent), but you raise an important point
for clarification: is a file that raises warning with CMOR good enough?
I would suggest that it should be, in order to avoid the conflict you
describe below. I.e. anything short of a critical error passes,

 

Cheers,

Martin

 

From: go-essp-tech-bounces at ucar.edu
[mailto:go-essp-tech-bounces at ucar.edu] On Behalf Of Bentley, Philip
Sent: 28 June 2010 11:46
To: GO-ESSP; doutriaux1 at llnl.gov
Subject: [Go-essp-tech] Out-of-bounds data and QC level 1 checks

 

Hi folks, 

Many of the output variables specified in the latest CMIP5 MIP tables
now have their valid min/max and absolute mean min/max values set. At
present, if the CMOR library detects input data values which contravene
any of these bounds it logs a non-critical error message and continues
to output the netcdf files comprising the atomic dataset.

Hypothesis: We then examine the netcdf output data and, after due
consultation with the relevant science expert(s), decide that the data
are in fact valid, or that the discrepancy from the bounds is so minimal
as to be inconsequential, or that the bounds are overly conservative.
Accordingly we submit the atomic dataset to a CMIP5 data node (for us,
BADC).

My question then is: Would such an atomic dataset pass ESGF's QC level 1
checks? 

My current (albeit hazy!) understanding is that the QCL1 checks are
equivalent to those implemented by CMOR.  So any dataset output by the
CMOR library should pass QCL1, right?

If this is not the case, then would it be desirable to have CMOR throw
instead a critical error and NOT generate the atomic dataset?

Regards, 
Phil 


-- 
Scanned by iCritical.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ucar.edu/pipermail/go-essp-tech/attachments/20100628/7693221e/attachment-0001.html 


More information about the GO-ESSP-TECH mailing list