Development issueshttps://develop.openfoam.com/groups/Development/-/issues2024-01-25T10:10:27Zhttps://develop.openfoam.com/Development/openfoam/-/issues/3068snappyhexmesh simple multiregion test case meshes have very bad surface quali...2024-01-25T10:10:27Zmonkeyseesnappyhexmesh simple multiregion test case meshes have very bad surface quality and broken patches### Summary
### Steps to reproduce
Case attached, issue of bad patches happens on trivial and complex meshes where there's nesting or adjacency between the two regions.
### Example case
attached, case was generated with freecad thoug...### Summary
### Steps to reproduce
Case attached, issue of bad patches happens on trivial and complex meshes where there's nesting or adjacency between the two regions.
### Example case
attached, case was generated with freecad though problem has been scene with other stl generation methods like salome. I chose a tapered shape, a wedge - I've observed snappy having problems
multiregion contains a configuration geared towards conformal meshing of 2 regions in one meshing invocation. splitmesh is geared to one meshing per invocation. The snapped surface quality is substantially higher in the splitmesh version, though both have a oddly large repeating gap or trouble at the same points on the simple inner region.
[meshing.tar](/uploads/630be6ec3e30b4ba726c337ec459924a/meshing.tar)
[mycad.FCStd](/uploads/be114e3949faefbf82cf9bc3d524768e/mycad.FCStd)
### What is the current _bug_ behaviour?
I think there's at least 2 issues here. One is that the patches are very messed up. The second is that we get an odd behavior in both of these cases around the same region in space which is implicated into the patches being malformed. There's also a macro tear happening through the inner region which doesn't make much sense to me.
In similar or more advanced cases I've noted degenerate faces, near zero area at times or varying surface normals or alternate assignments of faces to differing patches. Flow would absolutely get mangled with these surfaces and the degenerate elements will drive courant numbers.
Here's a single pass multiregion output, note the very bad patches - the "inner" patch surface and "inner_to_outer" are disjoint and both incomplete. Makes downstream work impractical.
![multiregion-no-facezones-bad-patches.png](/uploads/f70836593d758a849215a22897202975/multiregion-no-facezones-bad-patches.png)
![multiregion-no-facezones.png](/uploads/9729e13786d0d2f8c3c856641da539fd/multiregion-no-facezones.png)
absolute nuttyness here:
![multiregion-no-facezones-nuttyness.png](/uploads/119ae64b047463f526445db0b71e71e5/multiregion-no-facezones-nuttyness.png){width="908" height="565"}
### What is the expected _correct_ behavior?
Here's a better though still a little odd mesh result for inner. This was meshed using separate invocations of snappyhexmesh so there's only one region at a time. It should be possible to get a conformal mesh result given there is only a single surface present at the interface which would give better topological information and allow skipping ami based interpolation without needing more advanced patch evaluation like https://cfd.direct/openfoam/free-software/non-conformal-coupling/
![splitmesh-same-settings.png](/uploads/6bad85fa172c854b20e550371c5a0e97/splitmesh-same-settings.png)
one more level of refinement was allowed for this to see what would happen:
![splitmesh-inner-edges-r3.png](/uploads/b752f08b51bc62c1e38bbab3d293a402/splitmesh-inner-edges-r3.png)
### Relevant logs and/or images
### Environment information
- OpenFOAM version : 2312
- Operating system : linux opensuse 15.5
- Hardware info :\`
- Compiler :
### Possible fixeshttps://develop.openfoam.com/Development/openfoam/-/issues/3067Different residuals between serial and decomposed parallel case2024-01-18T12:47:18ZDjilou MioubDifferent residuals between serial and decomposed parallel caseGreetings,
In running the cavity tutorial I've noticed that the residuals differ between the serial case and the decomposed case.
The steps I followed are:
- run the serial case `icoFoam > logSerial`
- Without changing anything except...Greetings,
In running the cavity tutorial I've noticed that the residuals differ between the serial case and the decomposed case.
The steps I followed are:
- run the serial case `icoFoam > logSerial`
- Without changing anything except the `decomposeParDict` file changed the number of subdomains to `2` and used the method `scotch`, then run: `mpirun -n 2 icoFoam -parallel > logParallel`
I run it for only 2 time steps, then compare the log files:
![image](/uploads/b0d38805f29d5fad47a37e6e81fa72ff/image.png)
Why there is a difference between the serial and parallel case?
**Note**: I am using the version 2306 on Ubuntu 22.04https://develop.openfoam.com/Development/openfoam/-/issues/3066masterUncollatedFileOperation compilation error on 23122024-01-20T15:12:18ZMatej FormanmasterUncollatedFileOperation compilation error on 2312### compilation problem.
I have: fetched the 2312 source code from master.
I have set my etc-darwin to take most of the libs fro the system (homebrew).
Compilation run with -j -l options.
``
Opt/src/OpenFOAM/primitives/ints/int32/int3...### compilation problem.
I have: fetched the 2312 source code from master.
I have set my etc-darwin to take most of the libs fro the system (homebrew).
Compilation run with -j -l options.
``
Opt/src/OpenFOAM/primitives/ints/int32/int32IO.o
make: *** [/Volumes/ofdisk/OpenFOAM-v2312/build/darwin64ClangDPInt32Opt/src/OpenFOAM/global/fileOperations/masterUncollatedFileOperation/masterUncollatedFileOperation.o] Error 1
make: *** Waiting for unfinished jobs....
Done logging to 'log.darwin64ClangDPInt32Opt'
``
my prefs.sh:
`
export projectDir="/Volumes/OFdisk/OpenFOAM-v2312"
export FOAM_CONFIG_ETC=etc-darwin
export WM_COMPILER_TYPE=system
export WM_COMPILER=Clang
export WM_PRECISION_OPTION=DP
export WM_LABEL_SIZE=32
export WM_COMPILE_OPTION=Opt
export WM_MPLIB=SYSTEMOPENMPI
export SCOTCH_VERSION=scotch-system
export fftw_version=fftw-system
export boost_version=boost-system
export cgal_version=cgal-system
export SCOTCH_ARCH_PATH=/usr/local/Cellar/scotch/7.0.4 ## 6.1.1 # run brew info scotch
export FFTW_ARCH_PATH=/usr/local/Cellar/fftw/3.3.10_1
export MPI_ARCH_PATH=/usr/local/Cellar/open-mpi/4.1.5
export BOOST_ARCH_PATH=/usr/local/Cellar/boost/1.82.0_1
export CGAL_ARCH_PATH=/usr/local/Cellar/cgal/5.6
export LDFLAGS="-L/usr/local/opt/readline/lib"
export CPPFLAGS="-I/usr/local/opt/readline/include"
export CXXFLAGS="-I/usr/local/Cellar/flex/2.6.4_2/include"
export FOAM_EXTRA_CXXFLAGS="-I/usr/local/Cellar/flex/2.6.4_2/include -DBOOST_MATH_DISABLE_FLOAT128"
export VTK_DIR="/usr/local/Cellar/vtk/9.2.5_1" # for runTimePostprocessing FO
export CMAKE_INCLUDE_PATH="/usr/local/Cellar/flex/2.6.4_2/include"
export CMAKE_LIBRARY_PATH="/usr/local/Cellar/flex/2.6.4_2/lib"
`Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/3065argList checking does not release all memory upon failure2024-01-03T10:12:34ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comargList checking does not release all memory upon failure<!--
*** 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 -->
small one: argList checking does not release all memory upon failure.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Run any app with incorrect args.
### 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.
-->
```
mattijs$ valgrind --leak-check=full --show-leak-kinds=all subsetMesh
==38812== Memcheck, a memory error detector
==38812== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==38812== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==38812== Command: subsetMesh
==38812==
Using: OpenFOAM-v2312 (2312) - visit www.openfoam.com
Build: _8afb4c8ecf-20231220
Expected 1 arguments but found 0
See 'subsetMesh -help' for usage
or 'subsetMesh -help-full' for extended usage
==38812==
==38812== HEAP SUMMARY:
==38812== in use at exit: 104 bytes in 2 blocks
==38812== total heap usage: 44,804 allocs, 44,802 frees, 4,078,666 bytes allocated
==38812==
==38812== 40 bytes in 1 blocks are still reachable in loss record 1 of 2
==38812== at 0x4A3813F: operator new[](unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==38812== by 0x892FB4C: Foam::argList::argList(int&, char**&, bool, bool, bool) (in OpenFOAM/OpenFOAM-plus/release/OpenFOAM-v2312/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so)
==38812== by 0x45A66F: main (in OpenFOAM/OpenFOAM-plus/release/OpenFOAM-v2312/platforms/linux64GccDPInt32Opt/bin/subsetMesh)
```
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2312|v2306|v2212|v2206|v2112 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2312Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/3064streamFunction FO message about not finding seed2023-12-20T13:10:09ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comstreamFunction FO message about not finding seed<!--
*** 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 -->
streamFunction FO reports message about not finding starting seed. Investigate. Also indentation of various FOs (see case below) is not consistent.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Run `incompressible/pisoFoam/RAS/cavity`
### What is the current *bug* behaviour?
Message about streamFunction not finding seed.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2306|v2212|v2206|v2112|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2310https://develop.openfoam.com/Development/openfoam/-/issues/3063scotch : different behaviour with/without weights2023-12-20T15:01:04ZMark OLESENscotch : different behaviour with/without weightsAs noted by @Mattijs and @Prashant, it appears that scotch produces a different decomposition if uniform weights are specified versus no weights. Internally they should be the same thing, but needs more investigation.
Modifies changes m...As noted by @Mattijs and @Prashant, it appears that scotch produces a different decomposition if uniform weights are specified versus no weights. Internally they should be the same thing, but needs more investigation.
Modifies changes made in 98246a438eMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/3062OPENMPI version in ThirdParty2024-01-18T12:46:44ZJozsef NagyOPENMPI version in ThirdParty### Summary
Incorrect openmpi version in etc/config.sh/mpi
### Steps to reproduce
In the current dev version in
etc/config.sh/mpi
it says
export FOAM_MPI=openmpi-4.1.2
If one selects in etc/bashrc
export WM_MPLIB=OPENMPI
there ...### Summary
Incorrect openmpi version in etc/config.sh/mpi
### Steps to reproduce
In the current dev version in
etc/config.sh/mpi
it says
export FOAM_MPI=openmpi-4.1.2
If one selects in etc/bashrc
export WM_MPLIB=OPENMPI
there is an error while compiling the ThirdParty directory, as the latest downloadable ThirdParty version is v2106 and there the openmpi version is 4.0.3
If one changes the version to
export FOAM_MPI=openmpi-4.0.3
compilation runs just fine. Possibly it would be a good idea to change the entry in etc/config.sh/mpi to 4.0.3, as this is the version shipping officially.
### Example case
not needed
### What is the current *bug* behaviour?
compilation error due to missing openmpi version
### What is the expected *correct* behavior?
correct compilation of 4.0.3
### Relevant logs and/or images
not needed
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2306|v2212|v2206|v2112|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : dev
- Operating system : ubuntu
- Hardware info : not needed
- Compiler : gcc
### Possible fixes
change entry to 4.0.3 or ship 4.1.2 in ThirdParty-v2312https://develop.openfoam.com/Development/openfoam/-/issues/3061Mistake in documentation? Linear eddy viscosity models2023-12-19T06:18:48ZAli BozorgzadehMistake in documentation? Linear eddy viscosity modelsI think there is a mistake in the documentation in [this link](https://doc.openfoam.com/2306/tools/processing/models/turbulence/ras/linear-evm/).
The mistake can be found right after "leading to:". The second term on the right hand side...I think there is a mistake in the documentation in [this link](https://doc.openfoam.com/2306/tools/processing/models/turbulence/ras/linear-evm/).
The mistake can be found right after "leading to:". The second term on the right hand side should have a negative sign. It should be like the following:
```math
-\rho \textbf{R}_{dev} = \mu_t \left( \nabla \overline{\textbf{u}} + \nabla (\overline{\textbf{u}})^T \right) {\color{red}-} \mu_t \left( \frac{2}{3} \nabla \cdot \textbf{u} \right) \textbf{I}
```https://develop.openfoam.com/Development/openfoam/-/issues/3060[future request] snappyHexMesh: 'std::out_of_range' error2023-12-19T08:39:15ZAkira Azami[future request] snappyHexMesh: 'std::out_of_range' error### Summary
The following error occurred when testing on the supercomputer Fugaku Pre/Post node (large memory(6TB on board)).
\[error messages\] terminate called after throwing an instance of 'std::out_of_range' what(): stoi
It appear...### Summary
The following error occurred when testing on the supercomputer Fugaku Pre/Post node (large memory(6TB on board)).
\[error messages\] terminate called after throwing an instance of 'std::out_of_range' what(): stoi
It appears that the information on the size of the memory could not be expressed integer range.
### Example case
### Steps to reproduce
\[tutorials\] tutorials/incompressible/pisoFoam/LES/motorBike/motorBike (When snappyHexMesh is executed)
$ ./Allrun
### Environment information
- OpenFOAM version : v2306, v2212, etc
- Operating system : RHEL 8.6 (kernel 4.18.0-372)
- Hardware info : Intel Xeon Platinum 8280L (2.70GHz/28core)
- Compiler : icpc (ICC) 2021.10.0 20230609
### Possible fixes
Changing the stoi function in src/OSspecific/POSIX/memInfo/memInfo.C to the stol function will terminate successfully. This correction was found by Fugaku support staff.
```
diff -r 146727f129a6 -r b255d5d23e65 src/OSspecific/POSIX/memInfo/memInfo.C
--- a/OpenFOAM-v2306/src/OSspecific/POSIX/memInfo/memInfo.C Fri Sep 22 16:37:54 2023 +0900
+++ b/OpenFOAM-v2306/src/OSspecific/POSIX/memInfo/memInfo.C Fri Sep 22 16:46:00 2023 +0900
@@ -100,17 +100,17 @@
if (key == "VmPeak")
{
- peak_ = std::stoi(line.substr(delim+1));
+ peak_ = std::stol(line.substr(delim+1));
--nkeys;
}
else if (key == "VmSize")
{
- size_ = std::stoi(line.substr(delim+1));
+ size_ = std::stol(line.substr(delim+1));
--nkeys;
}
else if (key == "VmRSS")
{
- rss_ = std::stoi(line.substr(delim+1));
+ rss_ = std::stol(line.substr(delim+1));
--nkeys;
}
}
@@ -148,7 +148,7 @@
if (key == "MemFree")
{
- free_ = std::stoi(line.substr(delim+1));
+ free_ = std::stol(line.substr(delim+1));
--nkeys;
}
}
```Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/3059Free Stream BC not working with ABL2023-12-19T10:11:10ZRaphael AranhaFree Stream BC not working with ABL<!--
*** 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
The freeStream BC is not working properly with atmBoundaryLayerInletVelocity. It is not loading the information of the ABL and only using the value .
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
### Example case
if you try to run the example in the link https://www.openfoam.com/documentation/guides/latest/api/classFoam_1_1freestreamFvPatchField.html
it will not work, it will request a value and the value will overwrite the ABL profile
<!--
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 : v2306|v2212|v2206|v2112|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :v2306
- Operating system : ubuntu
- 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
-->https://develop.openfoam.com/Development/openfoam/-/issues/3058solver displacementLaplacian not working in v2212 and v2306 windows distribution2023-12-21T16:24:31ZDuncan van der Heulsolver displacementLaplacian not working in v2212 and v2306 windows distribution<!--
*** 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
snappyHexMesh can not find the displacementLaplacian solver required for the cell displacement in the layer addition step.
### Steps to reproduce
run tutorial \mesh\snappyHexMesh\iglooWi thFridgesDirectionalRefinement
### 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?
snappyHexMesh fails to generate mesh layer addition
### What is the expected *correct* behavior?
snappyHexMesh successfully completes mesh layer addition
### Relevant logs and/or images
Selecting motion solver: displacementLaplacian
--> FOAM FATAL IO ERROR: (openfoam-2212)
Unknown solver type displacementLaplacian
Valid solver types :
2(displacementInterpolation displacementLayeredMotion)
file: system/snappyHexMeshDict.addLayersControls at line 300.
From static Foam::autoPtr<Foam::displacementMotionSolver> Foam::displacementMotionSolver::New(const Foam::word&, const Foam::polyMesh&, const Foam::IOdictionary&, const pointVectorField&, const pointIOField&)
in file motionSolvers/displacement/displacement/displacementMotionSolver.C at line 115.
FOAM exiting
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2306|v2212|v2206|v2112|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :V2212/v2306
- Operating system :Windows10
- Hardware info :Intel I9
- 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
-->Pawan GhildiyalPawan Ghildiyalhttps://develop.openfoam.com/Development/openfoam/-/issues/3057bug: Is this file supposed to be nuTilda not muTilda2024-01-03T09:56:28ZHAN BINbug: Is this file supposed to be nuTilda not muTildaIs this file supposed to be nuTilda instead of muTilda? Why are all the other models nuTilda? This one is muTilda. There is only one LES case in the compressible directory.The file address is below
https://develop.openfoam.com/Developme...Is this file supposed to be nuTilda instead of muTilda? Why are all the other models nuTilda? This one is muTilda. There is only one LES case in the compressible directory.The file address is below
https://develop.openfoam.com/Development/openfoam/-/blame/master/tutorials/compressible/rhoPimpleFoam/LES/pitzDaily/0/muTilda#L13https://develop.openfoam.com/Development/openfoam/-/issues/3056checkMesh writes fields with 'calculated' also on empty patches2023-12-13T17:10:59ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcheckMesh writes fields with 'calculated' also on empty patches<!--
*** 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 -->
`checkMesh -writeAllFields` on case with empty writes volFields with 'calculated' on empty patches. E.g. paraview does not like this at all.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
```
cavity tutorial
checkMesh -writeAllFields
```
and look at e.g. `faceWeight` on frontAndBack empty patches.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
Probably not override the empty constraint? Or have paraview accept `patchType` override?
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2306|v2212|v2206|v2112|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2310https://develop.openfoam.com/Development/openfoam/-/issues/3055snappyHexMesh :: Prediction of maxNewCells wrong with new code2023-12-15T22:25:11ZTobias HolzmannsnappyHexMesh :: Prediction of maxNewCells wrong with new code<!--
*** 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
Hey everybody,
in v2306, the balancing method within snappy was improved based on the code snippet I provided to L2.
https://develop.openfoam.com/Development/openfoam/-/merge_requests/607
The issue appears now due to a one-liner change from Mattijs:
- This line now calculates only zero for the `maxLocalCell` variable, if we first refine and then balance https://develop.openfoam.com/Development/openfoam/-/commit/4a5f542cb431665fc85165e13b29ab1202b99aa3#31acf059fb90704d54379ac0c705eac1a85803dd_2601_2632
- This is related to the fact that this line was introduced by Mattijs to fix the wrong `balance` calculation: https://develop.openfoam.com/Development/openfoam/-/blob/develop/src/mesh/snappyHexMesh/meshRefinement/meshRefinementRefine.C?ref_type=heads#L2762
Hence, the calculation of `maxLocalCells` is wrong (as it is zero all the time and the trigger value will never be taken into account). However, this value is mainly necessary if e.g., locally on one single proc a refinement happens significantly (imagine a refinement based on the surfaceFeatureAngle while using a `level (4 6)` refinement for example.
The discrepancy at the moment is:
- The balancing factor is calculated correctly (in previous versions we were over predicting the nNewCells value due to the fact that the refinement took place alreads)
- On the other hand, the balancing trigger value `maxLocalCells` is zero now (if refineAndBalance is used) and thus, the trigger will not be used anymore
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
To check that the values of `maxLocalCells` are always zero, simply execute snappyHexMesh while having `maxLocalCells 100000000;` to explicitly go step into the `refineAndBalance` function rather than `balanceAndRefine`.
<!-- How one can reproduce the issue - this is very important -->
<!--
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?
Described in the summary.
<!-- What actually happens -->
### What is the expected *correct* behavior?
If we use `refineAndBalance` the `maxLocalCells` should be calculated correctly.
<!-- What you should see instead -->
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->https://develop.openfoam.com/Development/openfoam/-/issues/3054updates of solver performance destroy pimple controls2023-12-13T11:42:14ZMark OLESENupdates of solver performance destroy pimple controlsWith commit 0ff86ee2e the management of firstIteration/finalInteration migrated into meshState. However, there is folded into the solverPerformance dictionary which is cleared with `setSolverPerformance` if the time index changes.
Optio...With commit 0ff86ee2e the management of firstIteration/finalInteration migrated into meshState. However, there is folded into the solverPerformance dictionary which is cleared with `setSolverPerformance` if the time index changes.
Options:
- ad hoc preservation of firstIteration/finalInteration when clearing the solverPerformaanceDict
- move firstIteration/finalInteration into a "controls" sub-dictionary and/or place in the main mesh state dictionary.
Reported by @MattijsMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/3053multiWorld not working with AMI2023-12-18T10:48:03ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commultiWorld not working with AMI<!--
*** 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 -->
multiWorld not working with AMI. On e.g. `tutorials/basic/laplacianFoam/multiWorld1` you'll get errors:
```
[right/0]
[right/0]
[right/0] --> FOAM FATAL ERROR: (openfoam-2309)
[right/0] attempt to access element 0 from zero sized list
[right/0]
[right/0] From void Foam::UList<Foam::List<int> >::checkIndex(const Foam::label) const [T = Foam::List<int>]
[right/0] in file /home/mattijs/OpenFOAM/OpenFOAM-plus/work/develop/openfoam/src/OpenFOAM/lnInclude/UListI.H at line 207.
[right/0]
```
### Steps to reproduce
See above
### 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 above
### What is the current *bug* behaviour?
<!-- What actually happens -->
See above
### 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.
-->
See above
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2306|v2212|v2206|v2112|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2308
### 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
-->
The AMIInterpolation now stores its own communicator (to be able to handle processor-agglomeration). This get set to worldComm at construction time. Instead it needs to be reset to the inter-world communicator.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/3052GAMG: support for polling2023-12-18T15:49:40ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comGAMG: support for polling<!--
*** 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 -->
processorGAMGInterfaceField does not implement ready() even though it maintains its own requests. Hence any polling will call matrixInterfaceUpdate in original order, negating any benefit of polling. Note that it only affects operations inside the GAMG solver.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Hard. Default lduInterfaceField::ready() returns true so it will do the waiting instead in the matrixInterfaceUpdate routine.
### What is the current *bug* behaviour?
<!-- What actually happens -->
Order of GAMG interface updates is always the same.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
Re-runs might give slightly different truncation error.
### 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 : v2306|v2212|v2206|v2112|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2309https://develop.openfoam.com/Development/openfoam/-/issues/3051foamFormatConvert messing up files2023-12-19T08:19:28ZFranz DfoamFormatConvert messing up files### Summary
When converting a Lagrangian case from binary to ascii with foamFormatConvert, it's messing up some values, notably the origID of the particles in the particleTracks. While they are fine in binary, or when running the case i...### Summary
When converting a Lagrangian case from binary to ascii with foamFormatConvert, it's messing up some values, notably the origID of the particles in the particleTracks. While they are fine in binary, or when running the case in ASCII from the beginning, they are set to -1 when converting the case.
### Steps to reproduce / Example
This can be reproduced using the tutorial case /tutorials/lagrangian/simpleReactingParcelFoam/verticalChannel
1. Edit the controlDict to have `writeFormat binary;` (instead of the default `ascii`)
2. Run the case (at least until it writes one step, that's a matter of a few seconds)
3. Do a quick `touch a.foam` and check the particleTracks in Paraview. The tracks have a value in the origId. This is how it should be.
4. Change the controlDict back to `writeFormat ascii;`
5. run `foamFormatConvert`
6. Go to verticalChannel/20/lagrangian/reactingCloud1Tracks, and have a look at the file origId (no need for Paraview, as it's ascii now), it now says `6202{-1}`, i.e. all origId entries in the track are `-1` (which is not very useful).
### What is the current *bug* behaviour?
origID becomes -1
### What is the expected *correct* behavior?
No change in the file contents.
### 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
- OpenFOAM version : v2306
- Operating system : Ubuntu 22.04.3 LTS
- 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
-->Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/3050Wrong keyword in template file for particleTrackProperties2023-12-18T15:49:05ZFranz DWrong keyword in template file for particleTrackPropertiesIn /applications/utilities/postProcessing/lagrangian/particleTracks/particleTrackProperties
Keyword in file (line 17): `cloudName`
Keyword expected by utility particleTracks: `cloud`In /applications/utilities/postProcessing/lagrangian/particleTracks/particleTrackProperties
Keyword in file (line 17): `cloudName`
Keyword expected by utility particleTracks: `cloud`Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/3049snappyHexMesh bit more printing2023-12-21T11:54:41ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsnappyHexMesh bit more printing### Functionality to add/problem to solve
Have more information about the layer generation outer iterations
### What does success look like, and how can we measure that?
Include the wanted number of layers to the printed information:...### Functionality to add/problem to solve
Have more information about the layer generation outer iterations
### What does success look like, and how can we measure that?
Include the wanted number of layers to the printed information:
```
patch faces layers overall thickness
target mesh [m] [%]
----- ----- ----- ---- --- ---
maxY 20 3 3 0.00061 87.1
minY 20 3 3 0.00061 87.1
A 12 3 3 0.000479 68.5
A_slave 12 3 3 0.000479 68.5
```Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.com