I used negative number to count the error message. @doutriaux1 used 0 or 1 for False and True in other functions.

I could not find any return values that would affect the computation error messages.

Can you tell me how you encountered this issue?

My apologies @dnadeau4, I misunderstood the problem. The issue is due to the fact that many of the checks performed in cmor_CV_checkParentExpID do not return an error code (most of the loops that end with cmor_handle_error(msg, CMOR_CRITICAL); are not followed by return (-1);). This has the same result as described in my initial comment (the returned ierr equals 0).

Do you think that when a cmor_handle_error is indicates an error has been encountered that ierr should be set to -1 or +1, rather than 0? Would that be the right thing to do? Is it possible?

@taylor13, I'm not sure if your question was directed at me, but the work I did for #171 involved recording (via cmor_handle_error_var) when a critical error (CMOR_CRITICAL specifically, rather than just a call to cmor_handle_error) was encountered so that cmor_close knew whether to finalise the file or not. In this case, cmor_handle_error_var is called on L4309 after calling cmor_setGblAttr, but also after ierr has been appended to (by cmor_CreateFromTemplate). Therefore, in this case, it makes sense for cmor_setGblAttr and cmor_CreateFromTemplate to both return either positive or negative values for ierr (otherwise they could cancel each other out).

I hope that's helpful? :)

The program sends a SIGTERM and the number of error ierr is lost when it is killed. At this stage, I don't want to make such a major code change. I called 455 cmor_handle_error() functions in all the .c.

I only work 10%-20% of my time for PCMDI now until next year.

Can we leave this open as a suggested future change? No need to address this issue, but we might want to in the future.

My apologies for not being clear.

I believe there is a genuine issue here.

In some cases where there is a problem in cmor_CV.c, i.e. cmor_handle_error is called, a negative value is not returned (see my original comment). See here, here and here (although should these two be a CMOR_WARNING?), here (and many others in this function) and here. This can be solved by adding return (-1); after every cmor_handle_error call (excluding those that are just warnings). I can add a pull request for this next week, if that's helpful?

Also, this and this is just a warning, so I don't think -1 should be returned.

I have convinced myself that the functions called in cmor_write before the call to cmor_handle_error_var here have negative return values, so the issue I reported in the last sentence here is not an issue :)

Pushing to 3.3.1, cannot be fix in 3.3.0 release time frame.

@ehogan I have very confused with all this #245 (comment) Some of the place where you want to return(-1) will stop the loop and you won't get all the information like a compiler (PCMDI requirements).
here

I will push this to 3.3.2, but I am not sure I can work on this, since I only work 8 hour/week for PCMDI. If you can create a PR, I might be able to merge it if my tests do not fails.

@ehogan @jonseddon just to let you know that @doutriaux1 is now working on CMOR3. How are you doing with CMIP6? I have not heard from you in a long time.

This issue is similar to what I observed in #540.

Should we have all of the CMOR CV functions return a positive error count rather than just -1?

It would be really nice to hear why some errors are "-1" and others "1". There must have been a good reason for making the distinction. Anyone remember one? @dnadeau4? @doutriaux1?

@taylor13 , @dnadeau4 commented on this at: #540

A lot of the functions in cmor_CV.c get called in cmor_setGblAttr.

However, if you were to mix up positive and negative errors you could wind up making it look like there were no errors. That was one of the issues I encountered while working with PrePARE in #540 where negative errors from cmip6_cv functions were being clobbered by PrePARE's checks where it added 1 to the error count. I resolved that issue by just detecting if the error is nonzero and then adding 1 to the error count.

There was one place that returned a positive integer for a warning in cmor_CV.c.

Another interesting thing to note of cmor_write is that there are errors that are -1.

There's a statement in cmor_tables.c that is checking if cmor_CV_set_entry returns 1.

I think to apply the "keep going like a compiler and accumulate the number of errors" method of CMOR, functions like cmor_CV_checkParentExpID should have an error count that is incremented at every error encountered and returned at the end. Several of the errors in cmor_CV_checkParentExpID are CMOR_CRITICAL. Shouldn't they be CMOR_NORMAL to prevent the error checking from ending prematurely?

