Development issueshttps://develop.openfoam.com/groups/Development/-/issues2023-10-28T14:01:38Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2961OpenFOAM v2306 gives YY_BUF_SIZE declare in scope error2023-10-28T14:01:38ZAziz ÖğütlüOpenFOAM v2306 gives YY_BUF_SIZE declare in scope errorI'm trying to compile openfoam v2306 on Centos 7.9 and I got YY_BUF_SIZE declare in scope error. Compiling process is attached to issue.[compiling_openfoam_v2306.txt](/uploads/cca81faecd94e20e0dc701f607057409/compiling_openfoam_v2306.txt)I'm trying to compile openfoam v2306 on Centos 7.9 and I got YY_BUF_SIZE declare in scope error. Compiling process is attached to issue.[compiling_openfoam_v2306.txt](/uploads/cca81faecd94e20e0dc701f607057409/compiling_openfoam_v2306.txt)https://develop.openfoam.com/Development/openfoam/-/issues/2959snappyHexMesh -dryRun fails2023-08-22T07:50:10ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsnappyHexMesh -dryRun fails<!--
*** 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 -->
`snappyHexMesh -dryRun` should checks (most) settings and give an estimate of expected cell count. It fails on the leak-path detection.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Any case with `locationsOutsideMesh`. Run `snappyHexMesh -dryRun`.
### What is the current *bug* behaviour?
<!-- What actually happens -->
segmentation error
### 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
Fix provided by @Prashant
@Prashanthttps://develop.openfoam.com/Development/openfoam/-/issues/2957Could not load libfieldFunctionObjects.so and user created library2023-08-08T07:38:02ZNicolas CharalambousCould not load libfieldFunctionObjects.so and user created libraryHi,
I have created a user defined object using the wmake in OPENFOAM 20.06. The in Make the files contained the following:
Helicity.C
LIB = $(FOAM_USER_LIBBIN)/helicity
Therefore, the new created object was helicity.so.
I included bo...Hi,
I have created a user defined object using the wmake in OPENFOAM 20.06. The in Make the files contained the following:
Helicity.C
LIB = $(FOAM_USER_LIBBIN)/helicity
Therefore, the new created object was helicity.so.
I included both helicity.so and libfieldFunctionObjects.so in controldict. However,
when running interphaseChangeFoam I am getting the following:
```
--> FOAM Warning :
From void* Foam::dlLibraryTable::openLibrary(const Foam::fileName&, bool)
in file db/dynamicLibrary/dlLibraryTable/dlLibraryTable.C at line 65
Could not load "libfieldFunctionObjects.so"
/home/ncharala/OpenFOAMv2006/OpenFOAM-v2006/platforms/linux64GccDPInt32Opt/lib/libfieldFunctionObjects.so: undefined symbol: _ZTIN4Foam15functionObjects15fieldExpressionE
--> FOAM Warning :
From void* Foam::dlLibraryTable::openLibrary(const Foam::fileName&, bool)
in file db/dynamicLibrary/dlLibraryTable/dlLibraryTable.C at line 65
Could not load "helicity.so"
```
How can I fix this?
Thank you
Nicolashttps://develop.openfoam.com/Development/openfoam/-/issues/2956Enabling SIGFPE on macOS arm642023-12-22T22:02:38ZGuanyang XueEnabling SIGFPE on macOS arm64### Summary
Enabling `SIGFPE` on macOS arm64
### Example case
Compile and run `applications/test/sigFpe` on ARM Mac it will print `Inf` instead of trapping `SIGFPE`.
### What is the current *bug* behaviour?
Results from `applications/t...### Summary
Enabling `SIGFPE` on macOS arm64
### Example case
Compile and run `applications/test/sigFpe` on ARM Mac it will print `Inf` instead of trapping `SIGFPE`.
### What is the current *bug* behaviour?
Results from `applications/test/sigFpe`
```
trapFpe: Floating point exception trapping - not supported on this platform
Provoking sigFpe (division by zero)
Infinity inf
```
Currently the code implemented by Tatsuya Shimizu https://develop.openfoam.com/Development/openfoam/-/commit/85760cbc347c4d5af01dd166084d452accd0b28e is not working, because:
1. On ARM64, `__fpcr` is the control register and `__fpsr` is the status register, see https://help.totalview.io/current/PDFs/TotalView_Reference_Guide.pdf page 453-454
2. On ARM64, the shift is 8 bits instead of 7 bits.
3. On ARM64, the mask definition is opposite to x86.
4. Even if everything is correct, Apple M1 throws `SIGILL` instead of `SIGFPE`. It terminates the executable and prints `illegal hardware instruction`.
I have fixed problem 1,2,3 in `feexceptErsatz.H`. For Problem 4, I did some dirty hack in `sigFpe.C` to enforce `SIGILL` in the handler. Currently there's no better way to implement this due to hardware/operating system limitations.
### What is the expected *correct* behavior?
After setting FPE masks, the CPU can trigger floating point exceptions, but throw 'SIGILL'. My fix picks up `SIGILL` and handles it as `SIGFPE` (only for macOS ARM64).
### Relevant logs and/or images
Results from `applications/test/sigFpe`
```
trapFpe: Floating point exception trapping enabled (FOAM_SIGFPE).
Provoking sigFpe (division by zero)
Infinity [stack trace]
=============
#1 Foam::sigFpe::sigHandler(int) in /Volumes/OpenFOAM/OpenFOAM-v2306/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#2 _sigtramp in /usr/lib/system/libsystem_platform.dylib
#3 main in Test-sigFpe
#4 start in /usr/lib/dyld
=============
zsh: floating point exception ./Test-sigFpe
```
Results from cavity tutorial case (set viscosity to negative number gives you immediate `SIGFPE`)
```
Starting time loop
Time = 0.005
Courant Number mean: 0 max: 0
smoothSolver: Solving for Ux, Initial residual = 1, Final residual = 3.87689e+220, No Iterations 1000
smoothSolver: Solving for Uy, Initial residual = 0, Final residual = 0, No Iterations 0
[stack trace]
=============
#1 Foam::sigFpe::sigHandler(int) in /Volumes/OpenFOAM/OpenFOAM-v2306/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#2 _sigtramp in /usr/lib/system/libsystem_platform.dylib
#3 Foam::PCG::scalarSolve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const in /Volumes/OpenFOAM/OpenFOAM-v2306/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#4 Foam::PCG::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const in /Volumes/OpenFOAM/OpenFOAM-v2306/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#5 Foam::fvMatrix<double>::solveSegregated(Foam::dictionary const&) in /Volumes/OpenFOAM/OpenFOAM-v2306/platforms/darwin64ClangDPInt32Opt/lib/libfiniteVolume.dylib
#6 Foam::fvMatrix<double>::solveSegregatedOrCoupled(Foam::dictionary const&) in /Volumes/OpenFOAM/OpenFOAM-v2306/platforms/darwin64ClangDPInt32Opt/lib/libfiniteVolume.dylib
#7 main in /Volumes/OpenFOAM/OpenFOAM-v2306/platforms/darwin64ClangDPInt32Opt/bin/icoFoam
#8 start in /usr/lib/dyld
=============
zsh: floating point exception icoFoam
```
### Environment information
- OpenFOAM version : All
- Operating system : macOS arm64
- Hardware info : Apple M1
- Compiler : Clang
### Possible fixes
I'm attaching two modified files in `src/OSspecific/POSIX/signals`. It shouldn't change anything on other platforms including x86 Macs. OpenFOAM SIGFPE can be successfully triggered on macOS arm64.
~~[feexceptErsatz.H](/uploads/5daae02b07e49ad02418463ec66ec342/feexceptErsatz.H)~~
~~[sigFpe.C](/uploads/ccdd9fb1744c206d6ddf79a5634e3751/sigFpe.C)~~
See comment for second versionhttps://develop.openfoam.com/Development/openfoam/-/issues/2955BUG: filmPyrolysisRadiativeCoupledMixed parallel error2023-09-08T10:48:52ZAndrew HeatherBUG: filmPyrolysisRadiativeCoupledMixed parallel error<!--
*** 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
As reported via @Prashant for EP#2050
### Steps to reproduce
See tutorial `combustion/fireFoam/LES/flameSpreadWaterSuppressionPanel`
- decompose each region (primary, film, pyrolysis) into 8 procs (used scotch)
- parallel failure at runtime due to operating on fields of different sizesv2312Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/2953provision for delayed reading of compound tokens2023-08-19T06:46:01ZMark OLESENprovision for delayed reading of compound tokensIn work initiated by @serge and @gregorweiss, the files are read and the compound token is tagged as such, but allocated with zero size. This maintains the token stream elements to allow delayed reading.In work initiated by @serge and @gregorweiss, the files are read and the compound token is tagged as such, but allocated with zero size. This maintains the token stream elements to allow delayed reading.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2951Deb package with Ubuntu 23.042023-08-02T18:58:36ZMarkus TowaraDeb package with Ubuntu 23.04### Summary
I followed the instructions here on XUbuntu 23.04
https://develop.openfoam.com/Development/openfoam/-/wikis/precompiled/debian
After this apt-get update complains:
```
E: The repository 'https://dl.openfoam.com/repos/deb...### Summary
I followed the instructions here on XUbuntu 23.04
https://develop.openfoam.com/Development/openfoam/-/wikis/precompiled/debian
After this apt-get update complains:
```
E: The repository 'https://dl.openfoam.com/repos/deb lunar Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
```
### Possible fixes
This path exists, however the release codename is lunar not luna
https://dl.openfoam.com/repos/deb/dists/luna/
Workaround: change lunar to luna in /etc/apt/sources.list.d/openfoam.listhttps://develop.openfoam.com/Development/openfoam/-/issues/2949BUG - AMI - areaNormalisationMode not written2023-09-01T10:39:30ZAndrew HeatherBUG - AMI - areaNormalisationMode not written`areaNormalisationMode` can be `project` or `mag` - but these values are not written in the boundary file for (re-)start`areaNormalisationMode` can be `project` or `mag` - but these values are not written in the boundary file for (re-)startv2312Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/2946Use UPtrList for managing objective functions2023-12-21T11:54:41ZMark OLESENUse UPtrList for managing objective functionsStumbled across these when examining other code...
The incompressiblePrimalSolver uses a List of pointers for the objective functions. I think that a UPtrList would make more sense. The primary reason being to encapsulate the pointer de...Stumbled across these when examining other code...
The incompressiblePrimalSolver uses a List of pointers for the objective functions. I think that a UPtrList would make more sense. The primary reason being to encapsulate the pointer dereference, as well as other methods (eg, test(), get(), ...).
The code that may need to be modified in any case is the use of lookupClass. This is usually OK, but there is no absolute guarantee about the iteration order.
Here's a code snippet using `sorted` instead, which generates a UPtrList as an intermediate type (a couple of allocations fewer than sending back a HashTable).
```
Foam::UPtrList<Foam::objective>
Foam::incompressiblePrimalSolver::getObjectiveFunctions() const
{
DynamicList<objective*> objectives;
for (auto& adjoint : mesh_.sorted<adjointSolver>())
{
if (adjoint.primalSolverName() == solverName_)
{
PtrList<objective>& managerObjectives =
adjoint.getObjectiveManager().getObjectiveFunctions();
for (objective& obj : managerObjectives)
{
objectives.push_back(&obj);
}
}
}
return UPtrList<objective>(objectives);
}
```Vaggelis PapoutsisVaggelis Papoutsishttps://develop.openfoam.com/Development/openfoam/-/issues/2944mapFieldsPar - source and target swapped - WIP code2023-09-01T11:13:55ZPrashant SonakarmapFieldsPar - source and target swapped - WIP codeDeveloped for [EP#944](https://exchange.openfoam.com/node/944)
and another [comment ](https://exchange.openfoam.com/node/2025#comment-21802)to be noted while integration
Only internal note.Developed for [EP#944](https://exchange.openfoam.com/node/944)
and another [comment ](https://exchange.openfoam.com/node/2025#comment-21802)to be noted while integration
Only internal note.Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/2940weightedFluxExample validation case does not plot anything2023-07-13T15:09:02ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comweightedFluxExample validation case does not plot anything<!--
*** 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 -->
functionObject produces line_T.xy or line_T_flux.xy. `plot` script expects `line_flux.xy`.
### 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-rc2
- Operating system :
- Hardware info :
- Compiler :Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2938bash: cannot set terminal process group (-1): Inappropriate ioctl for device2024-01-04T07:29:53ZGeon-Hongbash: cannot set terminal process group (-1): Inappropriate ioctl for deviceHi,
I'm not sure if it is appropriate to raise docker issue here, but I need your help.
Recently I tried to run OpenFOAM on Windows by following the instruction described here: https://develop.openfoam.com/Development/openfoam/-/wikis/...Hi,
I'm not sure if it is appropriate to raise docker issue here, but I need your help.
Recently I tried to run OpenFOAM on Windows by following the instruction described here: https://develop.openfoam.com/Development/openfoam/-/wikis/precompiled/windows
I installed WSL and docker on a Windows system and run the OpenFOAM-default image on it.
But when I run the image, I faced the following error message and the status of the container turned to exited.
```
---------------------------------------------------------------------------
========= |
\\ / F ield | OpenFOAM in a container [from OpenCFD Ltd.]
\\ / O peration |
\\ / A nd | www.openfoam.com
\\/ M anipulation |
---------------------------------------------------------------------------
Release notes: https://www.openfoam.com/news/main-news/openfoam-v2306
Documentation: https://www.openfoam.com/documentation/
Issue Tracker: https://develop.openfoam.com/Development/openfoam/issues/
Local Help: more /openfoam/README
---------------------------------------------------------------------------
System : Ubuntu 22.04.2 LTS (admin user: sudofoam)
OpenFOAM : /usr/lib/openfoam/openfoam2306
Build : _fbf00d6b-20230626 OPENFOAM=2306 patch=0
Note
Different OpenFOAM components and modules may be present (or missing)
on any particular container installation.
Eg, source code, tutorials, in-situ visualization, paraview plugins,
external linear-solver interfaces etc.
---------------------------------------------------------------------------
bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell
root@399e74dd484f:~# exit
```
I set the WSL distro to be Ubuntu but it doesn't help for me.
How can I handle this problem?
Many thanks in advance.
Regards,
Geon-Hong.https://develop.openfoam.com/Development/openfoam/-/issues/2937Generating uniformly sampling on a sphere for StochasticDispersionRAS2023-07-29T06:26:40ZVictor PozzobonGenerating uniformly sampling on a sphere for StochasticDispersionRAS### Functionality to add/problem to solve
The current implementation of the sampling to get a random direction for the turbulent velocity perturbation seems faulty.
Indeed, the current sampling draws number for angle from [0, 2pi] and [...### Functionality to add/problem to solve
The current implementation of the sampling to get a random direction for the turbulent velocity perturbation seems faulty.
Indeed, the current sampling draws number for angle from [0, 2pi] and [0, pi] uniform distributions. Yet, on a sphere the Jacobian makes the angle correlated and the second angle should not be chosen independently from the first angle value.
File: lagrangian/turbulence/submodels/Kinematic/DispersionModel/StochasticDispersionRAS/StochasticDispersionRAS.C
### Target audience
(Who will benefit from the changes?) -> Users
(What type of cases?) -> Lagrangian cases
### Proposal
The current sampling method could be replaced by a corrected one such as: http://corysimon.github.io/articles/uniformdistn-on-sphere/
### What does success look like, and how can we measure that?
By projecting the drawn vector on a plane. Currently, we should get a square. After the correction, we should get a disk.
### Links / references
http://corysimon.github.io/articles/uniformdistn-on-sphere/
### Funding
NAhttps://develop.openfoam.com/Development/openfoam/-/issues/2936redistributePar creates unnecessary directories2023-12-21T15:58:19ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comredistributePar creates unnecessary directories<!--
*** 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 -->
`redistributePar -fileHandler collated` in distributed mode creates unnecessary directories
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
- decompose a case
- move processorDDD to different directories
- and adjust decomposeParDict:roots accordingly
- run redistributePar to redistribute the case `mpirun -np 4 redistributePar -parallel -fileHandler collated`
- it will have created a `processsors4` directory on every root
### 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 : 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
### 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/2935Patch: Visual Studio Code Support Fix #22023-07-06T15:25:32ZVolker WeißmannPatch: Visual Studio Code Support Fix #2Please apply the following patch:
```diff
diff --git a/bin/tools/vscode-settings b/bin/tools/vscode-settings
index 80a9f30898..a585e50abc 100755
--- a/bin/tools/vscode-settings
+++ b/bin/tools/vscode-settings
@@ -141,10 +141,10 @@ fi
...Please apply the following patch:
```diff
diff --git a/bin/tools/vscode-settings b/bin/tools/vscode-settings
index 80a9f30898..a585e50abc 100755
--- a/bin/tools/vscode-settings
+++ b/bin/tools/vscode-settings
@@ -141,10 +141,10 @@ fi
cat << JSON_CONTENT
- "C_Cpp.autocomplete": "Disabled",
- "C_Cpp.errorSquiggles": "Disabled",
- "C_Cpp.formatting": "Disabled",
- "C_Cpp.intelliSenseEngine": "Disabled"
+ "C_Cpp.autocomplete": "disabled",
+ "C_Cpp.errorSquiggles": "disabled",
+ "C_Cpp.formatting": "disabled",
+ "C_Cpp.intelliSenseEngine": "disabled"
}
}
JSON_CONTENT
```https://develop.openfoam.com/Development/openfoam/-/issues/2934COMP: missing hostUncollatedFileOperation2023-09-01T10:39:30ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comCOMP: missing hostUncollatedFileOperation### Functionality to add/problem to solve
hostUncollated fileOperation not included in Make/files in v2306.### Functionality to add/problem to solve
hostUncollated fileOperation not included in Make/files in v2306.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2933AMIInterpolation::append has many list resizing2023-12-21T15:58:32ZMark OLESENAMIInterpolation::append has many list resizingIn [AMIInterpolation::append](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/meshTools/AMIInterpolation/AMIInterpolation/AMIInterpolation.C#L851) the updated maps are constructed by append/resizing two labelList entr...In [AMIInterpolation::append](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/meshTools/AMIInterpolation/AMIInterpolation/AMIInterpolation.C#L851) the updated maps are constructed by append/resizing two labelList entries.
This initial bookkeeping could be easily handled as a set of labelRanges. For example,
```
labelList mapMap, newMapMap;
{
List<labelRange> mapMapRanges(srcSubMap.size());
List<labelRange> newMapMapRanges(srcSubMap.size());
label total = 0;
label total1 = 0;
label total2 = 0;
forAll(srcSubMap, proci)
{
const label len1 = srcConstructMap[proci].size();
const label len2 = newSrcConstructMap[proci].size();
mapMapRanges[proci] = labelRange(total, len1);
total += len1;
total1 += len1;
newMapMapRanges[proci] = labelRange(total, len2);
total += len2;
total2 += len2;
}
mapMap.resize(total1);
newMapMap.resize(total2);
total = 0;
for (const labelRange& range : mapMapRanges)
{
const label beg = range.start();
const label len = range.size();
labelList::subList slice(mapMap.slice(total, len);
ListOps::identity(slice, beg);
total += len;
}
total = 0;
for (const labelRange& range : newMapMapRanges)
{
const label beg = range.start();
const label len = range.size();
labelList::subList slice(newMapMap.slice(total, len);
ListOps::identity(slice, beg);
total += len;
}
}
```https://develop.openfoam.com/Development/openfoam/-/issues/2932processorLOD boxes with odd mapping2023-07-06T06:28:21ZMark OLESENprocessorLOD boxes with odd mappingBy inspection - the processorLOD in meshToMesh appears to use regular mapDistribute ordering (local proc first) whereas AABBTree definitely uses linear ordering (as noticed in regression: 7b20e888a80).By inspection - the processorLOD in meshToMesh appears to use regular mapDistribute ordering (local proc first) whereas AABBTree definitely uses linear ordering (as noticed in regression: 7b20e888a80).v2312Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2931Tutorial wallMountedHump uses the wrong Wall function2023-07-12T07:28:20ZDjilou MioubTutorial wallMountedHump uses the wrong Wall functionIn the tutorial `$FOAM_TUTORIALS/incompressible/pimpleFoam/LES/wallMountedHump` the `bottomWall` patch uses the `kqRWallFunction`. However, monitoring the maximum y+ value for that patch in the `wallMountedHump/results/kOmegaSSTDDES-Delt...In the tutorial `$FOAM_TUTORIALS/incompressible/pimpleFoam/LES/wallMountedHump` the `bottomWall` patch uses the `kqRWallFunction`. However, monitoring the maximum y+ value for that patch in the `wallMountedHump/results/kOmegaSSTDDES-DeltaOmegaTilde-useSigmaTrue` case (This results directory is created after running Allrun script) reveals that the maximum y+ is less than 1.
According to the documentation of [kqRWallFunction](https://www.openfoam.com/documentation/guides/latest/doc/guide-bcs-wall-turbulence-kqRWallFunction.html), this wall function works only for High-Re turbulence models. In this case, the wall function should be changed to `kLowReWallFunction`
Here is the output of yPlus functon object (the case runs from t=0 to t=0.1s):
```
# y+ ()
# Time patch min max average
0.035 bottomWall 5.069050e-01 7.116099e-01 6.489882e-01
0.036 bottomWall 5.035144e-01 7.100054e-01 6.465464e-01
0.037 bottomWall 5.001048e-01 7.086455e-01 6.441265e-01
0.038 bottomWall 4.966794e-01 7.073639e-01 6.417274e-01
0.039 bottomWall 4.932415e-01 7.060872e-01 6.393480e-01
0.04 bottomWall 4.897940e-01 7.048148e-01 6.369876e-01
0.041 bottomWall 4.863399e-01 7.035460e-01 6.346452e-01
0.042 bottomWall 4.828823e-01 7.022801e-01 6.323201e-01
0.043 bottomWall 4.794237e-01 7.010166e-01 6.300118e-01
0.044 bottomWall 4.759671e-01 6.997553e-01 6.277195e-01
0.045 bottomWall 4.725155e-01 6.984956e-01 6.254428e-01
0.046 bottomWall 4.690714e-01 6.972373e-01 6.231812e-01
0.047 bottomWall 4.656373e-01 6.959800e-01 6.209343e-01
0.048 bottomWall 4.622159e-01 6.947235e-01 6.187016e-01
0.049 bottomWall 4.588097e-01 6.934673e-01 6.164829e-01
0.05 bottomWall 4.554209e-01 6.922117e-01 6.142778e-01
0.051 bottomWall 4.520517e-01 6.909564e-01 6.120862e-01
0.052 bottomWall 4.487040e-01 6.897016e-01 6.099079e-01
0.053 bottomWall 4.452075e-01 6.884473e-01 6.077425e-01
0.054 bottomWall 4.417060e-01 6.871933e-01 6.055900e-01
0.055 bottomWall 4.382235e-01 6.859400e-01 6.034502e-01
0.056 bottomWall 4.347618e-01 6.846872e-01 6.013230e-01
0.057 bottomWall 4.313231e-01 6.834351e-01 5.992084e-01
0.058 bottomWall 4.279095e-01 6.821836e-01 5.971061e-01
0.059 bottomWall 4.245221e-01 6.809329e-01 5.950163e-01
0.06 bottomWall 4.211628e-01 6.796831e-01 5.929388e-01
0.061 bottomWall 4.178332e-01 6.784341e-01 5.908735e-01
0.062 bottomWall 4.145346e-01 6.771863e-01 5.888206e-01
0.063 bottomWall 4.112684e-01 6.759399e-01 5.867799e-01
0.064 bottomWall 4.080356e-01 6.746950e-01 5.847513e-01
0.065 bottomWall 4.048376e-01 6.734517e-01 5.827350e-01
0.066 bottomWall 4.016753e-01 6.722102e-01 5.807310e-01
0.067 bottomWall 3.985497e-01 6.709706e-01 5.787391e-01
0.068 bottomWall 3.954626e-01 6.697331e-01 5.767600e-01
0.069 bottomWall 3.924149e-01 6.684975e-01 5.747934e-01
0.07 bottomWall 3.894046e-01 6.672636e-01 5.728381e-01
0.071 bottomWall 3.864079e-01 6.660293e-01 5.708842e-01
0.072 bottomWall 3.834329e-01 6.648026e-01 5.689403e-01
0.073 bottomWall 3.805406e-01 6.635933e-01 5.670317e-01
0.074 bottomWall 3.776905e-01 6.623808e-01 5.651291e-01
0.075 bottomWall 3.748725e-01 6.611678e-01 5.632378e-01
0.076 bottomWall 3.720980e-01 6.599561e-01 5.613582e-01
0.077 bottomWall 3.693651e-01 6.587466e-01 5.594904e-01
0.078 bottomWall 3.666728e-01 6.575399e-01 5.576346e-01
0.079 bottomWall 3.638041e-01 6.563364e-01 5.557909e-01
0.08 bottomWall 3.609299e-01 6.551364e-01 5.539595e-01
0.081 bottomWall 3.580968e-01 6.539406e-01 5.521404e-01
0.082 bottomWall 3.553050e-01 6.527487e-01 5.503337e-01
0.083 bottomWall 3.525546e-01 6.515607e-01 5.485393e-01
0.084 bottomWall 3.498455e-01 6.503767e-01 5.467574e-01
0.085 bottomWall 3.471777e-01 6.491968e-01 5.449879e-01
0.086 bottomWall 3.445508e-01 6.480211e-01 5.432307e-01
0.087 bottomWall 3.419651e-01 6.468499e-01 5.414861e-01
0.088 bottomWall 3.394202e-01 6.456837e-01 5.397540e-01
0.089 bottomWall 3.369156e-01 6.445221e-01 5.380343e-01
0.09 bottomWall 3.344512e-01 6.433651e-01 5.363270e-01
0.092 bottomWall 3.296422e-01 6.410654e-01 5.329501e-01
0.094 bottomWall 3.249912e-01 6.387853e-01 5.296237e-01
0.095 bottomWall 3.227224e-01 6.376523e-01 5.279787e-01
0.096 bottomWall 3.203673e-01 6.365246e-01 5.263469e-01
0.097 bottomWall 3.177192e-01 6.354036e-01 5.247308e-01
0.098 bottomWall 3.151147e-01 6.342874e-01 5.231283e-01
0.099 bottomWall 3.125565e-01 6.331759e-01 5.215393e-01
0.1 bottomWall 3.099769e-01 6.320555e-01 5.199387e-01
```Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2926Confusing/misleading GeometricField constructor2023-07-06T06:29:11ZMark OLESENConfusing/misleading GeometricField constructorAs raised as [cfd-online issue](https://www.cfd-online.com/Forums/openfoam-programming-development/250569-how-create-field-without-reading-0-directroy.html), the following field constructor can be misleading:
```
//- Construct and read g...As raised as [cfd-online issue](https://www.cfd-online.com/Forums/openfoam-programming-development/250569-how-create-field-without-reading-0-directroy.html), the following field constructor can be misleading:
```
//- Construct and read given IOobject
GeometricField
(
const IOobject& io,
const Mesh& mesh,
const bool readOldTime = true
);
```
One could suppose that the constructor respects the readOption of the IOobject but it does not. It always reads!
For a non-read constructor, the preferred form would be
```
GeometricField
(
const IOobject& io,
const Mesh& mesh,
const dimensionSet& ds,
const word& patchFieldType = PatchField<Type>::calculatedType()
);
```
but this may be non-obvious.
- Minimum fix: more explicit documentation, add a warning message when using with incorrect readOption so that it emits something before possibly failing.
- TBD: have the constructor switch to readIfPresent behaviour or even no-read. In these cases, not really sure if the implied boundaries are also "calculated" etc. Could potentially change some existing code?Mark OLESENMark OLESEN