DecomposePar generates internal holes
2 Attachment(s)
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 :) |
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. |
1 Attachment(s)
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. Code:
blockMesh Code:
cp system/decomposeParDictSim system/decomposeParDict 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. |
Quick answers:
|
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. Code:
@ I = 0 |
Quote:
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:
|
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. |
All times are GMT -4. The time now is 16:50. |