Hydrata - ANUGA Flood Simulation

Quality 73 / 100needs work

28 tools, about 10,950 tokens to load them all · tool set f9c4ddfde255 · tools last changed 2026-10-19 · checked 2026-10-20 18:38 UTC

Tool changes

• 2026-10-19set_comparison_toleranceadded

  Save a project's default tolerance for comparing runs with flood observations. Needs Editor (or above). Every later get_observation_comparison (and the map's Compare with observations tab) uses it unless a tolerance is passed. Only save it when the user asks to change the project's default; to show the figures at another tolerance, pass `tolerance` to get_observation_comparison.

• 2026-10-19set_observation_exclusionadded

  Exclude a flood observation from ONE run's comparison with observations, or include it again. Needs Editor (or above) on the project. The exclusion is logged with the user and reason (nothing is overwritten) and keyed on (run, layer, fid), so it survives a recompute. The figures change at once: `headline_after` is the run's headline with the change applied. To exclude, the user must give the reason: if they have not, ASK them; do not make one up.

• 2026-10-19get_observation_comparisonadded

  Compare a run with the project's flood observations: how well does it match them? Returns `headline` (the figures to tell the user, e.g. "47 observations · 31 within ±0.30 m (66%) · bias -0.12 m · RMSE 0.35 m · 1 excluded"), `headline_numbers` (the same as numbers), `tolerance_m` (used) and `default_tolerance_m` (the project's saved one), `statistics` (the API's summary: n, within, within_pct, bias_m, rmse_m, weighted_rmse_m, mae_m, max_abs_m, excluded, not_scored by reason, gauges), `gauges` (Gauge records: peak error, timing error, NSE), `datum_checks` (warn the user only when `warning` is true: both datums known and different; `not_recorded` = the terrain has no recorded datum, stated in `note`, not a warning) and one row per observation: observed_m / modelled_m / residual_m (modelled - observed, + = model high), within, scored / not_scored_reason, match (`outside_run_window` = not this flood), excluded + exclusion {reason, by, at}. `sampling` counts how the modelled values were read: `centroid` (the peak of the mesh triangle the observation sits in), `nearest_node_fallback` (an older run without that peak: the nearest mesh node's value, tell the user) and `nearest_node` (just outside the mesh); each row's `sample.method` says which. There is no pass or fail: report the figures. A run that is not historic has none (`has_comparison` false) — do not retry it.

• 2026-10-19add_observation_photo_linkadded

  Attach a photo to a flood observation as a reference LINK (never a file). MCP never uploads photo bytes. A local path, file:// URL or data: URI is refused: to upload a photo file, open the observation in the map and use the photo strip on its form (JPEG, PNG or HEIC, 25 MB, 10 per observation). The link counts toward the 10.

• 2026-10-19delete_observationadded

  Delete one flood observation and its photos (cannot be undone). DELETEs /projects/<id>/flood-observations/<layer>/observations/<fid>/; a missing fid is an error (404), not a silent success.

• 2026-10-19update_observationadded

  Edit one flood observation (PATCH; only the fields given change). The API checks the stored observation merged with `changes` and refuses (400, every bad field named) rather than store a half-valid one. Photos are not fields: attach a link with add_observation_photo_link.

• 2026-10-19add_observationsadded

  Add flood observations (Flood mark, Timed level, Gauge record, Dry point) to a layer. POSTs each observation to /projects/<id>/flood-observations/<layer>/observations/ in order. The API validates every field: a row it refuses (400) is listed in `rejected` with its `problems` and the rest still land; a refusal that is not about the row (403 not an Editor, 404, 409) stops the batch and is reported in `stopped`, with `not_sent_count`. Stages are on the LAYER's vertical datum. Photos are not part of an observation: attach a link with add_observation_photo_link.

• 2026-10-19list_observationsadded

  List a project's flood observation layers, or one layer's observations. Without layer_id: every layer (layer_id, title, dataset_alternate, vertical_datum, datum_offset_m, has_features). With layer_id: {layer, count, results} where each observation carries its `fid` (the key for update_observation / delete_observation), subtype + subtype_label, stage/depth, sigma, bound, the observed window in UTC, `datum` status (an `unknown` datum is not scored), `photo_count` and `problems` (fields drawn in the map that fail validation, reported, never fixed).

• 2026-10-19create_observation_layeradded

  Create a flood observation layer in a project and wait for its map layer. A flood observation layer holds real flood evidence (Flood marks, Timed levels, Gauge records, Dry points) that every historic run is compared with (Compare with observations). It is project-level: it is never a scenario input. POSTs /projects/<id>/flood-observations/, then polls the layer until its GeoServer layer exists (`ready`), usually a few seconds; until then add_observations refuses. On `timed_out`, call list_observations later.