@durack1 @taylor13
I have some questions about this section in cmor_CV_checkParentExpID.

Lines 1049-1051 will make the function return 0 if "no parent" is found in the above attribute from CMIP6_CV.json. Does that mean we can ignore checking the other attributes in cmor_CV_checkParentExpID when the CV has "no parent" for parent_experiment_id? Shouldn't it just report an error if it doesn't find "no parent" in the CV, and then continue finding other errors?

@mauzey1 there are two identifiers, the parent_activity_id (or MIP, e.g. CMIP, DAMIP, AerChemMIP etc) and the parent_experiment_id so for e.g. the mip_era / activity_id / experiment_id: CMIP6 CMIP historical experiment would normally have a parent experiment of CMIP6 CMIP piControl

@durack1
What I was pointing out in #245 (comment) was that it was getting the parent_activity_id from the experiment's CV rather than the parent_experiment_id when seeing if it was "no parent" when there is no parent_experiment_id in the data file.

If there is no parent_experiment_id attribute in the file and "no parent" was in the parent_experiment_id of the experiment's CV, then it would exit as successful. Does that mean a file having no parent_experiment_id attribute is treated as having parent_experiment_id = "no parent" if "no parent" was one of the parent experiments in the experiment's CV? If so, then shouldn't the other attributes be evaluated as if it was the "no parent" case? Otherwise, shouldn't having no parent_experiment_id in the data file be considered an error regardless of what the parent is in the experiment's CV?

@mauzey1 got it, this logic was something that @taylor13 likely worked on with @dnadeau4 . So I might defer to @taylor13. Having said that, there was a CV cleanup a long while back that attempted to address these issues, If we missed some entries, we could run another CV cleanup too

@durack1 @taylor13

Should the above section of code be changed so that it breaks from the loop but not return? The break is already there but is not reached due to the return. Or should the message be an error instead of a warning?

@mauzey1 just to confirm this is using the cmip6-cmor-tables/Tables/CMIP6_CV.json file isn't it?

I ask, as for this file we do the work of accumulating contributions that are registered in CMIP6_CVs/CMIP6_source_id.json and then create each of the source entries that you are referring to

@durack1 Yes, that is the file I am referring to.

