Restore genForeFireCase.py as a general landscape writer

[HugoFara]

Addresses #167. @filippi is the reviewer because he removed this script, and this proposes putting it back — that call is his.

The removal was intentional

I filed #167 saying the script was documented in four places and present in none, which is true, but I framed it as an oversight. The history says otherwise:

fd4b1c8 2023-10-12 FiretoNC copied into prealCF2Case.py
ac0baba 2023-12-18 genForeFireCase.py deleted ("clean more post-processing")

Two months apart, consumer first. The function had been inlined where it was actually used, and the standalone file was then removed as dead code. That is ordinary de-duplication, and this pull request undoes it.

Why I think it is still worth doing

prealCF2Case.py's copy has since diverged into something specialised:

• domain and parameters attributes are set by iterating the dicts — no required-key check, no float coercion
• elevation is written as f4 rather than f8
• wind is written as one combined wind variable in a potential-field form (NAXES, NDIRCOEFFS, NI, NJ), with the windU/windV calls commented out above it

It is now the back half of the Meso-NH PGD → case pipeline, and it needs a PGD file to do anything. So there is no general-purpose landscape writer in the repository, while docs/source/user_guide/landscape_file.rst, tools/README.md, tools/preprocessing/READMEscripts.md and the legacy user guide all describe one. Users following the documentation to build their first case have nothing to reach for.

The cheaper alternative is to delete the four references. That respects ac0baba most directly and takes minutes. It also leaves a new user with no path to a landscape file, which is why I am proposing this instead — but if the answer is "we removed it on purpose, fix the docs", that is a good answer, say so and I will close this and send that patch instead. No need to justify the original decision.

What is in here, if it does land

Restored from ac0baba^ with three fixes, since it was not usable as it stood.

The 3-D and 4-D paths were broken. Dimensions were read off the array as (NY, NX, NZ, NT) while the variable was created as (NT, NZ, NY, NX) and assigned without transposing. Only the 2-D path was right. Running the original on fields with four distinct lengths:

4-D: ValueError: shape mismatch: objects cannot be broadcast to a single shape
3-D: ValueError: cannot find dimension windUNT in this group or parent groups

The 3-D branch created NZ but never NT, so it failed at variable creation rather than at assignment.

Fields are now indexed outermost axis first — (NY, NX), (NZ, NY, NX), (NT, NZ, NY, NX) — which is the convention prealCF2Case.py settled on when it fixed its own copy, with the old lines left commented out above the working ones. Two scripts in one directory with opposite conventions would be worse than either alone.

scipy.io.netcdf is deprecated, and scipy is not a dependency of this project. Uses netCDF4, which the tests already require, writing the same NETCDF3_CLASSIC format prealCF2Case.py writes.

parametersProperties has seven required keys — date, duration, refYear, refDay, year, month, day — which tools/README.md called "the other optional properties you may want to put in the list". Omitting one raised a bare KeyError over a half-written file. They are checked before the file is opened, and the error names what is missing.

Verification

tests/python/test_genforefirecase.py (new): builds a landscape, hands it to ForeFire, ignites and steps; checks the 3-D and 4-D shapes and values; checks that a missing parameter key is reported before anything is written. Four cases, all passing. The shape cases use four different lengths, since NY == NT and NX == NZ is what let the old broadcast succeed by accident.

It skips the load-and-simulate case when pyforefire is not importable, so it stays runnable while iterating on the writer alone.

Documentation

The three live documents now describe what exists. docs/_legacy/UserGuide/ForeFireGeneralUsage.tex also mentions the script, at a stale path, and is left alone deliberately — editing an archived document would suggest it is maintained.

Unifying the two implementations is not attempted here. They now do different things, and choosing between the combined wind variable and separate windU/windV is a question about what ForeFire should read, not a cleanup.

---

This pull request, including its code changes and this description, was generated by Claude Opus 5, and reviewed manually before submitting.