[boffin5]

Finally I got my chtMultiRegion case to run, sort of. It goes through all of the meshing and setup machinations, and then the run output reads:

Solving for fluid region fluid
Porosity region porosityBlockage:
    selecting model: DarcyForchheimer
    creating porous zone: porosityBlockage:porous

At which point it just stops. No error verbage, no system call, nothing.
In snappyHexMeshDict for the fluid region, I have bumped the maxGlobalCells way up to 50 million cells, albeit this is probably just for meshing and not related to my problem.
My PC system has 64 Gb of installed RAM, so that shouldn't be related to the cause.
I have attached the snappyHexMeshDict file for both regions, along with the controlDict and execution log, in hopes that one of the great forum members can venture a cause for this misfortune.

[boffin5]

My first effort to understand the problem was to whack off most of the fuselage, in order to reduce the size of the simulation. Image is attached.
But the run failed again in the same way.
I would appreciate any suggestions as to how I can investigate this weird problem!

[boffin5]

I should have attached these, better late than never.

[peterhess]

Hello!

I did not run such a big case before and it was interessting testing the limits as in your case.

I used a simple case and increased the number of cells to over 12 000 000 cells as in your case on a system with 16 GB Memory.

blockMech crashed because of memory problems...

blockMesh needed by me 1 GB for 1 000 000 cells.

I watched it on System Monitor on Ubuntu 22.04./OF10.0.

I dont use snappyHexMesh. I belive that snappyHexMesh uses much more memory than blockMesh.

If the problem in physical memory then try to reduce the number of cells and run the meshing and at the same time watch System Monitor.

If the avaliable memory exceeded, then you have a memory limitation.

If not, then try to increase the number of cells in snappyHexMeshDict.

--------------------------------------------------------------

Take a look to the log file of snappyHexMesh.

If the program finished the process correctly, then you will see the word:

End

at the ende of the file.

Else:

Killed

if not.

--------------------------------------------------------------

Check the mesh opticaly and see if the mesh is complate.

snappyHexMesh produce an incomplate mesh, if the physical memory exceeded or the maximal number of cells reached.

It produce the mesh also if it is not complate.

It happend to me long time ago, that snappyHexMesh produced an incomplate mesh and the solution froze exactly as by your case.

--------------------------------------------------------------

I belive you made it already, but anyway I will say it.

Increase both:

maxLocalCells

and

maxGlobalCells

Then see if the mesh generated will have the same number of cells as before.

If yes, then the problem most properly in the physical memory size.

--------------------------------------------------------------

Max volume = 0.228235 in checkmesh-fluid is too big and could affect the results. That is not a problem for now to run the case...

Regards

Peter

[boffin5]

Apparently my problem is not due to a lack of memory space. Currently it has two bodies in the fluid region: a fuselage and a fairing which contains the radiator. First I tried truncating the fuselage, but that didn't solve the problem. So then I just ran the case with the fairing and the radiator only. Still, it failed, and in paraview the fluid region is shown in red. I believe that this indicates that there is a problem with my fairing surface.
So I ran 'surfaceCheck' on the surface; here is the output:

Reading surface from "fairing1.stl" ...

Statistics:
Triangles    : 70032
Vertices     : 35305
Bounding Box : (21.4137 -0.3192 9.27732) (22.7505 1.71451e-18 9.53603)

Region  Size
------  ----
fairing 70032


--> FOAM Warning : 
    From function bool validTri(bool, const Foam::triSurface&, Foam::label)
    in file surfaceCheck.C at line 103
    triangle 59223 vertices ((12962 13054 12942) 0) has the same vertices as triangle 59227 vertices ((12962 12942 13054) 0) coords:3((21.7078 -0.22349 9.33137) (21.7103 -0.22352 9.33139) (21.7073 -0.22352 9.33142))
Surface has 1 illegal triangles.
Dumping conflicting face labels to "illegalFaces"
Paste this into the input for surfaceSubset

