Development issueshttps://develop.openfoam.com/groups/Development/-/issues2023-06-19T13:37:22Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2734Dockerhub containers for v2206 and above2023-06-19T13:37:22ZTimofey MukhaDockerhub containers for v2206 and aboveDear all,
I'm testing some CI tools for compiling OpenFOAM applications, and managed to get Cirrus CI to work nicely.
I currently have 2 workflows: one which installs OpenFOAM via apt-get and the other using an OpenCFD docker container f...Dear all,
I'm testing some CI tools for compiling OpenFOAM applications, and managed to get Cirrus CI to work nicely.
I currently have 2 workflows: one which installs OpenFOAM via apt-get and the other using an OpenCFD docker container from Dockerhub:
```
v2212_task:
container:
image: ubuntu:jammy
test_script:
- apt-get update
- apt-get install -y wget
- wget -q -O - https://dl.openfoam.com/add-debian-repo.sh | bash
- apt-get install -qq openfoam2212-dev
- /usr/bin/openfoam2212 wmake
v2112_task:
container:
image: opencfd/openfoam2112-dev
test_script:
- /usr/bin/openfoam2112 wmake
```
The one in the OpenCFD container runs 5 seconds and the other one about a minute, so it seems there is quite some benefit in using Dockerhub.
Which leads to the question: what is the status of the [Dockerhub repository](https://hub.docker.com/u/opencfd/)? The latest container seems to be 2112, so the two latest versions are missing. There is, however, a version-less container, which was updated 3 months ago. Is this a snapshot of the `develop` branch? I am aware of the new `openfoam-docker` script, which is very nice. But I don't think I can use it in the CI, since it will be launching Docker inside Docker. It seems that ideally one would like to have the containers on Dockerhub.
Best,
Timofeyhttps://develop.openfoam.com/Development/openfoam/-/issues/2733XiFoam tutorial moriyoshiHomogeneous fails with sigfpe2024-01-04T10:07:26ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comXiFoam tutorial moriyoshiHomogeneous fails with sigfpe<!--
*** 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 -->
combustion/XiFoam/RAS/moriyoshiHomogeneous tutorial does not run
### Steps to reproduce
cd combustion/XiFoam/RAS/moriyoshiHomogeneous
foamRunTutorials
### 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 -->
sigfpe when obtaining `psiu()` in the first iteration.
### 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 : v2212https://develop.openfoam.com/Development/openfoam/-/issues/2731Clarification on Lambda2 function object2023-09-29T12:54:35ZYannClarification on Lambda2 function object### Functionality to add/problem to solve
The description of the Lambda2 function object states:
> The Lambda2 function object computes the second largest eigenvalue of the sum of the square of the symmetrical and anti-symmetrical par...### Functionality to add/problem to solve
The description of the Lambda2 function object states:
> The Lambda2 function object computes the second largest eigenvalue of the sum of the square of the symmetrical and anti-symmetrical parts of the velocity gradient tensor.
But it seems the function actually computes the opposite value: -Lambda2
`return store
(
resultName_,
-eigenValues(SSplusWW)().component(vector::Y)
);`
This is a bit confusing, since negative Lambda2 values are supposed to indicate vortex cores while in OpenFOAM you need to look for positive values to get vortex cores.
### Target audience
Anyone using Lambda2 to visualize vortex structures
### Proposal
Two possible solutions:
1. writing the actual Lambda2 rather than -Lambda2
2. updating the function description to clearly mention the opposite value of Lambda2 is written
I don't really have a preference between these solutions, as long as the description matches the code to avoid misleading users.
### Links / references
This old thread put me on track: https://www.cfd-online.com/Forums/openfoam-post-processing/117005-lambda2-openfoam-utilities.htmlKutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2730faceAreaWeightAMI more verbose error2023-06-12T14:31:12ZRegő SimonfaceAreaWeightAMI more verbose error### Functionality to add/problem to solve
If the faceAreaWeightAMI class cannot find a target, it'll print the source face ID in the error which isn't that helpful.
### Target audience
AMI users
### Proposal
The current code in fa...### Functionality to add/problem to solve
If the faceAreaWeightAMI class cannot find a target, it'll print the source face ID in the error which isn't that helpful.
### Target audience
AMI users
### Proposal
The current code in faceAreaWeightAMI.C at line 363
```
FatalErrorInFunction
<< "Unable to set target face for source face " << srcFacei
<< abort(FatalError);
```
could be changed to:
```
FatalErrorInFunction
<< "Unable to set target face for source face " << srcFacei
<< " with centre: " << srcPatch0().faceCentres()[srcFacei] << abort(FatalError);
```
And instead of an error for example:
`Unable to set target face for source face 84468`
the user can find the problematic area immediately with the following tiny extra info:
`Unable to set target face for source face 84468 with centre: (0.138558 0.724811 1.9799)`v2306Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2729The calculation using slip velocity boundary condition on the wall in chtMult...2023-03-27T19:34:40ZLEI WANGThe calculation using slip velocity boundary condition on the wall in chtMultiRegionFoam can not converge<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
### 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 : 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 :Ubuntu-18.04
- 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/2727New sigma turbulence model not included for compressible LES2023-04-13T10:14:13ZJulius BergmannNew sigma turbulence model not included for compressible LES<!--
*** 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 new 'sigma' turbulence model introduced in v2206 for LES is not applicable for compressible simulations, but only for incompressible simulations. Maybe it was forgotten to be implemented in commit 54806ea7 , as the file [/src/TurbulenceModels/incompressible/turbulentTransportModels/turbulentTransportModels.C](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/TurbulenceModels/incompressible/turbulentTransportModels/turbulentTransportModels.C) was altered but not [/src/TurbulenceModels/compressible/turbulentFluidThermoModels/turbulentFluidThermoModels.C](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/TurbulenceModels/compressible/turbulentFluidThermoModels/turbulentFluidThermoModels.C).
### Possible fixes
Add the following lines to line 134 of the file [/src/TurbulenceModels/compressible/turbulentFluidThermoModels/turbulentFluidThermoModels.C](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/TurbulenceModels/compressible/turbulentFluidThermoModels/turbulentFluidThermoModels.C):
```
#include "sigma.H"
makeLESModel(sigma);
```Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2724inverse of singular or small tensors is still fragile2023-06-13T18:09:43ZMark OLESENinverse of singular or small tensors is still fragileFor very small tensors, the pseudo-inverse provides a more robust, but potentially more costly approach.
Oddly, within the symmTensorField.C there is special trapping of 2D cases, but the detection and adjustment are only triggered base...For very small tensors, the pseudo-inverse provides a more robust, but potentially more costly approach.
Oddly, within the symmTensorField.C there is special trapping of 2D cases, but the detection and adjustment are only triggered based on the first element (which is probably not robust enough).Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2720Build from Source Failed GCC 11.2.0 (WSL)2023-04-06T10:08:08ZBrandon DentonBuild from Source Failed GCC 11.2.0 (WSL)OpenFOAM v2212 won't compile from source. When following the wiki's instructions, the following errors result. Configuration details are provided below. I'm not sure how to fix the "error: ‘memchr’ has not been declared in ‘::’" error.
...OpenFOAM v2212 won't compile from source. When following the wiki's instructions, the following errors result. Configuration details are provided below. I'm not sure how to fix the "error: ‘memchr’ has not been declared in ‘::’" error.
```
Compiling enabled on 16 cores
gcc=/mnt/c/Users/Brandon/software/apps/gcc/11.2.0/bin/gcc
clang=
mpirun=/mnt/c/Users/Brandon/software/libs/openmpi/4.1.5/gcc/11.2.0/bin/mpirun
make=/usr/bin/make
cmake=/mnt/c/Users/Brandon/software/apps/cmake/3.22.0/bin/cmake
wmake=/mnt/c/Users/Brandon/software/builddir/OpenFOAM-v2212/wmake/wmake
m4=/usr/bin/m4
flex=/usr/bin/flex
compiler=/mnt/c/Users/Brandon/software/apps/gcc/11.2.0/bin/g++
g++ (GCC) 11.2.0
========================================
2023-03-07 19:05:43 -0500
Starting compile OpenFOAM-v2212 Allwmake
Gcc system compiler []
linux64GccDPInt64Opt, with SYSTEMOPENMPI sys-openmpi
========================================
built wmake-bin (linux64Gcc)
========================================
Compile OpenFOAM libraries
========================================
ln: OpenFOAM/lnInclude
ln: OSspecific/POSIX/lnInclude
wmake libo (POSIX)
dep: fileMonitor.C
dep: fileStat.C
dep: regExpPosix.C
dep: printStack.C
dep: sigQuit.C
dep: timer.C
dep: sigWriteNow.C
dep: sigStopAtWriteNow.C
dep: sigInt.C
dep: sigSegv.C
dep: memInfo.C
dep: sigFpe.C
dep: POSIX.C
dep: cpuInfo.C
dep: cpuTimePosix.C
Ctoo: sigFpe.C
Ctoo: memInfo.C
Ctoo: cpuTimePosix.C
Ctoo: sigInt.C
Ctoo: cpuInfo.C
Ctoo: POSIX.C
Ctoo: sigSegv.C
Ctoo: sigQuit.C
Ctoo: sigStopAtWriteNow.C
Ctoo: timer.C
Ctoo: regExpPosix.C
Ctoo: fileStat.C
Ctoo: sigWriteNow.C
Ctoo: fileMonitor.C
Ctoo: printStack.C
In file included from /mnt/c/Users/Brandon/software/builddir/OpenFOAM-v2212/src/OpenFOAM/lnInclude/string.H:56,
from /mnt/c/Users/Brandon/software/builddir/OpenFOAM-v2212/src/OpenFOAM/lnInclude/word.H:46,
from /mnt/c/Users/Brandon/software/builddir/OpenFOAM-v2212/src/OpenFOAM/lnInclude/fileName.H:51,
from /mnt/c/Users/Brandon/software/builddir/OpenFOAM-v2212/src/OpenFOAM/lnInclude/fileNameList.H:49,
from /mnt/c/Users/Brandon/software/builddir/OpenFOAM-v2212/src/OpenFOAM/lnInclude/OSspecific.H:42,
from memInfo/memInfo.C:30:
/mnt/c/Users/Brandon/software/apps/gcc/11.2.0/include/c++/11.2.0/cstring:77:11: error: ‘memchr’ has not been declared in ‘::’
77 | using ::memchr;
| ^~~~~~
/mnt/c/Users/Brandon/software/apps/gcc/11.2.0/include/c++/11.2.0/cstring:78:11: error: ‘memcmp’ has not been declared in ‘::’
78 | using ::memcmp;
| ^~~~~~
/mnt/c/Users/Brandon/software/apps/gcc/11.2.0/include/c++/11.2.0/cstring:79:11: error: ‘memcpy’ has not been declared in ‘::’
79 | using ::memcpy;
| ^~~~~~
/mnt/c/Users/Brandon/software/apps/gcc/11.2.0/include/c++/11.2.0/cstring:80:11: error: ‘memmove’ has not been declared in ‘::’
80 | using ::memmove;
| ^~~~~~~
/mnt/c/Users/Brandon/software/apps/gcc/11.2.0/include/c++/11.2.0/cstring:81:11: error: ‘memset’ has not been declared in ‘::’
81 | using ::memset;
| ^~~~~~
/mnt/c/Users/Brandon/software/apps/gcc/11.2.0/include/c++/11.2.0/cstring:82:11: error: ‘strcat’ has not been declared in ‘::’
82 | using ::strcat;
| ^~~~~~
/mnt/c/Users/Brandon/software/apps/gcc/11.2.0/include/c++/11.2.0/cstring:83:11: error: ‘strcmp’ has not been declared in ‘::’
83 | using ::strcmp;
| ^~~~~~
/mnt/c/Users/Brandon/software/apps/gcc/11.2.0/include/c++/11.2.0/cstring:84:11: error: ‘strcoll’ has not been declared in ‘::’
84 | using ::strcoll;
| ^~~~~~~
/mnt/c/Users/Brandon/software/apps/gcc/11.2.0/include/c++/11.2.0/cstring:85:11: error: ‘strcpy’ has not been declared in ‘::’
85 | using ::strcpy;
| ^~~~~~
/mnt/c/Users/Brandon/software/apps/gcc/11.2.0/include/c++/11.2.0/cstring:86:11: error: ‘strcspn’ has not been declared in ‘::’
86 | using ::strcspn;
| ^~~~~~~
/mnt/c/Users/Brandon/software/apps/gcc/11.2.0/include/c++/11.2.0/cstring:87:11: error: ‘strerror’ has not been declared in ‘::’
87 | using ::strerror;
| ^~~~~~~~
/mnt/c/Users/Brandon/software/apps/gcc/11.2.0/include/c++/11.2.0/cstring:88:11: error: ‘strlen’ has not been declared in ‘::’
88 | using ::strlen;
| ^~~~~~
/mnt/c/Users/Brandon/software/apps/gcc/11.2.0/include/c++/11.2.0/cstring:89:11: error: ‘strncat’ has not been declared in ‘::’
89 | using ::strncat;
| ^~~~~~~
/mnt/c/Users/Brandon/software/apps/gcc/11.2.0/include/c++/11.2.0/cstring:90:11: error: ‘strncmp’ has not been declared in ‘::’
90 | using ::strncmp;
| ^~~~~~~
/mnt/c/Users/Brandon/software/apps/gcc/11.2.0/include/c++/11.2.0/cstring:91:11: error: ‘strncpy’ has not been declared in ‘::’
91 | using ::strncpy;
| ^~~~~~~
/mnt/c/Users/Brandon/software/apps/gcc/11.2.0/include/c++/11.2.0/cstring:92:11: error: ‘strspn’ has not been declared in ‘::’
92 | using ::strspn;
| ^~~~~~
/mnt/c/Users/Brandon/software/apps/gcc/11.2.0/include/c++/11.2.0/cstring:93:11: error: ‘strtok’ has not been declared in ‘::’
93 | using ::strtok;
| ^~~~~~
/mnt/c/Users/Brandon/software/apps/gcc/11.2.0/include/c++/11.2.0/cstring:94:11: error: ‘strxfrm’ has not been declared in ‘::’
94 | using ::strxfrm;
| ^~~~~~~
/mnt/c/Users/Brandon/software/apps/gcc/11.2.0/include/c++/11.2.0/cstring:95:11: error: ‘strchr’ has not been declared in ‘::’
95 | using ::strchr;
| ^~~~~~
/mnt/c/Users/Brandon/software/apps/gcc/11.2.0/include/c++/11.2.0/cstring:96:11: error: ‘strpbrk’ has not been declared in ‘::’
96 | using ::strpbrk;
| ^~~~~~~
/mnt/c/Users/Brandon/software/apps/gcc/11.2.0/include/c++/11.2.0/cstring:97:11: error: ‘strrchr’ has not been declared in ‘::’
97 | using ::strrchr;
| ^~~~~~~
/mnt/c/Users/Brandon/software/apps/gcc/11.2.0/include/c++/11.2.0/cstring:98:11: error: ‘strstr’ has not been declared in ‘::’
98 | using ::strstr;
| ^~~~~~
```https://develop.openfoam.com/Development/openfoam/-/issues/2719TopoSet shows wrong cell/face count while running in parallel (only showing m...2023-03-10T17:47:09ZTobias HolzmannTopoSet shows wrong cell/face count while running in parallel (only showing master counts)<!--
*** 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 all, during some tests I figured out that topoSet is showing wrong face/cell counts in the output while running in parallel. Its simply a problem of the outputted text but this should be fixed as well as it is somehow non conservative.
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
Run the motorbike tutorial (incompressible/simpleFoam/motorBike) and add the following line to the topoSetDict:
```
{
name testWallFaceSet;
type faceSet;
action new;
source patchToFace;
patch lowerWall;
}
```
after `topoSet` is executed in parallel we get the following output:
```
Time = 0
mesh not changed.
Created cellZoneSet inner
Applying source boxToCell
Adding cells with centre within boxes 1((-1 -0.5 0) (6 0.5 2))
cellZoneSet inner now size 253135
Created faceSet lowerWallFaces
Applying source patchToFace
Adding all faces of patches (lowerWall) ...
Found matching patch lowerWall with **662 **faces.
faceSet lowerWallFaces now size **5349**
End
```
As one can see, the output of faces for the *lowerWall* is **662** (which comes from the master proc). However, the total number of faces is **5349** as given in the output as well. Hence, people might be confused.
### What is the current *bug* behaviour?
The output of faces/cell count is related to the master proc.
<!-- What actually happens -->
### What is the expected *correct* behavior?
The output should include the complete amount of cells/faces of all procs.
<!-- What you should see instead -->
### 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
### Possible fixes
Probably a global reduction of the data is missing and hence, only the master proc data is used.
<!--
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/2716OpenFOAM-v1912 with ParaView-5.10.1 with error: Cannot use ParaView reader mo...2023-12-29T11:28:04ZC SOpenFOAM-v1912 with ParaView-5.10.1 with error: Cannot use ParaView reader module library (PVFoamReader) The PV_PLUGIN_PATH environment value is not setI've installed **OpenFOAM-v1912** in Linux desktop environment with **ParaView version 5.10.1** along with **Aerosolved library**.
I tried to test run the cavity tutorial from foam, but failed with errors shown as:
**Cannot use ParaView...I've installed **OpenFOAM-v1912** in Linux desktop environment with **ParaView version 5.10.1** along with **Aerosolved library**.
I tried to test run the cavity tutorial from foam, but failed with errors shown as:
**Cannot use ParaView reader module library (PVFoamReader)
The PV_PLUGIN_PATH environment value is not set**
May I know why?
The steps were entering directory cavity in $FOAM_RUN directory,
then blockMesh
then paraFoam &
and the errors popped up as shown in the figure below.
![image](/uploads/c6e56bf1fd00085b0683395e74284865/image.png)
It does linking to the ParaView, but with no figure there.
![image](/uploads/51211298e86de260f628f46aa45a09b9/image.png)
May I know where I did wrongly? Please correct me.
Thank you in advanced.
Regards,
Cindyhttps://develop.openfoam.com/Development/openfoam/-/issues/2715Improved point-cell and cell-point topology methods2023-03-05T09:57:06ZMark OLESENImproved point-cell and cell-point topology methodsOptimization potential when building cell/point and point/cell connectivity. !596Optimization potential when building cell/point and point/cell connectivity. !596https://develop.openfoam.com/Development/openfoam/-/issues/2714compilation changes for gcc-13 and/or c++17/20 etc2023-03-05T09:56:24ZMark OLESENcompilation changes for gcc-13 and/or c++17/20 etccross-refs
- https://bugzilla.redhat.com/show_bug.cgi?id=1816301
- https://gcc.gnu.org/gcc-13/porting_to.htmlcross-refs
- https://bugzilla.redhat.com/show_bug.cgi?id=1816301
- https://gcc.gnu.org/gcc-13/porting_to.htmlMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2712Add thousand separators to meshing utility output2023-02-28T23:15:09ZGuanyang XueAdd thousand separators to meshing utility output### Functionality to add/problem to solve
Adding thousand separators to the output so it's easier for human to read long integers.
### Target audience
All meshing utilities (and probably some other applications)
### Proposal
Add s...### Functionality to add/problem to solve
Adding thousand separators to the output so it's easier for human to read long integers.
### Target audience
All meshing utilities (and probably some other applications)
### Proposal
Add some code to `messageStream` when printing integers
### What does success look like, and how can we measure that?
For example the current output of `blockMesh` is like
```
Mesh Information
----------------
boundingBox: (0 -0.0005 0) (0.012 0.0005 5e-05)
nPoints: 4911759
nCells: 4729600
nFaces: 14369360
nInternalFaces: 14008240
----------------
```
Adding thousand separators to integers will make it much easier to read.
```
Mesh Information
----------------
boundingBox: (0 -0.0005 0) (0.012 0.0005 5e-05)
nPoints: 4,911,759
nCells: 4,729,600
nFaces: 14,369,360
nInternalFaces: 14,008,240
----------------
```
### Links / references
You don't need to write any code to parse numbers. C++ has built-in functions to do that.
https://cplusplus.com/reference/locale/numpunct/https://develop.openfoam.com/Development/openfoam/-/issues/2710GAMG + processorAgglomeration + interpolateCorrection fails2024-01-08T11:02:44ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comGAMG + processorAgglomeration + interpolateCorrection 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 -->
Divide by zero when
- GAMG
- processorAgglomerator masterCoarsests;
- interpolateCorrection true;
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Any parallel case using GAMG. E.g. `pitzDaily` tutorial.
### What is the current *bug* behaviour?
<!-- What actually happens -->
Sigfpe since coarseLevel correction is not sent across when processor agglomerating. Instead the coarse-level correction stays zero for the missing/remote elements. This causes a divide by zero when normalising.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
No failure.
### 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
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->
Avoid accessing coarse-level when interpolating correction. Or send across coarse-level correction.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2709[Feature request] Macro expansion: Access keywords from separate files2024-01-10T16:36:52Zs1291[Feature request] Macro expansion: Access keywords from separate filesHello,
If I am not mistaken, It appears that OpenFOAM ESI versions do not provide a way to access external keywords from separate files.
OpenFOAM 9 and newer versions allow accessing keywords from separate files with the following synt...Hello,
If I am not mistaken, It appears that OpenFOAM ESI versions do not provide a way to access external keywords from separate files.
OpenFOAM 9 and newer versions allow accessing keywords from separate files with the following syntax:
```
aValue $FOAM_CASE/otherFile!foo;
```
`aValue` will have the value of `$foo` from the file `otherFile` within the case.
My workaround is to use a temporary dictionary with include to access the external keyword, e.g:
```
temp_dict
{
#include "otherFile"
}
aValue $temp_dict/foo;
#remove temp_dict
```
Is this feature already available that I am not aware of?
Thank youhttps://develop.openfoam.com/Development/openfoam/-/issues/2708Wrong equation of volume of injectedParticleInjection model and injectedParti...2023-06-12T14:31:12ZJunichi MukaiWrong equation of volume of injectedParticleInjection model and injectedParticleDistributionInjection model### Summary
The correct coefficient would be 1/6, not 1/16.
[InjectedParticleInjection.C](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/lagrangian/intermediate/submodels/Kinematic/InjectionModel/InjectedParticleIn...### Summary
The correct coefficient would be 1/6, not 1/16.
[InjectedParticleInjection.C](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/lagrangian/intermediate/submodels/Kinematic/InjectionModel/InjectedParticleInjection/InjectedParticleInjection.C#:~:text=scalar%20vol%20%3D%20pow3(diameter_%5Bi%5D)*mathematical%3A%3Api/16.0%3B)
[InjectedParticleDistributionInjection.C](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/lagrangian/intermediate/submodels/Kinematic/InjectionModel/InjectedParticleDistributionInjection/InjectedParticleDistributionInjection.C#:~:text=const%20scalar%20volume%20%3D%20sumPow3*mathematical%3A%3Api/16.0%3B)v2306https://develop.openfoam.com/Development/openfoam/-/issues/2706globalIndex gather fails with multi-world2023-02-22T10:17:23ZMark OLESENglobalIndex gather fails with multi-worldAs noted in discussions with @andy - the globalIndex gather uses procIDs, but these are the subranks (in the parent), not the actual ranks for the communicator.
@MattijsAs noted in discussions with @andy - the globalIndex gather uses procIDs, but these are the subranks (in the parent), not the actual ranks for the communicator.
@MattijsMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2704Reverse reaction rate in ReversibleReaction artificially restricted - might d...2023-06-12T14:31:12ZDaveReverse reaction rate in ReversibleReaction artificially restricted - might deliver wrong results### Summary
Reversible reactions in OpenFOAM deliver wrong results when the backward/ reverse reaction acts strongly.
### Steps to reproduce
Run appended test case and display generated `lineplot.png` file.
### Example case
Below te...### Summary
Reversible reactions in OpenFOAM deliver wrong results when the backward/ reverse reaction acts strongly.
### Steps to reproduce
Run appended test case and display generated `lineplot.png` file.
### Example case
Below test case features the reacting flow in a channel (0,1 x 0,1 x 1 m³) at $`T_\mathrm{in}=300\,\mathrm{°C}`$, $`U_\mathrm{in}=10\frac{\mathrm m}{\mathrm s}`$, $`(x_{\mathrm H_2}=x_{\mathrm H_2\mathrm O}=x_\mathrm{CO}=x_{\mathrm{CO}2})_\mathrm{in}=0.25`$ and adiabatic free-slip walls considering both water-gas shift as well as methane-steam reforming reaction:
[Arrhenius_Parameter.zip](/uploads/54a95386ef602dced0e582ad6fc51af8/Arrhenius_Parameter.zip)
### What is the current *bug* behaviour?
The backward reaction rate is currently limited by limiting the concentration-based equilibrium constant `Kc` to an (arbitrary) value of 1e-6:
```
Foam::scalar Foam::ReversibleReaction
<
ReactionType,
ReactionThermo,
ReactionRate
>::kr
(
const scalar kfwd,
const scalar p,
const scalar T,
const scalarField& c
) const
{
return kfwd/max(this->Kc(p, T), 1e-6);
}
```
The unit of this value differs with depending the stoichiometric coefficients of the reaction educts and products, which further points out the arbitrariness of this value:
$`K_c=K_{(p)}\left(\frac{p^\ominus}{\bar RT}\right)^{\sum_k{\nu_k''-\nu_k'}}=e^{-\frac{\Delta_{\mathrm R}G^\ominus}{\bar RT}}\left(\frac{p^\ominus}{\bar RT}\right)^{\sum_i{\nu_i''}-\sum_k{\nu_k'}}`$
$`[K_c]=\left(\frac{\mathrm{kmol}}{\mathrm m^3}\right)^{\sum_i{\nu_i''}-\sum_k{\nu_k'}}`$
In contrast to this, the forward reaction coefficient is **not** restricted at all.
Especially for reactions, where the direction of reaction is not clear at a first glance or strongly depends on the temperature, this can lead to wrong results which are hard to identify.
### What is the expected *correct* behavior?
The backward reaction rate should remain unrestricted just as the forward reaction rate.
### Relevant logs and/or images
The left picture shows the results of the test case for the original reversible reaction implementation in OpenFOAM. The reaction does nearly not take place as the backward reaction of the methane steam reaction is restricted. This also leads to nearly no change in the temperature.
The right picture shows the results of the same test case for the correct reversible reaction implementation. Both the development of the species and the temperature are in perfect agreement with results generated in Ansys CFX, Ansys Fluent, StarCCM+ and analytical calculation.
<table><tr>
<td>
<figure>
<img src="/uploads/358ed4fd30a9ea6b72ead34c5d1b4176/grafik.png"/><figcaption>Test case results for temperature and gas species development using original ReversibleReaction.C</figcaption>
</figure>
</td>
<td>
<figure>
<img src="/uploads/be7bde53cd5680d5f78fac8180a82e3d/lineplot.png"/><figcaption>Test case results for temperature and gas species development using patched ReversibleReaction.C</figcaption>
</figure>
</td>
</tr></table>
<figure>
<img src="/uploads/96ba5dafe917e8667172fba1e8f52b3d/grafik.png" width="50%"/><figcaption>Comparison of test case results between CFX, Fluent, StarCCM+, analytical solution and OpenFOAM with correct reversible reaction implementation</figcaption>
</figure>
### Environment information
- OpenFOAM version : v2212, 10 and all previous
- Operating system : Ubuntu 2204 LTS @ WSL2.0 and all other systems
### Possible fixes
In `$FOAM_SRC/thermophysicalModels/specie/reaction/Reactions/ReversibleReaction/ReversibleReaction.C`, the 1e-6 in line [131](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/thermophysicalModels/specie/reaction/Reactions/ReversibleReaction/ReversibleReaction.C#L131) should simply be replaced by `VSMALL`:
```
Foam::scalar Foam::ReversibleReaction
<
ReactionType,
ReactionThermo,
ReactionRate
>::kr
(
const scalar kfwd,
const scalar p,
const scalar T,
const scalarField& c
) const
{
return kfwd/max(this->Kc(p, T), VSMALL);
}
```v2306https://develop.openfoam.com/Development/openfoam/-/issues/2703mixedExpr boundary condition not working2023-06-19T21:11:33ZPhilippose RajanmixedExpr boundary condition not working### Summary
Using the **exprMixed** boundary condition in OpenFOAM-v2212 causes the solver to throw up the following error:
```
--> FOAM FATAL IO ERROR: (openfoam-2212)
Entries 'valueExpr' and 'gradientExpr' (mixed-conditon) no...### Summary
Using the **exprMixed** boundary condition in OpenFOAM-v2212 causes the solver to throw up the following error:
```
--> FOAM FATAL IO ERROR: (openfoam-2212)
Entries 'valueExpr' and 'gradientExpr' (mixed-conditon) not found in dictionary "D:/SmallProjects/999_Temp/001_OpenFOAM_Tests /002_exprMixed_Bug_001/0/U.boundaryField.(plateOut_01)"
file: 0/U.boundaryField.(plateOut_01) at line 48 to 58.
From void Foam::expressions::patchExprFieldBase::readExpressions(const Foam::dictionary&, Foam::expressions::patchExprFieldBase::expectedTypes, bool)
in file expressions/fields/base/patchExprFieldBase.C at line 91.
FOAM exiting
```
The same case works as expected without any errors when run using OpenFOAM-v2206.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
This issue can be reproduced every time, when using the **exprMixed** boundary condition in any of the boundary field files, for example:
```
"(plateOut_01)"
{
type exprMixed;
value $internalField;
variables
(
"qOut{plateIn_01} = -sum(phi)"
"qIn = sum(phi)"
);
valueExpr "(qIn + 0.1*(qOut - qIn))/sum(area())*face()/area()";
fractionExpr "(phi > 0) ? 0 : 1";
}
```
### 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
-->
An example case hat been attached along with this bug report which reproduces the problem when run using OpenFOAM-v2212, but runs fine when using OpenFOAM-v2206
[002_exprMixed_Bug_001.zip](/uploads/cc7cae3c8c93d62ada53d6fcb9b3edb9/002_exprMixed_Bug_001.zip)
### What is the current *bug* behaviour?
<!-- What actually happens -->
The OpenFOAM solver exits with as error while setting up the boundary fields right in the beginning of the solve, before the first iteration has been run.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
If the bug is fixed, the expectation is that the solver goes through the initial boundary field setup and starts the solve iterations, as seen when the case is run using OpenFOAM-v2206.
### 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 inserted text in the summary section and example case uploaded along with this issue report.
### 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 : Windows 11 (OpenFOAM native cross-compile)
- Hardware info : -na-
- Compiler : minGW Cross-compile (OpenSUSE)
### 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
-->
There has been a change in the file:
[patchExprFieldBase.C](https://develop.openfoam.com/Development/openfoam/-/blob/cc6ba5c1a04873d902534fcd6167b1a8bed52930/src/finiteVolume/expressions/fields/base/patchExprFieldBase.C#L73)
At the line pointed to by the link, between OpenFOAM-v2206 and OpenFOAM-v2212, which makes both the ***valueExpr*** and ***gradientExpr*** mandatory for the exprMixed boundary condition. In OpenFOAM-v2206, this error was only thrown when both, ***valueExpr*** and ***gradientExpr*** were missing from the definition, but worked if either one of the keywords were present (and when relevant, along with ***fractionExpr***).
The problem can be solved by using an empty string for the ***gradientExpr*** in the patch boundary definition.
Is this an intended change? Using an empty string for an entry which is not required, is not an elegant solution.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2702UPtrList iterator does not skip empty entries2023-03-09T10:20:27ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comUPtrList iterator does not skip empty entries### Functionality to add/problem to solve
Looping over an UPtrList:
```
const lduInterfacePtrsList patches(lMesh.interfaces());
for (const auto& pp : patches)
{
Pout<< "Patch:" << pp.type() << endl;
}
```
it do...### Functionality to add/problem to solve
Looping over an UPtrList:
```
const lduInterfacePtrsList patches(lMesh.interfaces());
for (const auto& pp : patches)
{
Pout<< "Patch:" << pp.type() << endl;
}
```
it does not skip the empty entries (from uncoupled patches).
### Target audience
Coders.
### Proposal
Q: what if we want to set the entries so require walking over all.
Attached a little test app.
[Test-lduMeshInterfacesCompilationError.C](/uploads/be94f8ada6f3b72724e44fe3a9106799/Test-lduMeshInterfacesCompilationError.C)Mark OLESENMark OLESEN