Development issueshttps://develop.openfoam.com/groups/Development/-/issues2023-05-30T18:21:55Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2629Tutorial on incompressible RAS eq. and lid-driven cavity not working as expected2023-05-30T18:21:55ZGiorgio GiorgianiTutorial on incompressible RAS eq. and lid-driven cavity not working as expectedRunning pisoFoam on the folder tutorials/incompressible/pisoFoam/RAS/cavity/ (with default input) is expected to run the simulation up to 10s achiving a Courant of ~0.2 max.
However, after time=2.5 the Courant number jumps to 1 and the ...Running pisoFoam on the folder tutorials/incompressible/pisoFoam/RAS/cavity/ (with default input) is expected to run the simulation up to 10s achiving a Courant of ~0.2 max.
However, after time=2.5 the Courant number jumps to 1 and the solution becomes meaningless.
![screens1](/uploads/bf213a5e6908c335ce3831807b355114/screens1.png)
![image](/uploads/f60f5e2348758910c233fffd1702089f/image.png)Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2628Link to source files doesn't work2024-01-10T11:06:28ZTorquil SørensenLink to source files doesn't workWhen using the documentation at https://www.openfoam.com/documentation/guides/latest/api, whenever I click on a link to a source file (*.C), I get a "file not found" web page. E.g, consider the following documentation page:
https://www....When using the documentation at https://www.openfoam.com/documentation/guides/latest/api, whenever I click on a link to a source file (*.C), I get a "file not found" web page. E.g, consider the following documentation page:
https://www.openfoam.com/documentation/guides/latest/api/semiPermeableBaffleMassFractionFvPatchScalarField_8C.html
Under "Detailed Description", there is a link "semiPermeableBaffleMassFractionFvPatchScalarField.C" to https://develop.openfoam.com/Development/OpenFOAM-plus/blob/OpenFOAM-v2112/src/thermoTools/derivedFvPatchFields/semiPermeableBaffle/semiPermeableBaffleMassFraction/semiPermeableBaffleMassFractionFvPatchScalarField.C
But this link doesn't work. I am sent to a "404 page not found" error page.
The same happens when I click on any such link to a *.C-file on any of the documentation pages.
Thankfully, the link further up "Go to the source code of this file" does work.https://develop.openfoam.com/Development/openfoam/-/issues/2627cloud functionObjects not working with collated format2022-11-09T15:32:55ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcloud functionObjects not working with collated format### Functionality to add/problem to solve
In various bits of lagrangian functionObjects it uses a local check to decide if the file needs to be written. This means that processors that hold zero particles never get involved in the IO an...### Functionality to add/problem to solve
In various bits of lagrangian functionObjects it uses a local check to decide if the file needs to be written. This means that processors that hold zero particles never get involved in the IO and this causes problems when using e.g. 'collated' file format.
### Target audience
Lagrangian & parallel & collated file format
### Proposal
Replace checks for `if (c.size())` with a proper parallel decision:
```
const bool haveParticles = c.size();
if (c.time().writeTime() && returnReduce(haveParticles, orOp<bool>()))
{
Nu.write(haveParticles);
}
```
### What does success look like, and how can we measure that?
No hang
Attached a patch that makes the aachenBomb tutorial run through.
[collated_writing.patch](/uploads/857e5685955bec2b84b9ab47795b56a2/collated_writing.patch)Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2626BUG: porousBafflePressure: fixedJump entries are not read2022-11-20T17:22:01ZKutalmış BerçinBUG: porousBafflePressure: fixedJump entries are not readSee the missing `dict` entry in the ctor: [porousBafflePressureFvPatchField.C#L59](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/TurbulenceModels/turbulenceModels/derivedFvPatchFields/porousBafflePressure/porousBaff...See the missing `dict` entry in the ctor: [porousBafflePressureFvPatchField.C#L59](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/TurbulenceModels/turbulenceModels/derivedFvPatchFields/porousBafflePressure/porousBafflePressureFvPatchField.C#L59)
The entries being not read by `porousBafflePressure` include (but not limited to):
```
jump
jump0
value
minJump
relax
```
```c
jump_(p.size(), Zero),
jump0_(p.size(), Zero),
minJump_(dict.getOrDefault<Type>("minJump", pTraits<Type>::min)),
relaxFactor_(dict.getOrDefault<scalar>("relax", -1)),
timeIndex_(this->db().time().timeIndex())
```Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2625argList option printing truncates incorrectly2022-11-18T20:24:49ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comargList option printing truncates incorrectly<!--
*** 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 -->
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
`mapFieldsPar -help`
outputs
```
-mapMethod <word>
Specify the mapping method
(direct|mapNearest|cellVolumeWeight|correctedCellVolumeWeig
t)
```
(it left out the 'h' in correctedCellVolumeWeight at position 80)
### What is the current *bug* behaviour?
<!-- What actually happens -->
See above
### 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
- Operating system :
- Hardware info :
- Compiler :Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2624expand the ListLoop macros2022-11-07T11:02:05ZMark OLESENexpand the ListLoop macrosFollowing discussions with Leopold and @sbna, makes sense to _unbox_ the List_FOR_ALL macro into its constituent parts.
As it stands, cannot place an loop pragmas in front, since there is an embedded initial looping parameter.
Cannot ea...Following discussions with Leopold and @sbna, makes sense to _unbox_ the List_FOR_ALL macro into its constituent parts.
As it stands, cannot place an loop pragmas in front, since there is an embedded initial looping parameter.
Cannot easily embed an `_Pragma()` within the macro since a macro paste token (`_n##i`) is used.
Main use case are the TFOR_ALL... macros in FieldM.H (used for various list/field operations). So replace there with explicit, identifiable loops.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2623direct reading with std::stream bypasses state checking2022-11-07T11:09:22ZMark OLESENdirect reading with std::stream bypasses state checkingAs noticed by @Mattijs with reading ensight files, the direct use of stdStream() for raw reading of strings means that failures are not properly noticed, since the IFstream wrapper state is not changed.
Needs visible `syncState()` metho...As noticed by @Mattijs with reading ensight files, the direct use of stdStream() for raw reading of strings means that failures are not properly noticed, since the IFstream wrapper state is not changed.
Needs visible `syncState()` method that can be called to ensure that the internal std::stream state and the OpenFOAM stream state match.
For ensight reading, this could be protected, but there are other locations using stdStream() that will need this too.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2622viewFactor not robust2022-11-25T08:05:30ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comviewFactor not robust<!--
*** 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 -->
viewFactor smoothing fails if a face 'sees' zero other faces.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Set up case with only one patch, with only face in the viewFactor. This will (hopefully) generate a map which has zero entries for that face (since there are no other faces it can see)
### 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 -->
sigfpe from dividing by zero size.
### 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 : 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
- Operating system :
- Hardware info :
- Compiler :
### Possible fixes
Protect division by zero.
<!--
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/2621limitTemperature option looks up thermo even if not active2022-11-30T08:26:02ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comlimitTemperature option looks up thermo even if not active<!--
*** 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 -->
Use limitTemperature in e.g. moveDynamicMesh with displacementLaplacian. displacementLaplacian constructs fvOptions. limitTemperature will fail since looks up thermo in constructor - even if not active.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
See above
### What is the current *bug* behaviour?
<!-- What actually happens -->
FatalError since cannot find thermo
### What is the expected *correct* behavior?
<!-- What you should see instead -->
At least obey 'active' flag
### 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
- Operating system :
- Hardware info :
- Compiler :
### Possible fixes
Use isActive flag in constructor.
<!--
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/2620BUG: SpalartAllmarasDES: zero-valued subgrid-scale TKE field2022-11-15T15:27:54ZKutalmış BerçinBUG: SpalartAllmarasDES: zero-valued subgrid-scale TKE field### Summary
The DES models of `SpalartAllmaras` produce zero-valued `k` fields whenever requested (e.g. by `turbulenceFields`.) The `k` is computed in [SpalartAllmarasDES.C#L459](https://develop.openfoam.com/Development/openfoam/-/blob/...### Summary
The DES models of `SpalartAllmaras` produce zero-valued `k` fields whenever requested (e.g. by `turbulenceFields`.) The `k` is computed in [SpalartAllmarasDES.C#L459](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/TurbulenceModels/turbulenceModels/DES/SpalartAllmarasDES/SpalartAllmarasDES.C#L459).
### Steps to reproduce
`./Allrun` the test case: [GL2619-test-case.zip](/uploads/3e596771d97bb743bedcd9e1a8705811/GL2619-test-case.zip), and inspect any `k` field.
### Environment information
3caeeb1f51998883efcca6020854c8c494e93b8a
### Possible fixes
- We need to understand why the current governing equations computing `k` field were used.
- We had introduced and validated estimation functions for `k`, `epsilon` and `omega` by c7357bd1c36c10f531444bb0a6272a6b9c434b94 for RANS SA model. Similar approximations can be used for DES SA model as well.Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2619distributedTriSurfaceMesh in non-NFS mode2022-10-26T16:13:47ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comdistributedTriSurfaceMesh in non-NFS mode<!--
*** 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 -->
distributedTriSurfaceMesh does not handle non-NFS mounted processors.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Set up case with distributedTriSurfaceMesh. decompose into two and move processor1 directory to new location. If case is called 'cavity':
```
decomposePar
mkdir -p machineB/cavity
mv processor1 machineB/cavity/
```
Change the decomposeParDict to switch on the distributed flag (or specify command-line options):
```
distributed yes;
roots ("<case>/machineB");
```
Run snappyHexMesh in parallel. The processor1 will fail.
### 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 -->
### 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 : 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 and earlier
- 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/2618BUG: functionObjectProperties: baseDict.findDict(objectName); interrupts func...2022-10-26T14:14:58ZKutalmış BerçinBUG: functionObjectProperties: baseDict.findDict(objectName); interrupts function object restarts### Summary
`./Allrun` the test case [GL2616-test-case.zip](/uploads/9875eb5b1df41f0da5bb35133dd6fbe8/GL2616-test-case.zip) with 0c3a938810. The restart with `pisoFoam` will throw the error below:
```
--> FOAM FATAL IO ERROR: (openfoa...### Summary
`./Allrun` the test case [GL2616-test-case.zip](/uploads/9875eb5b1df41f0da5bb35133dd6fbe8/GL2616-test-case.zip) with 0c3a938810. The restart with `pisoFoam` will throw the error below:
```
--> FOAM FATAL IO ERROR: (openfoam-2206 patch=220907)
Entry 'totalIter' not found in dictionary "
```
### Possible fixes
Change `objectName` in [functionObjectProperties.C#L140](https://develop.openfoam.com/Development/openfoam/-/blob/develop/src/OpenFOAM/db/functionObjects/functionObjectProperties/functionObjectProperties.C#L140) to `entryName`.Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2617simplify openmp handling2023-01-26T14:31:13ZMark OLESENsimplify openmp handlingCurrent wmake/rules define `-DUSE_OMP`, which was added for integration of cfmesh but isn't needed in general.
- simplify by removing that define (handle separately within cfmesh) and also provide an option to override from wmake itself...Current wmake/rules define `-DUSE_OMP`, which was added for integration of cfmesh but isn't needed in general.
- simplify by removing that define (handle separately within cfmesh) and also provide an option to override from wmake itself. Eg (`wmake -no-openmp`)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2616AABBTree can recurse indefinitely2022-11-24T12:21:09ZMark OLESENAABBTree can recurse indefinitelySince the AABB boxes overlap, it is possible that after splitting a node there is so much excess that the left/right almost entirely overlap or that the splitting is actually ineffective. In this case need to stop there, otherwise it wil...Since the AABB boxes overlap, it is possible that after splitting a node there is so much excess that the left/right almost entirely overlap or that the splitting is actually ineffective. In this case need to stop there, otherwise it will recurse indefinitely.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2615Wrong radial velocity near the rotating wall (rotatingWallVelocity)2022-10-27T11:44:07ZJinghong SuWrong radial velocity near the rotating wall (rotatingWallVelocity)I am using the type rotatingWallVelocity to simulate taylor-couette flow. Strangely, the radial velocity of the rotating wall is equal to 0, while the cells close to the rotating wall, especially the first layer cells, show abnormal radi...I am using the type rotatingWallVelocity to simulate taylor-couette flow. Strangely, the radial velocity of the rotating wall is equal to 0, while the cells close to the rotating wall, especially the first layer cells, show abnormal radial velocities. In order to observe this phenomenon more clearly, I simulated the case where the inner and outer walls have the same angular velocity. The inlet and outlet are set to be cyclic. The front patch and back patch are set to be empty.
The magnitude of velocity
![image](/uploads/0f7078bbf688b88557c3b30965848655/image.png)
The radial velocity(ur)
![image](/uploads/6afd7c719a5c92133ad1e1fa2767e020/image.png)
The radial velocity(ur) is obtained by codes following:
`dimensionedVector zNormal("zNormal", dimless, vector(0.0, 0.0, 1.0));volVectorField C = mesh.C();
volVectorField xy = (C - zNormal * (C & zNormal));
ur = U & xy / mag(xy);`
The run file is attached below
[rotatingWallVelocity_test.zip](/uploads/e4004366ceb38fae485b6d9253610224/rotatingWallVelocity_test.zip)
OpenFOAM version : v2012
Operating system : centoshttps://develop.openfoam.com/Development/openfoam/-/issues/2614First summand is added twice in integratedNonUniformTable2022-12-21T17:34:48ZMartin BeckerFirst summand is added twice in integratedNonUniformTableIn file
/src/thermophysicalModels/thermophysicalProperties/thermophysicalFunctions/integratedNonUniformTable/integratedNonUniformTableThermophysicalFunction.C
lines 69 and 109 , and same for lines 70 and 127:
The first summand "intf_[i-...In file
/src/thermophysicalModels/thermophysicalProperties/thermophysicalFunctions/integratedNonUniformTable/integratedNonUniformTableThermophysicalFunction.C
lines 69 and 109 , and same for lines 70 and 127:
The first summand "intf_[i-1]" is added twice, once in line 58 and then again in line 87 in the member function intfdT().
Same for intfByTdT.
In OpenFOAM-dev this was just fixed:
https://bugs.openfoam.org/view.php?id=3915Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2613Reconstructing a mesh with a cyclic fixed Jump returns errors.2022-12-23T15:15:14ZNidal SaabReconstructing a mesh with a cyclic fixed Jump returns errors.Whenever I try to reconstruct a case with a fixed jump boundary condition I get the following error. running this with OpenFOAM v8, and v9 works just fine.
Here is the error:
`Create time
Reconstructing fields for mesh region0
Time...Whenever I try to reconstruct a case with a fixed jump boundary condition I get the following error. running this with OpenFOAM v8, and v9 works just fine.
Here is the error:
`Create time
Reconstructing fields for mesh region0
Time = 0.015s
Reconstructing FV fields
Reconstructing volScalarFields
nut
p
--> FOAM FATAL ERROR:
Attempt to cast type processorCyclic to type fixedJump
From function To& Foam::refCast(From&) [with To = const Foam::fixedJumpFvPatchField<double>; From = const Foam::fvPatchField<double>]
in file /home/ubuntu/OpenFOAM/OpenFOAM-10/src/OpenFOAM/lnInclude/typeInfo.H at line 114.
FOAM aborting
#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::error::abort() at ??:?
#2 Foam::fixedJumpFvPatchField<double> const& Foam::refCast<Foam::fixedJumpFvPatchField<double> const, Foam::fvPatchField<double> const>(Foam::fvPatchField<double> const&) at ??:?
#3 non-virtual thunk to Foam::fixedJumpFvPatchField<double>::rmap(Foam::fvPatchField<double> const&, Foam::List<int> const&) at ??:?
#4 ? in "/opt/openfoam10/platforms/linux64GccDPInt32Opt/bin/reconstructPar"
#5 ? in "/opt/openfoam10/platforms/linux64GccDPInt32Opt/bin/reconstructPar"
#6 ? in "/opt/openfoam10/platforms/linux64GccDPInt32Opt/bin/reconstructPar"
#7 ? in "/opt/openfoam10/platforms/linux64GccDPInt32Opt/bin/reconstructPar"
#8 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#9 ? in "/opt/openfoam10/platforms/linux64GccDPInt32Opt/bin/reconstructPar"
Aborted (core dumped)
`Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2612distributedTriSurfaceMesh does not like having zero triangles on a processor2022-11-24T12:21:09ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comdistributedTriSurfaceMesh does not like having zero triangles on a processor<!--
*** 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 -->
If a small surface gets used as a distributedTriSurfaceMesh it can happen that zero triangles end up on a processor. This upsets the local tree searching since it assumes there is at least on node on the tree.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
### 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
-->
[bug.zip](/uploads/51dced42aacaded54abda43b02e0ec4d/bug.zip)
Run decomposePar & parallel snappyHexMesh (see the ./Allrun script). Exits with a sigsegv due to accessing out-of-bounds
### 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
- 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
-->
Avoid local searching if no tree.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2611mirrorMesh not mirroring cellLevel and pointLevel fields2022-10-18T07:59:40Zfranco otaolamirrorMesh not mirroring cellLevel and pointLevel fields<!--
*** 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 mirrorMesh utility, does not mirror cellLevel and pointLevel data generated by snappyHexMesh while meshing. this breaks the possibility of using some tools such as renumberMesh or redistributePar.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Create a mesh using snappyHexMesh, mirror it using mirrorMesh and then try to use renumberMesh the last one will give an error about the size is not equal in cellLevel
### What is the current *bug* behaviour?
<!-- What actually happens -->
the cellLevel and pointLevel are not being mirrored
### What is the expected *correct* behavior?
<!-- What you should see instead -->
the cellLevel and pointLevel should be mirrored and added to each field
### 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.
-->
the error part of the log for renumberMesh for example:
```
[49]
[49]
[49] --> FOAM FATAL IO ERROR: (openfoam-2206)
[49] size 15139 is not equal to the expected length 30278
[49]
[49] file: processor49/0/cellLevel at line 19 to 88.
[49]
[49] From Foam::Field<Type>::Field(const Foam::word&, const Foam::dictionary&, Foam::label) [with Type = double; Foam::label = long int]
[49] in file /local1/openfoam/OpenFOAM-v2206/src/OpenFOAM/lnInclude/Field.C at line 218.
[49]
FOAM parallel run exiting
```
### 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
- Operating system :centOS
- Hardware info :
- Compiler :precompiled package for redhat
### 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
-->
right now the easy solution, in case that we dont need the cellLevel and pointLevel fields, as for the case of renumberMesh, we can simply delete this fields by for example ```rm -f processor*/0/cellLevels``` nevertheless this fields are necessary in other cases. this issue has been discussed and adressed in the fondation vr (issue 0002712)https://develop.openfoam.com/Development/openfoam/-/issues/2610windAroundBuildings tutorial leaks when used with cellZones2022-10-20T14:28:00ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comwindAroundBuildings tutorial leaks when used with cellZones### Functionality to add/problem to solve
snappyHexMesh leaks through (topologically) closed surfaces. In the `incompressible/simpleFoam/windAroundBuildings` tutorial change the snappyHexMeshDict to mesh the surface as cellZones
```
...### Functionality to add/problem to solve
snappyHexMesh leaks through (topologically) closed surfaces. In the `incompressible/simpleFoam/windAroundBuildings` tutorial change the snappyHexMeshDict to mesh the surface as cellZones
```
refinementSurfaces
{
buildings
{
level (3 3);
patchInfo { type wall; }
faceZone buildings;
cellZone buildings;
cellZoneInside inside;
}
}
```
This will leak out of the marginal triangles. There are some problems with the surface:
- zero-sized edges
- a region with inconsistent orientation (numbering of neighbouring vertices should be opposite)
but the leakage does not seem to be limited to that.
Ideally the intersection / nearest of the surfaces should not look at the disconnected triangles but look at the surface instead so rays can never shoot in between neighbouring triangles.
The current workaround is to increase the geometric tolerance on the triSurfaceMesh ('tolerance').
### Target audience
snappyHexMesh on marginal triangulations
### Proposal
Look into octree intersection/nearest classification. E.g. `treeDataPrimitivePatch<PatchType>::findIntersection`.
### What does success look like, and how can we measure that?
Above tutorial
### Links / references
### FundingMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.com