create_scenario

com.hydrata/hydrata-mcp-server · Verify this server

Create a DRAFT scenario (no build, no run) and report its mesh-triangle estimate. POSTs /projects/<id>/scenarios/ with the write fields, then GETs the scenario detail — the create response carries NO estimate; the detail's `mesh_triangle_count_estimate` (+ `_breakdown`) does. Returns a compact record: id, name, the FK ids as stored, resolution, duration, `computed_status` (`created` = no run yet), the estimate and its breakdown, and http_status. Next step: build_scenario (which asks for confirm=true above 100,000 triangles). Nothing is meshed or queued here. Units: `resolution` on the SCENARIO is a LENGTH in metres — ANUGA maximum_triangle_area = resolution²/2 (run_utils.py:227/:290; FloatField default 100, not nullable; 0 makes the estimate None) and the same value becomes the raster cell size; a MeshRegion FEATURE's `resolution` is consumed by the mesher as an AREA (max_triangle_area, m²) while the estimate prices it as a length, so attached regions mesh ~15x more than estimated (Towradgi 100/36/8 m² regions: estimate ~18k, mesh ~283k); the smallest MeshRegion value becomes the raster cell size. The server does NOT validate that the FK ids belong to `project_id` — pass the row ids attach_input_layer / get_terrain returned for THIS project. Every FK is nullable at create time, and the build fails later on a scenario with no terrain, or with neither an inflow nor a rainfall. A `boundary` whose row has no features (the default 'Boundary 01' before attach_input_layer) is accepted here and refused by build_scenario. The estimate is None when resolution is 0; an estimate of 0 with a real boundary is a very coarse mesh, not an error.