open TELEMAC-MASCARET The mathematically superior suite of solvers

Bonjour,

Je travaille sur des ruptures de digues. Pour cela, j'impose dans mon modèle un hydrogramme de brèche sur ma frontière amont (point de rupture). Quand je lance la simulation, celle-ci s'arrète en cours (elle se lance bien sur quelques pas de temps) malgré avoir crée artificiellement une "cuvette d'eau" en pied de la frontière amont pour ne pas être à sec. Il s'agit vraissemblablement d'un problème de régime torrentiel sur ma frontière amont. J'ai lu que la solution pourrait être d'imposer une hauteur d'eau non nulle sur cette frontière pour toute la simulation. Le problème est qu'avec fudaa, il ne peut être imposé qu'un hydrogramme ou une auteur d'eau en entrée mais pas les deux...
Une idée pour résoudre ce problème ?

En vous remerciant par avance,

Hi,

I'm working on dams break. I impose a hydrograph as upstream boundary with fudaa and when running the simulmation, it stops with the error attached.

It's maybe because of the torrential flow at the boundary, even if I have set a water level in the initial conditions. I have read the solution could be to impose a water level on the boundary during the whole simulation but I don't manage to do so. With fudaa, I can't impose both an hygrograph and a water level on the upsteram boundary...

An idea to resolve this error ?

Thanks

Hello,

You can bypass Fudaa by changing the boundary conditions file. Having both prescribed discharge and elevation is a line that starts with 5 5 5, instead of 4 5 5. Then you can edit also the steering file.
Other possibility: a deeper pond at the entrance, so that the flow remains fluvial ?
Cheers,

JMH

Hi,

I had the idea too to change the conlim file before this post but the result was the same... Maybe I did it wrong... But with a deeper and larger pond it seems to work. Thanks for the advise. I wouldn't fancy so a huge pond would be necessary to run it... I thought 1 m of water at the entrance would be the max rational and it's more than 2.5 m to run it...

Thanks again,

QGL