Development issueshttps://develop.openfoam.com/groups/Development/-/issues2019-12-09T22:22:46Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1003incorrect kahip resolution with absolute paths2019-12-09T22:22:46ZMark OLESENincorrect kahip resolution with absolute paths- affects installations using a central (non-ThirdParty) location for KAHIP.
- reported https://github.com/spack/spack/pull/8982- affects installations using a central (non-ThirdParty) location for KAHIP.
- reported https://github.com/spack/spack/pull/8982Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1381Incorrect indexing in adjointSolverManager2020-01-16T18:05:03ZAdminIncorrect indexing in adjointSolverManagerIn the following the index should simply be `solveri` and not `objectiveSolverIDs_[solveri]`
```
scalar objValue(Zero);
for (const label solveri : objectiveSolverIDs_)
{
objectiveManager& objManager =
adjo...In the following the index should simply be `solveri` and not `objectiveSolverIDs_[solveri]`
```
scalar objValue(Zero);
for (const label solveri : objectiveSolverIDs_)
{
objectiveManager& objManager =
adjointSolvers_[objectiveSolverIDs_[solveri]].getObjectiveManager();
objValue += objManager.print();
}
```
\## Reattaching the author to the issue ticket: @andy ##v1912Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/693incorrect implementation of jumpCyclic BC2018-03-14T17:24:39ZAdminincorrect implementation of jumpCyclic BCbegin at line 94 of jumpCyclicFvPatchField.C
```c++
template<class Type>
Foam::tmp<Foam::Field<Type>>
Foam::jumpCyclicFvPatchField<Type>::patchNeighbourField() const
{
const Field<Type>& iField = this->primitiveField();
const lab...begin at line 94 of jumpCyclicFvPatchField.C
```c++
template<class Type>
Foam::tmp<Foam::Field<Type>>
Foam::jumpCyclicFvPatchField<Type>::patchNeighbourField() const
{
const Field<Type>& iField = this->primitiveField();
const labelUList& nbrFaceCells =
this->cyclicPatch().neighbFvPatch().faceCells();
tmp<Field<Type>> tpnf(new Field<Type>(this->size()));
Field<Type>& pnf = tpnf.ref();
Field<Type> jf(this->jump());
if (!this->cyclicPatch().owner())
{
jf *= -1.0;
}
if (this->doTransform())
{
forAll(*this, facei)
{
pnf[facei] = transform
(
this->forwardT()[0], iField[nbrFaceCells[facei]]
) - jf[facei];
}
}
else
{
forAll(*this, facei)
{
pnf[facei] = iField[nbrFaceCells[facei]] - jf[facei];
}
}
return tpnf;
}
```
Mathematically, jumpCyclic BC must enforce the jump condition between patch faces. However, in the implementation, it seems that the jump condition are enforced between the inner cell and neighbour cells, which is obviously incorrect.https://develop.openfoam.com/Development/openfoam/-/issues/611incorrect format on VTK xml output2019-12-09T22:11:26ZMark OLESENincorrect format on VTK xml outputThe face writer emits `ASCII` and `BINARY` instead of `ascii` and `binary`The face writer emits `ASCII` and `BINARY` instead of `ascii` and `binary`Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/486Incorrect fall-through in directionalPressureGradientExplicitSource2019-12-09T22:04:15ZMark OLESENIncorrect fall-through in directionalPressureGradientExplicitSourceMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1957Incorrect eigenvalues for a symmetric positive-definite matrix2021-03-02T20:25:51ZRobert Manson-SawkoIncorrect eigenvalues for a symmetric positive-definite matrix### Summary
It appears I am getting incorrect eigenvalues for a symmetric positive-definite matrix. It results in incorrect eigenvectors which end up being linearly dependant (as if the matrix was [defective](https://en.wikipedia.org/wi...### Summary
It appears I am getting incorrect eigenvalues for a symmetric positive-definite matrix. It results in incorrect eigenvectors which end up being linearly dependant (as if the matrix was [defective](https://en.wikipedia.org/wiki/Defective_matrix)). This impacts the `turbulentInletDFSEM` as `eddy` objects lose a dimension.
### Steps to reproduce
Here's a minimal example, I concocted:
```cpp
#include "fvCFD.H"
int main(int argc, char *argv[])
{
Info<< "\nCalculating eigenvalues of a symmetric positive-definite matrix\n";
symmTensor A = symmTensor(
0.005,
-0.0003,
0.001,
0.002,
0.0001,
0.002);
vector lambda(eigenValues(A));
Info<< "Eigenvalues (OpenFOAM): " << lambda << endl;
Info<< "Eigenvalues (numpy.linalg): (0.00532289, 0.00160802, 0.0020691)" << endl;
return 0;
}
```
### What is the current *bug* behaviour?
Output I am getting:
```
Eigenvalues (OpenFOAM): (0.00183856 0.00183856 0.00532289)
Eigenvalues (numpy.linalg): (0.00532289, 0.00160802, 0.0020691)
```
### What is the expected *correct* behaviour?
See above. I compared it with `numpy.linalg`.
### Environment information
- OpenFOAM version : v2006
- Operating system : Arch Linux
- Hardware info : Intel(R) Core(TM) i7-4810MQ CPU @ 2.80GHz
- Compiler : gcc :
### Possible fixes
Use alternatives eigensolvers. I currently went with Eigen but I am looking for another OpenFOAM native solution.Kutalmış BerçinKutalmış Berçinhttps://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/594Incorrect documentation for the van Driest LES delta2019-01-09T21:15:59ZAdminIncorrect documentation for the van Driest LES deltaThe description of the van Driest LES delta is incorrect. It is currently a copy from the cubeRootVol delta, see
https://develop.openfoam.com/Development/OpenFOAM-plus/blob/OpenFOAM-v1706/src/TurbulenceModels/turbulenceModels/LES/LESdel...The description of the van Driest LES delta is incorrect. It is currently a copy from the cubeRootVol delta, see
https://develop.openfoam.com/Development/OpenFOAM-plus/blob/OpenFOAM-v1706/src/TurbulenceModels/turbulenceModels/LES/LESdeltas/vanDriestDelta/vanDriestDelta.H
Kind regards,
TimofeyKutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1270incorrect default location for project site binaries2019-12-09T22:37:28ZMark OLESENincorrect default location for project site binaries`FOAM_SITE_APPBIN` and `FOAM_SITE_LIBBIN` are still using WM_PROJECT_VERSION instead of FOAM_API`FOAM_SITE_APPBIN` and `FOAM_SITE_LIBBIN` are still using WM_PROJECT_VERSION instead of FOAM_APIMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/243incorrect component order of symmTensor for some ensight output2019-12-09T22:04:13ZMark OLESENincorrect component order of symmTensor for some ensight output- affects foamToEnsightParts, sampled surfaces- affects foamToEnsightParts, sampled surfacesVersion v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/3033Incorrect check for polyMesh::dbDir()2023-12-07T16:48:39ZMark OLESENIncorrect check for polyMesh::dbDir()It checks `objectRegistry::dbDir() == defaultRegion` but this only works on the assumption that the polyMesh is rooted directly on time.
If we relocate to a different database (eg, "finite-volume"), the dbDir() would then be something l...It checks `objectRegistry::dbDir() == defaultRegion` but this only works on the assumption that the polyMesh is rooted directly on time.
If we relocate to a different database (eg, "finite-volume"), the dbDir() would then be something like "finite-volume/region0".
Should be checking on objectRegistry::name() directly, as per polyMesh::regionName().Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1288Incorrect behaviour of overset and cellVolumeWeight2020-04-16T12:11:25ZAdminIncorrect behaviour of overset and cellVolumeWeight### Summary
I’ve identified three possible problems with overset and specifically cellVolumeWeight interpolation method. I’ve attached three patches that attempts to resolve the three problems. There is also a small test case to illust...### Summary
I’ve identified three possible problems with overset and specifically cellVolumeWeight interpolation method. I’ve attached three patches that attempts to resolve the three problems. There is also a small test case to illustrate the problems. The test case is explained in a little bit more detail in the README file.
1) First of cellVolumeWeight is a bit chatty. I’ve enclosed all Pouts into a if(debug). This is the first patch.
2) "Cell: X at:(x y z) zone: 0 changed from hole to calculated but there is no donor"
I think there could be several reasons why this error is thrown. A less fatal approach would be to revert cells with no donors to HOLE. Although it has to be done before findHoles and walkFront. The second patch does this.
3) Of course a better approach would be to find where the error is made. The cells shouldn’t have been set to CALCULATED in the first place. I attempt to fix this in patch 3.
### Steps to reproduce
Run the attached test case with overPimpleDyMFoam. The fatal error is thrown during the first iteration. Now change the number of cells in the x-direction in the background mesh from 36 to 37 and the case runs for a little longer until the overset grid again linest up with the background mesh.
Please see the README for instructions on how to run the case. Basically compile rangeLimitedLinearSpring and then run Allrun in the checkvalve folder.
### Example case
A very crude test case of a check valve closing during reverse flow is attached.
[testcase.tgz](/uploads/a8d1bad8d29b7156c61559f8e1c4c27c/testcase.tgz)
### What is the current *bug* behaviour?
I believe a mistake is made in the function combineCellTypes. There, allCellTypes is set to HOLE if interpolatedPatchTypes is a patch and if there is insufficient overlap. Now if the patch from the overset grid cuts the background mesh exactly between cells (or close enough) both cells on both sides will have good overlap and they aren’t set to HOLEs. This will cause findHoles to fail when it “walks” and sets faces to isBlocked. Later when the mesh is split there will be leaks and the entire region might not be found where there should be holes. Theses cells are instead set to CALCULATED. The third attached patch overcomes this problem by simply not checking if there is sufficient overlap and just sets the cells to HOLE when they are cut by a patch from another region. I think it’s a safe assumption that all cells cut by patches from other regions should be HOLE. Before commit 16fb52d42bb5eff4d59910c99410e6f524ef25cc where the tolerance is adjusted, it was also possilbe that the error wasn't thrown, instead regions in the background mesh where set to CALCULATED where they should have been HOLE.This could be seen as high velocites in the background mesh where there should be no solution.
### What is the expected *correct* behavior?
There should be no fatal error, at least not this particular one. The field cellTypes should be correctly calcualted.
### Relevant logs and/or images
Please see attached case.
### Environment information
OpenFOAM version : plus/v1812
Operating system : ubuntu, redhat 6.4
Compiler : gcc
This bug report is based of commit 4569a8b3c5636ae30122ac570cbbca697fc1e07f from 12th of april.
### Possible fixes
blamed file:
[src/overset/cellCellStencil/cellVolumeWeight/cellVolumeWeightCellCellStencil.C](https://develop.openfoam.com/Development/OpenFOAM-plus/blob/4569a8b3c5636ae30122ac570cbbca697fc1e07f/src/overset/cellCellStencil/cellVolumeWeight/cellVolumeWeightCellCellStencil.C)
In the attached tar-file there is a folder called patches, either apply them or use the file in the "foldermodified_files_after_patch3" which conatins all three patches.
This is a version where all three patches have been applied.
[cellVolumeWeightCellCellStencil.C](/uploads/a19d46b73eb6b0c30ae41c30bdcd9997/cellVolumeWeightCellCellStencil.C)
I've tested with the attached case and twoSimpleRotors. They run fine. I havn't tested other overset solvers.
Also please note that the pressure field is stil calculated in HOLE regions. I haven't found a reason for this. But at least no the velocity field is zero in these regions.
\## Reattaching the author to the issue ticket: @nicolasedh ##https://develop.openfoam.com/Development/openfoam/-/issues/2642Incorrect algorithm in void Foam::fvMatrix<Type>::setValuesFromList2023-01-18T11:47:48ZZhao WuIncorrect algorithm in void Foam::fvMatrix<Type>::setValuesFromList<!--
*** 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
Incorrect algorithm in `void Foam::fvMatrix<Type>::setValuesFromList` in file [src/finiteVolume/fvMatrices/fvMatrix/fvMatrix.C:L226](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/finiteVolume/fvMatrices/fvMatrix/fvMatrix.C#L226)
<!-- Summarize the bug encountered concisely -->
### What is the current *bug* behaviour?
within Loop `forAll(cellLabels, i)`, the source_ is first set by `source_[celli] = value*Diag[celli];`.
Then the value of `source_[nei[facei]]` is immediatly changed by the `-=` operator.
However, `nei[face]` might be behind `celli`, therefore this modification might be overwritten by the upcoming celli loop.
<!-- What actually happens -->
### What is the expected *correct* behavior?
I think we should split the single loop `forAll(cellLabels, i)` into two.
The first loop is to set the initial value of `psi` and `source_`, and the second loop is to do the `-=` operation.
<!-- 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 : 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 : all versions
- Operating system : N/A
- Hardware info : N/A
- Compiler : N/A
### 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
-->
```cpp
forAll(cellLabels, i)
{
const label celli = cellLabels[i];
const Type& value = values[i];
psi[celli] = value;
source_[celli] = value*Diag[celli];
}
forAll(cellLabels, i)
{
const label celli = cellLabels[i];
const Type& value = values[i];
if (symmetric() || asymmetric())
{
...
}
}
```https://develop.openfoam.com/Development/openfoam/-/issues/3035inconsistent use of endEntry2023-12-07T16:48:20ZMark OLESENinconsistent use of endEntryAs noted in discussions with @serge , there are still a few places with `os << token::END_STATEMENT << nl` instead of using `endEntry()`
Having `endEntry()` can be useful when trying to trigger on the end event (such as with the cohere...As noted in discussions with @serge , there are still a few places with `os << token::END_STATEMENT << nl` instead of using `endEntry()`
Having `endEntry()` can be useful when trying to trigger on the end event (such as with the coherent format).https://develop.openfoam.com/Development/openfoam/-/issues/308Inconsistent openmpi between sh and csh2018-05-29T05:39:49ZMark OLESENInconsistent openmpi between sh and cshVersion v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2534Inconsistent number of particles escaping the system2023-05-30T18:55:52ZGuanyang XueInconsistent number of particles escaping the system### Summary
The number of particles escaping the system is inconsistent.
I've asked this question (the last reply of the thread) a long time ago but no one answered:
https://www.cfd-online.com/Forums/openfoam-solving/217086-particle-fa...### Summary
The number of particles escaping the system is inconsistent.
I've asked this question (the last reply of the thread) a long time ago but no one answered:
https://www.cfd-online.com/Forums/openfoam-solving/217086-particle-fate-dpmfoam-mppicfoam.html#post766848
Might be related to this issue: https://develop.openfoam.com/Development/OpenFOAM-plus/-/issues/1306
### Steps to reproduce
Run particle tracking with user compiled particle forces added to `src/lagrangian/intermediate/submodels/Kinematic/ParticleForces`.
The particle force is simply modified from `PressureGraident` so I don't think there's any bug in my particle force.
### Example case
I don't want to share the case file as it is research related.
If you can't reproduce one with built-in particle force, I'll create a minimal case to reproduce that.
### What is the current *bug* behaviour?
This is the log from v2112. Obviously the number 80777 is problematic, and the simulation result doesn't make sense.
```
Current number of parcels = 1963
Current mass in system = 8.222595172e-15
Linear momentum = (4.11548211259e-17 -1.5147123108e-17 4.67553491316e-27)
|Linear momentum| = 4.38537870697e-17
Linear kinetic energy = 4.111297586e-17
Average particle per parcel = 1
Injector model1:
- parcels added = 9861
- mass introduced = 4.13056602094e-14
Parcel fate: system (number, mass)
- escape = 80777, 3.38357906372e-13
Parcel fate: patch frontAndBackPlanes|confinement|sidewall|inlet (number, mass)
- escape = 0, 0
- stick = 0, 0
Parcel fate: patch outlet (number, mass)
- escape = 7898, 3.3083065037e-14
- stick = 0, 0
```
### What is the expected *correct* behavior?
I've done some particle tracking researches using v1712 before and I know this version didn't give me any issue.
I tried to backport the same particle force to V1712 and everything looks normal:
```
Current number of parcels = 467
Current mass in system = 1.95616502564e-15
Linear momentum = (5.25816684692e-17 -4.81196024144e-19 1.35596323969e-34)
|Linear momentum| = 5.25838702324e-17
Linear kinetic energy = 1.77465381473e-18
Injector model1:
- parcels added = 9893
- mass introduced = 4.1439701496e-14
Parcel fate: system (number, mass)
- escape = 9426, 3.94835364703e-14
Parcel fate: patch frontAndBackPlanes|confinement|sidewall|inlet (number, mass)
- escape = 0, 0
- stick = 0, 0
Parcel fate: patch outlet (number, mass)
- escape = 9426, 3.94835364701e-14
- stick = 0, 0
```
### Relevant logs and/or images
Above
### Environment information
- OpenFOAM version : v2112
- Operating system : Rocky Linux
- Hardware info :
- Compiler : gcc
### Possible fixes
I can confirm v1712 doesn't have this issue, but v1912 and after does. From the thread https://www.cfd-online.com/Forums/openfoam-solving/217086-particle-fate-dpmfoam-mppicfoam.html, the OP said he used v1812, so most likely the bug was introduced between v1712 and v1812.https://develop.openfoam.com/Development/openfoam/-/issues/2279inconsistent input parameters for fan BCs2021-12-05T14:33:52ZMark OLESENinconsistent input parameters for fan BCssome fan BCs have rpm as scalar, others as Function1. Some parameters (eg, fan efficiency) may be lost on copy and output.some fan BCs have rpm as scalar, others as Function1. Some parameters (eg, fan efficiency) may be lost on copy and output.v2112Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/148Inconsistent/incorrect build environment2023-12-07T19:01:57ZMark OLESENInconsistent/incorrect build environmentthird-party settings may be inconsistent with the OF settings.
Using lib instead of lib64 for 3rd-party gmp paths etc.third-party settings may be inconsistent with the OF settings.
Using lib instead of lib64 for 3rd-party gmp paths etc.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1296inconsistent handling of trapping exceptions between IOerror and error2019-05-20T12:44:37ZMark OLESENinconsistent handling of trapping exceptions between IOerror and errorWith the #575 change (87fdc2eaf3cd8c3bb005e110802b7053dc7eed79) it is possible to throw/catch exceptions in parallel, but this was not propagated to IOerror.With the #575 change (87fdc2eaf3cd8c3bb005e110802b7053dc7eed79) it is possible to throw/catch exceptions in parallel, but this was not propagated to IOerror.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1148inconsistent handling of optional dimensions for dimensioned Type2019-06-28T09:40:25ZMark OLESENinconsistent handling of optional dimensions for dimensioned TypeThis is a continuation of #1116
- lookupOrDefault handles optional dimensions
- lookupOrAddToDict does lookup and adding on base type (ie, no dimensions)
- readIfPresent (and now readEntry), work directly with value_ - so also cannot ha...This is a continuation of #1116
- lookupOrDefault handles optional dimensions
- lookupOrAddToDict does lookup and adding on base type (ie, no dimensions)
- readIfPresent (and now readEntry), work directly with value_ - so also cannot handle optional dimensionsv1906Mark OLESENMark OLESEN