I don't know how far this already has been addressed, but I'd like to suggest "intelligent" boundary conditions.

Background: In several projects we had to evaluate scenarios where boundary conditions like gates or weirs had to be regulated dynamically not only dependent on the water level right at one specific stringdef but also dependent on multiple. For example retention regulations like Q = minimum(threshold minus Q_river1 minus Q_river2, Q according to depth-discharge relation, Q_emergency, etc.) would be very handy.

A first version of this could be the linking of multiple regulations to one boundary and dynamic evaluation.

Let me know if you need further examples or if you are interested in a collaboration for development.

Cheers, Sam

As of now, this is my approach:

1. run a simulation to evaluate when the obstruction is happening, e.g. due to wood debries I have a reduction of the available area at 80%: when the wet area on the stringdef upstream of the bridge is 80% of the initial I consider the bridge as obstructed. Let's assume this time to be t = t*

2. run a second simulation starting at t=t* (not a restart, but a re-run) using another "model.json" file where I insert a wall internal boundary condition

By doing this, my results.h5 file will be updated by the simulation having the internal wall.

The drawbacks of this method are:

1. I am overwriting the result from t=t* to the end of the simulation, thus making it impossible to see the partial outputs, i.e. to generate progressive xdmf files to check the progress of the simulation

2. the height of the wall is infinite, thus I cannot simulate the bridge being overflown; this is precautionary which works fine for me, but it might not be ok for everyone else

My feature request would be to have the possibility of inserting an obstacle of given height at a given time. It would be ideal to have something like a dynamic weir with adjustable height in time. With such a feature I could run the first simulation and then a second one, where a weir of given height would "appear" at a given time.

I have been using Basement since 2014. This is a feature request regarding saving hydraulic data at probe locations.
In basement, one is required to give the cell no in which probe is located. However, probe locations are known by
its x,y coordinates and not cell no. This requires the user to determine the cell no in which probes are located.

It is requested that instead of cell no , (x,y) coordinates be fed as input to determine the probe locations internally
by basement itself.

regards

I think a major issue of BMv3 at the moment is the absence of an internal boundary condition for sediment transport.

It would be very nice to have a sort of equilibrium_in transport condition to link two cross-sections, i.e. an internal condition linked to the hydraulic onem which allows for sediment to be transported downstream of a structure!

Best,
Matteo

Thanks, Michel

In model.json, within the HYDRAULICS block, it is possible to track flood-variables with the statement:

"FLOOD": {
    "tracking_timestep": 300.0
}

Then the results.h5 container contains a dataset at RESULTS/CellsAll/FloodVar with flood arrival time, the maximum water depth, flow velocity and specific discharge.

The per time-step data (RESULTS/CellsAll/HydState) on the other hand contains water surface elevation, specific discharge in x direction, qx  and specific discharge in y direction, qy. From the later two it is possible to calculate flow-direction and draw some nice flow arrows.

So the feature request is to add qx and qy to the flood dataset.

Thanks, Michel

I'm a PhD student in Instituto Superior Técnico of University of Lisbon, in Portugal, and I've been using BASEMENT (v2.8) in order to estimate urban prone areas to flooding. For this purpose, I've been assuming strong simplifications regarding the interaction with the underground drainage network, which plays a crucial role in the regulation of urban floods.

As a PhD student, one of my goals is to give a step further in this matter and to be able to integrate and run simultaneously a 2D surface model (in this case BASEMENT) and a 1D drainage network model (such as EPA SWMM), with interactions between them.

I would like to ask if you have any interest on this and/or if you have any developments on this subject. I believe it makes no sense to spend time on doing something that is already developed with such quality as BASEMENT for the superficial flow simulation.

Looking forward to your feedback and hoping everything is going well on this unsteady phase we are going through,

Kindly regards
João Barreiro

Nowadays, lot of researchers are using the 2dSW-porosity model to calculate urban flooding.It runs about 2 to 3 order of magnitude faster than the conventional SW model. If possible, kindly make available the above feature in Basement.

Regards

I believe it would be useful for research purposes to remove the boundaries on the lateral_transport_factor to allow for rather high Ikeda parameters.

Thanks

Currently, the exit code when running basement in batch-mode is always zero (which means in unix-terms: success), although the program might have encountered an error.

When running multiple simulations this is not optimal, because it is harder to detect erroneous setups. So please use an exit code != 0 (e.g. 1) when basement encounters errors.

Thanks, Michel

- I have used the interpolate Z to node-tool using a Raster dataset in QGIS.
- My Model domain is slightly larger than the DEM-Domain.
- The node-values for the points outside of the DEM-Domain were given the value -999 for the elevation
- when exporting the 2dm from those z-values, the mesh domain is cut --> no mesh is created where nodes are -999

- Could you set this value to "0" or let the user choose how to treat it e.g. with an extrapolation method? Then we have the nodes still in the 2dm file even if their elevation is not interpolated.

Thanks a lot and best regards!
Matthias

is there any chance in near future to develop a technique for 1D coupled network in which we can model four channel junction.

regards