[Swagga5aur]

Hello dear openFOAM'ers,

I'm working with some HTPEM modelling based upon the source code found at: http://openfuelcell.sourceforge.net/.

Currently having a working case running with a single processor, however, when I decompose the case it generates internal empty regions as shown in the attachments, one pre decomposition and the other decomposed. The regions is only generated in the processor to processor plane (where they meet).

I have tried with simple decomposition method, manual (based upon a cellID generation from the previously mentioned code) and scotch.

Scotch resulted in no visible regions, however, the simulation could not run due to naming issues caused by the decomposition.

The base mesh is generated in snappyHexMesh and I noticed this issue when trying to reconstruct the regions of a parallel simulation I got the following error when reconstructing the point fields: Incomplete patch point addressing


Thanks for any support in advance and please let me know if any additional information is required for support on this issue.

Best regards Lasse

[wyldckat]

Quick answer: This looks like a rendering bug, not an OpenFOAM bug... see this entry on the FAQ to see what I mean: https://openfoamwiki.net/index.php/F...is_in_ParaView

As for the "Incomplete patch point addressing", I suspect that is due to something else entirely... but without more specific steps and the file names themselves, along with complete error outputs, it's hard to diagnose the issue here.

[Swagga5aur]

Hello Bruno,

thanks for the quick response.
I just suspected the gaps as the same tendencies aren't observed in a similar case from the source code.

The mesh is generated through the following.

blockMesh
surfaceFeatureExtract
rm -rf system/decomposeParDict
mv system/decomposeParDictMesh system/decomposeParDict
decomposePar
mpirun -np $NPROCS snappyHexMesh -overwrite -parallel
reconstructParMesh -constant

rm -rf processor*
mv system/decomposeParDict system/decomposeParDictMesh

##-------------------------------------------------------------------------------
echo -e "   - Split mesh into the single regions"

splitMeshRegions -cellZones -overwrite

#-------------------------------------------------------------------------------
echo -e "   - Create file for paraview"
touch paraview.foam

#-------------------------------------------------------------------------------
echo -e "   - Rename air and fuel patches"
createPatch -region fuel -overwrite
createPatch -region air -overwrite


rm -rf 0

cp -a 0.org 0

topoSet -region air
topoSet -region fuel
topoSet -region electrolyte

After this the case is run able in serial directly. To run it in parallel I run the following code to pre process the case.

cp system/decomposeParDictSim system/decomposeParDict
cp -rf system/decomposeParDict system/air/.
cp -rf system/decomposeParDict system/fuel/.
cp -rf system/decomposeParDict system/abp/.
cp -rf system/decomposeParDict system/cbp/.
cp -rf system/decomposeParDict system/electrolyte/.

decomposePar -force
decomposePar -region air
decomposePar -region fuel
decomposePar -region electrolyte
decomposePar -region abp
decomposePar -region cbp

mpirun -np $NPROCS foamExec splitMeshRegions -cellZones -parallel

@ I = 0
while ( $I < $NPROCS )

cp -rf processor$I/1/. processor$I/constant/.

rm -rf processor$I/1

@ I++

end

