Shared-Mesh Solver Comparison on Naizin#

Note

This page and its static assets are auto-generated by python -m tools.doc_gallery. The Sphinx build only reads committed PNG and JSON artifacts.

This case reuses two committed run folders for the same Naizin catchment mesh. It compares full water-table elevation and water-table depth maps at the last saved time step, plus head chronicle comparisons at three contrasted probe locations, then renders parity plots and compact error bars.

See also

Read the gallery and validation reading guide if you want the parameter mapping, a recommended reading order, and the first modifications to try.

Simulation comparison figure for the shared Naizin mesh
Parity plots and error bars comparing the committed MODFLOW 6 and Boussinesq runs on the shared Naizin mesh.

Case Setup#

  • Reference simulation: MODFLOW 6 on the committed Gmsh catchment mesh.

  • Candidate simulation: Boussinesq reusing the exact same mesh bundle.

  • Compared observables: full watertable_elevation and watertable_depth maps at the last saved time step.

  • Three head probes sample contrasted response zones: outlet lowland, mid-basin storage, and upstream ridge.

What It Shows#

  • How two solver families can be compared on exactly the same triangular support.

  • How map-wide parity plots complement scalar metrics such as MAE and RMSE.

  • How three point chronicle comparisons expose outlet, mid-basin, and upstream response differences.

  • How comparison figures can be regenerated from committed run folders without rerunning the solvers.

Key Parameters#

  • The most important modelling choice is not a scalar parameter but support equality: both runs must use the same saved mesh if you want a fair map-wide comparison.

  • run_comparison_example12_map_existing.toml defines which run folders are compared and which observables are sampled from them.

  • The compared observables (watertable_elevation, watertable_depth) determine whether the figure emphasizes absolute state mismatch or near-surface response mismatch.

  • The three point observables reuse anchors from comparison_points.toml so the same physical locations are compared across simulations.

  • Interpret RMSE and MAE together: RMSE highlights stronger local mismatches while MAE gives the typical cell-wise discrepancy.

How To Read It#

  • Check first that the comparison is support-consistent: same mesh, same spatial observable, same saved time step.

  • Then read the parity cloud shape. A tight cloud around the 1:1 line means the two solvers agree across most cells.

  • Use the error bars and scalar metrics to judge whether disagreement is diffuse or concentrated in specific ranges of the state variable.

  • Do not read this page as a validation benchmark: it is a solver-to-solver comparison, not a comparison against an analytical truth.

Next Steps#

Reproduce#

Run the underlying example or validation case with:

python -m tools.doc_gallery

Refresh the committed gallery artifacts with:

python -m tools.doc_gallery

Source Pointers#

  • docs/source/_static/capability_gallery/simulation_comparison/example12_map_simulation_comparison_comparison_manifest.json

  • docs/source/_static/capability_gallery/simulation_comparison/example12_map_simulation_comparison_comparison_metrics.json

  • docs/source/_static/capability_gallery/simulation_comparison/example12_map_simulation_comparison_observables.csv

  • docs/source/_static/capability_gallery/simulation_comparison/example12_map_simulation_comparison_summary_metrics.csv

  • docs/source/_static/capability_gallery/simulation_comparison/example12_map_simulation_comparison_difference_metrics.csv

Artifacts#

  • docs/source/_static/capability_gallery/simulation_comparison/example12_map_simulation_comparison.png

  • docs/source/_static/capability_gallery/simulation_comparison/example12_map_simulation_comparison_summary.json stores the displayed metrics plus source hashes used by python -m tools.doc_gallery --check.