Development issueshttps://develop.openfoam.com/groups/Development/-/issues2024-01-04T07:29:53Zhttps://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/2930"Clean" build fails with ThirdParty MPI2023-07-05T12:20:49ZBernhard Gschaider"Clean" build fails with ThirdParty MPI### Summary
When doing a build on
- a clean system
- with a ThirdParty MPI-implementation
- ThirdParty-packages that depend on that MPI
the compilation of packages depending on MPI fails because thw path to the MPI-implementation is...### Summary
When doing a build on
- a clean system
- with a ThirdParty MPI-implementation
- ThirdParty-packages that depend on that MPI
the compilation of packages depending on MPI fails because thw path to the MPI-implementation is not in the environment variables
This happens because during the first sourcing of the `etc/bashrc` the MPI-Implementation is not there and the variables are therefor not set
### Steps to reproduce
This happens for instance when loading the sources into a docker image where only the bare minimum for compiling is installed (no system-MPI) and running the `$WM_PROJECT_DIR/Allwmake` there
### What is the current *bug* behaviour?
Compilation runs through but some decomposition methods (like Scotch) are missing
### What is the expected *correct* behavior?
Compilation runs through (including Scotch et al)
### 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 : OpenFOAM v2306 but also 221 and 2206 (didn't try older)
- Operating system : Unix-like
- Hardware info : any
- Compiler : any
### Possible fixes
This can be fixed by sourcing the config.sh/mpi after the compilation of the MPI-implementation in the ThirdParty-Allwmake.
the patch
[resourceEtcBashrc.patch](/uploads/6368cca5680fc75effe76e233c6d953b/resourceEtcBashrc.patch)
applies this patch to the ThirdParty-2306Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2927OpenFOAM 2306 build instructions and source tgz files2023-07-03T15:02:57ZDavid HuckabyOpenFOAM 2306 build instructions and source tgz files
The file for the current build instructions from source reference the v2212 files:
https://develop.openfoam.com/Development/openfoam/-/blob/master/doc/Build.md
```
* Source: https://dl.openfoam.com/source/v2212/OpenFOAM-v2212.tgz
* Thi...
The file for the current build instructions from source reference the v2212 files:
https://develop.openfoam.com/Development/openfoam/-/blob/master/doc/Build.md
```
* Source: https://dl.openfoam.com/source/v2212/OpenFOAM-v2212.tgz
* ThirdParty: https://dl.openfoam.com/source/v2212/ThirdParty-v2212.tgz
```
And the directory for the latest distribution: https://dl.openfoam.com/source/latest/
does not include a source file, e.g. "OpenFOAM-v2306.tgz" for the 2306 version.https://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 OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2925Tensor operations: taking the inner product of three tensors produces a diffe...2023-11-17T19:24:36ZRyley McConkeyTensor operations: taking the inner product of three tensors produces a different result depending on if an intermediate variable is used<!--
*** 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 following operations do not produce the same result for C :
1. C = A & A & A;
2. B = A & A; then C = B & A;
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Here is an example set of operations. Tensors B2a and B2b should be equal (since they are both S & S & S), but the results are different.
```
S = symm(fvc::grad(U));
B1 = S & S;
B2a = S & S & S;
B2b = B1 & S;
```
### 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
-->
I have attached an example case and example application that writes the above two results.
### What is the current *bug* behaviour?
A different result is produced for the two operations.
<!-- What actually happens -->
### What is the expected *correct* behavior?
The two operations should produce the same result. I believe the second result (after using an intermediate variable) is correct mathematically. I am not sure yet what operation is being performed in the first case (S & S & S).
<!-- 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.
-->
![Screenshot_from_2023-06-29_14-10-26](/uploads/cd1596da5d86af14d126bc93c02b109d/Screenshot_from_2023-06-29_14-10-26.png)
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2212|v2206|v2112|v2106|v2012 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2112
- 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
-->[case_0p5.zip](/uploads/bb01c9483630e4766047cdd604e4a897/case_0p5.zip)[writeFields_test.zip](/uploads/e1acfc378b8ff008c795511c01ca5bec/writeFields_test.zip)Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2924resdistributePar -decompose fails in postChannel tutorial2023-11-22T07:22:27ZTimofey MukharesdistributePar -decompose fails in postChannel tutorial<!--
*** 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
Running
`mpirun 36 redistributePar -decompose -parallel`
in `planeChannel/results/DFSEM` crashes with
`[20] Cannot find point in pts1 matching point 0 coord:(57.65 0.88207685 3.1415927) in pts0 when using tolerance 6.2398167e-06`
and a following cascade of errors.
### Steps to reproduce
Go to the planeChannel tutorial, and run ./Allrun to generate the cases. Then execute `redistributePar` as above.
### A comment
I would like to stress that getting this utility to work properly, also in conjunction with the collated file format, is absolutely critical for LES/DNS runs. Serial `decomposePar` is just no longer an option, once the number of processors is in the order of thousands.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2212|v2206|v2112|v2106|v2012 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : master @ spack
- Operating system : Linux
- Hardware info : LUMI C node/ AMD EPYC 7742 64-Core Processor
- Compiler : gcc (SUSE Linux) 7.5.0Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2923expressions rand() ignores time state2023-06-26T15:59:58ZMark OLESENexpressions rand() ignores time stateWith the addition of objectRegistry handling to Function1/PatchFunction1 (c1a04abd96ee) the old time-state handling within expressions was overhauled to handle that as well. It appears that the seeding for rand() is only using the time-...With the addition of objectRegistry handling to Function1/PatchFunction1 (c1a04abd96ee) the old time-state handling within expressions was overhauled to handle that as well. It appears that the seeding for rand() is only using the time-state (unset) and handling of objectRegistry got missed for that function.
@THOMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2922Brownian motion force should use cubic distribution2023-07-13T15:10:38ZGuanyang XueBrownian motion force should use cubic distribution### Summary
The current code in BrownianMotionForce.C is calculating wrong Brownian motion force. The equation used to be correct (now it's commented out). However this reporter (https://develop.openfoam.com/Development/openfoam/-/commi...### Summary
The current code in BrownianMotionForce.C is calculating wrong Brownian motion force. The equation used to be correct (now it's commented out). However this reporter (https://develop.openfoam.com/Development/openfoam/-/commit/ee9e7cf0375147af1e9d57a039ad4f241bad8e4f,https://bugs.openfoam.org/view.php?id=2153) didn't know how to properly set up a particle tracking simulation and used an unrealistically large time step to generate wrong results. Unfortunately Mr. Henry Weller believed in him and adapted his wrong code. The ESI version is also affected.
### Steps to reproduce
I'm attaching an example case to reproduce. The domain is 2um x 2um x 2um box with stationary water inside. 2000 x 1um particles are injected at (0,0,0) with `BrownianMotion` and `sphereDrag` enabled. After some time, collect all coordinates and calculate the RMS of the particles (I use paraview+excel).
### Example case
This case takes 2 hours to run on my workstation. It might be OK to reduce the total time. However the time step should always be smaller than particle relaxation time (5e-8s in this case).
[Tesetcase-v2212.zip](/uploads/a35708e213aece4919013b01ac50a561/Tesetcase-v2212.zip)
```
blockMesh
decomposePar
mpirun -np 8 reactingParcelFoam -parallel
```
### What is the current *bug* behaviour?
The spherical distribution is generating a Brownian motion force that is sqrt(3) times smaller than it should be. The validation case provided by the original reporter made 2 mistakes: 1. Use 2D geometry to validate 3D Brownian motion. 2. Use super large timestep (20,000 times of particle relaxation time) to simulate Brownian motion.
### What is the expected *correct* behavior?
Literature 1: Dispersion and Deposition of Spherical Particles from Point Sources in a Turbulent Channel Flow https://www.tandfonline.com/doi/ref/10.1080/02786829208959550
Literature 2: https://dl.cfdexperts.net/cfd_resources/Ansys_Documentation/Fluent/Ansys_Fluent_Theory_Guide.pdf (page 425) Fluent is using the "cubic distribution" as well.
The RMS of the particle should match the theoretical value from diffusion coefficient (https://en.wikipedia.org/wiki/Random_walk#Relation_to_Wiener_process), where RMS^2 should equal to 6Dt.
Here T=293, mu=1e-3, d=1e-6, therefore using Stokes-Einstein equation D=4.3e-13.
### Relevant logs and/or images
![RMS](/uploads/75381e2df0676711e4e0b13618c0fc74/RMS.png)
### Environment information
- OpenFOAM version : all versions since 2016
- Operating system :
- Hardware info :
- Compiler :
### Possible fixes
Use the following code in `src/lagrangian/turbulence/submodels/Thermodynamic/ParticleForces/BrownianMotion/BrownianMotionForce.C` will generate correct results.
```
Random& rnd = this->owner().rndGen();
for (direction dir = 0; dir < vector::nComponents; dir++)
{
value.Su()[dir] = f*rnd.GaussNormal<scalar>();
}
```
This should be faster than the implementation that is commented out, as `rnd.GaussNormal<scalar>()` generates a pair of random numbers.v2312Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2820foamMeshToFluent delivers meshes that are non-conformal with specifications a...2023-11-03T16:28:56ZDavefoamMeshToFluent delivers meshes that are non-conformal with specifications and that are incompatible with Fluent utility tmerge### Summary
When a mesh is exported from OpenFoam in Fluent format using `foamMeshToFluent`, a msh is generated that consists of several sections with a defined structure, see e.g. [here](http://www.eureka.im/302.html) or [here](https:/...### Summary
When a mesh is exported from OpenFoam in Fluent format using `foamMeshToFluent`, a msh is generated that consists of several sections with a defined structure, see e.g. [here](http://www.eureka.im/302.html) or [here](https://romeo.univ-reims.fr/documents/fluent/tgrid/ug/appb.pdf).
The exported mesh can be read into Ansys Fluent and ICEM without any problems. However, if the officially shipped Ansys utility `tmerge` is used for merging two or more msh files into one, the merged mesh shows artifacts when loaded into Fluent. The same occurs, when `tmerge` is only given one msh file and writes it to new msh file that should in theory have an identical content as the input file (unless of some differences in formatting). However, this is not the case. `tmerge` writes a wrong number of points into the point section header:
| original msh file | after `tmerge` |
| ------ | ------ |
| ![grafik](/uploads/e6f7126197aab55fd13eff817c054d25/grafik.png) | ![grafik](/uploads/0f8b15f4cb5ce3ac30df5d1e80dd615b/grafik.png) |
As a consequence, Fluent does not import all nodes of the new msh file but only a few, while all other nodes fall down to (0,0,0), which creates the artifacts after import. After some trial and error, the reason seems to be the id that `foamMeshToFluent` writes in the node header. While Ansys assigns id 3 per default (e.g. when exporting a mesh from Ansys Meshing to msh file), `foamMeshToFluent`writes id 1. This interferes with id 1, which is also used for the cell header. When manually changing the node header id from 1 to 3, `tmerge` does the correct job and all artifacts are gone.
### Steps to reproduce
1. Export an arbitrary blockMesh with `foamMeshToFluent`:
2. Load this msh file in Fluent and display mesh -> everything looks fine.
3. Take the same msh file, let it run through `tmerge` and write it to a new msh file:
Windows: `"C:\Program Files\ANSYS Inc\v231\fluent\fluent23.1.0\utility\tmerge\win64\tm3d.exe" case.msh case_new.msh`
Linux: `./mnt/software/ansys_inc/v231/fluent/fluent23.1.0/utility/tmerge/lnamd64/tmerge_3d case.msh case_new.msh`
4. Load this new msh file in Fluent and display mesh -> mesh has artifacts.
### What is the current *bug* behaviour?
`foamMeshToFluent` defines the node section in a msh file under id 1 (see last line):
```
(0 "FOAM to Fluent Mesh File")
(0 "Dimension:")
(2 3)
(0 "Grid dimensions:")
(10 (0 1 163c 0 3))
(12 (0 1 efa 0 0))
(13 (0 1 339c 0 0))
(10 (1 1 163c 1 3)
...
```
### What is the expected *correct* behavior?
Ansys always defined the node section in a msh file with id 3 as per default (see last line):
```
(0 grid written by ANSYS Meshing
nodes: (10 (id start end type) (x y z ...))
faces: (13 (id start end type elemType)
(v-0 v-1 .. v-n right-cell left-cell ...))
cells: (12 (id start end type elemtype))
parent-face: (59 (start end parent child) (nchilds child0 child1 ...))
)
(2 3)
(10 (0 1 c 0))
(13 (0 1 b 0))
(12 (0 1 2 0))
(10 (3 1 c 1 3)(
...
```
### Relevant logs and/or images
![grafik](/uploads/83086801a4a1452f1e2a2078e1ee18f3/grafik.png)
### Environment information
- OpenFOAM version : v2212, 10 and all previous
- Operating system : Ubuntu 2204 LTS @ WSL2.0 and all other systems
### Possible fixes
In `/usr/lib/openfoam/openfoam2212/applications/utilities/mesh/conversion/foamMeshToFluent/fluentFvMesh.C`, the first `1` after `(10 (` in line 104 should simply be replaced by a `3` (see last line):
```
// Writing points
fluentMeshFile
<< "(10 (3 1 ";
fluentMeshFile.setf(ios::hex, ios::basefield);
fluentMeshFile
<< nPoints() << " 1 3)"
<< std::endl << "(" << std::endl;
```
There will be no negative consequences/ interference as `foamMeshToFluent` specifies
- the internal faces under id 2 ff.: `<< "(13 (2 1 ..."` (ll. 135 f.),
- boundary faces starting from id 10 (hex a): `<< "(13 (" << patchi + 10 << ...` (ll. 71 f.) and
- cells under id 1: `<< "(12 (1 1 " << ...` (ll. 221 f.)
Hence, ids 3 to 9 are unused and may be used for node header id. To be consistent with Ansys, I would choose id 3 as suggested above.v2312Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2819potential parallel issues for function objects used a patchSet2023-08-19T06:53:47ZMark OLESENpotential parallel issues for function objects used a patchSetIn function objects such as wallShearStress, the patches can be restricted using a "patches" keyword. The retrieved indices are stored as a labelHashSet (ensures that they are unique). This is generally mostly OK, except that there is no...In function objects such as wallShearStress, the patches can be restricted using a "patches" keyword. The retrieved indices are stored as a labelHashSet (ensures that they are unique). This is generally mostly OK, except that there is no ***absolute 100% guarantee ™*** that iterating across will be the same across all ranks - which means that any global operations such as gMin/gMax etc could potentially block.
This is admittedly a bit of a stretch (since the hash insertion operations will be the same on all ranks, and all ranks have the same hasher), but should be adjusted for v2312.
FYI: @kuti and @andyv2312Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2817interpolation cell-point not working in processorCyclicPointPatchField (in no...2023-06-30T13:44:08ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.cominterpolation cell-point not working in processorCyclicPointPatchField (in nonBlocking 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 -->
processorCyclicPointPatchField does not buffer local send data when running non-blocking. This gives memory errors on bigger cases (if running with cyclics where owner and neighbour might be on different processors)
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Run `incompressible/pimpleFoam/LES/periodicHill/transient` tutorial. At the postprocessing at the end it triggers a cell->point interpolation which under valgrind shows up the errors. Note that the only thing that matters is to have the processorCyclic patches + volPointInterpolation.
### 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 -->
Get NaN (1e-318) in last element of array when printing out the values. Get valgrind memory errors.
### 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 : v2212|v2206|v2112|v2106|v2012 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2212
- 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
-->
Use persistent buffer for transferring data (ideally only when running non-blocking)
@markMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2816Issue in wallHeatFlux evaluation - with readFields2023-06-26T08:17:40ZPrashant SonakarIssue in wallHeatFlux evaluation - with readFieldsAttached modified tutorial gives error while executing postProcess step in develop branch.
It works when:
- with readFields disabled, and wallHeatFlux FO having region=region0
- with readFields enabled and wallHeatFlux FO without region ...Attached modified tutorial gives error while executing postProcess step in develop branch.
It works when:
- with readFields disabled, and wallHeatFlux FO having region=region0
- with readFields enabled and wallHeatFlux FO without region keyword
[buoyantCavity.tgz](/uploads/f0ac85ce292468c3c0678283a01cf338/buoyantCavity.tgz)
The same error happens in other (larger) case with v2212 as well.Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2815purgeWrite does not work for overset solvers2023-06-26T07:46:45ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.compurgeWrite does not work for overset solvers<!--
*** 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 -->
Any overset case with purgeWrite still writes all dumps.
### 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
-->
Any overset case
### What is the current *bug* behaviour?
<!-- What actually happens -->
Does not delete written directories
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2212|v2206|v2112|v2106|v2012 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2212
- Operating system :
- Hardware info :
- Compiler :Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.com