|
[Sponsors] |
Parallel run crashes when trying to loop into faces of a patch |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
October 3, 2013, 16:10 |
Parallel run crashes when trying to loop into faces of a patch
|
#1 |
New Member
George D.
Join Date: Jan 2012
Posts: 2
Rep Power: 0 |
Hello everybody. I am trying to calculate a flux using an expression that is related to the value of pressure in 2 different patches of my domain.
To find the label of the patches, I am using: label patchID1 = mesh.boundaryMesh().findPatchID("side1"); const polyPatch& cPatch1 = mesh.boundaryMesh()[patchID1]; label patchID2 = mesh.boundaryMesh().findPatchID("side2"); const polyPatch& cPatch2 = mesh.boundaryMesh()[patchID2]; This works fine. Then: forAll(cPatch1, facei) { J.boundaryField()[patchID1][facei] = p.boundaryField()[patchID1][facei] - p.boundaryField()[patchID2][facei]; } While in serial this works perfectly, in parallel the solver crashes. the two patches have the same number of faces. Can anybody help me in this? I inspect that this is related to the communication of the processors but I am not sure how to fix it. Thank you in advance. |
|
October 4, 2013, 15:27 |
|
#2 |
Senior Member
Niels Gjoel Jacobsen
Join Date: Mar 2009
Location: Copenhagen, Denmark
Posts: 1,903
Rep Power: 37 |
Hi George,
I would suspect that the decomposition is such that you have different number of faces on the two patches on each processor. Try to investigate processor*/constant/boundary, and you will probably see that the number of faces on the two patches is not the same per processor. Another thing, which you might want to consider carefully, is that right now you assume a matching ordering of the faces. In general cases with might not be the case. Kind regards, Niels
__________________
Please note that I do not use the Friend-feature, so do not be offended, if I do not accept a request. |
|
October 4, 2013, 16:27 |
|
#3 |
New Member
George D.
Join Date: Jan 2012
Posts: 2
Rep Power: 0 |
Hi Niels,
Thank you very much for your response. Indeed it is the way you described it, however the option preservePatches in decomposeParDict doesn't seem to help. George |
|
February 10, 2014, 19:29 |
|
#4 |
Senior Member
Joachim Herb
Join Date: Sep 2010
Posts: 650
Rep Power: 22 |
Probably too late, but nevertheless: Both patches (side1, side2) have to calculated by the same processor. So I guess preservePatches just guarantees that each patch is calculated by one processor but not all together. You might be able to do the calculation for each patch on an (arbitrary) processor and then use Pstream::scatter to exchange the information between the processors.
|
|
February 11, 2014, 11:18 |
|
#5 |
New Member
NaiXian Leslie Lu
Join Date: Jun 2009
Location: France
Posts: 26
Rep Power: 17 |
Which OpenFOAM version are you using?
__________________
Cheers, Leslie LU |
|
February 11, 2014, 11:21 |
|
#6 | |
New Member
NaiXian Leslie Lu
Join Date: Jun 2009
Location: France
Posts: 26
Rep Power: 17 |
Quote:
Hi Niels, How does one get face IDs of a polyPatch? I've just posted a thread http://www.cfd-online.com/Forums/ope...-boundary.html and reading your comments I feel that you might have the answer. Thanks in advance!
__________________
Cheers, Leslie LU |
||
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
y+ and u+ values with low-Re RANS turbulence models: utility + testcase | florian_krause | OpenFOAM | 114 | August 23, 2023 06:37 |
error in parallel run | immortality | OpenFOAM Running, Solving & CFD | 7 | January 1, 2013 14:35 |
[blockMesh] Cyclic BC's: Possible face ordering problem? (Channel flow) | sega | OpenFOAM Meshing & Mesh Conversion | 3 | September 28, 2010 13:46 |
Problem with rhoSimpleFoam | matteo_gautero | OpenFOAM Running, Solving & CFD | 0 | February 28, 2008 07:51 |
Multicomponent fluid | Andrea | CFX | 2 | October 11, 2004 06:12 |