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?

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

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 reaching out.

It looks like the STANDARD boundaries in_flow1 and in_flow2 are defined inside the mesh domain, please know that STANDARD type boundary only applies at domain boundary and make sure the geometry setting is correct.

Regards,
Zhiling

However, while running some tests and looking at the influence of the initial conditions, I noticed that if I increase the slope, at the same flow rate, the issue of high inlet velocities is progressively reduced.
That said, this solution is not very realistic in practice. Do you have any other ideas or suggestions?

However, when I try to run the flood hydrograph, everything works correctly up to a certain point (around 16,800 s out of a total of 60,000 s), where there is a sudden increase in the inflow velocities (from 4 m/s to 8–10 m/s), and I don’t understand why. Could this be a problem related to the morphology of the inlet section?

Thank you for your help.
Debora

If I want to simulate a bridge with piers and possible backflow, where do you recommend I put the upstream and downstream conditions in an h-q relation? I would like to simulate the piers with weir.

I'm using the V4 release.

What do you think?

Thanks

If you only want to impose rainfall via a source term, then the SOURCE block would be the way to go. The uniform_in and uniform_out standard boundary conditions are typically used to impose in- and outflow of rivers.

The 'type' specifies the unit of the value in 'data' or the value time series in 'file'. The unit of 'type' = 'total' is m3/s, whereas 'type' = 'distributed' results in units of mm/h. So in your case you add 200 m3/s to the Settlement region. But without further information I cannot say why you get en error when you remove the in- and outflow boundaries.

Best regards,
Matthias

I don't see an issue with the boundary condition.  I cannot help you out without further details on what the problem is. Does the model crash even with safe mode off?

Best regards,
Matthias

So the simulation crashes with safe_mode off or do you just get mass balance errors without crash? I cannot guess where the mass balance problems originate without further info on the simulation setup.

Best regards,
Matthias

looks like the python package h5py is not available on your system.
Try (re)installing it with something like

 pip install h5py 

The correct command depends on your system and python environment, please check out https://docs.h5py.org/en/stable/build.html#install to find the correct one.

Does this solve your problem?