|
[Sponsors] |
reconstructPar fails due to missing procBoundary |
![]() |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
![]() |
![]() |
#1 |
New Member
Henning
Join Date: Sep 2020
Posts: 8
Rep Power: 6 ![]() |
Hi everyone,
I have run into a problem regarding parallel computing in OpenFOAM. As a background (I can't see how it would matter, but nevertheless..) I have set up a multi-region case where I have two solids and one fluid. I've written a script which does - in short - the following: 1. create background mesh from UNV file 2. decompose mesh with redistributePar 3. snappyHexMesh 4. create cell sets for regions 5. reconstruct mesh with redistributePar 6. surfaceToPatch 7. decompose mesh with redistributePar 8. ... 9. run case The step with surface to patch is neccessary in order to avoid creating a domain0-region, you can find a couple of post here regarding that problem. Surface to patch only runs in serial mode that is why I have to reconstruct the case again. Everything is working fine in serial mode, with 2 and also with 3 cores. But when I try to run it on 4 cases, step 5 - the reconstructing - fails with the message Code:
--> FOAM FATAL IO ERROR: Cannot find patchField entry for procBoundary3to0 Code:
Processor 0 Number of cells = 27324 Number of faces shared with processor 1 = 1188 Number of faces shared with processor 2 = 759 Number of processor patches = 2 Number of processor faces = 1947 Number of boundary faces = 3603 Processor 1 Number of cells = 27324 Number of faces shared with processor 0 = 1188 Number of faces shared with processor 3 = 759 Number of processor patches = 2 Number of processor faces = 1947 Number of boundary faces = 3603 Processor 2 Number of cells = 27324 Number of faces shared with processor 0 = 759 Number of faces shared with processor 3 = 1188 Number of processor patches = 2 Number of processor faces = 1947 Number of boundary faces = 3603 Processor 3 Number of cells = 27324 Number of faces shared with processor 1 = 759 Number of faces shared with processor 2 = 1188 Number of processor patches = 2 Number of processor faces = 1947 Number of boundary faces = 3603 So, the question is, is this a bug, which only happens in rare cases and has not been adressed yet, or is there another solution? I did only find this post but I already added the include statement. Thanks a lot and cheers Edit: replaced reconstructPar with redistributePar (which I was already using but I mixed things up posting this) Last edited by dasbrot; November 12, 2020 at 06:32. |
|
![]() |
![]() |
![]() |
![]() |
#2 |
Senior Member
anonymous
Join Date: Jan 2016
Posts: 416
Rep Power: 15 ![]() |
Hi!
You shouldn't be able to use reconstructPar after snappy. reconstructPar is only for field reconstruction, but since your mesh is changed (probably changed after snappy or snappy did nothing) you have to reconstruct the mesh too. You should use reconstructParMesh and then reconstructPar, or you can use simply redistributePar with the -reconstruct switch which will do the same but in one run. Also I have no idea how did you decomposed your case with reconstructPar, but you should decompose with decomposePar. |
|
![]() |
![]() |
![]() |
![]() |
#3 |
New Member
Henning
Join Date: Sep 2020
Posts: 8
Rep Power: 6 ![]() |
Hi simrego,
thanks for your answer! I'm sorry, I mixed things up, I'm already using redistributePar, editing my post now .. Thank you anyways, cheers! |
|
![]() |
![]() |
![]() |
![]() |
#4 |
New Member
Henning
Join Date: Sep 2020
Posts: 8
Rep Power: 6 ![]() |
In case anyone stumbles over this issue, it was already solved and answered here, but I did not find it before (e.g. in this post).
The error lies within snappyHexMesh, which overwrites the processor boundaries. For example, if the decomposing led to a boundary procBoundary0to1, snappyHexMesh would overwrite it to e.g. procBoundary0to2. So the reconstructing (and the cell set creation before) would fail due to the missing boundary. The solution to this problem lies in overwriting all the boundary files in the '0'-folder in all processor*-directories with empty files, e.g. for temperature Code:
... dimensions [0 0 0 1 0 0 0]; internalField uniform 300; boundaryField { #include "$WM_PROJECT_DIR/etc/caseDicts/setConstraintTypes" ".*" { type calculated; value $internalField; } } Code:
ls -d processor* | xargs -i cp -r 0.orig/* ./{}/0/ $1 cheers |
|
![]() |
![]() |
![]() |
![]() |
#5 |
New Member
Join Date: Mar 2022
Posts: 7
Rep Power: 5 ![]() |
Hi,
I had the same problem but your solution somehow didn't work for me. But I found the problem: I had: runParallel snappyHexMesh -overwrite in the script. After deleting the "-overwrite" flag, the error was gone. |
|
![]() |
![]() |
![]() |
Tags |
reconstructpar |
Thread Tools | Search this Thread |
Display Modes | |
|
|
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
Custom Thermophysical Properties | wsmith02 | OpenFOAM | 4 | June 1, 2023 14:30 |
[swak4Foam] funkyDoCalc with OF2.3 massflow | NiFl | OpenFOAM Community Contributions | 14 | November 25, 2020 03:30 |
[OpenFOAM.org] Error running #codeStream/functions wmake lnInclude fails to open *.H Files | tarik | OpenFOAM Installation | 8 | June 14, 2020 03:12 |
[swak4Foam] Problem installing swak_2.x for OpenFoam-2.4.0 | towanda | OpenFOAM Community Contributions | 6 | September 5, 2015 21:03 |
problem due to reconstructPar? | doubtsincfd | OpenFOAM | 0 | June 3, 2011 16:16 |