cp4cds / c3s_34g_qc_results Goto Github PK

The first draft appears to support only a single error per file with cf_error_code and cf_status provided as strings. Can we modify this to, for example cf_error_codes giving a list of error codes and cf_warning_code giving a list of warnings?

initial prepare checks showed that 7 different Dreq versions are involved in our subset:
1.00.21, 23, and 27-31 -- need to define how to handle this: check with version valid at publication time .. etc. also need to define QC flags accordingly ..

Should we omit AWI-CM-1-1-MR ocean data which is on an unstructured grid? I can't see C3S users making much use of this -- and the CMORised files don't describe the grid in enough detail anyway.

We should restructure this repository so that all the releases live on the master branch. Let's use the current release that we are working on r4_decadal, as the prototype. It lives under:

https://github.com/cp4cds/c3s_34g_qc_results/tree/master/QC_Results/r4_decadal

Here is my proposed new directory structure:

QC_Results / 
    <release_id> / QC_template.json
        / <check_type> / <json or csv/gz>
        / final / <csv/gz>
        / final / <json>

So an example would be:

QC_Results / 
    r4_decadal / QC_template.json
        / time_checks / r4_decadal_time_checks.csv.gz
        / final / r4_decadal_qc_results.csv.gz
        / final / r4_decadal_qc_results.json

When we have finalised a version, then I think we create a release of the entire repository and tag it as the release name, e.g. "r4_decadal".

@glevava @wachsylon: what do you think? I am happy for an alternative approach if you have one.

We should include some header information in the manifests.

e.g.

cf_m["header"] = {'application':'CF Checker', 'institution':'CEDA', 'configuration':'Version ...., CF-1.7' }
cf_m["results"][["21.14100/1fe581d0-0c10-328d-8b78-941834e09b19"] = {...}