Fix wrong variable names

[xylar]

Check the variables inside a file, not just the file name

Fixes #11.

The problem

A file could be named correctly, contain the wrong variable, and be reported as No errors. Good job !. The checks were driven by whatever a file happened to contain, filtered by the data request — for ivar in file_variables: if ivar in ismip_var: — so if nothing in the file was a requested name, the loop body never ran and the file accrued zero errors without a single numerical, spatial, time or attribute check having been performed on it.

Reproduced against main before making any change, by mutating one file of the seeded synthetic scalar dataset per case:

Case	Mutation	Before	After
A	lim_….nc holds a variable named limm	0 errors, "No errors. Good job !"	1 naming error
B	lim_….nc holds limnsw instead of lim	1 error, but incidental — a standard_name mismatch, after units, ranges, fill value and time had all been checked against limnsw's row of the request	1 naming error, and the incidental one is gone
C	file renamed bogusvar_….nc	file itself reports "No errors"; only the indirect "mandatory variable lim missing"	1 naming error plus the missing-variable error

Case A is the issue as filed. Case B is the same blind spot doing something worse than staying silent: it checked the file against the wrong criteria and passed it, and would have passed silently too had the two variables shared a standard_name or had the request left it blank. Case C had no signal whatsoever for a non-mandatory variable.

The fix

The file name states which variable of the data request a file carries, so it is the file name, not the file's contents, that now decides what gets checked and which row of the request to check it against. On top of that the naming category gained four checks, all of them reported as naming errors and listed in the synthesis at the top of the log.

The file contains the variable its name promises. Reported with the near-miss spelling where there is one, so the log says 'limm' may be a misspelling of 'lim' rather than leaving the reader to spot it. A file that fails this has nothing left to check, so its remaining checks are skipped, as they already were for the other naming errors that make a file uncheckable.

The file holds nothing else. One requested variable per file is the convention, and nothing enforced it. What counts as extra needed care, because CF lets the requested variable bring companions that plainly belong in the file: _allowed_file_variables admits the bounds of a coordinate (which is how time_bounds reaches every FL file), the container variable a grid_mapping points at, and any auxiliary coordinates named through coordinates. They are found by following the attributes that refer to them rather than by matching names, so a group that calls its bounds variable something else is not punished for it.

The variable has the dimensions the request asks for, in the conventional order. REQUESTED_DIMENSIONS translates the request's Dim column into the dimensions of a file — the two differ in more than notation, since the request writes them innermost-first and calls the time dimension t, while the files write them outermost-first in CF order and call it time. A transposed variable passes every other check this tool has, because the spatial tests read the x and y coordinates and the numerical tests take a minimum and a maximum, and neither has any reason to look at how a variable's axes are arranged.

The variable field of the file name is a variable of the request. The obvious else would have been wrong here: ismip_var is the request as narrowed by --variable-list, and the README has modelers check a directory once for its scalars and once for its x,y,t files, under which reading every lithk_….nc becomes an error during the scalars pass. Those files are not being checked, not failing, so the error is reserved for a name that is in neither the narrowed nor the full request, and there is a test guarding the distinction.

Also in here

_insert_synthesis announced a "Naming tests errors report:" and then listed nothing, because its loop was for i in range(iline, len(report_naming_issues)) with iline already around 24 — an empty range for any realistic number of issues, and the wrong index had there ever been more than 24. It was harmless while naming issues were rare; these commits make them common, so the report is now worth having and now works.

Commits

Seven, each one independently reviewable, each leaving the suite green and the golden log consistent. Only the first is a prerequisite for the others, and only the dimension-order commit depends on the dimension-set commit.

1. Check that a file contains the variable its name promises — the presence check together with the switch to filename-driven checking. Deliberately one commit and not two: separating them would leave an intermediate state where the checks are driven by a variable that may not exist.
2. Report unexpected variables in a file
3. Check variable dimensions against the data request — the set of dimensions
4. Report a variable whose dimensions are in the wrong order
5. Report a file name whose variable is not in the data request
6. Document the new variable checks in the README
7. Fix the naming-issues report in the log synthesis — a pre-existing bug, last in the series so it is easy to drop or move to its own issue

Testing

39 tests, green, up from 31. Eight are new, and each of the new checks has a test that fails without its commit. The suite gained an x,y,t baseline, which it did not have before — dimension order needs a variable with more than one dimension — generated with non-mandatory variables included, because refgeoid (x,y) and litemp (x,y,z,t) are the only variables of their shape in the request and two of the four dimension forms would otherwise go unexercised. It passes with zero errors.

The two dimension tests rebuild a lithk file with its shape changed, since netCDF cannot reshape a variable in place; every other variable, every attribute and the unlimited dimension are copied across unchanged, and each test requiring exactly one error is what shows the rebuild leaves every other check seeing what it saw before.

The golden reference log gains three lines per file and loses none — the three new OK lines, checked one commit at a time so that each diff was purely additive and of a single form. The commits that should not have touched it did not.

Compatibility

Files that are correct are unaffected: the same variable is checked against the same row of the request as before, and passing files gain only the new OK lines in their log. Every new error is a file that was previously being reported as clean while being wrong, or in case C not reported at all.