Triangle quality (equilateral=1, collapsed=0):
    0 .. 0.05  : 0.00122801
    0.05 .. 0.1  : 0.000656843
    0.1 .. 0.15  : 0.00069968
    0.15 .. 0.2  : 0.000599726
    0.2 .. 0.25  : 0.000585447
    0.25 .. 0.3  : 0.00228467
    0.3 .. 0.35  : 0.000599726
    0.35 .. 0.4  : 0.00069968
    0.4 .. 0.45  : 0.000713959
    0.45 .. 0.5  : 0.000956706
    0.5 .. 0.55  : 0.00129941
    0.55 .. 0.6  : 0.00177062
    0.6 .. 0.65  : 0.0017135
    0.65 .. 0.7  : 0.00479781
    0.7 .. 0.75  : 0.011609
    0.75 .. 0.8  : 0.0298292
    0.8 .. 0.85  : 0.0510195
    0.85 .. 0.9  : 0.0844899
    0.9 .. 0.95  : 0.12827
    0.95 .. 1  : 0.676177

    min 1.17952e-05 for triangle 8
    max 1 for triangle 8556

Edges:
    min 0.000100682 for edge 58 points (21.4207 -0.0012907 9.32995)(21.4207 -0.00137149 9.33001)
    max 0.0142272 for edge 56191 points (21.9783 -0.3175 9.32665)(21.9874 -0.317872 9.33758)

Checking for points less than 1e-6 of bounding box ((1.3368 0.3192 0.25871) metre) apart.
Found 0 nearby points.

Surface is not closed since not all edges connected to two faces:
    connected to one face : 584
    connected to >2 faces : 2
Conflicting face labels:592
Dumping conflicting face labels to "problemFaces"
Paste this into the input for surfaceSubset

Number of unconnected parts : 1

Number of zones (connected area with consistent normal) : 2
More than one normal orientation.


End

I really don't know how to make sense of these results. My surface is not closed; in fact, it shouldn't be since I am mirroring it in the simulation. I know of a utility called surfaceHookUp, but don't know how to use it, or if it is even appropriate.

Attached is an image of the fairing with its radiator. It's red, indicating a problem, and the fairing is kind of rough, as its meshed with a finess of (4 4). If I meshed it any finer, I got a failure with a 'plane normal of zero length' message.

I'm hoping someone can help me with finding the problem with the fairing stl surface. If need be, I can put it in dropbox, as it's too big to attach.

This is all rather strange, since when I ran the fuselage and fairing as a simpleFoam case, it worked fine.

[peterhess]

Hello!

If you want, please upload the case.

Without the mesh. I can mesh it myself. For size reduction...

Regards

Peter

[boffin5]

Thanks peterhess,

For the whole case, the zip file can be found in dropbox:
https://www.dropbox.com/s/uqh86irs86...allel.zip?dl=0

And for the fairing stl file only:
https://www.dropbox.com/s/jy73z0pwot...g.stl.zip?dl=0

I would appreciate any help; for years, I have been learning OpenFoam cases in an increasingly complex progression, and for my goals, this is my graduation case.
Along the way, I have received terrific help from forum members, who I thank once again!

[boffin5]

The script for running the case is ./runp and for cleaning, ./clean

[boffin5]

I had the fuselage boundary conditions commented out. I'll fix and repost.
Alan w

[boffin5]

updated dropbox link for the complete case:
https://www.dropbox.com/s/rt6a3ht20z...allel.zip?dl=0

[peterhess]

Hello!

You have an ill geometry in fuselage.

I was able to generate mesh using snappy.

The mesh produces additional regions.

Run the case and you will find the mesh.

I suggest to repair the geometry first, since it is not a snappy problem...

https://drive.google.com/file/d/1Lh3...ew?usp=sharing

I made many simplifications in the case, since the problem here is generating the mesh.

Regards

Peter

[boffin5]

I looked at your case, but decided to do some additional searching as well. As part of my investigations, once again I created some simple bodies for a chtMultiRegion test case.

Supposing the problems to be related to the interface between my radiator region and the fairing region, I meshed the bodies in salome, taking particular care to create the areas of interface as a square mesh, for both regions. See attached images. This way, the interface between regions is exactly the same, so 'mapNearest' in fvOptions should have an easy time in mapping the interface.

Another thing I found, is a ramification of problems when using 'mirrorMesh' in the simulation. When using 'mirrorMesh' along with 'mapNearest', the result was a locking up of the simulation when it tried to map the interface. When I didn't mirror the mesh, it ran okay.

Therefore, henceforth I will abandon the use of 'mirrorMesh' in my simulations. In lieu of this, I will model half of the geometry in my CAD system, mesh it in salome, and use the 'transformation/symmetry' in salome to create the whole mesh. Then I export the stl file into OpenFoam.

Actually, there was another inherent problem with mirrorMesh, in that it wouldn't run in parallel. But that is overtaken by events.

This is just one instance of lessons learned during a long, slog of wrestling with OpenFoam. But I'll get there.