|
[Sponsors] |
ParMETIS / intel MPI run time issue since 7.2 |
![]() |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
![]() |
![]() |
#1 |
New Member
Join Date: Apr 2021
Posts: 6
Rep Power: 5 ![]() |
Hello,
I face trouble having a working parallel installation of SU2 version 7.2 and 7.3 with intel MPI (19 or 21). The problem shows up at run time from the ParMetis with execution errors: PARMETIS ERROR adjncy is NULL.We did not encountered such a problem in previous build (7.0 and even 7.1), with the same (INTEL) MPI libraries. Any idea of where this issue could come from ? Any change in ParMetis coming with SU2 between 7.1 and 7.2 ? Thanks in advance for your help! Gérald |
|
![]() |
![]() |
![]() |
![]() |
#2 |
New Member
Cherith Lavisetty
Join Date: Jan 2023
Posts: 7
Rep Power: 3 ![]() |
I am getting the same error for higher order triangular elements, as the node ordering is different the way gmsh does and SU2 interprets, so i changed the order of nodes for connectivity but now i am getting a segmentation fault donno why, could anyone suggest a way to solve this...
|
|
![]() |
![]() |
![]() |
![]() |
#3 |
Senior Member
bigfoot
Join Date: Dec 2011
Location: Netherlands
Posts: 596
Rep Power: 17 ![]() |
so does the exact same setup work for you for lower order elements? Can you make the 2 cases available,
1. working setup with linear elements 2. same setup with nonlinear elements crashing I personally do not know too much about this implementation, but it will definitely help to have a practical problem to look at and to be able to reproduce it. |
|
![]() |
![]() |
![]() |
![]() |
#4 |
New Member
Cherith Lavisetty
Join Date: Jan 2023
Posts: 7
Rep Power: 3 ![]() |
So the issue was that lets say there is a second order triangular element, when we solve a problem in FEM the number is like
3 65 142 right , but when we output a mesh from gmsh it numbers it as 6 45 123 . And it messes up the type of element it mentions in the file, instead of giving out the element type to be 109 which is the reference for a 2nd order square element it gives out 28 and even for the boundary markers it gives out something else. So these things when SU2 tries to read the mesh becomes a problem and we get the connectivity problems. It would be a lot easier if someone could fix the code in gmsh to give out the right mesh configuartions for higher order meshes. |
|
![]() |
![]() |
![]() |
Tags |
parmetis mpi 7.2+ |
|
|
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
Postprocess: sampleDict works but creates no output folder | shock77 | OpenFOAM Post-Processing | 14 | November 15, 2021 08:27 |
[blockMesh] Issue with mergePatchPairs | JohnnyMercu | OpenFOAM Meshing & Mesh Conversion | 1 | May 30, 2021 00:24 |
laplacianFoam with source term | Herwig | OpenFOAM Running, Solving & CFD | 17 | November 19, 2019 13:47 |
pimpleDyMFoam computation randomly stops | babapeti | OpenFOAM Running, Solving & CFD | 5 | January 24, 2018 05:28 |
Micro Scale Pore, icoFoam | gooya_kabir | OpenFOAM Running, Solving & CFD | 2 | November 2, 2013 13:58 |