[kawechel]

Hi -

I have been running the simpleFoam motorbike tutorial in parallel using the following decomposition options:

1) decomposePar with scotch followed by snappyHexMesh with ptscotch
2) decomposePar with hierarchical followed by snappyHexMesh with hierarchical

I then reconstruct the mesh using reconstructParMesh, following by another decomposePar before I run potentialFoam and simpleFoam.

If I skip the reconstruction/decomposition step, I get the following error:

-------------
Create time

Create mesh for time = 0

Reading field p

[0]
[5]

[5] -[0] --> --> FOAM FATAL IO ERRO[0]
[6]kkeywfile: torBike_frt-fairing:001%1 is undefined in dictionary "OpenFOAM-2.1.1/run/tutorials/incompressible/simpleFoam/motorBikeParallel/processor
6/0/p::boundaryField

[6] OpenFOAM-2.1.1/run/tutorials/incompressible/simpleFoam/motorBikeParallel/processor5/0/p::boundaryField[0]
[0
[6] f
le: OpenFOAM-2.1.1/run/tutorials/incompressible/simpleFoam/motorBikeParallel/processor6/0/p::boundaryField26 t to lin58.
db/dictionary/dictionar

etc.
--------------

Can anyone explain to me why the reconstruction/decomposition step is necessary? I can sort of understand it when using scotch/ptscotch, but not if the method is hierarchical for both decomposePar and snappyHexMesh. For large meshes the reconstruction takes a long time, so if there is a way to go directly from snappyHexMesh to potentialFoam or simpleFoam, I'd like to understand how to do it!

Thanks,
kawechel

[wyldckat]

Greetings kawechel and welcome to the forum!

I'm too tired right now to try and explain this, but I suggest you the following threads/posts:

• Possibilities on how to not need to reconstruct the mesh: Parallel Computing decomposePar post #29
• Read the whole thread for more information: Parallel Computing decomposePar

Best regards,
Bruno

[kawechel]

Hi Bruno -

thanks for you message. I've read the post/thread, but am not really any the wiser.

Based on the pisoFoam motorbike tutorial, my script now looks like this:

./Allclean
. $WM_PROJECT_DIR/bin/tools/RunFunctions

cp $FOAM_TUTORIALS/resources/geometry/motorBike.obj.gz constant/triSurface/
mkdir 0
cp -r 0.org 0 > /dev/null 2>&1

runApplication blockMesh

# decomposePar uses SCOTCH 
cp ./system/decomposeParDict.scotch ./system/decomposeParDict
runApplication decomposePar -force
mv log.decomposePar log.decomposePar.1

# snappyHexMesh uses PTSCOTCH
cp ./system/decomposeParDict.ptscotch ./system/decomposeParDict
runParallel snappyHexMesh 32 -overwrite -parallel

find . -type f -iname "*level*" -exec rm {} \;
ls -d processor* | xargs -i cp -r 0.org/* ./{}/0/ $1

runParallel renumberMesh 32 -overwrite

runParallel potentialFoam 32 -noFunctionObjects -writep -parallel

runParallel `getApplication` 32

runApplication reconstructParMesh -mergeTol 1e-6 -constant
runApplication reconstructPar

but unfortuantely I get errors from renumberMesh when I run this:

keyword procBoundary30to18 is undefined in dictionary "~/OpenFOAM-2.1.1/run/tutorials/incompressible/simpleFoam/motorBikeParallel/processor30/0/nut::boundaryField"

What am I missing? There is indeed no procBoundary keyword in any of the nut files, but how can I make sure it is there?

thanks,
kawechel

[wyldckat]

Hi kawechel,

Then something is broken in your "0.org" folder, because inside the file "0.org/nut" you should have this:

"proc.*"
{
    type            processor;
}

That is the magic boundary condition that takes care of all processor boundaries.
If you look at the script code, the following line takes care of replacing the contents of the "0" folder on all processors, based on "0.org" (which stands for "0.original"):

ls -d processor* | xargs -i cp -r 0.org/* ./{}/0/ $1

Best regards,
Bruno

[kawechel]

Hi Bruno -

Thanks for your help with this. I've no moved past the previous error, but am now encountering another issue:

Renumbering processor face decomposition map faceProcAddressing
--> FOAM FATAL ERROR: 
problem faceI:107 masterFaceI:0
From function renumberMesh

I am using the simpleFoam motorbike case and the only modifications I've made are the ones you suggested. What else am I missing?

thanks,
kawechel

[kawechel]

Hi -

I briefly thought I had fixed the problem by reverting to running renumberMesh in serial, but that seems to end up only dealing with the mesh on processor 0...

Looking at faceProcAddressing in the processorX/constant/polyMesh files, I get blocks of negative numbers. Is that possibly the cause of the problem?

Grateful for any pointers in the right direction.

thanks,
Michele

[wyldckat]

Hi Michele,

I'm a bit lost on your description, but if I understand you correctly, then on the script you've got on post #3, I would say that the first occurrence of this line:

cp -r 0.org 0 > /dev/null 2>&1

should not be there. The reason is because this line:

ls -d processor* | xargs -i cp -r 0.org/* ./{}/0/ $1

will make the necessary copies after the mesh has been generated.

Additionally, have you confirmed that your "0.org" folder is identical to the original version?

Best regards,
Bruno