openfoam issueshttps://develop.openfoam.com/Development/openfoam/-/issues2024-01-29T18:57:45Zhttps://develop.openfoam.com/Development/openfoam/-/issues/3092MPI_Send MPI_ERR_COUNT: invalid count argument 140 million cells (bug)2024-01-29T18:57:45ZIlya ElizarovMPI_Send MPI_ERR_COUNT: invalid count argument 140 million cells (bug)### Summary
I have encountered a problem with MPI_Send routine while running a 140 million cells case on the cluster: Virgo cluster at GSI Helmholtz Centre for Heavy Ion Research https://hpc.gsi.de/virgo/
I'm using chtMultiRegionSimple...### Summary
I have encountered a problem with MPI_Send routine while running a 140 million cells case on the cluster: Virgo cluster at GSI Helmholtz Centre for Heavy Ion Research https://hpc.gsi.de/virgo/
I'm using chtMultiRegionSimpleFoam to solve a heat transfer problem for a multilayer PCB with vias in great detail. The solver goes through a few regions with no problem, but when it proceeds to a very big region with 141 211 296 cells, it crashes with the error below.
I have tried to increase number of subdomains, e.g. 1024, 2048, 4096 CPUs (all hierarchical method) and 1024 (with ptscotch), but the error persists. This makes me think, that the error is caused by the absolute number of cells in the region and independent of decomposition. A few more things were tried as a solution, but with no success: https://www.cfd-online.com/Forums/openfoam-solving/253681-mpi_send-mpi_err_count-invalid-count-argument.html
### Steps to reproduce
Basically, any solver with with comparable mesh size case should fail. Surely, to run such a case, a lot of computational resources are required that's why it's difficult to reproduce.
Feel free to contact me if you need more details on the Virgo cluster that I'm using. Meanwhile, I will ask OpenFOAM community if anybody could test it on a cluster with comparable size.
### Example case
My case can be found at https://sf.gsi.de/f/4db522c9b39b4125855f/?dl=1 (24,2 Mb)
_Requirements: 1024 CPUs (it's with multithreading), 4 Gb RAM per processor, Slurm workload manager, OpenFOAM installed with WM_LABEL_SIZE=64_
Simply run ./Allrun script
The case uses collated file format.
### What is the current _bug_ behaviour?
It seems that MPI_Send is called with a negative count argument. The count argument is a signed int https://www.open-mpi.org/doc/v4.1/man3/MPI_Send.3.php of 32 bit size, so it is likely overflowing (MPI_Send with a count \> INT_MAX).
### What is the expected _correct_ behavior?
Basically, the solver should proceed with the very big region if there's no hardware limitations like in this situation.
### Relevant logs and/or images
chtMultiRegionSimpleFoam fails with the following error message:
```plaintext
<...>
[lxbk1164:3797445] *** An error occurred in MPI_Send
[lxbk1164:3797445] *** reported by process [710282087,0]
[lxbk1164:3797445] *** on communicator MPI_COMM_WORLD
[lxbk1164:3797445] *** MPI_ERR_COUNT: invalid count argument
[lxbk1164:3797445] *** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort,
[lxbk1164:3797445] *** and potentially your MPI job)
slurmstepd: error: *** STEP 19265579.0 ON lxbk1164 CANCELLED AT 2024-01-19T18:02:26 ***
srun: Job step aborted: Waiting up to 32 seconds for job step to finish.
<...>
```
Full logs that were generated by the case can be downloaded at https://sf.gsi.de/f/66935ac60645422da948/?dl=1 log.\* files are ordinary logs that OpenFOAM generates, Slurm-\*.out are logs from the workload manager.
### Environment information
- OpenFOAM version : v2306
- Operating system : CentOS-based
- Hardware info : https://hpc.gsi.de/virgo/user-guide/overview/hardware.html
- OpenMPI : 3.1.6, 4.1.2 (from ThirdParty-v2306), 5.0.0 (tried with three of them)
- Slurm: 21.08.8-2
- Compiler : gcc-toolset-13, gcc 10.2.0 (tried with the two)
### Possible fixes
The PStream interface accepts a std::streamsize and implicitely casts it to the int argument on the mpi interfaces, performing a narrowing conversion https://develop.openfoam.com/Development/openfoam/-/blob/master/src/Pstream/mpi/UOPstreamWrite.C#L56
```plaintext
<source>:3:27: error: static assertion failed
3 | static_assert(sizeof(int) == sizeof(std::streamsize));
| ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~
<source>:3:27: note: the comparison reduces to '(4 == 8)'
```
(from https://godbolt.org/)
OpenFOAM would have plenty of options to deal with this situation by e.g. issuing multiple MPI_Send or choose a larger MPI_Datatype.
P.S. It seems that there's a problem adding a bug label: /label ~bughttps://develop.openfoam.com/Development/openfoam/-/issues/3091OpenFOAM v2306 Sigma Turbulence Model Wrong Behavior2024-02-14T17:33:18ZJan GärtnerOpenFOAM v2306 Sigma Turbulence Model Wrong Behavior<!--
*** 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
In OpenFOAM v2306 a new turbulence model, the Sigma model, has been introduced. However, using OpenFOAM v2306, compiled on Ubuntu 22.04 LTS with GCC 11.4, results in wrong turbulent viscosity fields. At our institute, we had been using the Sigma model before it was introduced in the main OpenFOAM branch and had already experienced problems in prior OpenFOAM versions if the compiler GCC 11.4 was used. This could be fixed in two ways:
1. Compile with Gcc 9.5
2. Modify the calculation of the Ssigma() term
We would encourage to modify the Ssigma() function to avoid this bug with the Gcc 11.3 compiler. Also it would be great to know why this error appears for newer OpenFOAM versions.
![nutComparison](/uploads/f28570b5b79d5824787953df0392819f/nutComparison.png)
### Steps to reproduce
We can provide a simple jet case where you can clearly see the issue in the turbulent viscosity.
Alternatively, use a case with a shear layer or jet flow and use the provided program, which calculates the turbulent viscosity and writes out the result.[src.tar.gz](/uploads/fdef1eaf5e3b77c9dc64d04a35da9468/src.tar.gz)
### What is the current *bug* behaviour?
As visible in the attached image, the turbulent viscosity is not smooth and does have significantly larger outliers.
### What is the expected *correct* behavior?
The turbulent viscosity should look like it is displayed on the right hand side of the attached image.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2312|v2306|v2212|v2206|v2112 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2306
- Operating system : Ubuntu 22.04 LTS
- Hardware info : AMD processor
- Compiler : GCC 11.4
### Possible fixes
In the Ssigma() function located in `DESModel::Ssigma()` (DESModel.C line 88) split the calculation of G in line 110 up into two parts:
```c++
const volTensorField gradUT = gradU.T();
const volTensorField G = gradUT & gradU;
```
For some reason, it works then correctly.
<!--
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/3088Significant DILU preconditioner speedup2024-01-18T12:50:13ZTim NoackSignificant DILU preconditioner speedup### Functionality to add/problem to solve
The current implementation of the DILU preconditioner uses the losort addressing for the forward sweep. See [line 129 DILUPreconditioner.C](https://www.openfoam.com/documentation/guides/latest/a...### Functionality to add/problem to solve
The current implementation of the DILU preconditioner uses the losort addressing for the forward sweep. See [line 129 DILUPreconditioner.C](https://www.openfoam.com/documentation/guides/latest/api/DILUPreconditioner_8C_source.html#l00129):
```cpp
for (label face=0; face<nFaces; face++)
{
const label sface = losortPtr[face];
wAPtr[uPtr[sface]] -=
rDPtr[uPtr[sface]]*lowerPtr[sface]*wAPtr[lPtr[sface]];
}
```
To understand the proposed change, consider the following 4x4 matrix and its LDU representation. For illustrative purposes, the matrix is dense:
$$
\begin{bmatrix}
a_{00} & a_{01} & a_{02} & a_{03} \\
a_{10} & a_{11} & a_{12} & a_{13} \\
a_{20} & a_{21} & a_{22} & a_{23} \\
a_{30} & a_{31} & a_{32} & a_{33}
\end{bmatrix} =
\begin{bmatrix}
& & & \\
a_{10} & & & \\
a_{20} & a_{21} & & \\
a_{30} & a_{31} & a_{32} &
\end{bmatrix} +
\begin{bmatrix}
a_{00} & & & \\
& a_{11} & & \\
& & a_{22} & \\
& & & a_{33}
\end{bmatrix} +
\begin{bmatrix}
& a_{01} & a_{02} & a_{03} \\
& & a_{12} & a_{13} \\
& & & a_{23} \\
& & &
\end{bmatrix}
$$
The current code traverses the coefficients of the lower matrix ($L$) in sorted order, i.e., $a_{10}, a_{20}, a_{21}, a_{30}, a_{31}, a_{32}$, and adds their contribution to the **row** that they are part of:
```cpp
wA[1] -= rD[1]*lower[0]*wA[0];
// done calculating wA[1]
wA[2] -= rD[2]*lower[1]*wA[0];
wA[2] -= rD[2]*lower[3]*wA[1];
// done calculating wA[2]
wA[3] -= rD[3]*lower[2]*wA[0];
wA[3] -= rD[3]*lower[4]*wA[1];
wA[3] -= rD[3]*lower[5]*wA[2];
// done calculating wA[3]
```
In other words, the current code calculates wA row by row. This is not optimal because it requires an additional memory lookup (via `losortPtr`) and, more importantly, the lower coefficients are not accessed in a contiguous manner. This is hard on the cache and leads to cache misses.
I propose the following change:
```cpp
for (label face=0; face<nFaces; face++)
{
wAPtr[uPtr[face]] -=
rDPtr[uPtr[face]]*lowerPtr[face]*wAPtr[lPtr[face]];
}
```
This code traverses the coefficients of the upper matrix ($U$) in sorted order, i.e., $a_{01}, a_{02}, a_{03}, a_{12}, a_{13}, a_{23}$, and adds their contribution to the **column** that they are part of:
```cpp
wA[1] -= rD[1]*lower[0]*wA[0];
// done calculating wA[1]
wA[2] -= rD[2]*lower[1]*wA[0];
wA[3] -= rD[3]*lower[2]*wA[0];
wA[2] -= rD[2]*lower[3]*wA[1];
// done calculating wA[2]
wA[3] -= rD[3]*lower[4]*wA[1];
wA[3] -= rD[3]*lower[5]*wA[2];
// done calculating wA[3]
```
In other words, after the algorithm finishes the calculation of a row, it distributes the contribution of the finished row to other rows.
From the perspective of the algorithm, it is important that no row of `wA` is used before it is fully calculated. This is the case in both implementations. The only difference is the order in which the coefficients are traversed. The result is numerically identical.
I run a quick benchmark on the `scalarTransportFoam/pitzDaily` testcase. In average, the preconditioner (forward + backward sweep) is around 31% faster.
On an interesting note, the DILU smoother already uses the proposed implementation.
### Target audience
Users of the DILU preconditioner.
### Proposal
See above.
### What does success look like, and how can we measure that?
nA
### Links / references
### Fundinghttps://develop.openfoam.com/Development/openfoam/-/issues/3086distributedTriSurfaceMesh : fails to work in certain mesh decomposition2024-01-16T05:26:29ZPrashant SonakardistributedTriSurfaceMesh : fails to work in certain mesh decompositionAttached an example case which fails in specific decomposition when using distributedTriSurface method. The case works when using triSurface method of invoking the geometry.[distributedTriSurface-issue.tgz](/uploads/11f031bd1928e7a5584f4...Attached an example case which fails in specific decomposition when using distributedTriSurface method. The case works when using triSurface method of invoking the geometry.[distributedTriSurface-issue.tgz](/uploads/11f031bd1928e7a5584f480fff1bbafb/distributedTriSurface-issue.tgz)
Reproducible in v2312
Cross Ref : EP#2357Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/3083vtkUnstructuredToFoam add read patches/regions capability2024-01-17T11:50:48Zfranco otaolavtkUnstructuredToFoam add read patches/regions capability### Functionality to add/problem to solve
Adding the possibility to read the boundaries of a vtk mesh imported using vtkUnstructuredToFoam
### Target audience
everyone who needs to import meshes to FOAM. the legacy vtk format is quit...### Functionality to add/problem to solve
Adding the possibility to read the boundaries of a vtk mesh imported using vtkUnstructuredToFoam
### Target audience
everyone who needs to import meshes to FOAM. the legacy vtk format is quite old, true, nevertheless, it is still used by several libraries and programs, and it is a quite simple format.
### Proposal
vtk format has a classification of the elements types such as it is shown in the following .vtk example and it is consisted of the following information:
```
POINTS #(list of all the vertexes internal and external of the mesh)
x0,y0,z0
x1,y1,z1
....
CELLS #(list of "cells" that can be nodes, edges, faces, volumetric cells)
nPoints0 p0 p1 p2
nPoints1 p1 p2 p3
....
CELL_TYPES #(indicates the type of element of the previous list such as if a 4 1 2 3 4 (a 'cell' in CELLS with 4 elements using the points 1, 2, 3 and 4) can be classified as a quadrangle face or a pyramid)
type0
type1
....
CELL_DATA #(is used to classify the CELLS in different groups, boundaries, regions etc)
scalar0
scalar1
.....
```
right now, OF when using vtkUnstructuredToFoam, it does not 'read' the information of CELL_DATA, it imports the mesh but all the faces goes to a defaultPatch. The feature request would be to use the CELL_DATA to reconstruct the patches from this information, even if the name of the boundary is simply the str(scalar)... to make 'usable' this format.
### What does success look like, and how can we measure that?
importing the vtk mesh I post it in this issue and getting the boundaries
### Links / references
here is information about the vtk format:
https://www.princeton.edu/~efeibush/viscourse/vtk.pdf
here is an old importer of vtk to FOAM:
https://github.com/edwardsp/VTKToFoam/blob/master/VTKToFoam.py
and here is a mesh example:
[test.vtk](/uploads/934da4e0a81da4671919da16713d1401/test.vtk)
### Funding
no funding sadly.https://develop.openfoam.com/Development/openfoam/-/issues/3079cyclicAMI transformation calculation uses a single face2024-01-11T13:28:32ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcyclicAMI transformation calculation uses a single face<!--
*** 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 -->
cyclicAMI transformation calculation uses a single face so can give large errors
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
### Example case
`incompressible/simpleFoam/pipeCyclic/`
In system/controlDict add:
```
DebugSwitches
{
cyclicAMI 1;
}
writePrecision 16;
```
and run e.g. checkMesh:
```
cyclicAMIPolyPatch::calcTransforms: patch:side2 Specified rotation: n0:(0 0.7071068286895752 -0.7071068286895752) n1:(0 -0.7071068286895752 -0.7071068286895752) swept angle: 90 [deg] reverse transform: (1 0 0 0 0 -1.00000011920929 0 1.00000011920929 0)
patch: side2
forwardT = 1((1 0 0 0 0 1.00000011920929 0 -1.00000011920929 0))
reverseT = 1((1 0 0 0 0 -1.00000011920929 0 1.00000011920929 0))
separation = 0()
collocated = 1(0)
```
The transformation should be close(r) to 1. Also checkMesh gives an open cells warning.
This is independent of #2635 since I replaced the #eval with calculated values in the blockMeshDict.
<!--
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 -->
no warning about open cells
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2312|v2306|v2212|v2206|v2112 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2312
### 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
-->
It currently uses the largest face.
- does it use the opposite face?
- or can it use some average?https://develop.openfoam.com/Development/openfoam/-/issues/3078moveMeshOuterCorrectors is ignored when using overPimpleDyMFoam2024-01-18T12:49:22ZRémi BoninmoveMeshOuterCorrectors is ignored when using overPimpleDyMFoam### Summary
An overset simulation with a 6DoF body is not affected by _moveMeshOuterCorrectors_ set to _yes_ when using several _nOuterCorrectors_ and the _newmark_ solver. The mesh is updated only once per timestep. This happens with _...### Summary
An overset simulation with a 6DoF body is not affected by _moveMeshOuterCorrectors_ set to _yes_ when using several _nOuterCorrectors_ and the _newmark_ solver. The mesh is updated only once per timestep. This happens with _overPimpleDyMFoam_, but _moveMeshOuterCorrectors_ works properly with _overBuoyantPimpleDyMFoam_.
### Steps to reproduce
Run a simulation with an overset mesh using the 6DoF library (_overPimpleDyMFoam_ solver, several _nOuterCorrectors_ and _moveMeshOuterCorrectors_ set to yes.
### What is the current *bug* behaviour?
The outer correctors happen properly, but the mesh movement is updated only once at the beginning of the current timestep.
### What is the expected *correct* behavior?
The mesh movement should be updated for every outer corrector.
### 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 : v2312|v2306|v2212|v2206|v2112 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2306
- Operating system : centOS
- Hardware info : 6 nodes with 26 cores each, case decomposed hierarchically
- Compiler :https://develop.openfoam.com/Development/openfoam/-/issues/3075Feature request: RANS turbulence modeling with rhoCentralFoam2024-01-18T12:48:56ZDjilou MioubFeature request: RANS turbulence modeling with rhoCentralFoamGreetings,
In the tutorials of `rhoCentralFoam` no tutorial demonstrate the use of RANS turbulence models.
Is it possible to implement RANS turbulence modelling for this solver?
Many thanks.Greetings,
In the tutorials of `rhoCentralFoam` no tutorial demonstrate the use of RANS turbulence models.
Is it possible to implement RANS turbulence modelling for this solver?
Many thanks.https://develop.openfoam.com/Development/openfoam/-/issues/3068snappyhexmesh simple multiregion test case meshes have very bad surface quali...2024-01-25T10:10:27Zmonkeyseesnappyhexmesh simple multiregion test case meshes have very bad surface quality and broken patches### Summary
### Steps to reproduce
Case attached, issue of bad patches happens on trivial and complex meshes where there's nesting or adjacency between the two regions.
### Example case
attached, case was generated with freecad thoug...### Summary
### Steps to reproduce
Case attached, issue of bad patches happens on trivial and complex meshes where there's nesting or adjacency between the two regions.
### Example case
attached, case was generated with freecad though problem has been scene with other stl generation methods like salome. I chose a tapered shape, a wedge - I've observed snappy having problems
multiregion contains a configuration geared towards conformal meshing of 2 regions in one meshing invocation. splitmesh is geared to one meshing per invocation. The snapped surface quality is substantially higher in the splitmesh version, though both have a oddly large repeating gap or trouble at the same points on the simple inner region.
[meshing.tar](/uploads/630be6ec3e30b4ba726c337ec459924a/meshing.tar)
[mycad.FCStd](/uploads/be114e3949faefbf82cf9bc3d524768e/mycad.FCStd)
### What is the current _bug_ behaviour?
I think there's at least 2 issues here. One is that the patches are very messed up. The second is that we get an odd behavior in both of these cases around the same region in space which is implicated into the patches being malformed. There's also a macro tear happening through the inner region which doesn't make much sense to me.
In similar or more advanced cases I've noted degenerate faces, near zero area at times or varying surface normals or alternate assignments of faces to differing patches. Flow would absolutely get mangled with these surfaces and the degenerate elements will drive courant numbers.
Here's a single pass multiregion output, note the very bad patches - the "inner" patch surface and "inner_to_outer" are disjoint and both incomplete. Makes downstream work impractical.
![multiregion-no-facezones-bad-patches.png](/uploads/f70836593d758a849215a22897202975/multiregion-no-facezones-bad-patches.png)
![multiregion-no-facezones.png](/uploads/9729e13786d0d2f8c3c856641da539fd/multiregion-no-facezones.png)
absolute nuttyness here:
![multiregion-no-facezones-nuttyness.png](/uploads/119ae64b047463f526445db0b71e71e5/multiregion-no-facezones-nuttyness.png){width="908" height="565"}
### What is the expected _correct_ behavior?
Here's a better though still a little odd mesh result for inner. This was meshed using separate invocations of snappyhexmesh so there's only one region at a time. It should be possible to get a conformal mesh result given there is only a single surface present at the interface which would give better topological information and allow skipping ami based interpolation without needing more advanced patch evaluation like https://cfd.direct/openfoam/free-software/non-conformal-coupling/
![splitmesh-same-settings.png](/uploads/6bad85fa172c854b20e550371c5a0e97/splitmesh-same-settings.png)
one more level of refinement was allowed for this to see what would happen:
![splitmesh-inner-edges-r3.png](/uploads/b752f08b51bc62c1e38bbab3d293a402/splitmesh-inner-edges-r3.png)
### Relevant logs and/or images
### Environment information
- OpenFOAM version : 2312
- Operating system : linux opensuse 15.5
- Hardware info :\`
- Compiler :
### Possible fixeshttps://develop.openfoam.com/Development/openfoam/-/issues/3067Different residuals between serial and decomposed parallel case2024-01-18T12:47:18ZDjilou MioubDifferent residuals between serial and decomposed parallel caseGreetings,
In running the cavity tutorial I've noticed that the residuals differ between the serial case and the decomposed case.
The steps I followed are:
- run the serial case `icoFoam > logSerial`
- Without changing anything except...Greetings,
In running the cavity tutorial I've noticed that the residuals differ between the serial case and the decomposed case.
The steps I followed are:
- run the serial case `icoFoam > logSerial`
- Without changing anything except the `decomposeParDict` file changed the number of subdomains to `2` and used the method `scotch`, then run: `mpirun -n 2 icoFoam -parallel > logParallel`
I run it for only 2 time steps, then compare the log files:
![image](/uploads/b0d38805f29d5fad47a37e6e81fa72ff/image.png)
Why there is a difference between the serial and parallel case?
**Note**: I am using the version 2306 on Ubuntu 22.04https://develop.openfoam.com/Development/openfoam/-/issues/3064streamFunction FO message about not finding seed2023-12-20T13:10:09ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comstreamFunction FO message about not finding seed<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
streamFunction FO reports message about not finding starting seed. Investigate. Also indentation of various FOs (see case below) is not consistent.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Run `incompressible/pisoFoam/RAS/cavity`
### What is the current *bug* behaviour?
Message about streamFunction not finding seed.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2306|v2212|v2206|v2112|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2310https://develop.openfoam.com/Development/openfoam/-/issues/3062OPENMPI version in ThirdParty2024-01-18T12:46:44ZJozsef NagyOPENMPI version in ThirdParty### Summary
Incorrect openmpi version in etc/config.sh/mpi
### Steps to reproduce
In the current dev version in
etc/config.sh/mpi
it says
export FOAM_MPI=openmpi-4.1.2
If one selects in etc/bashrc
export WM_MPLIB=OPENMPI
there ...### Summary
Incorrect openmpi version in etc/config.sh/mpi
### Steps to reproduce
In the current dev version in
etc/config.sh/mpi
it says
export FOAM_MPI=openmpi-4.1.2
If one selects in etc/bashrc
export WM_MPLIB=OPENMPI
there is an error while compiling the ThirdParty directory, as the latest downloadable ThirdParty version is v2106 and there the openmpi version is 4.0.3
If one changes the version to
export FOAM_MPI=openmpi-4.0.3
compilation runs just fine. Possibly it would be a good idea to change the entry in etc/config.sh/mpi to 4.0.3, as this is the version shipping officially.
### Example case
not needed
### What is the current *bug* behaviour?
compilation error due to missing openmpi version
### What is the expected *correct* behavior?
correct compilation of 4.0.3
### Relevant logs and/or images
not needed
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2306|v2212|v2206|v2112|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : dev
- Operating system : ubuntu
- Hardware info : not needed
- Compiler : gcc
### Possible fixes
change entry to 4.0.3 or ship 4.1.2 in ThirdParty-v2312https://develop.openfoam.com/Development/openfoam/-/issues/3059Free Stream BC not working with ABL2023-12-19T10:11:10ZRaphael AranhaFree Stream BC not working with ABL<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
The freeStream BC is not working properly with atmBoundaryLayerInletVelocity. It is not loading the information of the ABL and only using the value .
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
### Example case
if you try to run the example in the link https://www.openfoam.com/documentation/guides/latest/api/classFoam_1_1freestreamFvPatchField.html
it will not work, it will request a value and the value will overwrite the ABL profile
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
### What is the current *bug* behaviour?
<!-- What actually happens -->
### What is the expected *correct* behavior?
<!-- What you should see instead -->
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2306|v2212|v2206|v2112|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :v2306
- Operating system : ubuntu
- Hardware info :
- Compiler :
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->https://develop.openfoam.com/Development/openfoam/-/issues/3056checkMesh writes fields with 'calculated' also on empty patches2023-12-13T17:10:59ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcheckMesh writes fields with 'calculated' also on empty patches<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
`checkMesh -writeAllFields` on case with empty writes volFields with 'calculated' on empty patches. E.g. paraview does not like this at all.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
```
cavity tutorial
checkMesh -writeAllFields
```
and look at e.g. `faceWeight` on frontAndBack empty patches.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
Probably not override the empty constraint? Or have paraview accept `patchType` override?
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2306|v2212|v2206|v2112|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2310https://develop.openfoam.com/Development/openfoam/-/issues/3055snappyHexMesh :: Prediction of maxNewCells wrong with new code2023-12-15T22:25:11ZTobias HolzmannsnappyHexMesh :: Prediction of maxNewCells wrong with new code<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
Hey everybody,
in v2306, the balancing method within snappy was improved based on the code snippet I provided to L2.
https://develop.openfoam.com/Development/openfoam/-/merge_requests/607
The issue appears now due to a one-liner change from Mattijs:
- This line now calculates only zero for the `maxLocalCell` variable, if we first refine and then balance https://develop.openfoam.com/Development/openfoam/-/commit/4a5f542cb431665fc85165e13b29ab1202b99aa3#31acf059fb90704d54379ac0c705eac1a85803dd_2601_2632
- This is related to the fact that this line was introduced by Mattijs to fix the wrong `balance` calculation: https://develop.openfoam.com/Development/openfoam/-/blob/develop/src/mesh/snappyHexMesh/meshRefinement/meshRefinementRefine.C?ref_type=heads#L2762
Hence, the calculation of `maxLocalCells` is wrong (as it is zero all the time and the trigger value will never be taken into account). However, this value is mainly necessary if e.g., locally on one single proc a refinement happens significantly (imagine a refinement based on the surfaceFeatureAngle while using a `level (4 6)` refinement for example.
The discrepancy at the moment is:
- The balancing factor is calculated correctly (in previous versions we were over predicting the nNewCells value due to the fact that the refinement took place alreads)
- On the other hand, the balancing trigger value `maxLocalCells` is zero now (if refineAndBalance is used) and thus, the trigger will not be used anymore
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
To check that the values of `maxLocalCells` are always zero, simply execute snappyHexMesh while having `maxLocalCells 100000000;` to explicitly go step into the `refineAndBalance` function rather than `balanceAndRefine`.
<!-- How one can reproduce the issue - this is very important -->
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
### What is the current *bug* behaviour?
Described in the summary.
<!-- What actually happens -->
### What is the expected *correct* behavior?
If we use `refineAndBalance` the `maxLocalCells` should be calculated correctly.
<!-- What you should see instead -->
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->https://develop.openfoam.com/Development/openfoam/-/issues/3047mapDistribute does not support non-blocking2023-12-09T18:13:44ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commapDistribute does not support non-blocking### Functionality to add/problem to solve
mapDistributeBase supports non-blocking / two-stage communication + consumption. This is not mapped through to mapDistribute. This is currently not used (e.g. non-blocking cyclicAMIFvPatchField ...### Functionality to add/problem to solve
mapDistributeBase supports non-blocking / two-stage communication + consumption. This is not mapped through to mapDistribute. This is currently not used (e.g. non-blocking cyclicAMIFvPatchField applies its own transformation). It might be useful if we want to extend e.g. wall distance calculation to use this two-stage process.
### Proposal
Add an send/receive equivalent to mapDistribute to replace the single mapDistributeBase::distribute.https://develop.openfoam.com/Development/openfoam/-/issues/3041cht solid temperature distribution2023-12-11T19:23:58ZPekkacht solid temperature distribution### Summary
Solid temperature distribution in steady cht solver with mixture models pureZoneMixture and pureMixture leads nonphysical results. The same case by simulated with separated regions give a different results than single region...### Summary
Solid temperature distribution in steady cht solver with mixture models pureZoneMixture and pureMixture leads nonphysical results. The same case by simulated with separated regions give a different results than single region case.
In pureZoneMixture case temperature distribution look that heat goes from lower to higher temperature. In pureMixture case heat flux does not match between regions. Temperature distribution looks logical but temperature levels are much higher that single region case.
![T2](/uploads/7aaa99e1c9251e903504ed2ac6cd0726/T2.png)
### Steps to reproduce
Please find attached cases. By looking heat flux data from log files and temperature distribution is possible notice difference between mixture models.
### Example case
### What is the current _bug_ behaviour?
Results are unreliable
### What is the expected _correct_ behavior?
In pureZoneMixture case temperature distribution can be "fix" by setting the same Cp values to all materials. I think that in solid solver is used alpha instead of kappa in temperature equation.
### Relevant logs and/or images
T fixed wall0 to 300 and wall1 to 400 K. Heat source 10 W in middle of the model. pureZoneMixture heat flux:
```plaintext
min/max/integ(wall0) = -1322.838, -1322.838, -132.2838
min/max/integ(wall1) = 1222.838, 1222.838, 122.2838
```
difference between in and out 10 W and it is OK. Respectively pureMixture case
```plaintext
min/max/integ(wall0) = -114.41282, -114.41282, -11.441282
min/max/integ(z1_to_z2) = 594.6436, 594.6436, 59.46436
min/max/integ(z2_to_z1) = -594.6436, -594.6436, -59.46436
min/max/integ(z2_to_z3) = 2408.3388, 2408.3388, 240.83388
min/max/integ(wall1) = -15889.687, -15889.687, -1588.9687
min/max/integ(z3_to_z2) = -2408.3388, -2408.3388, -240.83388
```
wall0 and wall1 difference is much higher (1588 - 11) than 10 W.
### Environment information
- OpenFOAM version : v2212
- Operating system : AlmaLinux 8
- Hardware info : Intel Core 8
- Compiler : gcc version 8.5.0 20210514 (Red Hat 8.5.0-18) (GCC)
### Possible fixes
\[chtCases.zip\](/uploads/0b33599299701063e04e68c42a50fb47/chtCases.zip
[chtCases.tar.xz](/uploads/12757bc6320abcbbc15e9fded6189f8e/chtCases.tar.xz)Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/3040Turbulence model not runtime selectable2023-12-05T11:50:08ZBas NieuwboerTurbulence model not runtime selectable<!--
*** 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
When I change a turbulence model during runtime, the turbulence properties are re-read as shown by the log: "Re-reading object turbulenceProperties from file ". However, the turbulence model itself does not change. I've tested this on openfoam V2306 and V1712 (oldest one I have on my machine).
It might be a design choice not to have this feature. However, I cannot find any warning on this in the documentation (or in the log). I might be a an odd one, wanting to change the turbulence model during runtime. I would like to change the turbulence model, since it allows using a more stable turbulence model during startup and changing it to a more accurate one during runtime.
### Steps to reproduce
1) Take the incompresseble TJunction case: (tutorials/incompressible/pimpleFoam/RAS/TJunction)
2) Increase the simulated time (say 15 s) to ensure you have time to change the turbulence dict before the end of the simulation
3) run blockMesh
4) run pimpleFoam > log
5) Change the turbulence model to kOmega in turbulenceProperties
- This should cause a crash, since the Omega field is not created/read. However, the solver just keeps on running
- Check if the turbulence properties is changed by looking for: "Re-reading object turbulenceProperties from file " in the log file.
### Example case
the incompresseble TJunction case: (tutorials/incompressible/pimpleFoam/RAS/TJunction)
### What is the current *bug* behaviour?
The simulation keeps on running using the kEpsilon model
### What is the expected *correct* behavior?
The simulation should crash, since the Omega field is not present.
### Environment information
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : aff5c3b680-20230703 OPENFOAM=2306 version=v2306 | v1712
Operating system : ubuntu 18.04
Compiler : gcc
### 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/3036epsilonWallFunction: Expression of espilon in log layer2023-11-27T17:35:31Zs1291epsilonWallFunction: Expression of espilon in log layerIn this documentation page about [`epsilonWallFunction`](https://www.openfoam.com/documentation/guides/latest/doc/guide-bcs-wall-turbulence-epsilonWallFunction.html), the expression of $\epsilon_\text{log}$ is given by:
$$
\epsilon_\tex...In this documentation page about [`epsilonWallFunction`](https://www.openfoam.com/documentation/guides/latest/doc/guide-bcs-wall-turbulence-epsilonWallFunction.html), the expression of $\epsilon_\text{log}$ is given by:
$$
\epsilon_\text{log} = wC_\mu\frac{k^{3/2}}{\nu_{t,w}y} \tag{1}
$$
However, in the [source code](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/TurbulenceModels/turbulenceModels/derivedFvPatchFields/wallFunctions/epsilonWallFunctions/epsilonWallFunction/epsilonWallFunctionFvPatchScalarField.C#L225), the following expression is used:
$$
\epsilon_\text{log} = wC_{\mu}^{3/4}\frac{k^{3/2}}{\kappa y} \tag{2}
$$
Unless the expressions $\frac{C_\mu}{\nu_{t,w}}$ and $\frac{C_{\mu}^{3/4}}{\kappa}$ are equivalent, the expression (1) should be corrected in the documentation.
Thank youhttps://develop.openfoam.com/Development/openfoam/-/issues/3032redistributePar slow with preservePatches cosntraint2023-11-23T07:14:20ZTimofey MukharedistributePar slow with preservePatches cosntraintFollow-up to #2924, but not necessarily related in terms of what causes the issue.
To reliably decompose cyclic boundaries with `redistributePar` we currently need to use the `preservePatches` constraint for the cyclic boundaries. Unfor...Follow-up to #2924, but not necessarily related in terms of what causes the issue.
To reliably decompose cyclic boundaries with `redistributePar` we currently need to use the `preservePatches` constraint for the cyclic boundaries. Unfortunately, this seems to cause a strong dip in performance of the utility. According to @Mattijs this should not really happen. I have first observed this on my own case, but now got some numbers using the `periodicHill` tutorial.
I use the `steadyState` case in the tutorial, bump the number of processors in `decomposeParDict` to 32, and accordingly switch to 4 partitions along y. Additionally, we add
```
constraints
{
patches
{
//- Keep owner and neighbour on same processor for faces in patches
// (only makes sense for cyclic patches and cyclicAMI)
type preservePatches;
patches (inlet outlet);
}
}
```
which we can comment and uncomment to compare.
Furthermore, it is better to make the case a bit larger, so in `blockMeshDict` we set the size of the `hex` to `(200 160 400)`, and then run `blockMesh`.
Now, we decompose the case with
`time mpirun -n 32 redistributePar -decompose -latestTime -parallel -fileHandler collated`
On my machine, I get a 3x slowdown when preserving the patches.