open TELEMAC-MASCARET The mathematically superior suite of solvers

Dear Community,

We have noticed possible inconsistencies between the scalar and parallel configurations in the newer versions of Sisyphe. To illustrate this we have examined the official example "canal_solid_discharge_inflow" in version v8p2r1:

In the scalar configuration, sediment is supplied almost equally distributed across the nodes at the model inlet. This leads to the fact that the bed development also develops almost horizontally - which is the expected development. In parallel configuration (3 cores were used here), however, it appears that sediment is not added to the top node (node #7 in this case) at any time! This leads to an extreme deepening of the bottom there. However, since the total amount added remains identical, more sediment is added to the remaining nodes, leading to increased sedimentation there. A check of the variables in DISIMP.f also confirmed this.
The figure in the attachments shows the bed development (evolution) after 200,000 time steps (i.e. 20,000 sec real time) and the differences, which are extreme (units in the figures are in meters). In sum, there are deviations of up to 1.5m.


In simulations at a real area/river we conducted this problem led to the fact that the simulation in parallel configuration delivered absolutely unrealistic depositions at the inlet and finally crashed.

Has anyone else noticed these differences? What could be the cause of this?
A test with an older version of Sisyphe (v6p3) showed that there these problems did not occur.

Many greetings,
Markus

Dear Markus,

the problem of the validation example is in conlit.f. At the first time step the solid discharge at the boundary nodes 1-7 is set to 0.001. In case of parallel (NCSIZE.GT.1) the parallel node number is calculated (I=MESH%KNOLG%I(I)). But Q2BOR%R(K) is still using the boundary node number K of the seriell case. This means that in parallel case the boundary conditions are not set correctly.

The question is, if you have the same reason for the big erosion at the boundaries in your real river application??

Best regards,
Rebekka

Dear Rebekka,

thanks for comming back to this topic and your info. Unfortunately yes! We discovered this problem first in a big, realworld river model and we could not explain the strange development. Thus we went to this simpler example for further tests. I think it was just bad luck when the boundaries for the real world domain were initiated, since the issue is not present in many other cases. Maybe i find some time the next weeks to work on a solution.

But anyway, my colleagues you've met at the TUC last week, mentioned in GAIA this should not be a problem anymore?


Kind regards,
Markus