openfoam issueshttps://develop.openfoam.com/Development/openfoam/-/issues2020-01-03T11:15:54Zhttps://develop.openfoam.com/Development/openfoam/-/issues/407BUG: volume sampling output location2020-01-03T11:15:54ZPrashant SonakarBUG: volume sampling output location[pitzDaily_sample_surfaceAndVol.tgz](/uploads/9b26e07b30ae20acd358fa402c72fb31/pitzDaily_sample_surfaceAndVol.tgz)
Case attached replicating issue.
- contains sampling for surface and volume type with writeFields=true
surface-> outputs...[pitzDaily_sample_surfaceAndVol.tgz](/uploads/9b26e07b30ae20acd358fa402c72fb31/pitzDaily_sample_surfaceAndVol.tgz)
Case attached replicating issue.
- contains sampling for surface and volume type with writeFields=true
surface-> outputs field in postProcessing directory
volume-> outputs field (!) in processor0 (for parallel) or case directory (serial)
@andy @MattijsVersion v1706Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/506ENH: provide warning / error message when field is not read!2021-07-06T11:05:31ZPrashant SonakarENH: provide warning / error message when field is not read!Attached case with fields declared as dictionary [pitzDaily-EP412.tgz](/uploads/73052f1b040d0e091e935fc0364e2e2f/pitzDaily-EP412.tgz)
decomposePar shows success, however there is no field decomposed in processors.
It would be good to a...Attached case with fields declared as dictionary [pitzDaily-EP412.tgz](/uploads/73052f1b040d0e091e935fc0364e2e2f/pitzDaily-EP412.tgz)
decomposePar shows success, however there is no field decomposed in processors.
It would be good to add a warning or error!
@Mattijs @andyVersion v1706Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/720add toc-style functionality to clouds/parcels2018-02-02T17:27:24ZMark OLESENadd toc-style functionality to clouds/parcelsCan currently write to an objectRegistry, but cannot otherwise ascertain which fields a cloud would normally write.
Add a classes() method similar to what objectRegistry and IOobjectList have. However, it is probably inconvenient to hav...Can currently write to an objectRegistry, but cannot otherwise ascertain which fields a cloud would normally write.
Add a classes() method similar to what objectRegistry and IOobjectList have. However, it is probably inconvenient to have the matcher predicate.
In the cloud:
template<class CloudType>
void queryClasses(const CloudType&, HashTable<wordHashSet>& classes) const
{
classes(IOField<label>::typeName).insert
({
"active",
"typeId",
});
classes(IOField<scalar>::typeName).insert
({
"nParticle",
"d",
"dTarget",
"rho",
"age",
"tTurb",
});
...
}
@andyv1806Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1067Problem with wave boundary conditions2024-03-08T22:57:31ZJohan RoenbyProblem with wave boundary conditionsThe wave boundary conditions are introducing a small fraction of air in the water phase. This is illustrated in the attached video:
![streamFunWaveProblem](/uploads/e4972a4f225032115a5583500e15852c/streamFunWaveProblem.mp4)
which shows...The wave boundary conditions are introducing a small fraction of air in the water phase. This is illustrated in the attached video:
![streamFunWaveProblem](/uploads/e4972a4f225032115a5583500e15852c/streamFunWaveProblem.mp4)
which shows the 0.99 and 0.9999 alpha contours of the $FOAM_TUTORIALS/multiphase/interFoam/laminar/waveExampleStreamFunction case.
The case was run as is.
If run with interIsoFoam instead of interFoam, isoAdvector collects the small amount of air in the water phase into bubbles that rise to the surface. A work around is to run interIsoFoam with surfCellTol = 1e-2 in fvSolution.solvers."alpha.water.*". But really this seems to be a problem with the wave BC's and not with isoAdvector.
A Paraview state file used to generate the movie is attached here: [state2.pvsm](/uploads/0ae150172498bbf215446260ada7e1e5/state2.pvsm)v1812Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/1126function object properties can only handle a single output2018-12-14T18:18:56ZMark OLESENfunction object properties can only handle a single outputthe sampled surfaces function object can contain several surfaces, but when it only has a single property to save the information. Eg,
Input:
```
plane0
{
type surfaces;
...
surfaces
(
planeA { ... }
...the sampled surfaces function object can contain several surfaces, but when it only has a single property to save the information. Eg,
Input:
```
plane0
{
type surfaces;
...
surfaces
(
planeA { ... }
planeB { ... }
);
```
uniform/functionObjects/functionObjectProperties
```
plane0
{
U
{
file "<case>/postProcessing/plane0/0.03/U_planeB.vtk";
}
}
```
possibly relevant for #1091 @andyv1906https://develop.openfoam.com/Development/openfoam/-/issues/1570Cloud post-processing data not written when steady case converges using resid...2020-01-28T09:28:57ZAndrew HeatherCloud post-processing data not written when steady case converges using residualControl<!--
*** 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 ...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
When using clouds in steady solvers combined with case termination controls set using `residualControl` in the `fvSolution` file, cloud post-processing data are not written on the last iteration.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Add `residualControl` settings to a steady flow solver with cloud functionality and cloud a post-processing object, e.g. `particleTracks`
```
particleTracks
{
type particleTracks;
trackInterval 5;
maxSamples 1000000;
resetOnWrite yes;
}
```
and notice that the cloud post-processing data are not written
### 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?
When the criteria specified in the `residualControls` dictionary are achieved the solver loop calls `time.writeAndEnd()` to write any objects registered with `AUTO_WRITE` and exits. Operations such as cloud post-processing are currently only triggered when evolving the cloud and intercept the `writeTime()` flag and are therefore missed.
### 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 : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :
- 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
-->
Couple of options
- instead of exiting straight away, run for 1 more iteration with the `writeTime_` flag set (e.g. using `time.writeOnce()` and exit
- intercept the `write()` call to trigger other post-processing actionsv2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/1340low limit of cut-off frequency ignored in surfaceNoise2020-03-09T06:15:06ZAdminlow limit of cut-off frequency ignored in surfaceNoisesurfaceNoise ignores the fl when writting the 1/3-data of SPL and PSD. That means the data of 1/3 SPL and PSDlower than fl are still written to files. The problem can be reproduced using the vortexShed tutorials.
Link to EP:
https://...surfaceNoise ignores the fl when writting the 1/3-data of SPL and PSD. That means the data of 1/3 SPL and PSDlower than fl are still written to files. The problem can be reproduced using the vortexShed tutorials.
Link to EP:
https://exchange.openfoam.com/node/1038
Son.
\## Reattaching the author to the issue ticket: @SonVo ##v2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/1875BUG: forces FO: adds forces and moments beyond binMax to the last bin2024-01-11T18:15:10ZKutalmış BerçinBUG: forces FO: adds forces and moments beyond binMax to the last bin<!--
*** 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 -->
In `forces` FO, when `binData == true` with a user-defined `binMax`, forces and moment estimations for the patch region outside the bin are added into the last bin if `binMax` is less than the extent of a given patch in the binning direction.
For example, in the following sketch, the forces and moments outside the linear bin are added into the bin-3.
![image](/uploads/5eeb391bf9891d0b6c09f6f68c8aed1e/image.png)
The error arises from the `applyBins` func:
```
...
const scalarField dd((d & binDir_) - binMin_);
forAll(dd, i)
{
label bini = min(max(floor(dd[i]/binDx_), 0), force_[0].size() - 1); // PROBLEM
force_[0][bini] += fN[i];
...
```
### 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 : 73057447a2v2012Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1797Write interval in forces function object2021-04-13T16:44:44ZRiccardo RossiWrite interval in forces function objectFor the first time, lately, I had the need to write forces with a specific interval and realized whatever value I used in writeInterval, the output file in postProcessing had the forces written every timeStep.
I then spent a couple of h...For the first time, lately, I had the need to write forces with a specific interval and realized whatever value I used in writeInterval, the output file in postProcessing had the forces written every timeStep.
I then spent a couple of hours trying to figure out if something was wrong in the function object input in the controlDict as well as trying to use old releases to see if something had changed or if a bug had occurred.
I then came across the issue #1642, and I believe, as an experienced user, this is very confusing.
In the referenced issue, it is mentioned that "The `writeControl` entry for the `forces` function object only controls the writing of the volume fields" and therefore the output must be controlled via `executeControl` and `executeInteval`.
In my humble opinion, or from the user point of view at least, I don't see the difference between the forces computed as the integral of pressure and shear over patches via `libforces`, where the output is controlled via execute-type controls, and the average values of pressure or any other variable computed via the `"libfieldFunctionObjects`, which is controlled via write-like controls instead.
Maybe the handling from the coding side is very different indeed, but I'm pretty sure no one out there would have figured that out plus there isn't any mention to it in the official documentation.v2012Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1672waveMaker MultiPaddleFlap crashes if the boundary normal is in the Y direction.2020-07-02T07:43:53ZJaap StolkwaveMaker MultiPaddleFlap crashes if the boundary normal is in the Y direction.### Summary
<!-- Summarize the bug encountered concisely -->
waveMaker MultiPaddleFlap crashes if the boundary normal is in the Y direction.
### Steps to reproduce
in version v1912, copy the multiphase\interFoam\laminar\waves\waveMake...### Summary
<!-- Summarize the bug encountered concisely -->
waveMaker MultiPaddleFlap crashes if the boundary normal is in the Y direction.
### Steps to reproduce
in version v1912, copy the multiphase\interFoam\laminar\waves\waveMakerMultiPaddleFlap example.
- I have swapped X and Y of verices in system/blockMeshDict (attached) and adjusted the vertex order to keep the hex () definition CCW.
- I swapped the X and Y decomposition in system/decomposeParDict
- in 0.orig/pointDisplacement, I changed the normal vector to: n (0 1 0)
- then ran the case using the Allrun script.
### Example case
place the attached system/blockMeshDict in the v1912 multiphase\interFoam\laminar\waves\waveMakerMultiPaddleFlap example, and make the 2 additional modifications mentioned above.
### What is the current *bug* behaviour?
It results in a floatingpoint-error in Foam::waveMakerPointPatchVectorField::initialiseGeometry()
without any other errors or warnings logged. (see attached log.interFoam)
### What is the expected *correct* behavior?
The calculation should run as the original example, or produce an error message when the waveMaker normal vector is outside the supported range.
I tried to reproduce with minimal changes to an example case. In my original case I had the waveMaker boundary on the -Y side and swapping everything in my case in the x=y line resolved my crash, but now the postprocessing does not follow my other cases that have the waveMaker boundary on the -X side.
### Relevant logs and/or images
[blockMeshDict](/uploads/ecde43c3bda4ea4dbc9d45ab7a45423e/blockMeshDict)
[log.interFoam](/uploads/ac80e7fd15e51b2884e8eb6c2302b5b7/log.interFoam)
### Environment information
- OpenFOAM version : v1912 (compiled from source)
- Operating system : ubuntu
- Hardware info : 2x Intel(R) Xeon(R) E5-2690 2.9 GHz
- Hardware info : 1x AMD 1950X
- Compiler : gccv2012Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/999unavailable "timeExample" V&V testcase2023-05-17T15:57:13ZAdminunavailable "timeExample" V&V testcaseThe documentation describes an example of various time schemes (ref. 1) with a link to a V&V testcase, timeExample (ref. 2).
The specific case seem to be unavailable in the repository (when following the link I get error 404: The page c...The documentation describes an example of various time schemes (ref. 1) with a link to a V&V testcase, timeExample (ref. 2).
The specific case seem to be unavailable in the repository (when following the link I get error 404: The page could not be found or you don't have permission to view it.).
References:
1) https://openfoam.com/documentation/cpp-guide/html/guide-schemes-time-example.html
2) https://develop.openfoam.com/development/OpenFOAM-plus/tree/master/tutorials/verificationAndValidation/schemes/timeExample
\## Reattaching the author to the issue ticket: @michele ##v2012Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1380Simplify output of the forces functionObject2020-11-07T16:14:52ZAdminSimplify output of the forces functionObject### Functionality to add/problem to solve
The output produced by the `forces` function object is much more complex than what it could be.
For each time step the output line is as
`0.65004 \t(4.966426e-01 1.252274e+00 -3.007485e-0...### Functionality to add/problem to solve
The output produced by the `forces` function object is much more complex than what it could be.
For each time step the output line is as
`0.65004 \t(4.966426e-01 1.252274e+00 -3.007485e-04)\t(4.246068e-01 1.273820e+00 2.141011e-17)\t(7.203576e-02 -2.154636e-02 -3.007485e-04)`
Here `\t` is a tab.
Also, two separate files are created, one for the forces and one for the moments.
### Proposal
Simply having 10 values separated by spaces or tabs (consistently!) would make it much easier to open the text file with e.g. numpy or pandas, without sacrificing much.
Combining both forces and moments into single file is also reasonable.
A switch could be added to allow falling back to the old output format.
\## Reattaching the author to the issue ticket: @timofeymukha ##v2012Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2060Wrong initialization of stepFraction_ in particle.C2022-04-26T16:03:12ZHunor CsalaWrong initialization of stepFraction_ in particle.C### Summary
Location: https://develop.openfoam.com/Development/openfoam/-/blob/develop/src/lagrangian/basic/particle/particle.C#L530 and lines 551, 584 as well.
In v2012, in the particle.C code, a variable called stepFraction_ is initia...### Summary
Location: https://develop.openfoam.com/Development/openfoam/-/blob/develop/src/lagrangian/basic/particle/particle.C#L530 and lines 551, 584 as well.
In v2012, in the particle.C code, a variable called stepFraction_ is initialized to be 1, while in all previous versions (v2006 or earlier) it was initialized to be 0. The definition of stepFraction is not changed, therefore, I believe the correct initialization is 0.
### Environment information
- OpenFOAM version : v2012
### Possible fixes
Change lines 530 (https://develop.openfoam.com/Development/openfoam/-/blob/develop/src/lagrangian/basic/particle/particle.C#L530), 551, 584 to: `stepFraction_(0.0),`. This is how it was in OpenFOAM v2006 and previous versions.v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1979Problem with totalFlux calculation in adjustPhi2022-04-26T16:06:28ZJohan RoenbyProblem with totalFlux calculation in adjustPhiThe variable totalFlux in cfdTools/general/adjustPhi/adjustPhi.C is calculated like this:
```
scalar totalFlux = VSMALL + sum(mag(phi)).value();
```
If I understand this correctly, the sum is over all internal faces.
At least in my cas...The variable totalFlux in cfdTools/general/adjustPhi/adjustPhi.C is calculated like this:
```
scalar totalFlux = VSMALL + sum(mag(phi)).value();
```
If I understand this correctly, the sum is over all internal faces.
At least in my case [floating2Dbox.zip](/uploads/09927295f1b004a086522694b51a693f/floating2Dbox.zip), the sum is initially zero, and I get totalFlux = 1e-300 although on the boundaries I have matching in- and outflow fluxes. For the attached case, this results in crash with:
```
--> FOAM FATAL ERROR: (openfoam-2012)
Continuity error cannot be removed by adjusting the outflow.
Please check the velocity boundary conditions and/or run potentialFoam to initialise the outflow.
Total flux : 1.0000000000000000251e-300
Specified mass inflow : 1.0000000000000059952
Specified mass outflow : 1.0000000000000064393
Adjustable mass outflow : 0
[floating2Dbox.zip](/uploads/eaba426b2041929d8e0787cc7a877d0d/floating2Dbox.zip)
```
The culprit is the line:
```
else if (mag(fixedMassOut - massIn)/totalFlux > 1e-8)
```
triggering the error.
My suggestion is to redefine totalFlux to also include the fixed boundary flux:
```
scalar totalFlux =
VSMALL + sum(mag(phi)).value() + mag(fixedMassOut) + mag(massIn);
```
It could also be considered to replace the hardcoded 1e-8 in the error condition above by for instance the `tolerance` of pFinal or p_rghFinal specified by the user in fvSolution.v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1976Possible bug in prescribedRotation restrain2022-04-26T16:07:46ZFederico ZilicPossible bug in prescribedRotation restrain<!--
*** 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
Hello, I'm running the boatAndPropeller tutorial and the prescribed rotations assigned to the propeller and rudder don't seem to match what is defined in dynamicMeshDict. This seems to be linked to the prescribedRotation restrain.
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
Run the boatAndPropeller tutorial with ./Allrun
### What is the expected *correct* behavior?
My understanding is that the propeller should accelerate until reaching a constant speed, and the rudder angular speed should be a sine wave, according to the dynamicMeshDict file:
![photo](/uploads/bf099782e4c89f1e0874717c7be293c5/photo.png)
### Relevant logs and/or images
The angular velocities as calculated with v2006:
![rud_ang_velocity](/uploads/e7888cc255404031ee1c007940befc26/rud_ang_velocity.png) ![pro_ang_velocity](/uploads/7d7a2712990bfdd9af1703894fdf479b/pro_ang_velocity.png)
### 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 : v2006 (tested with v1912 and v2012 as well)
- Operating system : Ubuntu
- Hardware info : x86_64
- Compiler : gcc 9.3.0
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->
My guess is that it could be the prescribedRotation restrain.
Thanks a lot.v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1972Incompressible non-uniform density turbulent model for VOF not compatible wit...2022-04-26T16:08:03ZBrecht DevolderIncompressible non-uniform density turbulent model for VOF not compatible with multiphaseStabilizedTurbulence fvOptionv2012 includes an incompressible non-uniform density turbulent model for VOF by adding
` density variable;`
in the turbulenceProperties dictionary ([https://openfoam.com/releases/openfoam-v2012/solver-and-physics.php#solver-...v2012 includes an incompressible non-uniform density turbulent model for VOF by adding
` density variable;`
in the turbulenceProperties dictionary ([https://openfoam.com/releases/openfoam-v2012/solver-and-physics.php#solver-and-physics-multiphase-rho-turbulence](https://openfoam.com/releases/openfoam-v2012/solver-and-physics.php#solver-and-physics-multiphase-rho-turbulence)).
This is not compatible with the multiphaseStabilizedTurbulence fvOption ([https://openfoam.com/releases/openfoam-v1912/solver-and-physics.php#solver-and-physics-vof-turbulence-stabilization](https://openfoam.com/releases/openfoam-v1912/solver-and-physics.php#solver-and-physics-vof-turbulence-stabilization)).
Modify damBreak tutorial (tutorials/multiphase/interFoam/RAS/damBreak) by adding system/fvOptions
```
/*--------------------------------*- C++ -*----------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: v2012 |
| \\ / A nd | Website: www.openfoam.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
object fvOptions;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
multiphaseStabilizedTurbulence1
{
type multiphaseStabilizedTurbulence;
active yes;
multiphaseStabilizedTurbulenceCoeffs
{
// Optional coefficients
lambda2 0.1; // A value of 0 sets the nut correction to 0
Cmu 0.09; // from k-epsilon model
C 1.51; // model coefficient from k-omega model
alpha 1.36; // 1/Prt
}
}
// ************************************************************************* //
```
Error message:
```
Creating finite volume options from "system/fvOptions"
Selecting finite volume options type multiphaseStabilizedTurbulence
Source: multiphaseStabilizedTurbulence1
--> FOAM FATAL ERROR: (openfoam-2012)
Unable to find incompressible turbulence model
From Foam::fv::multiphaseStabilizedTurbulence::multiphaseStabilizedTurbulence(const Foam::word&, const Foam::word&, const Foam::dictionary&, const Foam::fvMesh&)
in file sources/derived/multiphaseStabilizedTurbulence/multiphaseStabilizedTurbulence.C at line 121.
FOAM exiting
```v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1909chtMultiRegionTwoPhaseEulerFoam, pimple2022-05-24T08:14:58ZRobin KamenickychtMultiRegionTwoPhaseEulerFoam, pimple<!--
*** 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 -->
Solver reports that it runs PIMPLE mode but actually it runs in PISO mode. Further more, residualControl for PIMPLE cannot be used.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Use $FOAM_TUTORIALS/heatTransfer/chtMultiRegionTwoPhaseEulerFoam/solidQuenching2D.
````
$./Allrun
````
Have a look at the log.chtMultiRegionTwoPhaseEulerFoam. It will show
````
PIMPLE: no residual control data found. Calculations will employ 2 corrector loops
````
You can further check that only one outer correction loop was done
![log](/uploads/bc0eaf803d6614eed6a57c2cdd536c3d/log.png)
Then change system/water/fvSolution from
````
PIMPLE
{
nOuterCorrectors 2;
nCorrectors 2;
nNonOrthogonalCorrectors 0;
nEnergyCorrectors 4;
faceMomentum yes;
}
````
into
````
PIMPLE
{
nOuterCorrectors 1;
nCorrectors 2;
nNonOrthogonalCorrectors 0;
nEnergyCorrectors 4;
faceMomentum yes;
}
````
Now, it informs
````
PIMPLE: Operating solver in PISO mode
````
There are no other differences in log because it run before in PISO mode as well. It just informed wrongly.
![log1](/uploads/eee26a12f3287435ec66c42c1fae2e38/log1.png)
Apparently, the solver outer loop logic which loops over fluid and solid regions is based on system/fvSolution. It constructs object of pimpleControl from system/\<region\>/fvSolution, but it does not use it for outer correction loops.
The pimplControl object is constructed in createFluidFields.H but it is used only for pressure correction loops and nonorthogonal correction. Thus, eventhough the number of outercorrectors and residualControl are read from system/\<region\>/fvSolution, they are not used.
The residualControl was tested adding
````
{
p_rgh {relTol 0; tolerance 1e-3;}
}
````
in the PIMPLE dictionary in system/fvSolution and system/water/fvSolution and defining the nOuterCorrectors to 10. However, the residualControl is ignored in system/fvSolution and in system/water/fvSolution is read but not used.
### Example case
Given 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?
Given above
<!-- What actually happens -->
### What is the expected *correct* behavior?
It should correctly inform whether PIMPLE runs as PIMPLE or in PISO. Also, residual conrol should be possible to use.
<!-- 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 : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :v1906 (most probably also in v2006, but not tested)
- Operating system : ubuntu 16.04.6 LTS
- Hardware info :
- Compiler : gcc
### Possible fixes
Perhaps pimpleControl class should be adapted for multiregion solvers.
<!--
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
-->
/lable ~bugv2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1894Equation in Burns.C of Turbulent dispersion model of Burns et al.2022-04-26T16:10:00ZGuan ChaoranEquation in Burns.C of Turbulent dispersion model of Burns et al.Burns is one of the turbulent dispersion models of interficial models in reactingEulerFoam. And the reference is
*Burns, A. D., Frank, T., Hamill, I., & Shi, J. M. (2004, May).The Favre averaged drag model for turbulent dispersion in Eu...Burns is one of the turbulent dispersion models of interficial models in reactingEulerFoam. And the reference is
*Burns, A. D., Frank, T., Hamill, I., & Shi, J. M. (2004, May).The Favre averaged drag model for turbulent dispersion in Eulerian multi-phase flows.In 5th international conference on multiphase flow, ICMF (Vol. 4, pp. 1-17).* [Reference link](https://www.researchgate.net/publication/261761053_The_Favre_Averaged_Drag_Model_for_Turbulent_Dispersion_in_Eulerian_Multi-Phase_Flows)
The equation used in `Burns.C` from the reference is
```math
\vec M_{\alpha}^{TD}=-\vec M_{\beta}^{TD}=-\frac{3}{4}C_D\frac{\overline r_{\beta}\rho_{\alpha}}{d_\beta}|\vec{U_\beta}-\vec{U_\alpha}|\frac{\nu_{t\alpha}}{\sigma_{r\alpha}}(\frac{1}{\overline r_{\alpha}}+\frac{1}{\overline r_{\beta}})\nabla \overline r_{\alpha}
```
And the correspponding source code in `Burns.C` is
```C++
0.75
*drag.CdRe()
*pair_.continuous().nu()
*continuousTurbulence().nut()
/(
sigma_
*sqr(pair_.dispersed().d())
)
*pair_.continuous().rho()
*pair_.dispersed()
*(
1.0/max(pair_.dispersed(), residualAlpha_)
+ 1.0/max(pair_.continuous(), residualAlpha_)
);
```
I tried to translate it into the mathematical form as
```math
\frac{3}{4}C_D\frac{\nu_\alpha\rho_\alpha \overline r_\beta}{d^2_\beta}\frac{\nu_{t\alpha}}{\sigma_{r\alpha}}(\frac{1}{\overline r_{\alpha}}+\frac{1}{\overline r_{\beta}})
```
The two equations seem not to be the same. The interphase velocity term $`|\vec{U_\beta}-\vec{U_\alpha}|`$ is missed in the source code and there is an additional term $`\frac{\nu_{\alpha}}{d_{\beta}}`$ in it.
Is there any relationship between these two terms?v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1820Support wallHeatFluxCalculation on incompressible fluid (icoReactingMultiphas...2022-04-26T16:10:00ZThomas EnzingerSupport wallHeatFluxCalculation on incompressible fluid (icoReactingMultiphaseInterFoam solver)### Functionality to add/problem to solve
Actually wallHeatFlux can be only calculated with compressible fluids. A try with the icoReactingMultiphaseInterFoam solver runs into the error message
> Unable to find compressible turbulence ...### Functionality to add/problem to solve
Actually wallHeatFlux can be only calculated with compressible fluids. A try with the icoReactingMultiphaseInterFoam solver runs into the error message
> Unable to find compressible turbulence model in the database
>
> From virtual bool Foam::functionObjects::wallHeatFlux::execute()
> in file wallHeatFlux/wallHeatFlux.C at line
### Target audience
Who will benefit from the changes?
All cases that need an wallHeatFlux value with incompressible solvers.
Other software in that OpenFOAM is included build actually own solutions for the problem and try to detect compressible/incompressible solver type. (e.g. preCICE openfoam-adapter)
### Proposal
A solution is present since 2012.
https://github.com/wyldckat/wallHeatFluxIncompressible
A look to
https://github.com/precice/openfoam-adapter/tree/master/CHT
could be helping.
### Changes
- Edit title. Maybe a problem with the solver?v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1810MRF correctBoundaryVelocity not working with rotatingWallVelocity bc2022-04-26T16:10:01ZMortesinsMRF correctBoundaryVelocity not working with rotatingWallVelocity bc<!--
*** 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 `correctBoundaryVelocity` method of the MRF does not correct the boundary velocity of a patch that has a `rotatingWallVelocity` boundary condition, so it just ends up having the `rotatingWallVelocity` condition that does not set the velocity normal to the face. For example, if I have a rim with an MRF only around the spokes, I need the `rotatingWallVelocity` boundary condition for the rest of the rim, but even the spokes that are inside the MRF don't have velocity normal to the face the way the `correctBoundaryVelocity` method should set.
### What is the current *bug* behaviour?
The whole patch has the velocity set as `rotatingWallVelocity` would, disregarding the MRF.
### What is the expected *correct* behavior?
The `correctBoundaryVelocity` method of the MRF should correct the velocity for the faces inside the MRF, setting the rotating velocity even if it's normal to the face.v2206Kutalmış BerçinKutalmış Berçin