• 2026-10-15attach_input_layerchangeddescription
  before

  Attach a GeoJSON you uploaded to GeoNode as the project's boundary, friction, inflow, rainfall, building, mesh_region or culvert layer. The agent moves the bytes: first upload the GeoJSON yourself, with the same credential, to GeoNode's upload endpoint at the site origin: curl -sS -u <user>:<password> -F "base_file=@/path/rainfall.geojson" https://<site>/api/v2/uploads/upload/ → JSON with `execution_id`. Then call this tool with it. The tool polls GET /api/v2/resource-service/execution-status/<execution_id> (bounded by timeout_seconds; statuses ready → running → finished | failed), reads the new dataset's pk, and PATCHes it onto the project's DEFAULT row of that kind ('Boundary 01' … 'MeshRegion 01' — the six rows the terrain import seeds ~30 s after get_terrain reports ready; if the list is still empty the tool says so: run finalize_terrain_upload / wait for get_terrain first). kind `culvert` (Hydraulic Structures; one two-point line per culvert, Inlet first, then Outlet): no culvert row is seeded, so the tool creates 'Culvert 01' when the project has none and waits for its layer. It reads your culverts back and maps your attribute names onto the culvert fields — name, shape (box|circular), width_m, height_m, diameter_m, upstream_invert_m, downstream_invert_m, barrels (1-20), wall_thickness_m, entrance_type, material (concrete|corrugated_metal), manning_n, blockage_pct (Reduced-area blockage, percent), length_override_m, description — accepting common alternatives (width, diameter, label, us_invert, ds_invert, num_barrels, manning, blockage, length, shape 'pipe' = circular, …) and filling the defaults (barrels 1, wall 0.20 m, square_edge_headwall, concrete, manning_n from the material, blockage 0). Other attributes are kept. If anything changed it re-uploads the mapped culverts and attaches THAT layer (`mapped`: renamed, filled, source_dataset_pk). `culvert_problems` lists what the build will still refuse (typically missing inverts) — the user fixes those in the map. The culvert engine conveys flow through each culvert in a run (GPU lanes and localhost; the multi-core CPU lanes refuse a culvert scenario). `outcome` is exactly one of: `attached` (row_id, gn_layer, dataset_pk, dataset_alternate — the WFS typename — and every row id seen); `timed_out` (still importing or still creating the culvert layer: call again with the same arguments, except pass `retry_execution_id` as execution_id when the result carries one); `upload_failed` (the execution record, incl. its log, is returned verbatim — fix the file and upload again); `no_default_row`; `no_dataset` (finished but no resource was recorded). The PATCH is refused with a 400 if the dataset is not owned by you. Refused, with no request made: kind `breakline` — no REST create path exists for it at HEAD (TASK-3040 AC6), so attaching one would only pretend. Also refused without a request: an execution_id that is not the UUID the upload returned. One GeoJSON per kind: all of a kind's features travel in that one file. A rainfall polygon names its gauge in its `data` property — create that gauge with create_time_series under the exact same name.

  after · 95% of words in common

  Attach a GeoJSON you uploaded to GeoNode as the project's boundary, friction, inflow, rainfall, building, mesh_region or culvert layer. The agent moves the bytes: first upload the GeoJSON yourself, with the same credential, to GeoNode's upload endpoint at the site origin: curl -sS -u <user>:<password> -F "base_file=@/path/rainfall.geojson" https://<site>/api/v2/uploads/upload/ → JSON with `execution_id`. Then call this tool with it. The tool polls GET /api/v2/resource-service/execution-status/<execution_id> (bounded by timeout_seconds; statuses ready → running → finished | failed), reads the new dataset's pk, and PATCHes it onto the project's DEFAULT row of that kind ('Boundary 01' … 'MeshRegion 01' — the six rows the terrain import seeds ~30 s after get_terrain reports ready; if the list is still empty the tool says so: run finalize_terrain_upload / wait for get_terrain first). kind `culvert` (Hydraulic Structures; one two-point line per culvert, Inlet first, then Outlet): no culvert row is seeded, so the tool creates 'Culvert 01' when the project has none and waits for its layer. It reads your culverts back and maps your attribute names onto the culvert fields — name, shape (box|circular), width_m, height_m, diameter_m, upstream_invert_m, downstream_invert_m, barrels (1-20), wall_thickness_m, entrance_type, material (concrete|corrugated_metal), manning_n, blockage_pct (Reduced-area blockage, percent), length_override_m, description — accepting common alternatives (width, diameter, label, us_invert, ds_invert, num_barrels, manning, blockage, length, shape 'pipe' = circular, …) and filling the defaults (barrels 1, wall 0.20 m, square_edge_headwall, concrete, manning_n from the material, blockage 0). Other attributes are kept. If anything changed it re-uploads the mapped culverts and attaches THAT layer (`mapped`: renamed, filled, source_dataset_pk). `culvert_problems` lists what the build will still refuse (typically missing inverts) — the user fixes those in the map. `leftover_datasets` lists the datasets the attach left unreferenced (the raw upload when it was re-uploaded; the empty factory layer of a 'Culvert 01' created here), each {dataset_pk, name, reason}, with a `leftover_hint`; the tool deletes nothing — the user may delete them. The culvert engine conveys flow through each culvert in a run (GPU lanes and localhost; the multi-core CPU lanes refuse a culvert scenario). `outcome` is exactly one of: `attached` (row_id, gn_layer, dataset_pk, dataset_alternate — the WFS typename — and every row id seen); `timed_out` (still importing or still creating the culvert layer: call again with the same arguments, except pass `retry_execution_id` as execution_id when the result carries one); `upload_failed` (the execution record, incl. its log, is returned verbatim — fix the file and upload again); `no_default_row`; `no_dataset` (finished but no resource was recorded). The PATCH is refused with a 400 if the dataset is not owned by you. Refused, with no request made: kind `breakline` — no REST create path exists for it at HEAD (TASK-3040 AC6), so attaching one would only pretend. Also refused without a request: an execution_id that is not the UUID the upload returned. One GeoJSON per kind: all of a kind's features travel in that one file. A rainfall polygon names its gauge in its `data` property — create that gauge with create_time_series under the exact same name.

Showing the latest 10. Full history: list_changes · trend: quality JSON.

Checks run on what our credential-free, read-only probes observe; tools are never called and no code audit is performed. How it is computed.