open TELEMAC-MASCARET The mathematically superior suite of solvers

Hi,

I am still dealing with a quite big mesh for flood wave modelling. Since I extended the mesh again, I have problems with Telemac 2D reading the boundary condition file. In parallel, T2D gives me the error:


| THE INPUT FILE ASSUMED TO BE 2D
|
| THERE ARE 1 TIME-DEPENDENT RECORDINGS
|
| ELEBD: ERROR AT POINT: 4
|
| THE BOUNDARY POINT: 38904
|
| DOES NOT BELONG TO ELEMENT : 0
|
| POSSIBLE REASONS:
|
| THE BOUNDARY CONDITION FILE IS NOT
|
| RELEVANT TO THE GEOMETRY FILE
|
| OR THE MESH HAS A WRONG TOPOLOGY
|


But in the conlim file, the boundary point 38904 has NOT number 4 (!!):

2 2 2 0.000 0.000 0.000 0.000 2 0.000 0.000 0.000 459925 38904 [/color] #
2 2 2 0.000 0.000 0.000 0.000 2 0.000 0.000 0.000 442860 38905 #
2 2 2 0.000 0.000 0.000 0.000 2 0.000 0.000 0.000 463428 38906 #

If I try the simulation single core, I get the SIGSEGV Segmentation fault error….

Why is T2D pretending, that the boundary condition file is wrong if it isn’t?

Many thanks,
Gabi

p.s.: V7p1r0 and V7p1r1 give the same error

Hi Gabi

You mentioned you extended the mesh. Did you generate the boundary condition file from scratch after that?
Which tool did you use to extend your mesh and how do you do that?
Could you join the files in order to allow us to check?

Regards

Hi Cath,

I extended the mesh using BK. The new part is an existing SMS-mesh from another project (new mesh 30 km river plus up to 5km width because of flood plains ).

I wpuld be happy, if you check the mesh, but the slf has approx. 18MB and is far to big for the Forum

In the mean time I checked the mesh and the conlim file again using Fudaa and using the option renumbering of the mesh I got less boundary points in the renumbered fudaa conlim file then in the BK file. Fudaa found no errors in the slf file.


But it did not solve the problem – I have a new error in T2D


INBIEF (BIEF): NOT A VECTOR MACHINE (ACCORDING TO YOUR DATA)
STOSEG: WRONG MESH
FACE 1
OF ELEMENT 899987
IS NOT WELL ORIENTED
(POINTS 459925 AND 463428 )

PLANTE: PROGRAM STOPPED AFTER AN ERROR
RETURNING EXIT CODE: 2

I cannot see, why T2D has a problem with this specific node….

I attached the Screen shot, hope it works..

Many thanks,
Gabi

Hi Gabi

Sorry but I'm not Cath!

It could be interesting to know exactly how you proceed to build your new mesh and the conlim file to understand where the problem comes from...
The facts that FUDAA produce a new conlim file with less boundary nodes let me thought you made a wrong manipulation in BK. You could try to create a new selafin object in BK and drag and drop the previous mesh with "wrong" conlim in order to recreate a clean IPOBO array and then create again the conlim file.

About the not well oriented element, it's hard to explain the origin. Is this element located at the junction between both mesh?

I also noticed you have a node with more than 10 elements just near the element you highlighted. maybe the problems are linked...

Regards

Hi and sorry;

I tranfered the SMS mesh with a python script to a t3s-mesh and created the slf file in BK.
This procedure worked for the last two (smaller) meshes well.

That means, I have a (running) mesh and added the new part of the mesh via the submesh option in the BK mesher. That means, despite the python script, everything made in BK - also the conlim file

I just tried to create a new selafin in BK and drop the t3s file and generate a new conlim file - it has again the 38906 nodes like before and not the 38903 than the fudaa conlim file ...

I know about the 10 elements, but the maximum number is 11 and in my experience it should work - remeshing the whole mesh with all the breaklines and islands (riverbanks, streets, houses...) is no Option

And the problem element is not in the junction..

Many thanks,
Gabi

Even the file is too big for the forum, could you share it with another platform?
I'm curious about the problem you encountered...

You could maybe try to check the mesh with stbtel, this will normally solve the problem of wrong mesh.

Regards

Hi,

maybe you can check the direction of the node numbering of the element. I'm not sure if Telemac cares about the direction, but most mesh tools need a counter clockwise numbering of the mesh elements.

Best regards,

Leo

Hi Leo,

thanks for the hint, but all elements are counter clockwise numbered.

Best regards,
Gabi

Hi Gabi,

Are you able to post (via an external link) your mesh. I have a whole bunch of open source tools that can do mesh processing (some include meshes created by SMS). I can take a look if you like.

Pat

Hi Christophe,
hi Pat,

thanks for the help, but after 4 times fudaa mesh check and 3 times stbtel check it is finally running (with the right number of boundary nodes).

I think it was a combination of factors telemac does not like: overstressed elements, more than 9.000 Islands, lots of breaklines,... and with the extension of the mesh it generated a Problem for telemac.

Best regards,
Gabi