PETSC error; Segment violation

[albisb]

Hi all,

I am trying to run a custom geometry (meshed using blockMesh) in DAFoam but for now I am trying only "runPrimal" option. When trying to run the mesh, I got the issue attached in the end of the message. I have seen similar issues in the forum but they didn't seem to sort out my problem. About my case:

• Latest DAFoam v3.0.7
• I took incompressible NACA0012 tutorial case, created a custom mesh with blockMesh and tried to run it with the runScript.py but changing the default run mode to "runPrimal". I also modified the patch name in the definition of CD and CL although I'm only doing forward run for now. I didn't modify system or constant files.
• I'm running it in redhat linux through a docker image
• The same mesh runs without an issue with simpleFoam
• I am not using "empty" boundary conditions. According to FAQs, I don't expect to be using any non-supported BC (I'm using fixedValue, symmetry, slip, zeroGradient, inletOutlet, calculated for nut)
• The mesh is about 70k cells
• While running it, memory consumption when executing "top" doesn't seem to be an issue
• I have successfully run a couple of tutorials, including the incompressible NACA0012
• I get the same error when running on serial (so, python runScript.py, without mpirun)

Do you know what the issue may be?

I also attach the full log in the message.

Thanks in advance

-----------------------------------------------------------------------------------------------
Checking if we need to compress the mesh files
Checking if we need to compress the mesh files
#------------------------------#
 Total Volume Nodes :    144490 
#------------------------------#
I/O    : uncollated
+-------------------- Symmetry Planes -------------------+
|           Point                        Normal          |
| (  0.000   0.000   0.000)    (  0.000   0.000   1.000) |
| (  0.000   0.000   0.100)    (  0.000   0.000   1.000) |
+--------------------------------------------------------+
#--------------------------------#
 Unique Surface Nodes :      1612 
#--------------------------------#
 Computing Denomenator Estimate...
 Load Balancing...
[a2ec778e056f:02022] 7 more processes have sent help message help-mpi-btl-base.txt / btl:no-nics
[a2ec778e056f:02022] Set MCA parameter "orte_base_help_aggregate" to 0 to see all help / error messages
 Finished Mesh Initialization.
OrderedDict([('bottom', [0]), ('inlet', [1]), ('left', [2]), ('outlet', [3]), ('plate', [4]), ('procBoundary0to1', [5]), ('procBoundary0to2', [6]), ('procBoundary0to3', [7]), ('right', [8]), ('top', [9]), ('allSurfaces', [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]), ('allWalls', [0, 4, 9]), ('designSurfaces', [4])])
[2]PETSC ERROR: ------------------------------------------------------------------------
[2]PETSC ERROR: Caught signal number 11 SEGV: Segmentation Violation, probably memory access out of range
[2]PETSC ERROR: Try option -start_in_debugger or -on_error_attach_debugger
[2]PETSC ERROR: or see https://www.mcs.anl.gov/petsc/documentation/faq.html#valgrind
[2]PETSC ERROR: or try http://valgrind.org on GNU/linux and Apple Mac OS X to find memory corruption errors
[2]PETSC ERROR: configure using --with-debugging=yes, recompile, link, and run 
[2]PETSC ERROR: to get more information on the crash.
[2]PETSC ERROR: Run with -malloc_debug to check if memory corruption is causing the crash.
[4]PETSC ERROR: ------------------------------------------------------------------------


[optLog.txt](https://github.com/mdolab/dafoam/files/12673801/optLog.txt)

[friedenhe]

The names in your primalBC-patches are not consistent with those defined in constant/polyMesh/boundary. We have just updated the DAFoam repo so that it will print out an error if this happens.a649d7e

[albisb]

Thanks, that worked. I had not considered that possibility since simpleFoam was going through.

[albisb]

Hi all,

I have more problems with this test case. I am testing the geometry, with a mesh generated with blockMesh, but when trying to make a runPrimal test, the case crashes even before starting with a "Primal solution failed for the baseline design", which I understand is a consequence of very poor mesh quality as reported in the log:

---

Starting time loop

Checking mesh quality for time = 0
Overall domain bounding box (-2.007490311658399 -3 0) (6 3 0.07500000000000002)
Mesh has 3 geometric (non-empty/wedge) directions 3{1}
Mesh has 3 solution (non-empty) directions 3{1}
Boundary openness (-9.282762132353522e-18 4.84950964601285e-18 -4.703915757429302e-16) OK.
***High aspect ratio cells found, Max aspect ratio: 1.965932450558755e+97, number of cells 188
<<Writing 188 cells with high aspect ratio to set highAspectRatioCells
Minimum face area = 9.218305745488083e-08. Maximum face area = 0.005741687780815459. Face area magnitudes OK.
***Zero or negative cell volume detected. Minimum negative volume: -1.402638214859792e-05, Number of negative volume cells: 188
<<Writing 188 zero volume cells to set zeroVolumeCells
Mesh non-orthogonality Max: 179.0784049812238 average: 15.66842655423797
*Number of severely non-orthogonal (> 70 degrees) faces: 242.
***Number of non-orthogonality errors: 372.
<<Writing 614 non-orthogonal faces to set nonOrthoFaces
***Error in face pyramids: 1121 faces are incorrectly oriented.
<<Writing 779 faces with incorrect orientation to set wrongOrientedFaces
***Max skewness = 20.75493277494445, 7 highly skew faces detected which may impair the quality of the results
<<Writing 7 skew faces to set skewFaces
Coupled point location match (average 0) OK.

Failed 5 mesh checks.

+------------------------------------------------------------------------------+
| pyDAFoam Error: Primal solution failed for the baseline design! |
+------------------------------------------------------------------------------+

---

However, the same mesh has been run in simpleFoam, and checkMesh (independent of DAFoam) shows good mesh quality:

---

Checking geometry...
Overall domain bounding box (-2 -3 0) (6.000000000000001 3 0.07500000000000002)
Mesh has 3 geometric (non-empty/wedge) directions (1 1 1)
Mesh has 3 solution (non-empty) directions (1 1 1)
Boundary openness (2.209107144101079e-20 -1.336288911466743e-17 1.978288153984782e-13) OK.
Max cell openness = 2.911996123318899e-16 OK.
Max aspect ratio = 3.986970223911959 OK.
Minimum face area = 0.0005479880949186633. Maximum face area = 0.002264004752941285. Face area magnitudes OK.
Min volume = 4.10991071189003e-05. Max volume = 6.790763429639231e-05. Total volume = 3.596249999999756. Cell volumes OK.
Mesh non-orthogonality Max: 4.990050541245304 average: 1.109847119746527
Non-orthogonality check OK.
Face pyramids OK.
Max skewness = 0.1314130984486241 OK.
Coupled point location match (average 0) OK.

Mesh OK.

---

I suspect that when IDWarp gets the mesh it destroys it for some reason, but didn't find a reason why. Also, the bad mesh quality elements that are stored in postProcessing have a completely different shape to the geometry I am testing.

Do you have any tip for this situation?

Thanks in advance

[albisb]

As an addition, I am running this case with FFD, and I already checked the FFD box contains the whole geometry in the 3 directions

[albisb]

Hi all, I found a solution to this problem. To my understanding, the FFD box should contain the geometry, which I understood that also for a "2D" geometry, it should protrude laterally from the domain. I tried adjusting the FFD lateral limits to the exact limit of the domain and now it works.