Development issueshttps://develop.openfoam.com/groups/Development/-/issues2022-09-28T14:12:02Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2537Problem with snappyHexMesh when OpenFOAM is compiled using FMA-Instructions2022-09-28T14:12:02ZFlavio GaleazzoProblem with snappyHexMesh when OpenFOAM is compiled using FMA-Instructions<!--
*** 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
I found a problem when using snappyHexMesh and a specific grid. In certain machines, the grid is correctly generated, in others, snappyHexMesh hangs in an endless loop.
The problem is correlated to FMA instructions (Fused Multiply-Accumulate) in new CPUs. I have tested using AMD EPYC and Intel Skylake CPUs, and various versions of GCC and Intel Compiler. When compiling the code with –O2 or –O3 and the flag for FMA (-mfma) or the CPU architecture (-march=znver2 or -march=skylake), FMA instructions are turned on, which have a different rounding precision than operations without FMA. Thus a test in particle.C is too strict, and the distance between particles and tet faces is not captured correctly. This creates an endless loop at the stage “Feature refinement iteration 0” of the grid creation.
The operation that uses FMA is the ^ operator used to calculate T in Foam::particle::stationaryTetReverseTransform. The test that fails is in Foam::particle::trackToStationaryTri, line 759 of particle.C `(if (Tx1[i] < - detA*SMALL))`.
### Steps to reproduce
Compile OpenFOAM with FMA flags on and off (the bugged code is in the src/lagrangian/basic/particle library).
Create the mesh from the file attached (mesh.tgz) using snappyHexMesh. Using the version compiled with FMA flags hangs.
[mesh.tgz](/uploads/d48ebc937bdea4fa7f27cc37c1b3e6f8/mesh.tgz)
### Example case
A small code example with the same operations as the ^ operator is also attached (Test_CrossProduct.cpp). Using separated multiply and addition results in (0 0 0), as the calculations are rounded twice. When using FMA, the result is rounded only once, showing the rounding error of a double variable (e.g. -8.73968e-17 -1.82965e-16 1.82965e-16).
[Test_CrossProduct.cpp](/uploads/bce4efcb9a48fc38ebee8838a4de79e4/Test_CrossProduct.cpp)
Without FMA
```
g++ -O3 -o Test_CrossProduct Test_CrossProduct.cpp
chmod 755 Test_CrossProduct
./Test_CrossProduct
```
With FMA
```
g++ -mfma -O3 -o Test_CrossProduct Test_CrossProduct.cpp
chmod 755 Test_CrossProduct
./Test_CrossProduct
```
### What is the current *bug* behaviour?
snappyHexMesh hangs in an endless loop.
### What is the expected *correct* behavior?
snappyHexMesh creates the grid.
### 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 : v2206|v2112|v2106|v2012|v2006 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2106
- Operating system : CentOS 8
- Hardware info : AMD EPYC, Intel Skylake
- Compiler : GCC and intel
### Possible fixes
The solution for this is straightforward, just replacing SMALL with ROOTSMALL, and everything works. The file with the correction is attached.
[particle.C.patch](/uploads/a26a860e86621fef7b54832d18f638f4/particle.C.patch)Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/2538BUG: diameterModel: duplicate entry error2022-08-19T09:03:35ZKutalmış BerçinBUG: diameterModel: duplicate entry error### Summary
`./Alltest` on `$FOAM_TUTORIALS/multiphase/twoPhaseEulerFoam/laminar/fluidisedBed` throws a duplicate entry error as follows:
```
Duplicate entry constant in runtime table diameterModel
#0 .../lin...### Summary
`./Alltest` on `$FOAM_TUTORIALS/multiphase/twoPhaseEulerFoam/laminar/fluidisedBed` throws a duplicate entry error as follows:
```
Duplicate entry constant in runtime table diameterModel
#0 .../linux64ClangDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam5error14safePrintStackERSo+0x2b) [0x7fee94eb627b]
#1 .../linux64ClangDPInt32Opt/lib/libcompressibleTwoPhaseSystem.so(_ZN4Foam13diameterModel31adddictionaryConstructorToTableINS_14diameterModels8constantEEC2ERKNS_4wordE+0xe4) [0x7fee95761e14]
#2 .../linux64ClangDPInt32Opt/lib/libreactingMultiphaseSystem.so(+0x25981f) [0x7fee89fe781f]
```
### Environment information
8b1514c99b-20220711Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2541Limiting the pressure (p or p_rgh) as an fvOption entry rather than having it...2022-07-25T15:44:42ZTobias HolzmannLimiting the pressure (p or p_rgh) as an fvOption entry rather than having it in the fvSolutions file### Functionality to add/problem to solve
For compressible flows it might be beneficial to limit the pressure values to some defined ranges in order to avoid non-physical behavior such as negative pressure or values which will never occ...### Functionality to add/problem to solve
For compressible flows it might be beneficial to limit the pressure values to some defined ranges in order to avoid non-physical behavior such as negative pressure or values which will never occur in the simulation one is performing. E.g., external aerodynamics might have a defined range around the atmospheric pressure value but will never get negative or too high.
We can limit the pressure values by using the pMin and pMax keywords inside the system/fvSolutions subDict (SIMPLE/PIMPLE/PISO) but personally, I would prefer to have some fvOption model that takes care of that such as the limitVelocity or limitTemperature. That would unify the code and we would have everything in one place.
Checking our actual implementation of the pMin and pMax results in the pressureControl class. So its implemented but maybe it would make sense to change it to be used with the fvOptions file?
### Target audience
As we have already an working implementation, probably no-one. However, we would have limitVelocity, limitPressure as well as limitTemperature in one place.
### Proposal
Its already implemented in the .org version.
https://github.com/OpenFOAM/OpenFOAM-dev/tree/master/src/fvConstraints/limitPressure
### What does success look like, and how can we measure that?
Success: Probably having all "limiting" constraints in one file (fvOptions) rather than split into fvSolution and fvOptions.
### Links / references
https://github.com/OpenFOAM/OpenFOAM-dev/commit/ab7d010a9aa91576a93ed7b09bb0f4e607a0fbd8
### Funding
Functionality already exist in the .org version.Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2546colons in filenames break Makefiles2022-08-24T16:42:07ZSergey Matsievskiycolons in filenames break Makefiles<!--
*** 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 -->
OpenFOAM sometimes uses colons in filenames (e.g. `0/jouleHeatingSource:V`). There's a number of issues due to this: #2224 #1142 #1675.
One additional problem with this is that colons (`:`) in file names [break Makefiles](https://lists.gnu.org/archive/html/bug-make/2004-10/msg00010.html).
Consider this example:
```makefile
FIELD_FILES_ORIG:=$(wildcard 0.orig/*)
FIELD_FILES:=$(foreach v,$(FIELD_FILES_ORIG),$(notdir $(v)))
FIELD_FILES_INITIAL:=$(foreach v,$(FIELD_FILES),0/$(v))
0/cellToRegion: constant/polyMesh $(FIELD_FILES_INITIAL) | 0
splitMeshRegions -cellZones -overwrite
renumberMesh -allRegions -overwrite
```
This code tracks changes in `0/*` files and run OpenFOAM subprograms on demand. However, it breaks when `:` characters are in the names of the files.
### Steps to reproduce
Execute code
```bash
git clone https://develop.openfoam.com/Development/openfoam.git --branch master
cd openfoam/tutorials/heatTransfer/chtMultiRegionSimpleFoam/jouleHeatingSolid
cat > Makefile << _EOF_
FILES:=\$(wildcard 0.orig/**/*)
all: \$(FILES)
echo success
_EOF_
make
```
Observe GNU Make error.
Fix file names and try again
```bash
rename 's/:/-/' 0.orig/solid/*
make
```
Observe output string `success`.
### 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 `Steps to reproduce`*
### What is the current *bug* behaviour?
<!-- What actually happens -->
OpenFOAM file names break GNU Make automation
### What is the expected *correct* behavior?
OpenFOAM file names do not break GNU Make automation
### 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 : v2206|v2112|v2106|v2012|v2006 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2206
- Operating system : GNU Debian bookworm
- Hardware info : x86-64
- 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
-->
It is clear that changing file name separator would break many existing OpenFOAM based projects. IMHO the best way to deal with this is to replace hardcoded file names with some kind of `FIELD_FILE_NAME_SEPARATOR` macro and throw a deprecation warning when its value is `:`. This way, people could easily roll back changes in case of problems with their projects.https://develop.openfoam.com/Development/openfoam/-/issues/2548dynamicCode compiler options get overwritten2022-09-28T16:28:41ZSergey MatsievskiydynamicCode compiler options get overwritten<!--
*** 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 -->
When using `scalarCodedSource` with custom libraries compiler options supplied via `codeOptions` field get overwritten. The same problem probably exists with `codeLibs`, but due to this error I could never get to the linking stage of the compilation.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
```bash
git clone https://develop.openfoam.com/Development/openfoam.git --branch master
cd openfoam/tutorials/heatTransfer/chtMultiRegionSimpleFoam/jouleHeatingSolid
cat > constant/solid/fvOptions << _EOF_
/*--------------------------------*- C++ -*----------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: 2206 |
| \\ / A nd | Website: www.openfoam.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
FoamFile
{
version 2;
format ascii;
class dictionary;
object fvOptions;
}
customHeatSource
{
type scalarCodedSource;
name heatSource;
active true;
scalarCodedSourceCoeffs
{
selectionMode all;
fields ( h );
codeInclude #{ #include <mpi.h> #};
codeOptions #{ #};
codeLibs #{ #};
codeCorrect #{ #};
codeAddSupRho #{ Pout << "hello!" << std::endl #};
codeAddSup #{ #};
codeConstrain #{ #};
}
}
_EOF_
./Allclean
./Allrun.pre
chtMultiRegionSimpleFoam
```
Observe compilation error `mpi.h: No such file or directory`.
Add output of `pkg-config --cflags mpi-cxx` and `pkg-config --libs mpi-cxx` to `codeOptions` and `codeLibs` of `constant/solid/fvOptions` respectively (sorry, I don't know how to set verbatim fields from `foamDictionary`). On my machine, edited lines look like this:
```c++
codeOptions #{ -pthread -I/usr/lib/x86_64-linux-gnu/openmpi/include -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi #};
codeLibs #{ -L/usr/lib/x86_64-linux-gnu/openmpi/lib -lmpi_cxx -lmpi #};
```
Run compilation again and catch compilation commands using [bear](https://github.com/rizsotto/Bear).
```bash
rm -rf dynamicCode
./Allclean
./Allrun.pre
bear -- chtMultiRegionSimpleFoam
```
Observe the same compilation error `mpi.h: No such file or directory`.
Issue command
```bash
cat dynamicCode/heatSource/Make/options
```
and observe that `codeOption` paths are the same as in `fvOptions` file
Issue command
```bash
cat compile_commands.json
```
and observe that `x86_64-linux-gnu` strings in compilation commands were replaced by `x86_64-1-gnu`.
### Example case
_See **Steps to reproduce**_
<!--
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 -->
User supplied compiler options are modified before compilation
### What is the expected *correct* behavior?
<!-- What you should see instead -->
User supplied compiler options are NOT modified before compilation
### 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 : v2206|v2112|v2106|v2012|v2006 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : master 76d719d1e6f955c85bbf2b37563c5c19b0c386d6
- Operating system : GNU Linux Debian bookworm
- Hardware info : x86-64
- Compiler : gcc (Debian 11.3.0-4) 11.3.0
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2550Abnormal velocity near the wall on overset mesh2022-08-13T08:45:54Zgrace wAbnormal velocity near the wall on overset mesh<!--
*** 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 -->
I tried to use the developed version(feature-overset-couplepatch) to simlulate a wall-contact problem for piston-like flow. The object in this case has no motion (it is set by zero amplitude of periodic motion) so that the pressure should be constant and velocity is zero on both sides of the object. However, a false velocity near the wall contact area is computed. Similar phenomena occurs when the amplitude is set non-zero(e.g. 0.2) for periodic motion.
The abnormal velocity is next to the porous cell. The velocity from the donor may be ill-calculated in this region.
### 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
-->
Here is the case file.
[wallcontact-zeromotion.zip](/uploads/6b49113b64c0d2142f1d67d8076a66bb/wallcontact-zeromotion.zip)
### What is the current *bug* behaviour?
<!-- What actually happens -->
The abnormity of the velocity near the wall corner occurs at the very first timestep and it is increased with the time step.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
The velocity near the wall corner should be zero.
### Relevant logs and/or images
Attach here is the results from the first timestep.
![celltype](/uploads/fe135b065002206a77ffa07c59c21661/celltype.png)
![U](/uploads/998363489f88d339f6ca676d84c629f2/U.png)
![p](/uploads/cd0f25cff44a8162ad8223352c2ea321/p.png)
![U-threshold](/uploads/504854ea8e675cab7d2cb25ee436f1aa/U-threshold.png)
![p-threshold](/uploads/90f4a928b64dfc775fb8574787fe6c10/p-threshold.png)
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
Courant Number mean: 0.671294 max: 0.75
Time = 0.01
inverseDistance : detected 2 mesh regions
zone:0 nCells:1875 voxels:(400 400 1) bb:(-0.5 -0.5 0) (0.5 0.5 0.05)
zone:1 nCells:501 voxels:(400 400 1) bb:(-0.5 -0.5 0) (0.5 0.5 0.05)
void Foam::cellCellStencils::inverseDistance::findHoles(const Foam::globalIndex&, const Foam::fvMesh&, const labelList&, const labelListList&, Foam::labelList&) const : Starting hole flood filling
void Foam::cellCellStencils::inverseDistance::findHoles(const Foam::globalIndex&, const Foam::fvMesh&, const labelList&, const labelListList&, Foam::labelList&) const : Starting hole cells : 97
void Foam::cellCellStencils::inverseDistance::findHoles(const Foam::globalIndex&, const Foam::fvMesh&, const labelList&, const labelListList&, Foam::labelList&) const : Marked internal hole boundaries : 143
void Foam::cellCellStencils::inverseDistance::findHoles(const Foam::globalIndex&, const Foam::fvMesh&, const labelList&, const labelListList&, Foam::labelList&) const : Marked all hole boundaries : 143
void Foam::cellCellStencils::inverseDistance::findHoles(const Foam::globalIndex&, const Foam::fvMesh&, const labelList&, const labelListList&, Foam::labelList&) const : Determined regions : 12
void Foam::cellCellStencils::inverseDistance::findHoles(const Foam::globalIndex&, const Foam::fvMesh&, const labelList&, const labelListList&, Foam::labelList&) const : Done local analysis
void Foam::cellCellStencils::inverseDistance::findHoles(const Foam::globalIndex&, const Foam::fvMesh&, const labelList&, const labelListList&, Foam::labelList&) const : Converted stencil into compact form
void Foam::cellCellStencils::inverseDistance::findHoles(const Foam::globalIndex&, const Foam::fvMesh&, const labelList&, const labelListList&, Foam::labelList&) const : Gathered region type
void Foam::cellCellStencils::inverseDistance::findHoles(const Foam::globalIndex&, const Foam::fvMesh&, const labelList&, const labelListList&, Foam::labelList&) const : Interpolated region type
void Foam::cellCellStencils::inverseDistance::findHoles(const Foam::globalIndex&, const Foam::fvMesh&, const labelList&, const labelListList&, Foam::labelList&) const : Determined regions changed : 0
void Foam::cellCellStencils::inverseDistance::findHoles(const Foam::globalIndex&, const Foam::fvMesh&, const labelList&, const labelListList&, Foam::labelList&) const : Finished hole flood filling : 0
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2206|v2112|v2106|v2012|v2006 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :v2112 feature-overset
- Operating system :ubuntu 20.04
- Hardware info :
- Compiler :gcc 9
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
In stencilWeights function, the inverse distance is used to calculate the weights of donor. It may need to consider the potential contribution from porous cell, e.g., the interpolate cell next to the porous cell in this case.
void Foam::cellCellStencils::inverseDistance::stencilWeights
(
const point& sample,
const pointList& donorCcs,
scalarList& weights
) const
{
// Inverse-distance weighting
weights.setSize(donorCcs.size());
scalar sum = 0.0;
forAll(donorCcs, i)
{
scalar d = mag(sample-donorCcs[i]);
if (d > ROOTVSMALL)
{
weights[i] = 1.0/d;
sum += weights[i];
}
else
{
// Short circuit
weights = 0.0;
weights[i] = 1.0;
return;
}
}
forAll(weights, i)
{
weights[i] /= sum;
}
}
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->https://develop.openfoam.com/Development/openfoam/-/issues/2551adjointOptimisation uses IOdictionary with processor-local scope2022-08-04T11:25:16ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comadjointOptimisation uses IOdictionary with processor-local scope<!--
*** 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 -->
adjointOptimisation uses localIOdictionary instead of plain IOdictionary
This is from visual inspection. The difference between the two is subtle and only in parallel : localIOdictionary is used to e.g. read a (decomposed) field, plain IOdictionary is used to read e.g. system/controlDict. The two versions have different IO behaviour - plain IOdictionary will look in the undecomposed directory, localIOdictionary will only look in the processorXXX directory. Can the IOdictionaries be different on different processors?
### What is the current *bug* behaviour?
<!-- What actually happens -->
We've seen this when using changeDictionary in parallel with `-fileHandler collated` - it does not change the correct file. Maybe it is not a problem for the adjointOptimisation.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2206|v2112|v2106|v2012|v2006 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2206
### 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 IOdictionary instead?Vaggelis PapoutsisVaggelis Papoutsishttps://develop.openfoam.com/Development/ThirdParty-common/-/issues/65Incorrect download links for METIS during compilation2022-08-04T14:44:02ZDanyal MohaddesIncorrect download links for METIS during compilation# Summary
The download links for METIS provided during ThirdParty compilation are out of date.
# Steps to Reproduce
1. Download the latest version of ThirdParty (v2206)
2. `./Allwmake`
# Current Behavior
When METIS compilation is reach...# Summary
The download links for METIS provided during ThirdParty compilation are out of date.
# Steps to Reproduce
1. Download the latest version of ThirdParty (v2206)
2. `./Allwmake`
# Current Behavior
When METIS compilation is reached (and skipped), the links provided to download METIS are to [this link](http://glaros.dtc.umn.edu/gkhome/metis/metis/overview) and [this link](http://glaros.dtc.umn.edu/gkhome/fetch/sw/metis/metis-5.1.0.tar.gz). These links are out of date; the package has since moved.
# Correct Behavior
The link provided to download METIS should be [this one](https://github.com/KarypisLab/METIS).
# Possible fix
Update the links in `BUILD.md`https://develop.openfoam.com/Development/openfoam/-/issues/2557Be able to choose the order of eigenvalues2022-08-11T07:26:55Zt RockBe able to choose the order of eigenvaluesCurrently the eigenvalue calculation returns the values in ascending order.
For several applications it is not uncommon to use them in descending order, which will require an additional operation to reverse the order.
If possible, I ...Currently the eigenvalue calculation returns the values in ascending order.
For several applications it is not uncommon to use them in descending order, which will require an additional operation to reverse the order.
If possible, I would like to request the possibility of selecting the order of the output.
Something like:
```
#include <iostream>
#include <vector>
#include <algorithm>
enum sortType{ascending, descending};
template<sortType S=ascending>
void sort (std::vector<double>& v)
{
std::sort(v.begin(), v.end());
}
template <>
void sort<descending> (std::vector<double>& v)
{
std::sort(v.begin(), v.end(), std::greater<>());
}
template<sortType S=ascending>
void foo(const std::vector<double>& v)
{
std::vector<double> v2 (v);
sort<S>(v2);
for (int i = 0; i< v.size(); i++)
{
std::cout << v2[i] << std::endl;
}
}
int main()
{
std::vector<double> tst = {1,3,4,2,5};
foo(tst);
foo<descending>(tst);
return 0;
}
```
This will keep the current code running as is, but with the flexibility of letting the user choose the order of the output.
It would also be nice to have the eigen vectors come out as column vectors. Currently they are row vectors. This would bring more similarity to other libraries, e.g., numpy, matlab
Best RegardsKutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2558faceAgglomerate assumes viewFactorsDict entries are all patch names2022-08-11T13:44:33ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfaceAgglomerate assumes viewFactorsDict entries are all patch names### Functionality to add/problem to solve
The `faceAgglomerate` app reads the `viewFactorsDict` (as does the `viewFactorsGen` app) . It iterates through the entries and checks if any are patch names. This gives big weirdness if e.g. a p...### Functionality to add/problem to solve
The `faceAgglomerate` app reads the `viewFactorsDict` (as does the `viewFactorsGen` app) . It iterates through the entries and checks if any are patch names. This gives big weirdness if e.g. a patch has the same name as one of the settings needed by `viewFactorsGen`.
### Target audience
Users of view factor radiation.
### Proposal
Put the patch information in `viewFactorsDict` in a sub dictionary:
```
writeViewFactorMatrix true;
writeFacesAgglomeration true;
writePatchViewFactors false;
//- Debug option
debug 1;
//- Dump connectivity rays
dumpRays false;
//- Optional per-patch agglomeration if faceAgglomerate is used
patchAgglomeration
{
".*"
{
nFacesInCoarsestLevel 100; // increase to get more radiation patches (coarse faces)
featureAngle 30; // 0: one radiation patch (coarse face) over one cell face
}
}
//- Maximum length for dynamicList. See /applications/utilities/preProcessing/viewFactorsGen/shootRays.H
maxDynListLength 1000000000;
```
### What does success look like, and how can we measure that?
- be backwards compatible
- use the patchAgglomeration subdictionary if it is thereMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2562Implementation errors in createBoxTurb utility2022-12-23T15:51:27ZMario HermesImplementation errors in createBoxTurb utilityDear ESI-OpenFOAM development team,
I use the OpenFOAM version 2112 and stumbled upon two implementation errors in the utility "createBoxTurb" which is used to initialize a homogeneous isotropic turbulent flow field based on the method...Dear ESI-OpenFOAM development team,
I use the OpenFOAM version 2112 and stumbled upon two implementation errors in the utility "createBoxTurb" which is used to initialize a homogeneous isotropic turbulent flow field based on the method published by Saad et al.
The first error is to be found here: /applications/utilities/preProcessing/createBoxTurb.C on the lines 63 and 64. In these lines, a random sample point on a unit sphere is created using spherical coordinates (s. Figure below).
![Bug_Report_image1](/uploads/0b97f48695035e16095c28681cf02e5d/Bug_Report_image1.PNG)
However, the spherical coordinates provided here are wrong since they say
vector = (sin(thetam * cos(phim)), sin(thetam * sin(phim)), cos(thetam))
However, the correct spherical coordinates should be (also according to the original publication of Saad et al., equation 10):
vector = (sin(theta)*cos(phim), sin(thetam)*sin(phim), cos(thetam))
So it seems the brackets have been accidentally put into the wrong positions here.
The second error is to be found in the same file on line 155. Here, the vector sigmaHatm is to be normalized (s. Figure below)
![Bug_Report_image2](/uploads/260fdc8d67a94017040470f60868da47/Bug_Report_image2.PNG)
Hence, the vector sigmaHatm is created via the equation:
sigmaHatm = zetaHatm^kappaTildem/(mag(kappaTildem))
However, the correct normalization equation also provided by Saad et al. in equation 9 of the original publication would be:
sigmaHatm = zetaHatm^kappaTildem/(mag(zetaHatm^kappaTildem))
It would be great if the errors could be removed in a future release.
Furthermore, I have a suggestion for the further development of this utility. The method published by Saad et al. is specifically formulated for a staggered grid arrangement of the variables in the mesh in order to meet the the zero divergence criterion in a finite difference formulation. Hence, the vector kappaTildem is created from the vector kappaHatm in lines 144 to 148 of the code. However, since the velocity vectors U are initialized in the cell centres corresponding to a collocated grid arrangement, the formulation of the vector kappaTildem is not meaningful for the grid arrangement of OpenFOAM as far as I would say. Hence, I would suggest to simply delete the lines 144 to 148 in the code and replace all subsequent "kappaTildem" with "kappaHatm".
This is my first bug report and contribution to the OpenFOAM community so I am not quite firm in best practices for bug reporting. I hope that my bug report provides useful information and of course I am happy to respond if I have left anything unclear. Furthermore, I am very grateful for the utility createBoxTurb since it helps me a great deal with my research.
Best regards
Mario HermesKutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2567Wrong Viscous force when using "density variable" in turbulenceProperties2022-08-19T12:43:12ZMyo Zin AungWrong Viscous force when using "density variable" in turbulencePropertiesA new "density variable" feature in turbulenceProperties was introduced in v2012. ([Release Notes](https://www.openfoam.com/news/main-news/openfoam-v20-12/solver-and-physics))
When I was testing the DTCHullMoving tutorial with "kEpsilon"...A new "density variable" feature in turbulenceProperties was introduced in v2012. ([Release Notes](https://www.openfoam.com/news/main-news/openfoam-v20-12/solver-and-physics))
When I was testing the DTCHullMoving tutorial with "kEpsilon" and "realizableKEpsilon" models and "density variable" in the constant/turbulenceProperites, the viscous component of the forces are too much underpredicted (over 7 times samller compared to the original settings). But the pressure component is almost the same as original result. The results are comparable with the original tutorial when running without "density variable" option. I believe there is a problem with that new feature.https://develop.openfoam.com/Development/openfoam/-/issues/2570foamDictionary does not allow wildcards as key2022-08-22T09:58:39ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfoamDictionary does not allow wildcards as key### Functionality to add/problem to solve
E.g. we want to change the 'type' for multiple patches :
```
foamDictionary 0/U -entry boundaryField/BFAN.*/type -set foo
```
### Target audience
Complex use of foamDictionary.
### Proposal
...### Functionality to add/problem to solve
E.g. we want to change the 'type' for multiple patches :
```
foamDictionary 0/U -entry boundaryField/BFAN.*/type -set foo
```
### Target audience
Complex use of foamDictionary.
### Proposal
Have each entry expanded into multiple keys by default. Optionally disable with `-literalRE` similar to `changeDictionary` so you could add a wildcard entry to a dictionary.
You could have inbetween where we expand some wildcards but not others but that might be overkill.
### What does success look like, and how can we measure that?
See if we can do above replacement.
### Links / references
### Fundinghttps://develop.openfoam.com/Development/openfoam/-/issues/2575Inconsistency of function objects folder names with mesh regions2022-09-06T19:04:17ZRiccardo RossiInconsistency of function objects folder names with mesh regionsWHen using solver like the chtMultiRegionFoam some functions objects, such as surfaceFieldValue, are written to postProcessing/<regionName> whereas others, like sampling, are written directly into postProcessing even though they are only...WHen using solver like the chtMultiRegionFoam some functions objects, such as surfaceFieldValue, are written to postProcessing/<regionName> whereas others, like sampling, are written directly into postProcessing even though they are only applied to a particular region.https://develop.openfoam.com/Development/openfoam/-/issues/2584'value' entry in bc not consistent in fvPatchField vs pointPatchField2022-09-24T09:22:30ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.com'value' entry in bc not consistent in fvPatchField vs pointPatchField### Functionality to add/problem to solve
There is inconsistency between pointPatchField, fvPatchField:
pointPatchField : use 'value' field if it is there. Look at valueRequired only if it isn't there.
fvPatchField : use 'value' field ...### Functionality to add/problem to solve
There is inconsistency between pointPatchField, fvPatchField:
pointPatchField : use 'value' field if it is there. Look at valueRequired only if it isn't there.
fvPatchField : use 'value' field only if valueRequired flag sethttps://develop.openfoam.com/Development/openfoam/-/issues/2586Potential bug while using multiple solvers with dynamicOversetFvMesh2022-09-20T16:52:40Zsuyash vermaPotential bug while using multiple solvers with dynamicOversetFvMesh<!--
*** 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 -->
I am trying to use two motion solvers simultaneously with dynamicOversetFvMesh. One of the solver "displacementLaplacian" morphs the mesh based on the linear oscillation defined in the pointDisplacement Boundary condition file. The other solver moves the overset mesh using solidBodyMotionSolver or multiSolidBodyMotionSolver functionality.
Now, While running the simulation, I am noticing that the second solver seems to function only on every alternate time steps rather than executing every timestep. The displacementLaplacian solver appears to function at every timestep.
While using multiSolidBodyMotionSolver with tabulated6DoFMotion function, it can also be noticed that the overset mesh actually returns to it's t_0 position at every alternate timestep.
I have seen the tutorial for floatingBodyWithSpring, where the application of two different solvers is pretty much the same as my case. But I am not sure why I am getting such an issue.
### 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
-->
I have attached my example case of a Translating flat plate with overPimpleDyMFoam solver, to reproduce the exact behaviour.
Just need to run "overPimpleDyMFoam".[HeavePlate_Issue.zip](/uploads/2548f0052021a0baa4a06f6f587da570/HeavePlate_Issue.zip)
### What is the current *bug* behaviour?
<!-- What actually happens -->
The overset mesh return to its t_0 position at every alternate time step. The mesh morphing, however, seems to update nicely at every time-step.
If we remove the displacementLaplacian solver, and just use the solidBodyMotionSolver or multiSolidBodyMotionSolver functionality, there is no issue.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
The overset mesh should not return to its t_0 position at every alternate time step. It should update to the new position from the last time-step position.
### 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 : v2012|v1912
Operating system : ubuntu
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2012|v1912
- 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/2588propellerInfo function object cannot find MRFProperties file2022-09-20T16:52:59ZNikola MajksnerpropellerInfo function object cannot find MRFProperties file
### Summary
When using `rotationMode MRF;` in `propellerInfo` function object `MRFProperties` file is not found even if it exists in `constant/MRFProperties`
### Steps to reproduce
1. Modify propellerInfo file to use `MRFProperties`...
### Summary
When using `rotationMode MRF;` in `propellerInfo` function object `MRFProperties` file is not found even if it exists in `constant/MRFProperties`
### Steps to reproduce
1. Modify propellerInfo file to use `MRFProperties` and run `simpleFoam -postProcess`
2. It produces an error below.
### What is the current *bug* behaviour?
Running for example `simpleFoam -postProcess` produces error below.
```
--> FOAM FATAL IO ERROR: (openfoam-2206)
Unable to find MRFProperties in the database. Is this an MRF case?
```
### What is the expected *correct* behavior?
No errors and function object executed successfully.
### Environment information
- OpenFOAM version : v2206|v2112
- Operating system : ubuntu 22.04
### Possible fixes
```
const auto* MRFZones =
new IOMRFZoneList(mesh_);
```
Using this code instead of the code below fixes the issue, but I think there might be a better way to do it, as I'm not OpenFOAM programming expert.
```
const auto* MRFZones =
mesh_.cfindObject<IOMRFZoneList>("MRFProperties");
```
https://develop.openfoam.com/Development/openfoam/-/blob/master/src/functionObjects/forces/propellerInfo/propellerInfo.C#L82
https://develop.openfoam.com/Development/openfoam/-/blob/master/src/functionObjects/forces/propellerInfo/propellerInfo.C#L148https://develop.openfoam.com/Development/openfoam/-/issues/2594useImplicit in chtMultiRegionFoam where temperature equation exists2022-09-29T13:23:23Zt RockuseImplicit in chtMultiRegionFoam where temperature equation exists### Functionality to add/problem to solve
I have ported `compressibleInterFoam` into the fluid section of `chtMultiRegionFoam` to have a two-phase VoF solver with conjugated heat transfer.
The solver will work with explicit boundary cou...### Functionality to add/problem to solve
I have ported `compressibleInterFoam` into the fluid section of `chtMultiRegionFoam` to have a two-phase VoF solver with conjugated heat transfer.
The solver will work with explicit boundary coupling. However, it would be nice to have the `useImplicit` feature available when working with `T` instead of `he`.
Is there any reason for restring the use of implicit coupling to the `he` field?
### Target audience
All people interested in using `TEqn` for conjugated heat transfer instead of `EEqn`
### Proposal
(How are we going to solve the problem?)
Since boundary conditions are specified for the temperature field, solve for T on the background and allow the direct use of TEqn in the coupled approach?https://develop.openfoam.com/Development/openfoam/-/issues/2595FPE in snappyHexMesh : motorBike2024-03-19T15:07:40ZPawan GhildiyalFPE in snappyHexMesh : motorBikeHello,
OpenFOAM-v2206
Machine : AMD
Compiler : AMD
**64 bit and 32 label**
**wmake -show-cxx**
-std=c++14 -m64 -pthread -DOPENFOAM=2206 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unu...Hello,
OpenFOAM-v2206
Machine : AMD
Compiler : AMD
**64 bit and 32 label**
**wmake -show-cxx**
-std=c++14 -m64 -pthread -DOPENFOAM=2206 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter
-Wno-invalid-offsetof -Wno-undefined-var-template -Wno-unknown-warning-option -O3 -DNoRepository -ftemplate-depth-100 -march=znver3 -fPIC
_snappyHexMesh crashes with FPE error(motorBike case ). However it works if we set FOAM_SIGFPE as false. Same with streamlines FO in the tutorial (pitzDaily)_
If we remove this option -march=znver3 (AMD optimisation flag, similar to AVX in intel), then case works without issue and also no need to set FOAM_SIGFPE as false
Attaching the snappyHexMesh.log file which fail showing sig fault. [log.snappyHexMesh](/uploads/551185948652dbc412b67c21fd92062c/log.snappyHexMesh) fault.https://develop.openfoam.com/Development/openfoam/-/issues/2597snappyHexMesh gets stuck at "Setting refinement level of surface to be consis...2022-09-29T12:49:52ZNikola MajksnersnappyHexMesh gets stuck at "Setting refinement level of surface to be consistent with shells."### Summary
I have noticed an issue where snappyHexMesh can take a very long time or even get stuck on the refinement phase.
This seems to happen when parts of the geometry are highly detailed and very small relative to the overall geom...### Summary
I have noticed an issue where snappyHexMesh can take a very long time or even get stuck on the refinement phase.
This seems to happen when parts of the geometry are highly detailed and very small relative to the overall geometry.
In such cases, snappyHexMesh will spend a lot of time on the step "Setting refinement level of surface to be consistent with shells."
It's not just the matter of number of faces. I have run simulations on STL file which were 20x larger in terms of number of faces and file size compared to the attached case without any issues at all.
### Steps to reproduce
Run the attached case
### Example case
The link below is the motorBike tutorial, with the geometry replaced by a problematic one.
https://drive.google.com/file/d/1WnyoL7RfQSrFZoLoe1yfAhu7qTmQCPNP/view?usp=sharing
The geometry is a simple box of 1 m with a detailed sphere of 1 mm radius inside. The top of the box is open.
### What is the current *bug* behaviour?
snappyHexMesh gets stuck at "Setting refinement level of surface to be consistent with shells." and it can take hours to complete, if at all. I had a case where it took 16 hours, and it was not finished, I had to kill it.
### What is the expected *correct* behavior?
snappyHexMesh not getting stuck at "Setting refinement level of surface to be consistent with shells."
### Environment information
- OpenFOAM version : v2206|v2112|v2106
- Operating system : ubuntu 22.04
- Hardware info : AMD Epyc with 24 cores
- Compiler : Installed with apt-get
### Possible fixes
https://develop.openfoam.com/Development/openfoam/-/blob/master/applications/utilities/mesh/generation/snappyHexMesh/snappyHexMesh.C#L1212
Commenting line 1212 will fix the issue, but I'm not sure if there are any consequences for the quality of the mesh. After visual inspection, the mesh looked good.