[mandli]

Fixes #761 and partially addresses #760.

Adds tests for the fixes and changed python and fortran code to match errors so that there are multiple error pathways (that match). Should now be consistent with what is mentione din #760 across all topo_type.

---

When coarsen > 1 and align is set, the align step moves the start of the crop window onto the coarse lattice through align. If the crop is narrower than coarsen grid points, that move can pass the end of the window, and then no kept point lies inside the crop. Python and Fortran handled this differently, and both were wrong:

• Python (coordinate_tools.crop_indices, which Topography.crop, the type-4 netCDF read, and the dtopo crop all use) returned an inverted window, e.g. (7, 5). That gave an empty Topography with no error. When the crop was within coarsen points of the file's upper edge, it raised an IndexError instead.
• Fortran (apply_align_buffer_coarsen) carried on and kept a point outside the crop. Next to the file edge, that point could be outside the file. The run finished normally with no warning.

Changes

• crop_indices raises EmptyAlignedCropWindow (a new subclass of EmptyCropWindow, and so of ValueError) when the aligned start passes the end of the window. Align candidates past the end of the array are now computed from the spacing instead of indexed.
• topotools._crop_indices reports this case with its own message ("contains no point of the coarsened grid… widen the crop to at least coarsen grid points, or change align"). The sub-cell message is unchanged.
• apply_align_buffer_coarsen stops with the matching error and prints the file, axis, coarsen and align. It takes two new arguments, fname and axis, so it can name them; all four callers are updated (types 2/3 and type 4).
• dev/design/topo_input_roadmap.md: adds an "In review / open" table covering this PR and the decision on Behavior when creating topo.data if crop_extent goes outside topo.extent for a topofile #760.

Crops wider than coarsen points are unaffected. For them every align candidate is a real array point, so the code computes exactly the same values as before.

Verification

• New Python tests in tests/test_coordinate_tools.py: the upper-edge IndexError case, the inverted-window case, and a sweep of every window 1 to coarsen points wide across the whole array (both ends included). The sweep checks that each crop either raises or keeps a first point inside the crop.
• test_crop_with_no_aligned_point_raises checks the same case through Topography.crop.
• test_crop_with_no_aligned_point_stops in tests/regression/topo_crop runs xgeoclaw for topo types 3 and 4 and checks for a nonzero exit, the error message, the file name, and the axis.
• Each new test fails on 0ba4db7b and passes with the fix. On the old Fortran, both regression runs exit 0.
• The two existing sweeps that compare against copies of the old crop code (768 combinations for two axes, plus the per-axis one) still match exactly.
• Python suite: 614 passed, 5 skipped, 1 xfailed. topo_crop regressions: 7 passed.

Related

#760 (a crop that runs off a file). Once a crop that can't keep any point is an error everywhere, a tile-selection helper there can use crop_indices to drop tiles that would come out empty after coarsening.