Development issueshttps://develop.openfoam.com/groups/Development/-/issues2022-07-28T04:30:32Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1675fieldCoordinateSystemTransform fails to write "U:Transformed" field on a Wind...2022-07-28T04:30:32ZJustin GraupmanfieldCoordinateSystemTransform fails to write "U:Transformed" field on a Windows OS### Summary
fieldCoordinateSystemTransform function object attempts to write "U:Transformed" field on Windows OS even though the ":" character it not supported in file names. This results in the field not being written.
### Steps to r...### Summary
fieldCoordinateSystemTransform function object attempts to write "U:Transformed" field on Windows OS even though the ":" character it not supported in file names. This results in the field not being written.
### Steps to reproduce
This can be reproduced using a modified version of the simpleFoam pipeCyclic tutorial.
1. Open a OpenFOAM-MS-DOSPrompt.bat window
2. Navigate to the attached slightly modified pipeCyclic tutorial
3. Run simpleFoam
The log will show that the field is trying to be written, but it never shows up in the time directory.
`functionObjects::fieldCoordinateSystemTransform coordinateTransform writing field: U:Transformed`
### Example case
[pipeCyclic.zip](/uploads/3059de4c995aef7c3ea9153da8be9610/pipeCyclic.zip)
### What is the current *bug* behaviour?
The U:Transformed is not written like it should be due to the Windows OS not supporting the ":" character in a file name.
### What is the expected *correct* behavior?
U:Transformed needs to be written with a compatible file name.
### Environment information
- OpenFOAM version : v1912
- Operating system : Windows 10
- Hardware info : Intel
- Compiler : MinGW
- Prompt : OpenFOAM-MS-DOSPrompt.bat
### Possible fixes
The simplest fix in my opinion would be to add the ability to change the name of the written field in the fieldCoordinateSystemTransform function object using an option like...
fields ( (U U_Transformed) );Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2472omegaWallFunction kinetic energy production term inconsistent with cited arti...2022-07-29T14:39:25ZPavel MačákomegaWallFunction kinetic energy production term inconsistent with cited articles<!--
*** 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 -->
This reference
_Exponential/Max blending of the viscous and inertial sublayers (tag:PH):
Popovac, M., & Hanjalić, K. (2007).
Compound wall treatment for RANS computation of complex
turbulent flows and heat transfer.
Flow, turbulence and combustion, 78(2), 177-202.
DOI:10.1007/s10494-006-9067-x_
from [omegaWallFunctionFvPatchScalarField.H](https://www.openfoam.com/documentation/guides/latest/api/omegaWallFunctionFvPatchScalarField_8H_source.html#l00046) recommends on page 193 that the production term _G0_ should be
![image](/uploads/137abb79bd529053f0c40d522588da4f/image.png).
However in code [omegaWallFunctionFvPatchScalarField.C](https://www.openfoam.com/documentation/guides/latest/api/omegaWallFunctionFvPatchScalarField_8C_source.html#l00301)
` G0[celli] +=
w
*(nutw[facei] + nuw[facei])
*magGradUw[facei]
*Cmu25*sqrt(k[celli])
/(nutw.kappa()*y[facei]);`
the term for _G0_ corresponds rather to ![image](/uploads/684346f9da580ddceaeb5f87b9296954/image.png).
### Environment information
- OpenFOAM version : v2112
### 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
-->
Change the _G0_ term to match the reference or add the reference from which the current relation was taken from.Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2059sixDoFRigidBodyState functions does not work for overInterDyMFoam solver2022-08-02T16:23:18ZHua ZensixDoFRigidBodyState functions does not work for overInterDyMFoam solver<!--
*** 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 -->
sixDoFRigidBodyState functions does not work for overInterDyMFoam solver
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
1. the tutorial: tutorials/multiphase/overInterDyMFoam/floatingBody
2. in controlDict add the following in the functions:
sixDoFRigidBodyState
{
type sixDoFRigidBodyState;
libs (sixDoFRigidBodyState);
angleFormat degrees;
}
3. run the case with Allrun script.
### Example case
As above
<!--
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 -->
The solver fail to run.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
### Relevant logs and/or images
--> FOAM FATAL ERROR: (openfoam-2012)
Attempt to cast type dynamicOversetFvMesh to type dynamicMotionSolverFvMesh
From To& Foam::refCast(From&) [with To = const Foam::dynamicMotionSolverFvMesh; From = const Foam::objectRegistry]
in file /home/user/openfoam/BuildEnv/debian-build/bionic-2012.latest/scratch/src/OpenFOAM/lnInclude/typeInfo.H at line 139.
FOAM aborting
#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::error::exitOrAbort(int, bool) at ??:?
#2 Foam::functionObjects::sixDoFRigidBodyState::write() at ??:?
#3 Foam::functionObjectList::execute() at ??:?
#4 Foam::Time::run() const at ??:?
#5 ? in /usr/lib/openfoam/openfoam2012/platforms/linux64GccDPInt32Opt/bin/overInterDyMFoam
#6 __libc_start_main in /lib/x86_64-linux-gnu/libc.so.6
#7 ? in /usr/lib/openfoam/openfoam2012/platforms/linux64GccDPInt32Opt/bin/overInterDyMFoam
Aborted (core dumped)
<!--
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 : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :v2012
- Operating system :Ubuntu 18.04
- Hardware info :
- Compiler :System
### 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
-->Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2427Increase flexibility of weightedFlux interpolation scheme2022-08-03T16:18:42ZGhost UserIncrease flexibility of weightedFlux interpolation scheme### Functionality to add/problem to solve
The weightedFlux interpolation scheme seems to need a pre-existing field/dictionary file to be able to get a value on the `patchNeighbourField()` function. This will appear when decomposing the ...### Functionality to add/problem to solve
The weightedFlux interpolation scheme seems to need a pre-existing field/dictionary file to be able to get a value on the `patchNeighbourField()` function. This will appear when decomposing the case, where each processor boundary condition will have a value.
This, however, is limiting the scheme since one needs to have the interpolation variable in a file and the interpolation field might have a dependency on another variable (temperature, time, etc...).
It would be beneficial to be able to do this with a `volScalarField` inside the code.
### Proposal
This scheme needs to obtain the value at the cell centre from a neighbour cell in another processor. This would make it suitable for having the interpolation variable with some dependency.
I have attached a test case showing that if no file exists, the `patchNeighbourField()` has a value of 0. And a possible fix.
The fix, however, does not seem very elegant. It is using the `syncTools` function `swapBoundaryCellList` which will "return" a field of the size of "nBoundaryFaces" which has substantial more information than needed.
[Case.zip](/uploads/56a31169b9164603f5bcb5cce43c1dcb/Case.zip)
### Links / references
Some references showing the interpolation of pressure with density:
https://onlinelibrary.wiley.com/doi/epdf/10.1002/fld.4055
https://www.sciencedirect.com/science/article/pii/S0141118706000812https://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/64Paraview:5.10.0: catalyst building issue2022-08-04T11:32:33ZPawan GhildiyalParaview:5.10.0: catalyst building issueHi ,
I am using latest release paraview as updated in sourceforge 5.10.0 release.
Build paraview successfully using mesa-llvm and it compiled well.
runTimepostprocessing : compiles well and work well. However catalyst
fail t...Hi ,
I am using latest release paraview as updated in sourceforge 5.10.0 release.
Build paraview successfully using mesa-llvm and it compiled well.
runTimepostprocessing : compiles well and work well. However catalyst
fail to compile with following error. (Note this issue is not there with Paraview-5.10.RC2)
![image](/uploads/b377779ef8b2fda54268a1761d94008a/image.png)Mark OLESENMark OLESENhttps://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/1743wallHeatFlux does not show region2022-08-10T16:48:13ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comwallHeatFlux does not show regionIn previous versions the header ('wallHeatFlux wallHeatFlux-solid write:') would appear before printing of the statistics so it would make it clear to which region the statistics belonged. This seems to be no longer the case:
```
mi...In previous versions the header ('wallHeatFlux wallHeatFlux-solid write:') would appear before printing of the statistics so it would make it clear to which region the statistics belonged. This seems to be no longer the case:
```
min/max/integ(walls) = 0, 0, 0
min/max/integ(solid_to_fluid) = -0.100497, -0.100095, -0.100296
wallHeatFlux wallHeatFlux-solid write:
writing field wallHeatFlux
min/max/integ(walls) = 0, 0, 0
min/max/integ(fluid_to_solid) = 0.100096, 0.100497, 0.100296
wallHeatFlux wallHeatFlux-fluid write:
writing field wallHeatFlux
```Kutalmış BerçinKutalmış Berçinhttps://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/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/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/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/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/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/2416Wall on overset mesh causes p-U coupling issues2022-09-07T08:42:52ZJozsef NagyWall on overset mesh causes p-U coupling issues<!--
*** 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 want to inject liquid into a 2D gap.
![image](/uploads/874bb6ca76fd8c4db182fce6c1b876af/image.png)
I want to add a wall on an overset mesh, which is supposed to act as a blockage.
![image](/uploads/c25dd89c61c539c0e8307b7a78e417ed/image.png)
Due to the contraction of the thickness of the gap I would assume, that the velocity in the area of the overset mesh with the wall will be increased (due to continuity). However, this is not the case.
I found this issue: https://develop.openfoam.com/Development/openfoam/-/issues/2341
and assumed that this could be some overInterDyMFoam problem with mass conservation. I tested the same flow with overPimpleDyMFoam and the same happens.
### Steps to reproduce
I uploaded four case files in a zip file. All four can be run with the one master Allrun script in v2112 (also v2012) in 1-2 minutes on on core.
### Example case
[reproducingCases.zip](/uploads/94a362cd067221ac2860a1b089ba516b/reproducingCases.zip)
### What is the current *bug* behaviour?
Here you can see the velocity profile:
![image](/uploads/329c5e7aa1c8098b0b679a585e18f5a0/image.png)
First gap is the simulation without the overset mesh (no contraction of thickness) and overPimpleDyMFoam.
Second gap is the simulation with the overset mesh (small contraction of thickness) and overPimpleDyMFoam.
Third gap is the simulation without the overset mesh (no contraction of thickness) and overInterDyMFoam.
Fourth gap is the simulation with the overset mesh (small contraction of thickness) and overInterDyMFoam.
Without an overset mesh, the results look good and reasonable. The moment I merge an overset mesh to the background mesh, the velocity "dissipates" in the area of the overset mesh.
The pressure behaves also incorrectly
![image](/uploads/4c0dabbdbbee27f3082c1532d96f460b/image.png)
without the overset mesh the pressure drop is reasonable. With the overset mesh the pressure drop disappears in the area of the overset mesh.
### What is the expected *correct* behavior?
Increase of velocity in region of contraction.
### Relevant logs and/or images
See above.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2112|v2106|v2012|v2006|v1912|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2112 (also v2012)
- Operating system : Ubuntu 18.04
- Hardware info : Intel CPU 6 cores (should not matter here)
- Compiler : GCC coming with OpenFOAM
### 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
-->
I am not sure. What i noticed is that I have to change the preconditioner between DILU and DIC depending whether I want to run the simulation with or without the overset mesh. In all cases the matrix solver is PBiCGStab though. Maybe this helps? I did try to fix this in the source code, but I am stuck. What I found is that the major impact is coming from pEqn.
In overPimpleDyMFoam the line:
U = cellMask*(HbyA - rAU*gradP);
In overInterDyMFoam the line:
U =
cellMask*
(
HbyA + rAU*fvc::reconstruct((phig - p_rghEqn.flux())/rAUf)
);
The multiplication with cellMask seems to introduce the errors. This might possibly be the source where the error comes out, possibly the cause is in some of the previous steps, where HbyA, rAU or phig are defined. This is where I am stuck.
### Final thoughts
Is this phenomenon
* my stupidity and ignorance (in this case I am sorry to waste you valuable time)
* a bug
* a feature
* something else
I am happy to support you with any help possibly, I know that you have a lot to do. Tell me, what I can test and I will execute the simulations and test.
Thank you!
Best regards,
JozsefSergio FerrarisSergio Ferrarishttps://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/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 set