Welcome, Guest
Username: Password: Remember me

TOPIC: NEGATIVE DETERMINANT in GEOELT: What to do?

NEGATIVE DETERMINANT in GEOELT: What to do? 12 years 1 month ago #5852

  • Lohr
  • Lohr's Avatar
Hello,

the output of telemac3d on the screen gives the following line:

"GEOELT: ELEMENT 32939 : NEGATIVE DETERMINANT"

The message comes directly after the message: END OF MEMORY ALLOCATION

The memory allocation runs normal.

I have no idea how to solve the problem.
Did someone have these message before and what is to do?

The output on the screen, *.cas, *.cli and *.slf files are attached.
Every hint is appreciated.

Thank you for your help
Hubert Lohr
Attachments:
The administrator has disabled public write access.

NEGATIVE DETERMINANT in GEOELT: What to do? 12 years 1 month ago #5854

  • pham
  • pham's Avatar
  • OFFLINE
  • Administrator
  • Posts: 1559
  • Thank you received: 602
Hello,

The problem must come from your mesh (or you mesh generator). Your element number 32939 seems to have three same vertices (#1, 1 and 1) so that your element is only a single node, and that is not allowed by bief library (please read subroutine GEOELT).

For my information, which mesh generator do you use?

Hope this helps,

Chi-Tuan
The administrator has disabled public write access.
The following user(s) said Thank You: Lohr

NEGATIVE DETERMINANT in GEOELT: What to do? 12 years 1 month ago #5857

  • Lohr
  • Lohr's Avatar
Hello Chi-Tuan,

thank you very much for your message.
The mesh has been generated by SMS. The format SMS is using for a mesh is *.2dm which can be imported by BlueKenue in order to transform it into a *.slf format.

The element 32939 seems to be a normal tria element according to a visual check in SMS and in BlueKenue (slf File).
Possibly, the problem came up due to the numbering of the nodes. Usually, SMS numbers the nodes either with the option "front width" or "band width". Both has nothing to do with counter-clock wise numbering. However, SMS can be forced to number the boundary nodes (and only the boundary nodes) counter-clock wise by using a nodestring which runs along all boundary nodes. Apart from that all other nodes numbered according to the usual way in SMS. The option for numbering in SMS is probably not that what is appropiate for a proper slf file, although it has worked in past with other meshes.
Now in the meantime, I gave up to go the direct way (importing 2dm mesh and creating slf file via BlueKenue). It works easier to export only the nodes as XYZ values from SMS and applying the triangulation option in BlueKenue.

Thank you again for your help which was very useful and directed me faster to a solution.
Best regards
Hubert
The administrator has disabled public write access.

NEGATIVE DETERMINANT in GEOELT: What to do? 12 years 1 month ago #5856

  • pham
  • pham's Avatar
  • OFFLINE
  • Administrator
  • Posts: 1559
  • Thank you received: 602
Hello again Hubert,

FYI, your element #92940 has the same problem as #92939 (forgotten to tell you in my previous post). I think you should generate another mesh and control its quality.

Regards,

Chi-Tuan
The administrator has disabled public write access.

NEGATIVE DETERMINANT in GEOELT: What to do? 12 years 1 month ago #5858

  • pham
  • pham's Avatar
  • OFFLINE
  • Administrator
  • Posts: 1559
  • Thank you received: 602
Hello Hubert,

Thanks for your answer. This helps me a lot to understand how other users manage to generate meshes.

I think (but have not tested) that if you edit array IKLE for element 32939 for every node, it should be written 1 thrice (IKLE is an array of dimensions NELEM x 3 which contains the number of nodes for every triangular element).
Just in case, even though it has not been maintained anymore, I used the old post-processor Rubens to quickly check this numbering. Maybe this is possible to do with BK. I let BK advanced users answer.

Best regards,

Chi-Tuan
The administrator has disabled public write access.
Moderators: pham

The open TELEMAC-MASCARET template for Joomla!2.5, the HTML 4 version.