Pre-processor error

[zercs]

Hello everyone,

I'm new to Code Saturne and I have a problem with my first case.

So, Ubuntu is running in the VirtualBox installed from a CAElinux distributive.
I made a mesh and exported from Salome in the .MED format (see the screenshot below to see the groups of faces, etc.)
Then I run Code-SaturneWizard, build a case and I get an error when trying to check mesh:
"SIGSEGV signal (access to forbidden memory area) intercepted"

I already tried to modify the mesh many times, but that gived no result. I have no skill in using Code Saturne from the command line, so I'm using the GUI.

Any help will be highly appreciated!

Result of check:
(you can find the information about the version, case info etc here)

Code: Select all

/opt/saturne-2.0.2/cs-2.0/bin/cs_preprocess --in ecs_cmd -m 
/home/caelinux/cases/LOL10/MESH/mesh5.med --num 1 --ensight --case check_mesh 

  .------------------------------.
  |                              |
  |   Code_Saturne Preprocessor  |
  |                              |
  `------------------------------'

  ECS   version 2.0.2   (Sat 01 Oct 2011 12:26:01 PM NOVT)

  CGNS 2.5.5 file format support
  MED 3.0.3 (HDF5 1.8.7) file format support
  Reading of compressed files ('.gz') with Zlib 1.2.3.3


Case configuration
------------------

 Date                : Mon 29 Apr 2013 05:48:02 AM NOVT
  System              : Linux 2.6.32-34-generic
  Machine             : caelinux-laptop
  Processor           : Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz
  Memory              : 1906488
  User                : caelinux (caelinux)
  Directory           : /home/caelinux/cases/LOL10/LOL10/RESU

  Case name           : check_mesh
  Mesh file           : /home/caelinux/cases/LOL10/MESH/mesh5.med



Reading mesh from file in MED (EDF/CEA) format
----------------------
  Mesh file: /home/caelinux/cases/LOL10/MESH/mesh5.med


  Mesh name: mymesh

  Number of vertices                          :    62598
SIGSEGV signal (access to forbidden memory area) intercepted !

Call stack 
1: 0x7f08aa63984d (libhdf5.so.7)
2: 0x7f08aa621326 (libhdf5.so.7)
3: 0x7f08aa6f3381 (libhdf5.so.7)
4: 0x7f08aa7167bc (libhdf5.so.7)
5: 0x7f08aa6b18fa (libhdf5.so.7)
6: 0x7f08aa6b1df7 (libhdf5.so.7)
7: 0x7f08aa6b9208 (libhdf5.so.7)
8: 0x7f08aa6b9dd0 (libhdf5.so.7)
9: 0x7f08aa6ac6f3 (libhdf5.so.7)
10: 0x7f08aa69ee99 (libhdf5.so.7)
11: 0x7f08aa6a9eb6 (libhdf5.so.7)
12: 0x7f08aa3b5e09 (libmedC.so.1)
13: 0x7f08aa2d53cd (libmedC.so.1)
14: 0x7f08aa318be2 (libmedC.so.1)
15: 0x7f08aa318d59 (libmedC.so.1)
16: 0x430784 (cs_preprocess)
17: 0x40ebeb (cs_preprocess)
18: 0x409fd0 (cs_preprocess)
19: 0x7f08a9cbec4d (libc.so.6)
20: 0x404209 (cs_preprocess)
End of stack

[Yvan Fournier]

Hello,

Could you either post your mesh, to check if we can reproduce the error, or test it using a more recent version of Code_Saturne ?

Regards,

Yvan

[zercs]

Of course, here you are! Sorry I forgot to add it in the previous message.

[zercs]

And here is my study, in case someone will be so kind to check if there's an error

[Yvan Fournier]

Hello,

Version 3.0 of Code_Saturne reads the mesh correctly, or at least does not crash; I do reproduce the crash in version 2.0.

In any case, your mesh only contains 2D elements, and is missing 3D elements, so it is not usable by Code_Saturne (either you did not define a volume mesh algorithm, or that algorithm failed). You would not have had the error if your mesh had been complete.

So under SALOME, check that you have 3D elements(using mesh info) before exporting the mesh for use with Code_Saturne.

Regards,

Yvan

[zercs]

Hello Yvan,

Thank you for your help, it actually solved my problem. I applied a Nextgen 3D algorithm, deleted all the unnecessary submeshes, created faces groups and it worked!

But now I have an error in boundary conditions.
Can you take a look, just in case you'll find an error?
I attach the error and listing files, and a new mesh that passed the check.

Regards

Mesh: https://drive.google.com/folderview?id= ... sp=sharing

error.txt

(927 Bytes) Downloaded 179 times

listing.txt

(23.33 KiB) Downloaded 186 times

[Yvan Fournier]

Hello,

As written in the error file, you can visualize which boundary conditions were not defined using the error.med or error.ensight in files in the postprocessing directory of your results (if using ParaView with an EnSight file, do not forget the "extract blocks" filter to separate "correct" and "error" parts).

Regards,

Yvan

[zercs]

Hello Yvan,

I'm sorry for taking your time, but I'll be grateful for your help! I did as you said and I remarqued that the internal part actually generated an error. I created a group of faces for that part in the mesh and made it a wall in Code Saturne. Now after like 20 minutes of calculation I get an error:

Code: Select all

SIGFPE signal (floating point exception) intercepted!

Call stack:
   1: 0x7f8625fdd982 <cs_sles_solve+0x1752>           (libsaturne.so.0)
   2: 0x7f8625fdf58b <reslin_+0x15b>                  (libsaturne.so.0)
   3: 0x7f8626151180 <invers_+0x250>                  (libsaturne.so.0)
   4: 0x7f86260063d3 <codits_+0x14e3>                 (libsaturne.so.0)
   5: 0x7f8626191450 <preduv_+0x7d00>                 (libsaturne.so.0)
   6: 0x7f862617a241 <navsto_+0xe01>                  (libsaturne.so.0)
   7: 0x7f86261c3d25 <tridim_+0xa1b5>                 (libsaturne.so.0)
   8: 0x7f8625ff7875 <caltri_+0x5085>                 (libsaturne.so.0)
   9: 0x7f8625fd29e3 <cs_run+0x843>                   (libsaturne.so.0)
  10: 0x7f8625fd2cc5 <main+0x1f5>                     (libsaturne.so.0)
  11: 0x7f8622771c4d <__libc_start_main+0xfd>         (libc.so.6)
  12: 0x40a359     <>                               (cs_solver)
End of stack

I searched on the forum for the posts with the same problem and found some advices. I consulted the listing where it's written many times "Warning! Gradients non convergents". And that's quite strange because the mesh passes preprocessing quite well. I don't know what else can I change in that mesh. Maybe try higher parameters of segmentation for mesh?

Have you got an idea of what can be the source of a problem?

Here you can find the mesh, listing and all the Code Saturne study: https://drive.google.com/folderview?id= ... sp=sharing

Regards

[Yvan Fournier]

Hello,

The non-orthogonaity mesh quality criterion is very bad near edges of your mesh (almost 90°, which is the worst "assymptotic" value you can have). It is not always easy to build a mesh with better quality criteria, so although better is lower, up to 70 or 80 degrees in some areas should not crash the code, though it may reduce local solution quality, but 89 degrees is bad. And boundary cells are more sensitive to bad mesh quality than others...

You may want to try using a non-reconstructed gradient (least squares with extended neighborhood may work better with a low-quality mesh). Also, the steady algorithm is usually less robust than converging an unteady solution to steady state (though it is faster). Using an "unsteady" algorithm with local time step is a good compromise (in version 3.0, that algorithm is presented as the default steady algorithm variant).

If you use SALOME's "viscous layers" when building your mesh, you may have a better quality mesh.

Check this section http://code-saturne.org/cms/documentation/BPG of this web-site for other, more complete recommendations.

Also, if you are just starting with Code_Saturne, there is no good reason to use version 2.0 (especially an obsolete release 2.0.2, while bug-fix releases are at 2.0.7, though in this specific case, it probably would not make much of a difference). Version 3.0 is much improved.

Regards,

Yvan