Report missing variables in cprnc

[billsacks]

This changes the final status of cprnc so that, if variables are missing from one of the files, the final status is not "IDENTICAL": this final status will now look like:

diff_test: the two files DIFFER only in their field lists

In addition, the number of variables present in file2 but not file1 is now reported in the final counts.

I'm not sure if this output format is exactly what we want - if not, I can change it.

Test suite: cprnc run_tests script Test baseline: previous version of master Test namelist changes: none Test status: identical except for expected differences

Fixes: Addresses PART OF issue #144

User interface changes?: none

Code review: none yet

[billsacks]

cc @jedwards4b @mnlevy1981

[billsacks]

After this change comes to master, we'll still need to do the following to fully address issue #144 :

1. Make changes to the system test scripts to parse the new output
2. Update and rebuild cprnc on all test platforms. Note that many of these likely still point to the old svn repository; for these, we'll need to add a clone of cime, and update the cprnc path in config_machines.xml to point to the new location.
3. Run some tests that trigger the new behavior; make sure these are treated properly by the test system

[rljacob]

Tagging @jgfouca

[jgfouca]

One thing that we'll need to check is if the scripts wrapping cprnc for various testing operations continue to work with your changes. In cime/scripts/Tools:

baseline_gen_comp component_compare.sh component_compare_test.sh component_compgen_baseline.sh component_write_comparefail.pl config_definition.xml

[billsacks]

@jgfouca - I agree - and thanks for enumerating the files that are affected. My intention had been to get the necessary cprnc changes on master and then let someone else handle these other pieces. But maybe that doesn't make sense, and really this should be done all at once.

What do you, @fischer-ncar and @jedwards4b think about that?

One important piece here is that updating cprnc itself has no impact on testing (unless things have changed recently): all of the testing scripts point to a pre-built version. On the other hand, I see the point that we might not want to update cprnc until the test scripts are ready to handle the new version, because otherwise this will block any other updates that are desired in cprnc.

[billsacks]

Closing this old PR. I'm going to open a new, updated PR with these changes and more in ESMCI.