SIGSEGV signal (forbidden memory area access) intercepted !

Hi all,

I'm having a little problem running a calculation with the user routines usdpst.F and usproj.F. When I don't include them in the calculation, all is working fine, but if I want to use one of them to define a post processing part or to obtain a pressure coefficient on a surface, I get the following error message :

---

SIGSEGV signal (forbidden memory area access) intercepted!

Call stack:
1: 0x41de6d <usdpst_+0x3d5> (cs14.exe)
2: 0x470700 <cregeo_+0x2a4> (cs14.exe)
3: 0x46824e <caltri_+0x53e> (cs14.exe)
4: 0x41f5ea <main+0x79a> (cs14.exe)
5: 0x7ffcba88e1c4 <__libc_start_main+0xf4> (libc.so.6)
6: 0x41d829 ? (?)
End of stack

Error running the calculation.

Check Kernel log (listing) and error* files for details


********************************************
Error in calculation stage.
********************************************

---

The geometry (and mesh) I'm using contains internal walls (I have an external rectangular domain, in which I have a cube with an opening on one of the faces, to obtain the ventilation in the cube). My external faces are defined as boundary regions, but the faces of the internal cube don't appear in listenv.pre, so I assumed I don't have to define them as boundary. Can this be the problem ?

I already ran several simulations using either usdpst, usproj, usvpst, ... without any problem.
I attach here the listing file.

Does anyone has an idea about what I can do to avoid this problem ?

Thanks in advance,

Alicia

Hello,

Issues in usdpst.F should be pretty rare (usvpst.F is more tricky, as values can be based on a subset mesh or parent mesh, interlaced or not, and inconsistent memory layout ant usage can lead to problems, but usdpst.F is much simpler and less error prone).

A possible issue would be a mix between loops on faces, boundary faces, or cells (ie. using getfbr instead of getcel or vice-versa, for example). Otherwise, you may have found a true bug, though this is less probable.

Could you post your usdpst.F code ?

You also add:

> The geometry (and mesh) I'm using contains internal walls (I have an external rectangular domain, in which I have a cube with an opening on one of the faces, to obtain the ventilation in the cube). My external faces are defined as boundary regions, but the faces of the internal cube don't appear in listenv.pre, so I assumed I don't have to define them as boundary. Can this be the problem ?

I am not sure I understand your configuration without a diagram, but listenv.pre should give you a summary of both interior an boundary faces belonging to a certain group (assuming you defined groups).

In any case, If you have a configuration in which you have thin walls, the way they are handled in Code_Saturne (preprocessing step) is as follows:
- Faces having at least one different vertex are considered different (the vertex coordinates may be the same, its number must be different)
- Faces based on the same vertex are considered identical: such faces are merged, so if they initially appeared as boundary faces, they may end up as interior faces if they have a cell on each side. If a group is assigned to faces supposedly on the boundary but appears in listenv.pre on interior faces, this is probably the case.

Hoping this helps.

Best regards,

Thank you for your quick and useful reply !

Actually I wanted some faces to be boundary faces but they were seen as internal faces. I changed the geometry to have a connection between these faces and the outside of my domain, and now it's ok.

But while preprocessing my .unv mesh, saturne assign for each group a family and a color, and usually creates a family for all the volumic cells. Here I get another family (plus the ones for my groups and for the cells), with boundary faces AND internal faces... I can't figure out what part of the domain it refers to. I think this is the cause of an error I get when running the calculation :
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@
@ @@ WARNING: ABORT BY BOUNDARY CONDITION CHECK
@ ********
@ INCORRECT OR INCOMPLETE BOUNDARY CONDITIONS
@
@ Value of type ITYPFB for boundary conditions must be
@ greater or equal to 1
@ and less than or equal to 200
@ One or more errors are listed above.
@
@ The calculation will not be run.
@
@ Verify the boundary condition definitions in the
@ appropriate user subroutine.
@
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

All my boundary conditions are defined with the GUI, when I import group from preprocessor listing I have only the families corresponding to the groups I create in my geometry.

Moreover I still get the error with SIGSEGV signal intercepted when trying to run the calculation with either usdpst or usproj.

I don't know if I'm clear here...
I attach my files (listing, listenv.pre, usclim, usiniv, usproj, usdpst, and screenshots of my geometry), so maybe you have an idea of what I'm doing wrong !

Thanks again for the help !!

Alicia

sorry for the wring attachment (twice the same without geom screenshots)

here's the right one

Hello,

To determine where the interior faces of color 7 are, you may run the preprocessor with the --fac-int option (maybe it was -fac-int in version 1.4, I'm not sure).

This option is also available using the GUI as an "interior faces" option in the mesh verification tab if I remember correctly.

Using this, an additional part (or mesh in the MED file) is generated by the Preprocessor in verification mode, and you can use a postprocessor (whether SALOME's VISU or a more powerful tool such as ParaView or VisIt) to see where those faces are.

In any case, I believe I have the explanation for your crash using usdpst.F: line 355, you loop on the number interior faces (NFAC) instead of boundary faces (NFABOR) to build a list of boundary faces. Replacing NFAC with NFABOR here should help.

As for your undefined boundary conditions, listenv.pre seems to indicate that 318 boundary faces of color 7 belong to no named group (family 2). To see where they are, you would need to compare the different areas when postprocessing the Preprocessor verification output, or under SMESH, build a new group containing all boundary faces minus those in other groups to see where they are (in Code_Saturne 2.0, when boundary faces have no boundary condition, a postprocessing output is generated automatically to help locate them, but older versions such as the pre-1.4 in CAELinux only give you a list of face numbers, which is not very useful as the numbering is usually different from the one in the mesh file).

Best regards,

Yvan Fournier