Development issueshttps://develop.openfoam.com/groups/Development/-/issues2022-05-26T13:19:28Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2493checkMesh + dynamicMotionSolverFvMeshAMI2022-05-26T13:19:28ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcheckMesh + dynamicMotionSolverFvMeshAMI<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
checkMesh reports open cells + incorrect AMI weights
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Run `incompressible/pimpleFoam/laminar/mixerVesselAMI2D/mixerVesselAMI2D-topologyChange` and then
`checkMesh -allGeometry -allTopology`
It will report e.g.:
```
***Open cells found, max cell openness: 0.333333, number of open cells 5760
```
```
AMI: Patch source sum(weights) min:2.00008 max:2.00008 average:2.00008
```
whereas the non-topo changing case reports 1.00022 (as expected)
### Example case
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
See above
### What is the current *bug* behaviour?
<!-- What actually happens -->
### What is the expected *correct* behavior?
<!-- What you should see instead -->
Consistent reported weights
### 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 : 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 : v2206
- Operating system :
- 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/2491lagrangian/coalChemistryFoam/simplifiedSiwek is finding librunTimePostProces...2022-12-23T14:57:31ZSergio Ferrarislagrangian/coalChemistryFoam/simplifiedSiwek is finding librunTimePostProcessing.so--> FOAM Warning :
From void *Foam::dlLibraryTable::openLibrary(const Foam::fileName &, bool)
in file db/dynamicLibrary/dlLibraryTable/dlLibraryTable.C at line 188
Could not load "librunTimePostProcessing.so"
librunTimePostP...--> FOAM Warning :
From void *Foam::dlLibraryTable::openLibrary(const Foam::fileName &, bool)
in file db/dynamicLibrary/dlLibraryTable/dlLibraryTable.C at line 188
Could not load "librunTimePostProcessing.so"
librunTimePostProcessing.so: cannot open shared object file: No such file or directory
--> FOAM Warning :
Unknown function type runTimePostProcessingv2306Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/2489redistributePar on moving mesh cases2022-05-26T10:36:15ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comredistributePar on moving mesh cases<!--
*** 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
1)
<!-- Summarize the bug encountered concisely -->
redistributePar -decompose on case with 'meshPhi' produces error message
2)
redistributePar -reconstruct flips meshPhi
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Take time dump of any moving mesh case with meshPhi. Use
```
mpirun -np 2 redistributePar -decompose -parallel -time XXX
```
and it will produce error message
```
From time 0.025 mesh:"constant/region0" have objects:
16
(
controlPoints
pointMotionU
C_0
Cs
cellMotionU
U
U_0
fsNetPhi
Uf
phi
C
V0
meshPhi
p
Uf_0
Us
)
[0]
[0]
[0] --> FOAM FATAL ERROR: (openfoam-2202 patch=220310)
[0] mesh flux field does not exist, is the mesh actually moving?
[0]
[0] From Foam::surfaceScalarField& Foam::fvMesh::setPhi()
[0] in file fvMesh/fvMeshGeometry.C at line 422.
[0]
FOAM parallel run aborting
[0]
[0] #0 Foam::error::printStack(Foam::Ostream&) at ??:?
[0] #1 Foam::error::simpleExit(int, bool) at ??:?
[0] #2 Foam::error::exiting(int, bool) at ??:?
[0] #3 Foam::fvMesh::setPhi() at ??:?
[0] #4 Foam::fvGeometryScheme::setMeshPhi() const at ??:?
[0] #5 Foam::fvGeometryScheme::movePoints() at ??:?
[0] #6 Foam::basicFvGeometryScheme::movePoints() at ??:?
[0] #7 Foam::surfaceInterpolation::updateGeom() at ??:?
[0] #8 Foam::primitiveMesh::cellVolumes() const at ??:?
[0] #9 Foam::polyTopoChange::changeMesh(Foam::polyMesh&, Foam::UList<int> const&, bool, bool, bool, bool) at ??:?
[0] #10 Foam::polyTopoChange::changeMesh(Foam::polyMesh&, bool, bool, bool, bool) at ??:?
[0] #11 Foam::fvMeshDistribute::repatch(Foam::List<int> const&, Foam::List<Foam::List<int> >&) at ??:?
[0] #12 Foam::fvMeshDistribute::deleteProcPatches(int) at ??:?
[0] #13 Foam::fvMeshDistribute::distribute(Foam::List<int> const&) at ??:?
```
### 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 : v2202
- Operating system :
- 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
-->
Switch on mesh.moving() flag?https://develop.openfoam.com/Development/openfoam/-/issues/2488redistributePar -decompose with inconsistent nProcs2024-01-08T13:36:51ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comredistributePar -decompose with inconsistent nProcs### Functionality to add/problem to solve
redistributePar -decompose gives illogical error message if the number of procs does not equal the number in the decomposeParDict. E.g. in decomposeParDict:
```
numberOfSubdomains 2;
```
Run wi...### Functionality to add/problem to solve
redistributePar -decompose gives illogical error message if the number of procs does not equal the number in the decomposeParDict. E.g. in decomposeParDict:
```
numberOfSubdomains 2;
```
Run with
```
mpirun -np 4 redistributePar -decompose -parallel
```
Produces output
```
[0] --> FOAM FATAL ERROR: (openfoam-2202 patch=220310)
[0] number of processor directories = 1 is not equal to the number of processors = 4
```
which is not very helpful.https://develop.openfoam.com/Development/openfoam/-/issues/2486controlPoints do not get reconstructed2022-05-25T11:46:07ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcontrolPoints do not get reconstructed### Functionality to add/problem to solve
interfaceTrackingFvMesh writes some control points to a file
"controlPoints"
(as a vectorIOField). This does not get reconstructed (tested with redistributePar -reconstruct on tutorial incomp...### Functionality to add/problem to solve
interfaceTrackingFvMesh writes some control points to a file
"controlPoints"
(as a vectorIOField). This does not get reconstructed (tested with redistributePar -reconstruct on tutorial incompressible/pimpleFoam/laminar/contaminatedDroplet2D)
### Target audience
finiteArea+mesh motion
### Proposal
Make a DimensionedField instead of IOField?
@markhttps://develop.openfoam.com/Development/openfoam/-/issues/2483Problem in internal energy calculation, rhoCentralFoam version > 20062022-11-22T14:49:48ZIvan SpissoProblem in internal energy calculation, rhoCentralFoam version > 2006<!--
*** 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 -->
As told to @mark, we encountered in a problem related to calculation of internal energy `e` for rhoCentralFoam in version > 2006
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Run one of the tutorials of `rhoCentralFoam`, for instance, _forwardStep_ and display the residuals (which are zero, direct solver) and the internal energy (that starts with negative values).
### 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
-->
_Load OpenFOAM V2112;_
```
[spissoi@dvlogin02 forwardStep]$ module load openfoam/v2112/GccOpt
[spissoi@dvlogin02 forwardStep]$ module li
Currently Loaded Modulefiles:
1) lapack/gcc/64/3.9.0 2) blas/gcc/64/3.8.0 3) fftw3/openmpi/gcc/64/3.3.8 4) openmpi/mlnx/gcc/64/4.0.4rc3 5) gcc/10.2.0 6) boost/1.66.0/gnu/10.2 7) openfoam/v2112/GccOpt
```
```
cp -r solvers/compressible/rhoCentralFoam/rhoCentralFoam/ $FOAM_USER_APPBIN
```
Now modify the `rhoCentralFoam.C` file in `myrhoCentralFoam.C` to add a line to monitor initial value of `e` at line 83
vi myrhoCentralFoam.C
```
82
83 Info<< "e\n" << e << endl;
84
85 Info<< "\nStarting time loop\n" << endl;
```
Adjust the relevant path in _myrhoCentralFoam/_ dir, renaming `rhoCentralFoam.C` in `myrhoCentralFoam.C`, and recompile:
```
./Allclean
./Allwmake
```
Now copy one of the tutorials, in that case forwardStep
cp $FOAM_TUTORIALS/compressible/rhoCentralFoam/forwardStep/ $FOAM_RUN
create the mesh with
```
blockMesh
```
And set only one-time step in _system/controlDict_
```
application rhoCentralFoam;
startFrom startTime;
startTime 0;
stopAt endTime;
endTime 0.002;
deltaT 0.002;
```
### What is the current *bug* behaviour?
<!-- What actually happens -->
By running the instrumented solver
`myrhoCentralFoam > log &`
Once the simulation is done is it possible to find, in the log file, the info about the internal energy which is negative with a value of -743.589
If the standard set-up is run with standard rhoCentralFoam solver:
`myrhoCentralFoam > log &`
```
[spissoi@dvlogin02 forwardStep]$ vim rho.log
type hePsiThermo;
mixture pureMixture;
transport const;
thermo hConst;
equationOfState perfectGas;
specie specie;
energy sensibleInternalEnergy;
}
Reading field U
Creating turbulence model
Selecting turbulence model type laminar
Selecting laminar stress model Stokes
fluxScheme: Kurganov
Starting time loop
deltaT = 0.00238095
Mean and max Courant Numbers = 0.66643 0.666666
Time = 0.00238095
diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
diagonal: Solving for rhoUx, Initial residual = 0, Final residual = 0, No Iterations 0
diagonal: Solving for rhoUy, Initial residual = 0, Final residual = 0, No Iterations 0
diagonal: Solving for rhoE, Initial residual = 0, Final residual = 0, No Iterations 0
ExecutionTime = 0.11 s ClockTime = 0 s
deltaT = 0.000712548
Mean and max Courant Numbers = 0.199446 0.200515
Time = 0.0030935
diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
diagonal: Solving for rhoUx, Initial residual = 0, Final residual = 0, No Iterations 0
diagonal: Solving for rhoUy, Initial residual = 0, Final residual = 0, No Iterations 0
diagonal: Solving for rhoE, Initial residual = 0, Final residual = 0, No Iterations 0
ExecutionTime = 0.12 s ClockTime = 0 s
deltaT = 0.000712548
Mean and max Courant Numbers = 0.199447 0.201005
Time = 0.00380605
diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
diagonal: Solving for rhoUx, Initial residual = 0, Final residual = 0, No Iterations 0
diagonal: Solving for rhoUy, Initial residual = 0, Final residual = 0, No Iterations 0
diagonal: Solving for rhoE, Initial residual = 0, Final residual = 0, No Iterations 0
ExecutionTime = 0.13 s ClockTime = 0 s
```
Even if, by displaying the fields, it seems that the solution advance and produces the expected shock waves, see attached figure.
### What is the expected *correct* behavior?
If openfoam v2006 is run, normal behavior is reproduced. By reproducing the same step as before, once the simulation is done it is possible to find, in the log file, the info about the internal energy which is positive with a value of 1.78572. And a normal residual behaviuor
<!-- 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.
-->
U field version openfoam v2112
![field_U_v2112](/uploads/4e617b73a28e91ed3f6bb5f970da4cd7/field_U_v2112.JPG)
Pressure field version openfoam v2112![filed_p_v2112](/uploads/b5fe85c38f11d10e301becafa219a7a0/filed_p_v2112.JPG)
### Environment information
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2112|v2006|
Operating system : ubuntu laptop|centos HPC etc
Hardware info : local installation on laptop and HPC installation
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
-->
Maybe it is due a non correct initialization of energy in the
`constant/thermophysicalProperties`
or in the creation of the initial field in
`createFields.H `
Thanks in advance
IvanKutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2473Wrong boundary behaviour by interFoam2022-07-12T09:34:28ZBahram HaddadiWrong boundary behaviour by interFoam<!--
*** 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
Performing simulations with interFoam, with an outlet for both phases, if the whole simulation domain is in the positive or negative quarter of coordinate system, then the simulation is correct and correct behavior of both fluids at the outlet is predicted. But as soon a part of the geometry is in the negative and the other part is in positive quarters of the coordinate system, then the outlet misbehaves and based on the used boundary conditions blocks or repels the fluid! This issue has been discussed in the very old forums of the cfd-online.com but no reason or solution was presented: https://www.cfd-online.com/Forums/openfoam/79714-not-outflow-outlet-interfoam.html
### Steps to reproduce
Using the original damBreak example of interFoam the mentioned behavior can be reproduced by changing the gravity direction from -y to -x and moving the geometry partially to the negative quarters (e.g. transformPoints -translate '(-0.3 -0.3 -0.007)'
).
### Example case
Please find the sample simulation with the original coordinates (original) and the sample with translated coordinates (translated) in the attachment.
Note: in both cases the gravity direction has been changed from -y to -x (that the water phase exits the atmosphere outlet)
### What is the current *bug* behavior?
The outlet boundary (in this case "atmosphere") behaves as a wall and repels the flow or causes non-physical behavior!
### What is the expected *correct* behavior?
The water should flow outside the geometry.
In general it is not expected that the behaviour of the simulation changes just by changing the coordinate system!!!
### Relevant logs and/or images
Pic1: the original simulation
Pic2: translated simulation
### Environment information
OpenFOAM version : v2006 (but as it can be seen from the forum link provided it is also happening in the older versions)
Operating system : ubuntu 20.04.1 LTS
Hardware info : -
Compiler : gcc
### Possible fixes
[damBreak.zip](/uploads/e3534d190a06ce95401b2e3998d39663/damBreak.zip)
![Fig1](/uploads/875c9f53c7b47336585fa6685d6a1015/Fig1.png)
![Fig2](/uploads/c0d223d6e5418b65485ea531f156100b/Fig2.png)https://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/2470Different results with interFoam for serial and parallel simulations with fix...2023-05-31T10:55:18Zalexander tismerDifferent results with interFoam for serial and parallel simulations with fixed time step<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
The parallel execution of a two-phase-simulation with `interFoam` results in a partly very different solution for the flow fields compared to a serial and to other distributed simulations. The simulation consists of a domain initially filled with air. Over time the domain is filled by a water jet from the top. The air leaves the domain at an outlet located on the side. The following figure gives an overview.
<img src="/uploads/d99b5d8c4c8c2c44637e294d5be0c0eb/descri.png" width="400">
The differences are observed for both, _metis_ and _simple_, decomposition methods. Furthermore, there are also different results with different number of processors (e.g. between 4 and 8).
We have also uploaded the complete case to [github](https://github.com/atismer/interFoam_saw/tree/6be2ac1302eb87cb533ed2cb991be46a2f3f982a).
### Steps to reproduce
Clone [this](https://github.com/atismer/interFoam_saw/tree/6be2ac1302eb87cb533ed2cb991be46a2f3f982a) github and run simulation on different number of processes
### 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 [here](https://github.com/atismer/interFoam_saw)
### What is the current *bug* behaviour?
Results are not equal for different decompositions and also not equal to the serial case. The following figure gives the result of a simulation on 4 (top left) and 8 (top right) processes. Bottom pictures give the result, again 4 (bottom left) and 8 (bottom right) processes, with a limited Courant number.
<img src="/uploads/8741549adf0581d08a18e660d3f3249e/plane_z_U.0007.png" width="400">
The above figures show field `U` on a plane located in the center in z direction of the case. Next figure shows the location of the plane.
<img src="/uploads/ccf57863222cf471a65ff8de1f316861/over_plane.png" width="200">
### What is the expected *correct* behavior?
<!-- What you should see instead -->
The results of different decomposed simulations and the serial simulation should be identical.
### 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 : 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 : `OpenFOAM-v2112` https://develop.openfoam.com/Development/openfoam/-/commit/14aeaf8dabfaf46e146a56a0e72beffeb401a5be
- Operating system : `openSUSE Leap 15.3`
- Hardware info : -
- Compiler : `gcc (SUSE Linux) 7.5.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
-->
The limitation (see [this](https://github.com/atismer/interFoam_saw/compare/6be2ac1..f955be0) diff) of the Courant number to a value of 1 gives much more similar results. Comare again bottom pictures within figure above.Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2465Error in mappedPatches/mappedPolyPatch/mappedPatchBase.C2022-05-12T16:34:43ZZeinab AbosedairaError in mappedPatches/mappedPolyPatch/mappedPatchBase.C<!--
*** 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 facing two contradicting error when applying samplingModes **(nearestCell and nearestOnlyCell)** in a MultiRegion problem.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
This can be easily reproduced by changing the sampleMode of the interface to nearestCell or nearestOnlyCell in a chtMultiRegion tutorial in constant/polyMesh/boundary file.
### Example case
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
### What is the current *bug* behaviour?
<!-- What actually happens -->
So I am running a MultiRegion problem, and I had a problem in mapping the cells at the interface, so I tried using different sampleMode, and when I came to try the **nearestCell** and the **nearestOnlyCell** , I found two contradicting errors.
So this is the boundary patch I am trying to map in constant/fluid/polyMesh/boundary:
```
airfoil
{
type mappedPatch;
inGroups 1(mappedPatch);
nFaces 292;
startFace 123418;
sampleMode nearestCell;
sampleRegion solid;
samplePatch airfoil;
offsetMode normal;
offset ( 0 0 0 );
distance 0.00005;
}
```
As you see here I am specifying the patch name as here as **samplePatch airfoil**, this is the error I get.
```
--> FOAM FATAL ERROR: (openfoam-2012)
No need to supply a patch name when in nearestCell mode.
From void Foam::mappedPatchBase::findLocalSamples(Foam::mappedPatchBase::sampleMode, Foam::label, const Foam::word&, const Foam::word&, const pointField&, Foam::List<Foam::Tuple2<Foam::Tuple2<Foam::PointIndexHit<Foam::Vector<double> >, Foam::Tuple2<double, int> >, int> >&) const
in file mappedPatches/mappedPolyPatch/mappedPatchBase.C at line 321.
FOAM exiting
```
From this error, I understood that I should remove the samplePatch entry, when I commented it as you see here:
```
airfoil
{
type mappedPatch;
inGroups 1(mappedPatch);
nFaces 292;
startFace 123418;
sampleMode nearestCell;
sampleRegion solid;
// samplePatch airfoil;
offsetMode normal;
offset ( 0 0 0 );
distance 0.00005;
}
```
I got this error:
```
--> FOAM FATAL ERROR: (openfoam-2012)
Supply either a patchName or a coupleGroup for patch airfoil in region fluid
From const Foam::word& Foam::mappedPatchBase::samplePatch() const
in file /home/pawan/OpenFOAM/OpenFOAM/OpenFOAM-v2012/src/meshTools/lnInclude/mappedPatchBaseI.H at line 74.
FOAM exiting
```
which is contradicting the previous error I got.
### What is the expected *correct* behavior?
I am expecting that this contradiction doesn't appear, and that it works in one of the two cases.
<!-- 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 : 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 : v2012
- Operating system : WSL
- Hardware info :
- 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
-->Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2457BUG: isoAdvection not conserving volume of fluid across cyclic boundaries2022-12-20T13:21:10ZJohan RoenbyBUG: isoAdvection not conserving volume of fluid across cyclic boundaries<!--
*** 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
isoAdvection not conserving volume of fluid across cyclic boundaries.
### Steps to reproduce
1. Execute the `Allrun` script in `$FOAM_TUTORIALS/multiphase/interIsoFoam/discInConstantFlowCyclicBCs`
2. Extract "Phase-1" volume from log:
` grep "Phase-1" log.interIsoFoam | cut -d' ' -f5 > Phase1`
3. Run gnuplot in the terminal and show data:
`plot "Phase1"`
In the figure you will see the Phase-1 content in the domain change when the blob travels through the cyclic boundaries
### Possible fixes
Reason for wrong behaviour:
IsoAdvection creates a surfaceScalarField dVf which is the Phase-1 volume crosing a face in the time deltaT.
dVf on a face uses the isoface information in its UPWIND cell.
This also goes for boundary faces where fluid flows OUT of the domain.
For boundary faces on which fluid flows INTO the domain isoAdvection does nothing because it assumes that the alpha1 boundary condition specifies how much of the incoming fluid that is Phase-1 and Phase-2, respectively.
Solution:
At [this point](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/transportModels/geometricVoF/advectionSchemes/isoAdvection/isoAdvection.C#L400) in the code - i.e. after havng set dVf on a downwind boundary face - check if the face is on a cyclic patch. If it is, set the same dVf value on the corresponding face of the coupled patch.
To solve this, I need to do a little digging into the functionality of cyclic related code. I will definitely do this before v2206. But if someone is up for fixing it before then, be my guest.v2306Johan RoenbyJohan Roenbyhttps://develop.openfoam.com/Development/openfoam/-/issues/2450Errors when using post-processing function for PLIC interfaces in InterIsoFoam2022-05-02T20:02:33Zwu erjunErrors when using post-processing function for PLIC interfaces in InterIsoFoamI used the post-processing function in InterIsoFoam to get the PLIC interfaces. Interfaces were successfully generated at the beginning. But after some time steps, there are some errors showing the failure of the generation process. The ...I used the post-processing function in InterIsoFoam to get the PLIC interfaces. Interfaces were successfully generated at the beginning. But after some time steps, there are some errors showing the failure of the generation process. The code I added in controlDict and the error prompted by the terminal are as follows.
The post-processing function in controlDict:
```
functions
{
surfaces
{
type surfaces;
libs (geometricVoF sampling);
writeControl writeTime;
surfaceFormat vtp;
fields (p U);
interpolationScheme cell;
surfaces
{
freeSurf
{
type interface;
interpolate false;
}
}
}
}
```
Errors prompted by the terminal:
```
Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::sigSegv::sigHandler(int) at ??:?
#2 ? in /lib64/libpthread.so.0
#3 Foam::cutCell::calcIsoFacePointsFromEdges(Foam::Vector<double> const&, Foam::Vector<double> const&, Foam::DynamicList<Foam::DynamicList<Foam::Vector<double>, 16>, 16> const&, Foam::DynamicList<Foam::Vector<double>, 16>&) at ??:?
#4 Foam::cutCellPLIC::facePoints() at ??:?
#5 Foam::reconstructionSchemes::surface() at ??:?
#6 Foam::sampledInterface::updateGeometry() const at ??:?
#7 Foam::sampledSurfaces::performAction(unsigned int) at ??:?
#8 Foam::functionObjects::timeControl::write() at ??:?
#9 Foam::functionObjectList::execute() at ??:?
#10 Foam::Time::run() const at ??:?
#11 ? at ??:?
#12 __libc_start_main in /lib64/libc.so.6
#13 ? at ??:?
/var/spool/slurm/d/job2377338/slurm_script: line 7: 22486 Segmentation fault interIsoFoam
```https://develop.openfoam.com/Development/openfoam/-/issues/2448chemFoam solver gets wrong results when using second order time scheme2022-05-17T04:32:25ZHaochen LiuchemFoam solver gets wrong results when using second order time scheme<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
When using the chemFoam solver to to run the corresponding tutorial case, we found that using "Euler" as the ddt scheme leads to correct results, which is the same as the CHEMKIN result (the final temperature is 2660K). While using "backward" or the other second order schemes leads to a much lower final temperature. We are not sure if this issue still exists in reactingFoam, which has been widely used in turbulent combustion simulations by OpenFOAM. This question is very important for us.
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
1. Run the tutorial case with default settings and plot the results. The case dictionary is: /tutorials/combustion/chemFoam/gri
2. Change the ddt scheme from "Euler" into "backward" and run the case again.
3. Plot the results and compare them with the CHEMKIN result provided in the tutorial case: /tutorials/combustion/chemFoam/gri/chemkin/senk.out
(The OpenFOAM version we use is v2112)
<!-- How one can reproduce the issue - this is very important -->
### Example case
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
### What is the current *bug* behaviour?
The final temperature does not agree with the CHEMKIN result for second order ddt schemes.
<!-- What actually happens -->
### What is the expected *correct* behavior?
The final temperature agree with the CHEMKIN result for different ddt schemes.
<!-- 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 : 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
- Operating system :Linux
- Hardware info :
- Compiler :gcc
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->https://develop.openfoam.com/Development/openfoam/-/issues/2442chtMultiRegionFoam with anistropic diffusivity2023-12-07T05:40:02ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comchtMultiRegionFoam with anistropic diffusivity### Functionality to add/problem to solve
chtMultiRegionFoam/solidFoam supports anisotropic diffusivity. This gets calculated by converting at startup the thermo properties into the coordinate system.
It does not recalculate the proper...### Functionality to add/problem to solve
chtMultiRegionFoam/solidFoam supports anisotropic diffusivity. This gets calculated by converting at startup the thermo properties into the coordinate system.
It does not recalculate the properties
- if the thermo properties change (e.g. temperature varying alpha)
- if the coordinate system changes (e.g. cylindrical coordinate system, pivoting across second axis)
### Target audience
Anyone using cht with changing solid properties.
### Proposal
Two possibilities:
- have option to update/correct coordinate system and update anisotropic diffusivity accordingly
- not cache aniAlphas but calculate it on-the-fly
@mark @Sergiohttps://develop.openfoam.com/Development/openfoam/-/issues/2437Loading external library (preCICE coupling library)2022-04-23T07:49:26ZPaul BrousseauLoading external library (preCICE coupling library)Hi,
We are trying to use the coupling-codes-library preCICE with Openfoam-v2112, compiled from source and without `thirdParty`, on a cluster with this distribution:
```
Distributor ID: CentOS
Description: CentOS Linux release 7.8.2003 ...Hi,
We are trying to use the coupling-codes-library preCICE with Openfoam-v2112, compiled from source and without `thirdParty`, on a cluster with this distribution:
```
Distributor ID: CentOS
Description: CentOS Linux release 7.8.2003 (Core)
Release: 7.8.2003
Codename: Core
```
PreCICE developers seem to think that our Openfoam compilation is the cause of the problem. Indeed this error occurs when loading the external library in the `controlDict`:
```
#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::sigFpe::sigHandler(int) at ??:?
#2 ? in /lib64/libpthread.so.0
#3 ? in /opt/ohpc/pub/libs/gnu8/openmpi3/trilinos/12.14.1/lib/libteuchoscore.so.12
#4 ? in /lib64/ld-linux-x86-64.so.2
#5 ? in /lib64/ld-linux-x86-64.so.2
#6 ? in /lib64/ld-linux-x86-64.so.2
#7 ? in /lib64/ld-linux-x86-64.so.2
#8 ? in /lib64/libdl.so.2
#9 ? in /lib64/ld-linux-x86-64.so.2
#10 ? in /lib64/libdl.so.2
#11 dlopen in /lib64/libdl.so.2
#12 Foam::dlOpen(Foam::fileName const&, bool) at ??:?
#13 Foam::dlOpen(Foam::fileName const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&) at ??:?
#14 Foam::dlLibraryTable::openLibrary(Foam::fileName const&, bool) at ??:?
#15 Foam::dlLibraryTable::open(Foam::fileName const&, bool) at ??:?
#16 bool Foam::dlLibraryTable::open<Foam::HashTable<Foam::autoPtr<Foam::functionObject> (*)(Foam::word const&, Foam::Time const&, Foam::dictionary const&), Foam::word, Foam::Hash<Foam::word> >*>(Foam::dictionary const&, Foam::word const&, Foam::HashTable<Foam::autoPtr<Foam::functionObject> (*)(Foam::word const&, Foam::Time const&, Foam::dictionary const&), Foam::word, Foam::Hash<Foam::word> >* const&, bool) at ??:?
#17 Foam::functionObject::New(Foam::word const&, Foam::Time const&, Foam::dictionary const&) at ??:?
#18 Foam::functionObjectList::read() at ??:?
#19 Foam::Time::run() const at ??:?
#20 ? at ??:?
#21 __libc_start_main in /lib64/libc.so.6
#22 ? at ??:?
Exception en point flottant
```
In fact, simply loading the preCICE library (and not using it) makes OF crashes. Of course, OF works well alone.
Do you have any guess on where to look and how to debug this ?
Thanks !
Paulhttps://develop.openfoam.com/Development/openfoam/-/issues/2431dynamicMotionSolverFvMeshAMI + surface sampler2022-03-31T10:19:51ZPrashant SonakardynamicMotionSolverFvMeshAMI + surface samplerfoamToEnSight and foamToVTK works fine with https://develop.openfoam.com/Development/openfoam/-/issues/2396, however attached a case [rotatingFanInRoom.tgz](/uploads/ff5be755b89b72e1d3bf2f49d39fa945/rotatingFanInRoom.tgz) which fails to ...foamToEnSight and foamToVTK works fine with https://develop.openfoam.com/Development/openfoam/-/issues/2396, however attached a case [rotatingFanInRoom.tgz](/uploads/ff5be755b89b72e1d3bf2f49d39fa945/rotatingFanInRoom.tgz) which fails to grab cut-plane proper cells. A few candidates are missing from cut-plane as discussed with @mark
![issue-candidates-missing](/uploads/2c1c51b1c5d22d7a87560e25bbcbd3b8/issue-candidates-missing.png)https://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/2420tutorial "rigidBodyHull" crashes after applying "prescribedRotation" restrain...2022-03-23T08:11:25ZLu Xintutorial "rigidBodyHull" crashes after applying "prescribedRotation" restraint to the propeller<!--
*** 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 -->
The tutorial case crashes soon after applying a prescribed rotational motion to the propeller.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
append the following after the 'force' restraint
propellerRotation
{
type prescribedRotation;
body propeller;
referenceOrientation (1 0 0 0 1 0 0 0 1);
axis (1 0 0);
omega table
(
(0 (0 0 0))
(50.0 (10.0 0 0))
);
relax 0.5;
p 0.6;
i 0.6;
d 0.6;
}
### Example case
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
### What is the current *bug* behaviour?
<!-- What actually happens -->
Program crashes
### What is the expected *correct* behavior?
<!-- What you should see instead -->
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2112|v2106|
Operating system : centos
Compiler : gcc
-->
- OpenFOAM version :v2112|v2106
- Operating system :centos
- 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
-->
The program runs well if the hull is only allowed to do translations.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/2411MRF : divergent flow near interface when the rotating zone is unaligned2022-03-15T08:33:41ZHenrique GropelliMRF : divergent flow near interface when the rotating zone is unalignedHello!
When simulating a wind turbine with unaligned flow (turbine with tilt) I got a divergent flow near the interface of the non inertial zone and inertial zone.
![uy](/uploads/ef8a385359a1883f3f2776bece0d378d/uy.png)
I’m simulating in...Hello!
When simulating a wind turbine with unaligned flow (turbine with tilt) I got a divergent flow near the interface of the non inertial zone and inertial zone.
![uy](/uploads/ef8a385359a1883f3f2776bece0d378d/uy.png)
I’m simulating in a steady flow regime with MRF (multiple reference frame), when the turbine is aligned with the flow the flow is fully converged.
![tilt0yn](/uploads/cffe5439f6cea9432105bca5c544069b/tilt0yn.png)
I have set the patches excluding the blade patches as non rotating patches in MRFProperties.
I had tested in three different meshes with different refinements in the interface (57MM cells in “A” mesh, 62MM cells in “B” mesh, 97MM cells in “C” mesh) to better achieve an interface weight in AMI. But the three meshes diverged.
For a last attempt I simulated an unaligned flow in an aligned mesh, changing the velocity components, but diverged as before.
The mesh is a cylinder 15 diameters long and 5 diameters high. Inside the mesh is a mesh of 2 diameters long and 2 diameters high, which is the rotating zone.
I don't have a small example, this link contains the results and the mesh: https://drive.google.com/file/d/1RqzYC68v9YfBUidHXLHVgNwdBBvTcORP/view?usp=sharing
Openfoam v2006, gcc v8.3, centos.