@mauzey1 so as we create this file, it will always have a source section, I am uncertain if there are any criteria set in the generation of this (it's the cronjob that you have reconfigured)? If there are tests in how source is constructed, then that should be considered in changing the behavior as described above

@durack1 The section I mentioned would only be reached if the "source_id" was not a valid JSON object in cmor_CV.json. For example, if you were processing a file with PrePARE with a "source_id" of "PCMDI-test-1-0"

        "source_id":{
            ...
            "PCMDI-test-1-0": "",
            ...

Should that be considered a critical error since there is something wrong with the table files?

@mauzey1 as we are generating the CMIP6_CV.json file, and control all the content, the only time that this test (and the result) would be useful is in the case that a user has "hacked" the CV file, and included a json-invalid entry.

I think in the case that anything is found wrong with the file(s), then a fatal error should be thrown and the user alerted to the error that was encountered. I make this statement knowing that you have implemented comprehensive testing, so a false positive fatal error is incredibly unlikely.

@taylor13 Would you like to comment on the logic of the code section posted in #245 (comment)?

If the data file doesn't have the attribute parent_experiment_id but the experiment in the CV file has "no_parent" as the parent_experiment_id, does that mean we can ignore the other attributes checked by cmor_CV_checkParentExpID? Should that be an error instead?

Apologies for the delay getting to this. Before commenting on what you asked me to comment on, I agree with @durack1 regarding the check on the source information in the CV.

Now for experiment_id and parent, etc. First, I'll outline how I would have constructed the logic:

Given an experiment_id, the experiment_id CV specifies the only acceptable options for parent_experiment_id and the only acceptable options for parent_activity_id. We need to check that what the user specifies for parent_experiment_id and parent_activity_id is consistent with those options.

If one of the options in the CV is for parent_experiment_id and parent_activity_id to be "no parent", then the user may specify "" for the values, but CMOR should change the empty strings to "no parent" before writing the file.

If the parent_experiment_id != "no parent" (and != ""), then the user must specify the following attributes (but the values are just examples):

    "parent_activity_id":      "CMIP"
    "parent_source_id":       "PCMDI-test-1-0",
    "parent_variant_label":   "r3i1p1f1",
 
    "parent_time_units":      "days since 1850-01-01",
    "branch_method":          "standard",
    "branch_time_in_child":   59400.0,
    "branch_time_in_parent":  59400.0,

If the user fails to specify these attributes, a fatal error should be raised.

Also when parent_experiment_id != "no parent", CMOR should set parent_mip_era = "CMIP6" . (It's probably o.k. for CMOR to invariably set parent_mip_era="CMIP6").

If parent_experiment_id = "no parent", then the first 5 entries should either be set to "" or "no parent"; if the user has specified something else, we should raise an error. (or we could simply override what the user specifies with "no parent" and raise a warning telling the user we have done that.) If the user has specified "", CMOR should replace that with "no parent" before writing the file.

If parent_experiment_id = "no parent", then the last two entries above (the times) may or may not be specified by the user. Unless the user specifies a value, we should omit these two attributes for the "no parent" case. If the user does specify values, they should be recorded in the file.

It is likely that currently CMOR is less thorough than outlined above, but CMOR should be at least consistent with the above. Perhaps @mauzey1 can say whether there are obvious inconsistencies or things that are unclear before I try to address the specifics.

thanks for attempting to address this issue raised so long ago.

@taylor13 So if the file has parent_experiment_id = "" or doesn't have parent_experiment_id in global attributes, then we should replace it with parent_experiment_id = "no parent" if that is the valid parent experiment in the CV?

The CV will never have ""; it will have "no parent" if there is no parent experiment. I think the user is allowed to specify for parent "", if there is "no parent", but CMOR should probably write out the attribute with the value "no parent". I guess if CMOR currently just omits the attribute in this case, that would be o.k., but I don't think CMOR should ever specify "" for the value of an attribute written to a file. That seems difficult for a user to interpret. Do you agree?

Darn I miss these @taylor13 discussions. 😄

@taylor13 Here is a change to the code that will replace "" with "no parent" for the parent_experiment_id value. Instead of exiting, it would continue to the next part of cmor_CV_checkParentExpID where it will process the other attributes for the "no parent" case.

    // Do we have a parent_experiment_id?
    if (cmor_has_cur_dataset_attribute(GLOBAL_ATT_PARENT_EXPT_ID) != 0) {
        CV_parent_exp_id = cmor_CV_search_child_key(CV_experiment,
                                                    PARENT_EXPERIMENT_ID);
        if (CV_IsStringInArray(CV_parent_exp_id, NO_PARENT)) {
            snprintf(msg, CMOR_MAX_STRING,
                    "Your input attribute \"%s\" defined as \"\" "
                    "will be replaced with \n! "
                    "\"%s\" as defined in your Control Vocabulary file.\n! ",
                    PARENT_EXPERIMENT_ID, NO_PARENT, NO_PARENT);
            cmor_handle_error(msg, CMOR_WARNING);
            cmor_set_cur_dataset_attribute_internal(PARENT_EXPERIMENT_ID,
                                                    NO_PARENT, 1);
        } else {
            snprintf(msg, CMOR_MAX_STRING,
                     "Your input attribute \"%s\" is not defined properly \n! "
                     "for your experiment \"%s\"\n!\n! "
                     "See Control Vocabulary JSON file.(%s)\n! ",
                     GLOBAL_ATT_PARENT_EXPT_ID, CV_experiment->key,
                     CV_Filename);
            cmor_handle_error(msg, CMOR_NORMAL);
            cmor_pop_traceback();
            return (-1);
        }
    }

@taylor13 @mauzey1 (and why the hell not @doutriaux1) you might want to double check (CMIP6_experiment_id.html)[https://wcrp-cmip.github.io/CMIP6_CVs/docs/CMIP6_experiment_id.html] (or the source json file) to make sure that this assumption holds. I think we cleaned it up, but not 100% sure