Hi,
In the tutorial on impact studies (3.4), the data frame is modified to create a grid structure where each grid is assigned a different parameter level. This allows running all scenarios at once and comparing/plotting the results easily.
Do you have any recommendations on how to adjust this workflow in case input data already come in grids? We’re hoping to look at water flow between grids in our case study area, so we want to keep the grid structure and run all grids simultaneously. Perhaps it’s possible to have a 2D grid structure with (grid x parameter level) or something?
Just to clarify — the grid structure in tutorial 3.4 is a way to batch-run scenarios: each “grid” is really a copy of the same site with one parameter changed, so you can compare results easily. It’s not meant to represent real spatial grids.
If you already have gridded input data for a real study area, running multiple grids should be fairly straightforward — could you share a bit more about what your input data looks like and how it’s structured? That would help us give more specific guidance on how to set things up.
Also worth flagging: inter-grid water routing isn’t currently supported, so each grid runs independently. If that’s important for your study we should discuss what’s feasible.
Hi,
Thanks! I’m aware that the tutorial uses a fake grid structure by creating copies of the same site with modified parameters. But if I understand correctly, the resulting structure is the same as real spatial grids, which is why I’m a bit confused on how to use both simultaneously.
I have test data in 15 (3x5) 400x400 m grids in one of central neighbhourhoods of Gothenburg. The yaml file thus contains 15 sites, one for each grid, with different parameters in each grid depending on land cover fractions, geometry etc. To run an impact study as described in the tutorial, I removed all grids but one from the yaml file and ran the analysis on it.
Re: inter-grid water flow, Fredrik and I have talked to Sue and we’re waiting for the re-introduction of this feature. This is why I want to keep a grid structure (but also keep modifying parameters to run impact studies:).
Hi @Janka, good follow-up — I think the confusion is coming from the tutorial using a DataFrame-level approach that doesn’t map well to multi-grid setups.
The tutorial’s Part 1 creates scenario “grids” by concatenating copies of a DataFrame with pd.concat. This works as a shortcut for single-site studies, but when you already have 15 real sites in your YAML config, trying to layer scenarios on top with DataFrame manipulation gets messy — which is why you ended up stripping down to one grid.
The simpler approach: work directly with the config objects. Since your YAML already defines all 15 sites, you can load it, modify the parameter you want to sweep, and run — no DataFrame surgery needed:
from supy import SUEWSSimulation
results = {}
for alb_offset in [0.0, 0.1, 0.2]:
# fresh load each time — all 15 sites from your YAML
sim = SUEWSSimulation("gothenburg.yml")
# modify building albedo across all sites
for site in sim._config.sites:
site.properties.land_cover.bldgs.alb += alb_offset
results[alb_offset] = sim.run()
Each run preserves your full 15-grid structure, so when inter-grid water flow is re-introduced the spatial relationships are already in place. And you can combine this with the Part 2 pattern (forcing modification) in the same loop if needed.
The key point: the pd.concat approach in the tutorial is a convenience for the functional API. With the OOP interface and a YAML config, you work at the config level directly.