rm -rf processor*/constant/polyMesh/sets processor*/constant/polyMesh/*Zones

# air zones
#
mpirun -np $NPROCS foamExec setSet -batch ./config/make.setAir -region air -constant -noVTK -parallel
mpirun -np $NPROCS foamExec setsToZones -noFlipMap -region air -constant -parallel

# fuel zones
#
mpirun -np $NPROCS foamExec setSet -batch ./config/make.setFuel -region fuel -constant -noVTK -parallel
mpirun -np $NPROCS foamExec setsToZones -noFlipMap -region fuel -constant -parallel

# electrolyte zones
#
mpirun -np $NPROCS foamExec setSet -batch ./config/make.setElectrolyte -region electrolyte -constant -noVTK -parallel
mpirun -np $NPROCS foamExec setsToZones -noFlipMap -region electrolyte -constant -parallel

I have attached a log with the entire error code when running reconstructPar for either of the respective fluid regions.

I am able to reconstruct the thin blue center region in the middle and the outer grey and red regions. Those three regions are all solids.

Let me know if there is any other information you require.

[wyldckat]

Quick answers:

1. I don't know which version of OpenFOAM you are using... wait, from the log file you are using OpenFOAM 6, therefore it should be possible to use the option "-dict" with decomposePar, e.g.:
   

   decomposePar -dict system/decomposeParDictMesh

2. The two createPatch commands, I guess that you have one "createPatchDict" within the respective region folder at "system"? E.g.: "system/air/createPatchDict"
   My concern here is for whatever reason, it used the same "system/createPatchDict" file, that could be one possible original of problems...
3. Strange... why didn't you use "-overwrite" with splitMeshRegions when running in parallel?
4. Why are you using setSet and setsToZones, if topoSet can be run in parallel!?
5. I've run just now the tutorial case "mesh/moveDynamicMesh/SnakeRiverCanyon" with the following commands:
   

   blockMesh
   decomposePar
   foamJob -p -s moveDynamicMesh
   reconstructPar

   And it worked well for me... it was able to reconstruct the point field "pointDisplacement".
   • That said, it is possible that this feature is not properly supported for regions...

Quick question: Is there any tutorial case on the openfuelcell project that I can use to test this myself? Because this is really strange... perhaps the point field is created incorrectly on each processor?

[Swagga5aur]

1. I'll use that from now on didn't realize that was a possibility. You are correct I am using OpenFOAM 6.

2. Yes that is correct, I rename two patches to from min, max to inlet and outlet of the respective regions (both fuel and air). I could try renaming some of the patches of the regions that I can reconstruct, to see if it provokes the issue.

3. Just used the same approach as in the source code example cases, it would make more sense to just overwrite and remove the step with copying and remove the 1 folder.

4. Same as no.3 same approach as the examples, just wanted to make something that works. I will use topoSet in my future cases as its more straight forward.

5. Hmm, well the current case I'm working on is based upon some confidential geometries, just reduced the domain with the size of blockMesh but having the original stl files in the directory.

I will try to make a dummy case before new year which is share able for further debugging.

Let me know if you want me to test something in the mean time.

I'm going to make the same case where no renaming/createPatch is required to see if this solves the issue.

I forgot to mention that I also run a renaming script for the decomposed case as the createPatch renaming is lost during decomposition and I believe that might be the main issue.

@ I = 0
while ( $I < $NPROCS )

	set DESTA = processor$I/constant/air/polyMesh
	set DESTF = processor$I/constant/fuel/polyMesh

	sed -i 's/minZ/airInlet/' $DESTA/*
	sed -i 's/maxZ/airOutlet/' $DESTA/*

	sed -i 's/minZ/fuelInlet/' $DESTF/*
	sed -i 's/maxZ/fuelOutlet/' $DESTF/*

    echo "processor"$I "done"
    @ I++
end

[wyldckat]

Originally Posted by Swagga5aur

I'm going to make the same case where no renaming/createPatch is required to see if this solves the issue.

I forgot to mention that I also run a renaming script for the decomposed case as the createPatch renaming is lost during decomposition and I believe that might be the main issue.

Quick answer: createPatch should work just fine, it's shouldn't be necessary for you to change that.

Furthermore, createPatch can also be executed in parallel as you do with the other applications. Therefore, you should not use the hack relying on "sed -i" to hack inside all files within "polyMesh".

So there are now two possible reasons for the problem in reconstruction:

1. A critical file in "polyMesh" might have gotten damaged.
2. The solver might not be dealing properly with the point fields.

[Swagga5aur]

That solved it, thanks Bruno and merry christmas!

What I did for now was just overwriting the splitMesh created decomposed directories with the individual decomposition of the respective regions such that they maintained there createPatch and topoSet modifications.

I could also just apply the createPatch and topoSet in parallel instead.