Development issueshttps://develop.openfoam.com/groups/Development/-/issues2021-07-06T16:37:25Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1514solid body motion solver does not work with rigid body solver2021-07-06T16:37:25ZAdminsolid body motion solver does not work with rigid body solverHi,
I am trying to use solid body motion as a mesh motion solver for rigid body motion. Although it lists the solid body motion as a valid motion solver, it fails to cast solver type and crash at the beginning. I have attached dynamicMe...Hi,
I am trying to use solid body motion as a mesh motion solver for rigid body motion. Although it lists the solid body motion as a valid motion solver, it fails to cast solver type and crash at the beginning. I have attached dynamicMeshDict file which can be placed in floatingBody overset tutorial to reproduce the error. The error line
--> FOAM FATAL ERROR:
Attempt to cast type solidBody to type displacementMotionSolver
Regards,
Ali
[6DoF.dat](/uploads/b4482b95045d89f392cbb664abc39412/6DoF.dat)
[dynamicMeshDict](/uploads/090b4e4130601b0d00883af3c85c20dc/dynamicMeshDict)
\## Reattaching the author to the issue ticket: @ashim ##https://develop.openfoam.com/Development/openfoam/-/issues/2630solidBody motionSolver does not use optional sub dictionary2023-05-30T18:20:15ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsolidBody motionSolver does not use optional sub dictionary<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
All motionSolvers should be able to either supply dictionaries inline or in a sub dictionary:
```
motionSolver solidBody;
solidBodyCoeffs
{
cellZone rotor;
solidBodyMotionFunction rotatingMotion;
origin (0 0 0);
axis (0 1 0);
omega 158; // rad/s
}
```
This does not work for solidBody anymore.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Attached case.
[testcase-zone-ignored.tgz](/uploads/4ff65b551b1a533d631152b9686bf182/testcase-zone-ignored.tgz)
### What is the current *bug* behaviour?
Does not read the selection of cells from the 'Coeffs' subdictionary. Instead applies motion to whole mesh.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
Same behaviour, independent of dictionary supplied in-line or a a 'solidBodyCoeffs' subdictionary.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2206|v2112|v2106|v2012|v2006 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :v1912 .. v2206
- Operating system :
- Hardware info :
- Compiler :
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/197snappy v1606+ potential bug with "mergePatchFaces off"2019-12-09T22:04:11ZAdminsnappy v1606+ potential bug with "mergePatchFaces off"I got the following error when setting "mergePatchFaces off" in snappyHexMesh (v1606+):
Merge refined boundary faces
----------------------------
[13]
[13]
[13] --> FOAM FATAL ERROR:
[13] attempted assig...I got the following error when setting "mergePatchFaces off" in snappyHexMesh (v1606+):
Merge refined boundary faces
----------------------------
[13]
[13]
[13] --> FOAM FATAL ERROR:
[13] attempted assignment to self
[13]
[13] From function void Foam::List<T>::operator=(const Foam::List<T>&) [with T = int]
[13] in file /share/OpenFOAM/OpenFOAM-v1606+/src/OpenFOAM/lnInclude/List.C at line 466.
[13]
FOAM parallel run aborting
When I set "mergePatchFaces on" the problem doesn't occur.
Best regards,
Charlie.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2657snappyMultiRegionHeaterImplicit does not constrain decomposition2022-12-23T13:52:22ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsnappyMultiRegionHeaterImplicit does not constrain decomposition<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
The heatTransfer/chtMultiRegionFoam/snappyMultiRegionHeaterImplicit does not use faceZones to constrain the decomposition. Hence it might lead to errors in the implicit solution (.. lduAssembly267 .. incorrect number of faces)
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Seems to depend on the scotch level. My version does not showcase problem.
### Example case
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
See tutorial case.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2206|v2112|v2106|v2012|v2006 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2206
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->
Use the faceZones generated by snappyHexMesh directly or have the topoSet step generate faceZones instead of currently faceSets.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/774snappyMultiRegionHeater crashing2018-03-19T10:59:23ZMark OLESENsnappyMultiRegionHeater crashing- snappy crashes with gcc 4.8.5, runs with clang 3.8.0- snappy crashes with gcc 4.8.5, runs with clang 3.8.0Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/453SnappyHexMesh writeFlags error - addedCells not written2017-06-29T20:38:04ZMatej FormanSnappyHexMesh writeFlags error - addedCells not writtenfrom 1612+ when running SHM with:
```
// Write flags
writeFlags
(
layerSets
);
```
Snappy will write to the Info stream:
```
Writing 5328 added cells to cellSet addedCells
Writing 2668 faces inside added layer to faceSet layerFace...from 1612+ when running SHM with:
```
// Write flags
writeFlags
(
layerSets
);
```
Snappy will write to the Info stream:
```
Writing 5328 added cells to cellSet addedCells
Writing 2668 faces inside added layer to faceSet layerFaces
```
This is from iglooWithFridges tutorial, but the sets are actually never written.
The same story for motorBike.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1255snappyHexMesh with sloppy patch following2020-01-08T14:34:44ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsnappyHexMesh with sloppy patch following### Functionality to add/problem to solve
snappyHexMesh will try to merge co-planar faces on a single cell into a single, large face. This minimises the individual distortion and generates more layers. It will not merge faces belonging ...### Functionality to add/problem to solve
snappyHexMesh will try to merge co-planar faces on a single cell into a single, large face. This minimises the individual distortion and generates more layers. It will not merge faces belonging to different patches. Occasionally it would be nice to merge across patches (saving the effort of merging the regions in the surface)Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/223snappyHexMesh with -region2019-12-09T22:04:11ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsnappyHexMesh with -regionsnappyHexMesh (since starts off from initial mesh) should support -regionsnappyHexMesh (since starts off from initial mesh) should support -regionhttps://develop.openfoam.com/Development/openfoam/-/issues/1221snappyHexMesh with empty regions in surfaces2020-01-08T14:35:48ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsnappyHexMesh with empty regions in surfaces<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
-->
<!--
All text between these marker...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
shm can potentially snap to a particular region. This is done by constructing a per-region search tree (triSurfaceRegionSearch). triSurfaceRegionSearch fails if there are some zero-sized regions.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Have surfaces with zero-sized regions. Run with
```snapControls:multiRegionFeatureSnap true```
### Example case
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
### What is the current *bug* behaviour?
<!-- What actually happens -->
out-of-bounds access in Map<label>
### What is the expected *correct* behavior?
<!-- What you should see instead -->
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
OpenFOAM version :
Operating system :
Compiler :
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
-->Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1165snappyHexMesh Warning2020-01-08T14:46:44ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsnappyHexMesh Warning```
--> FOAM Warning :
From function void Foam::HashTable<T, Key, Hash>::resize(Foam::label) [with T = int; Key = int; Hash = Foam::Hash<int>; Foam::label = int]
in file HashTable.C at line 570
HashTable contains 395 cannot ...```
--> FOAM Warning :
From function void Foam::HashTable<T, Key, Hash>::resize(Foam::label) [with T = int; Key = int; Hash = Foam::Hash<int>; Foam::label = int]
in file HashTable.C at line 570
HashTable contains 395 cannot resize(0)
```Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/572snappyHexMesh : visualising connection between inside and outside points2020-01-03T09:46:50ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsnappyHexMesh : visualising connection between inside and outside pointsWould be nice to have a leak-detection process, either built-in or stand-alone, that can detect mesh paths between provided 'inside' and 'outside' points.Would be nice to have a leak-detection process, either built-in or stand-alone, that can detect mesh paths between provided 'inside' and 'outside' points.https://develop.openfoam.com/Development/openfoam/-/issues/814snappyHexMesh under valgrind reports lots of uninitialised memory2021-07-06T12:52:28ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsnappyHexMesh under valgrind reports lots of uninitialised memory(unfinished) With 2a4ddaa9c6b0190e46493280d1f96218d3f242dd:
[processor0.log](/uploads/2bd561adf7957a5fd78a82a657f46fbb/processor0.log)
(unfinished) Under 1712:
[processor0.log](/uploads/1cd1f03b2b518904f4db9ca22f234ddf/processor0.log)(unfinished) With 2a4ddaa9c6b0190e46493280d1f96218d3f242dd:
[processor0.log](/uploads/2bd561adf7957a5fd78a82a657f46fbb/processor0.log)
(unfinished) Under 1712:
[processor0.log](/uploads/1cd1f03b2b518904f4db9ca22f234ddf/processor0.log)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2792snappyHexMesh spends excessive time balancing during refinement2023-06-26T10:30:45ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsnappyHexMesh spends excessive time balancing during refinement### Functionality to add/problem to solve
snappyHexMesh balances mesh before or after each refinement step. For large numbers of cores (e.g. 8000) balancing can be expensive.
### Target audience
snappyHexMesh on large numbers of cores...### Functionality to add/problem to solve
snappyHexMesh balances mesh before or after each refinement step. For large numbers of cores (e.g. 8000) balancing can be expensive.
### Target audience
snappyHexMesh on large numbers of cores.
### Proposal
Not do balancing until a reasonable number of cells per processor has been reached.
### What does success look like, and how can we measure that?
Speedup.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1166snappyHexMesh: positional smoothing modifies geometry2019-01-10T15:01:07ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsnappyHexMesh: positional smoothing modifies geometrypositional smoothing modifies boundary points. In below I set the 3D cursor on the mesh before positional smoothing (but after expansion ratio smoothing). The mesh after positional smoothing has changed the boundary
![after_positional_s...positional smoothing modifies boundary points. In below I set the 3D cursor on the mesh before positional smoothing (but after expansion ratio smoothing). The mesh after positional smoothing has changed the boundary
![after_positional_smoothing](/uploads/dcdc983f4c8c2307e93afe2c8eb8a3fd/after_positional_smoothing.png)Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/735snappyHexMesh openmp compilation error for linux64IccKNL and INTELMPI targets2020-06-19T14:46:59ZAdminsnappyHexMesh openmp compilation error for linux64IccKNL and INTELMPI targetsThe $WM_PROJECT_DIR/wmake/rules/linux64IccKNL/openmp macro is not working for snappyHexMesh. The Intel compiler outputs the following error regarding openmp library calls:
`/opt/app/openfoam/ThirdParty-v1712-intelmpi-knl/platforms/linux...The $WM_PROJECT_DIR/wmake/rules/linux64IccKNL/openmp macro is not working for snappyHexMesh. The Intel compiler outputs the following error regarding openmp library calls:
`/opt/app/openfoam/ThirdParty-v1712-intelmpi-knl/platforms/linux64IccKNLDPInt32/lib/libkahip.so: undefined reference to omp_get_max_threads`
`/opt/app/openfoam/ThirdParty-v1712-intelmpi-knl/platforms/linux64IccKNLDPInt32/lib/libkahip.so: undefined reference to omp_get_thread_num`
Intel compiler: icpc --version
icpc (ICC) 18.0.0 20170811
Copyright (C) 1985-2017 Intel Corporation. All rights reserved.
$WM_PROJECT_DIR/etc/bashrc was configured with the following modified values:
export WM_PROJECT_VERSION=v1712-intelmpi-knl
export WM_COMPILER=IccKNL
export WM_MPLIB=INTELMPI
As a workaround, the -qopenmp compiling option was added to the CC variable line in $WM_PROJECT_DIR/wmake/rules/linux64IccKNL/c++
CC = icpc -std=c++11 -xmic-avx512 `-qopenmp` -fp-trap=common -fp-model precise -fp-speculation=safe
OpenFOAM is being compiled now without errors.
[bashrc](/uploads/8775af5187d7b880d2e67771dc134946/bashrc)
[c++](/uploads/a724b1aa0b945c3b8390de6df6522cbf/c++)
\## Reattaching the author to the issue ticket: @braulhiu ##https://develop.openfoam.com/Development/openfoam/-/issues/1175snappyHexMesh occasionally hangs in parallel layer extrusion2019-12-09T22:37:27ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsnappyHexMesh occasionally hangs in parallel layer extrusion- case was hanging in parallel
- with one of the processors in an infinite loop (in addPatchCellLayer)
Problem:
- shm layer addition can get any mesh to add layers to.
- sometimes this mesh might have a baffle on the patch-to-extrude
(-...- case was hanging in parallel
- with one of the processors in an infinite loop (in addPatchCellLayer)
Problem:
- shm layer addition can get any mesh to add layers to.
- sometimes this mesh might have a baffle on the patch-to-extrude
(- a baffle is two back-to-back faces that share the same points)
- this is of course not possible to extrude so we disable this
However
- what if the baffle faces are on different processors
- each processor does not detect that the face is part of a baffle
- so might try to extrude
and this would lead to a hang since all the edges of the face connect to the same neighbour (admittedly on a different processor).Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2463SnappyHexMesh multiregion snapp of chamfer2022-05-09T13:03:20ZVojtech BetakSnappyHexMesh multiregion snapp of chamfer### Summary
SnappyHexMesh fails in the chase of multi-region snap to chamfer. At the interface is created a wavy mesh. In some cases has been observed a formation of a gap at the interface between mesh regions (cellzones). This wavy in...### Summary
SnappyHexMesh fails in the chase of multi-region snap to chamfer. At the interface is created a wavy mesh. In some cases has been observed a formation of a gap at the interface between mesh regions (cellzones). This wavy interface is not observed when the interface has e.g. cylindrical shape.
### Environment information
-->
- OpenFOAM version : v2112
- Operating system : openSuse
- Hardware info :
- Compiler : gcc-10
[snappyII.tar.xz](/uploads/8c9564e298e9d9e83132a614d1eac01a/snappyII.tar.xz)
![geom-multiRegion](/uploads/81621703ff1eb35dfd262c2db812fe68/geom-multiRegion.png)
![geomII](/uploads/37fcbfbdfbb06357bb8dd06027ed36c9/geomII.png)
![geom](/uploads/5c8daa4190f8750541c263aa72f01cc4/geom.png)
![wires](/uploads/492fda8a44fb071e80edb65ed6a42e29/wires.png)https://develop.openfoam.com/Development/openfoam/-/issues/1352snappyHexMesh - mergeAcrossPatches fails on symmetryPlane2023-12-07T19:05:02ZAdminsnappyHexMesh - mergeAcrossPatches fails on symmetryPlane<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be ...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
The new feature of snappyHexMesh "mergeAcrossPatches" works well on patch boundaries and greatly improves layer coverage. Unfortunately it damages a symmetry plane.
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
Generate mesh for a case where the geometry intersects the symmetry plane.
<!-- How one can reproduce the issue - this is very important -->
### Example case
Is attached.
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
### What is the current *bug* behaviour?
When mergeAcrossPatches is true, not only the faces at patch boundaries on the geometry are merged (which is very desirable for layer coverage), but also the faces at the boundary between geometry and symmetry plane. Consequently, the symmetry plane is substantially not planar. See attached images.
<!-- What actually happens -->
### What is the expected *correct* behavior?
The faces should only be merged at patch boundaries on the geometry. Intersections between the geometry and the domain boundaries should be treated as features where the faces won't be merged.
For a symmetry plane the current behavior leads to an error (as it is not planar), but the same applies for boundaries which are patches, e.g. the lowerWall boundary in the motorbike tutorial.
<!-- What you should see instead -->
### Relevant logs and/or images
Attachements:
* mergeAcrossPatches-false.png - No merged faces; symmetry plane planar
![mergeAcrossPatches-False](/uploads/28e6b35c64a4c145176636ff2b066e53/mergeAcrossPatches-False.png)
* mergeAcrossPatches-true.png - merged faces; "crimpled" edge between symmetry plane and geometry.
![mergeAcrossPatches-True](/uploads/8359d4e8e853512d121e0146fd7080ec/mergeAcrossPatches-True.png)
* mergeAcrossPatches.tgz - example case. Use Allrun to run (runs a few seconds).
(/uploads/9917f61abe18891cca38d55325d8db74/mergeAcrossPatches.tgz)
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v1906
- Operating system : ubuntu
- Hardware info :
- Compiler : gcc
### Possible fixes
Ideas:
* Explicitly exclude certain patches from the merge mechanism
* Identify feature at intersection of geometry with domain boundary.[mergeAcrossPatches.tgz]
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->https://develop.openfoam.com/Development/openfoam/-/issues/2803snappyHexMesh maxGlobalCells is limited by int32 limit 2,147,483,647 (2.147 B...2023-06-19T14:06:21ZJulius BergmannsnappyHexMesh maxGlobalCells is limited by int32 limit 2,147,483,647 (2.147 Billion)### Description of error
SnappyHexMesh crashes whenever one wants to extend the variable maxGlobalCells past the int32 upper limit of 2,147,483,647.
Here the error when trying to set it as 4,000,000,000 (4e9):
Expected integral (i...### Description of error
SnappyHexMesh crashes whenever one wants to extend the variable maxGlobalCells past the int32 upper limit of 2,147,483,647.
Here the error when trying to set it as 4,000,000,000 (4e9):
Expected integral (int32), value out-of-range on line 0: double 4000000000
I tried out setting it to 4000000000, 4e9, 4000000000L - all resulting in the same error.
### What to fix
Read in the variable from the dictionary in long representation - is that possible? Elsewise read it in as double and check as double. We do not need precice checks so double check would be fine.
### Who would benefit from this change
We want to make OpenFoam exa-scale ready, so this upper limit needs to be adjusted. I expect to surpass this upper limit for the exaFoam Grand Challenge CRM-HL during meshing process.https://develop.openfoam.com/Development/openfoam/-/issues/1572snappyHexMesh leak detection is prone to false positives2024-01-10T16:49:17ZJustin GraupmansnappyHexMesh leak detection is prone to false positives<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be ...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
snappyHexMesh leak detection using the locationsOutsideMesh keyword is highly prone to false positives. In other words, a detected leak often doesn't actually cause the mesh to leak when meshed.
### Steps to reproduce
I've attached a simple model to demonstrate this issue. The model is simply a block inside of another block. The inner block has a triangle removed which snappyHexMesh detects as a leak.
On the attached model run...
* blockMesh
* snappyHexMesh -overwrite
You should get an error and a leak path is exported. Now...
* remove the locationsOutsideMesh keyword in the snappyHexMeshDict
* re-run snappyHexMesh
* Review mesh, you'll see that there is no leak into the inner box
### Example case
[boxLeakBug.zip](/uploads/48fe8be4c572aefea8a29b2dcc218453/boxLeakBug.zip)
### What is the current *bug* behaviour?
snappyHexMesh detects a leak when there isn't one.
### What is the expected *correct* behavior?
snappyHexMesh should only detect a leak if there actually is one.
### Environment information
- OpenFOAM version : v1906
- Operating system : RHEL/Windows 10
- Hardware info : Intel
- Compiler : gcc/minGW
### Possible fixes
I suspect the leak detection code is not using the same method that is used to find regions and remove cells during the castellation phase. If possible, the same walking method used to find regions and remove cells should be used to find leaks between the two points. The current method produces way too many false positives to be useful on more complex geometry.v2012