I'm running BASEMENT v4.2.0 on Ubuntu 22.04 (GUI)

Setup:
- OS: Linux (Ubuntu), locale en_US.UTF-8 / LC_NUMERIC=ja_JP.UTF-8
- BASEMENT v4.2.0, installed binaries in /usr/bin/BMv4_*
- Test case: TestCases/1_H_CDB_Benchmark/BMv4/10k (circular dam-break benchmark)
- The same test case (same files) runs successfully on Windows with the GUI.

Steps to reproduce on Linux:
1. Open the test case folder in the BASEMENT GUI.
2. GUI correctly displays the contents of model.json.
3. Click "Write".

Result in GUI:
STDOUT : BASEMENT v4.2.0 (v4.2.0)
STDOUT : BASEHPC setup binary
STDERR : -> no model definition found
STDERR : -> ... unfortunately BASEMENT is killed!

However, running the setup binary directly from the command line in the same folder works perfectly when the model file is passed with the -f flag:

/usr/bin/BMv4_BASEHPC_setup -f model.json -o setup_test.h5

-> completes successfully, "BASEMENT successfully processed all necessary jobs!"

But running it WITHOUT -f (i.e. model.json as a positional argument) fails immediately with:

PARSE ERROR: Argument: model.json
             Couldn't find match for argument

Could you please check how the Linux build of the GUI constructs the command line for BASEHPC_setup?
It looks like a Linux-specific packaging/argument-passing bug rather than a model.json compatibility issue.

Happy to provide more logs or test further if useful.

Thanks,
Maxim

We are pleased to announce the release of BASEmesh version 2.3.0. You can install and upgrade to the new version directly using pip or ifyou use QGIS plugin, simply upgrade in plugin manager.

Key Changes:
- The new version performs large meshing and cleaning up drastically faster than before (~1 sec run time now for a previously ~1 hour task).
- Elevation looking up from a mesh is also much faster now (~12x faster)
- Fixed nodestring ordering for bent or zigzagging line strings, which could previously result in incorrectly ordered nodestrings.
- Breaking change for Python users: the deprecated basemesh.basechange import path is gone. Use import basechange instead.

For QGIS Plugin users:
- The progress bars now work normally and show what's happening;
- Fixed a bug where some valid elevation mesh layers didn't show up in the Advanced Interpolation tab;
- Linux builds of the plugin now include the same compiled speed-up as Windows.

Other changes:
- BASEchange: fixed the last cross-section of a CSV/tabulated channel not picking up the template's default values, unlike every other cross-section in the channel.

Kind regards
The development team of BASEMENT

Thanks for the specification. I think this is feasible and hopefully, we can include this in the next release.

Best regards,
Matthias

I'm having problems with my model using BASEHPC:

I'm facing the problem, that when modelling bridges and large culverts with h-Q relations (linked boundaries) i have big differences in the upstream and downstream water depth. This is to be expected with "no_momentum" but i also tried the other types.

While this wouldn't be as big of a problem for one linked boundary, in my model domain i have multiple in short succession occurring bridges/culverts, resulting in a really strange longitudinal water surface elevation profile along the river.

Regarding mesh quality: i have a really high resolution DEM, i implemented max_area of my cells at and around the boundary at 0.1 or 0.2. So this shouldn't be the problem.

For h-Q i used normal depth flow calculations, which are obviously quite sensitive to chosen slope and roughness value....

Is there a "BEST" approach to minimize or even eliminate these jumps in water depth/water surface elevation?

And what is the best way to implement h-Q relations when using BASEHPC? Like sort of a checklist on important things when creating the h-Q relations.

*EDIT:
In BASEMD there's the Gate boundary, why is this not implemented in BASEHPC?

Equilibrium transport capacity refers to the transport capacity calculated with the selected bedload formula type (e.g., MPM). What this actually does for the transport_capacity boundary condition in each time step:

1. Calculate the cumulative transport capacity Q_b over the boundary based on the transport capacity in each cell that borders that boundary
2. Calculate a specific transport capacity over the boundary by dividing by the nodestring length q_b = Q_b/L
3. Set the flux at each edge of the boundary to q_b

In this case, the hydraulic state just refers to the flow velocity and depth in the cells along the boundary.

For cases where the transport capacity varies strongly along the nodestring/boundary, this might result in deposition in cells along the boundary where the transport capacity is much smaller than the specific transport capacity q_b. If you want zero sediment transport over the upstream inflow boundary, you can simply not define a upstream boundary condition in the BEDLOAD block.

Best regards,
Matthias

This will be fixed in the next release! Thanks for the bug report.

Best,
Matthias

The elevation interpolation tool of BASEmesh allows to use multiple elevation sources, i.e. combination of DTM and elevation meshes. You could create a local elevation mesh in the regions where you want to overwrite the DTM elevation with other elevation information. Using lines and points directly is not possible at the moment.

Best regards,
Matthias

Thanks for the suggestion. I'll see if we can implement this.

Best regards,
Matthias

I guess you were able to answer this question in the meantime, but for future reference: This is typically done via the EXTERNAL_SOURCE block and using material indices, as you did in the model setup described here: https://forum.basement.ethz.ch/viewtopic.php?id=5590#1.

Best regards,
Matthias

The first point I would check is the CFL number. A value of 1.0 is generally too high and can reduce numerical stability. I suggest using 0.95 or lower.

Rainfall-runoff simulations can also become challenging when very shallow flow occurs over steep or irregular terrain. Some of the warnings appear in cells with relatively steep slopes, for example around 0.4. The mesh warning about very small elements should therefore also be investigated using geofile_Grid.err.

A limited number of isolated negative-depth warnings does not necessarily mean that the overall simulation results are invalid. I suggest checking the total mass balance at the end:

total rainfall input = total outflow + water stored in the domain + numerical mass error

This provides a better indication of whether the warnings materially affect the results.

Is there a particular reason you are using BASEMD instead of BASEHPC? BASEHPC is usually considerably faster. However, we recently identified that its current solver is not always sufficiently accurate for very shallow flows over irregular terrain. The next release, which is planned for the coming weeks, will include a solver specifically implemented for rainfall-runoff simulations.

Best regards,
Matthias

Could you send me a minimal model setup to my email? I'll try to have a look.

Best regards,
Matthias

At the moment, BASEMENT does not support running a single simulation on multiple GPUs, so there is no additional YAML or simulation.json setting for this.

GPU memory usage is determined by the problem size and enabled features, such as the number of mesh cells and sediment grain classes. Having more GPU memory available than the simulation requires will therefore not improve performance. Similarly, GPU utilization may remain below 100% depending on the model setup and computational workload.

Best regards,
Matthias

Thank you for your answer.

Yes I know which presentation you are referring to. The presenter mentioned that the clogging occurred when a given wetted area was reached. Then I assume the wetted area is limited to the area with clogging. I was however not able to get the answer to how he effectively implemented a constraint to the wetted area in the "after clogging part" of the BASEMENT modelisation, i.e. how one can limit the wetted area to a given value at a given place in the model.

Thanks for raising those issues. If you send us the modified code, we will gladly evaluate to include it the improvements in the official version and will have a look at issues 1. and 2.

Best,
Matthias