Development issueshttps://develop.openfoam.com/groups/Development/-/issues2020-06-19T14:38:04Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1341Improve lumped point functionality2020-06-19T14:38:04ZMark OLESENImprove lumped point functionality- Alternative euler orders for lumped point definitions
- with the more recent changes to quaternion and euler coordinate rotations we can now also support rotations
beyond the standard 'ZXZ' euler intrinsic rotations.
- cross ref: E...- Alternative euler orders for lumped point definitions
- with the more recent changes to quaternion and euler coordinate rotations we can now also support rotations
beyond the standard 'ZXZ' euler intrinsic rotations.
- cross ref: EP 1008
- Support multiple controllers (not just a single axis)
- Enable VTK output in parallel
Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2531Improvement of calculation in interface curvature in interFoam and InterIsoFoam2022-08-05T12:13:33Ztakuya yamamotoImprovement of calculation in interface curvature in interFoam and InterIsoFoam### Functionality to add/problem to solve
This implementation reduces the calculation error of interface curvature in interFoam and interIsoFoam. This implementation was reported by Hoang et al. Comput. Fluids 86 (2013) 28-36. I impleme...### Functionality to add/problem to solve
This implementation reduces the calculation error of interface curvature in interFoam and interIsoFoam. This implementation was reported by Hoang et al. Comput. Fluids 86 (2013) 28-36. I implemented this method. This implementation reduces the spurious current drastically.
This problem is also reported in issue https://develop.openfoam.com/Development/openfoam/-/issues/2479.
Especially in the case of interIsoFoam, this filter drastically reduces the velocity of spurious current. (Yamamoto and Komarov, Investigation for optimal use of VOF method in OpenFOAM, Proc. of OpenCAE Symposium 2021 (2021) The OpenCAE Society of Japan)
### Target audience
To who want to reduce the velocity of spurious current.
### Proposal
I attach the repair patch for $FOAM_SRC/transportModels/interfaceProperties/interfaceProperties.C and $FOAM_SRC/transportModels/interfaceProperties/interfaceProperties.H
[interfacePropertiesC.patch](/uploads/5a6c7b99dacee152468604dd5032d5a2/interfacePropertiesC.patch)
[interfacePropertiesH.patch](/uploads/f11b9dcc3f0faad3b3a8dcacf09f9a68/interfacePropertiesH.patch)
### What does success look like, and how can we measure that?
I simulated the static bubble in water. In this case, the spurious current is generated due to the imbalance of surface tension force. We attached the both case with and without smoother.
With smoother![wSmoother](/uploads/d8df39475df8e5684fc8d3845d153793/wSmoother.png)
Without smoother![woSmoother](/uploads/7aee58526a89677612c5e3c1aba17570/woSmoother.png)
### How to control the number of Laplacian filter
In system/fvSolution, one needs to add the following sentence (nSmooth) in addition to other parameters such as nAlphaCorr, nAlphaSubCycles.
> nAlphaCorr 5;
> nAlphaSubCycles 1;
> nSmooth 3;
The larger number of nSmooth smooths the original distribution of alpha. Therefore, too large nSmooth has possibility to worsen the calculation accuracy.
### Available solvers
When one uses this patch, the following solvers can use this smoother as an option.
* interFoam
* interIsoFoam
* overInterDyMFoam
* compressibleInterFoam
* compressibleInterDyMFoam
* compressibleInterIsoFoam
* overCompressibleInterDyMFoam
* compressibleInterFilmFoam
* interPhaseChangeFoamKutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1579improvements foamToEnsightParts2020-06-22T10:10:10ZMark OLESENimprovements foamToEnsightPartsCurrently foamToEnsight and foamToEnsightParts perform somewhat differently.
- foamToEnsight works in serial/parallel, but does not handle cellZones
- foamToEnsightParts handles cellZone, but only works in serial
Desirable to retain ce...Currently foamToEnsight and foamToEnsightParts perform somewhat differently.
- foamToEnsight works in serial/parallel, but does not handle cellZones
- foamToEnsightParts handles cellZone, but only works in serial
Desirable to retain cellZone information in parallel as well, which implies making foamToEnsightParts parallel-aware. Explore the possibility of merging some foamToEnsightParts aspects into ensightMesh (ie, foamToEnsight) and enabling/disabling on a switch.
Cross-ref: EP1109v2006Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1216Improvements for PDRFoam (solver and utilities)2019-12-17T10:04:01ZMark OLESENImprovements for PDRFoam (solver and utilities)@Sergio @pratap@Sergio @pratapMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1060improvements for topoSet2020-11-17T13:16:45ZMark OLESENimprovements for topoSet- need to distinguish between topoSetSource (CELL, FACE, POINT)
- support multiple zones, multiple patches
- keyword consistency (eg, centre vs origin)- need to distinguish between topoSetSource (CELL, FACE, POINT)
- support multiple zones, multiple patches
- keyword consistency (eg, centre vs origin)v1812Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/240Improvements to foamToEnsight*2021-01-27T10:52:08ZMark OLESENImprovements to foamToEnsight*During testing of issue #231 noticed that startup/conversion time (per step) to be dependent on the number of times-steps converted (foamToEnsight).
The per step conversion time for foamToEnsightParts is constant.
In serial, the writing ...During testing of issue #231 noticed that startup/conversion time (per step) to be dependent on the number of times-steps converted (foamToEnsight).
The per step conversion time for foamToEnsightParts is constant.
In serial, the writing times for foamToEnsight are generally much slower than foamToEnsightParts.
No comparison in parallel, since foamToEnsightParts is not yet parallelized.Version v1612Mark OLESENMark OLESEN2016-10-14https://develop.openfoam.com/Development/openfoam/-/issues/694Improvements to turbulence decay control2019-12-09T22:18:09ZAdminImprovements to turbulence decay controlAs noted here: https://develop.openfoam.com/Development/OpenFOAM-plus/commit/82a4b88c2fc06b9c45f0d21ca3da265acc8790f8#note_5497 by @hikassem the decay control code could benefit from a couple of updatesAs noted here: https://develop.openfoam.com/Development/OpenFOAM-plus/commit/82a4b88c2fc06b9c45f0d21ca3da265acc8790f8#note_5497 by @hikassem the decay control code could benefit from a couple of updatesAdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/2982improveMeshQuality: error in constrainedCellsSet command-line flag handling2023-09-18T09:02:28ZGerhard HolzingerimproveMeshQuality: error in constrainedCellsSet command-line flag handling<!--
*** 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 `constrainedCellSet` command line option does nothing.
Quite early in the main() method, the option for constrained cells is added to the list of options as shown below:
`argList::addOption("constrainedCellsSet", "word");`
Later, the passed arguments are checked for the option of constrained cells, as shown below:
```c
word constrainedCellSet;
if (!args.readIfPresent("constrainedCellSet", constrainedCellSet))
{
Info<< "No constraints applied on the smoothing procedure" << endl;
}
```
Unfortunately, there's a typo such that the option "constrainedCellsSet" is added to the command line options, however, later "constrainedCellSet" is checked against. Notice "constrainedCell**s**Set" vs. "constrainedCellSet".
Thus, the option to constrain cells currently does nothing, respectively can not be used.
### 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
-->
Even, when fixing the mis-matched strings, such that the option is actually checked, it still seems to do nothing.
Here's a mesh, where I created a boundary layer using snappyHexMesh, which created a cellSet named addedCells.
![before](/uploads/216bb81e58126869d7d70c0ffc7891fb/before.png)
When I run `improveMeshQuality -constrainedCellSet addedCells` the cells of the boundary layer are still part of the mesh smoothing.
Only the faces at the boundaries are unaffected.
![after](/uploads/6c294e73e29151cea59f9d8b6736c3be/after.png)
Maybe, this feature wasn't intended to protect whole cells from being smoothed.
### What is the current *bug* behaviour?
<!-- What actually happens -->
Running `improveMeshQuality -constrainedCellsSet addedCells` does nothing
Terminal output
```
...
Default number of surface iterations is 2
Using default quality threshold 0.1
No constraints applied on the smoothing procedure
Resizing points!
Starting creating cells
...
```
Running `improveMeshQuality -constrainedCellSet addedCells` leads to an error, since it's no valid option. However, that's what would later be checked in the case as it is now.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
I would expect that the cells of the passed cellSet are not affected by the smoothing operation, which is currently the case.
### 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 : v2306|v2212|v2206|v2112|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2306
- Operating system : ubuntu
- 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
-->
Match the strings in lines 59 and 96 in improveMeshQuality.C
``argList::addOption("constrainedCellsSet", "word");``
`if (!args.readIfPresent("constrainedCellSet", constrainedCellSet))`https://develop.openfoam.com/Development/openfoam/-/issues/909improve robustness of cmake targets2018-07-02T09:33:45ZMark OLESENimprove robustness of cmake targetsAs note as a [catalyst issue](https://develop.openfoam.com/Community/catalyst/issues/5) some failures if WM_OSTYPE is not set.
Transfer some of the configuration setup from there.As note as a [catalyst issue](https://develop.openfoam.com/Community/catalyst/issues/5) some failures if WM_OSTYPE is not set.
Transfer some of the configuration setup from there.v1806Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1830improve support for compiler/link options2020-09-08T08:00:48ZMark OLESENimprove support for compiler/link optionsAs discussed with @Mattijs would like to improve ease of using the gold linker.
Could leverage some changes made with #1671, but this create a different output directory (eg, linux64Gcc+goldDPInt32Opt). This is not only ugly, but potenti...As discussed with @Mattijs would like to improve ease of using the gold linker.
Could leverage some changes made with #1671, but this create a different output directory (eg, linux64Gcc+goldDPInt32Opt). This is not only ugly, but potential annoying when switching between gold and non-gold linkage.
The preferred solution would entail a new variable `WM_COMPILE_CONTROL` (working name) that would be funneled into the rules.
FYI: @andyMark OLESENMark OLESENhttps://develop.openfoam.com/Development/ThirdParty-common/-/issues/17improve support for non-system python locations2017-08-03T06:19:28ZMark OLESENimprove support for non-system python locationsMentioned in https://exchange.openfoam.com/node/424
@PrashantMentioned in https://exchange.openfoam.com/node/424
@PrashantMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/855Inaccurate radiation calculation2023-06-02T13:36:58ZAdminInaccurate radiation calculationI tried a validation problem with fvDOM on axisymmetric case. The example case is attached.
Radiative analytical heat flux from "hot" wall comes out to 260.9 kW/m2.
Axisymmetric test case under-predicts the heat flux (15% error) (wed...I tried a validation problem with fvDOM on axisymmetric case. The example case is attached.
Radiative analytical heat flux from "hot" wall comes out to 260.9 kW/m2.
Axisymmetric test case under-predicts the heat flux (15% error) (wedge patch)
Steps to reproduce:
1. Download the zip
2. Extract and execute Allrun (50 or 100 timestep entry is sufficient to analyze the issue)
3. Observe qr field on hot and cold patches in paraview
Is there a way to solve this problem?
Thanks in advance!
.[multiRegionHeaterRadiation.zip](/uploads/2e14f8503eb768712bc0a8c79ce00045/multiRegionHeaterRadiation.zip)https://develop.openfoam.com/Development/openfoam/-/issues/3112incidental allocations caused by profiling trigger2024-03-09T18:30:56ZMark OLESENincidental allocations caused by profiling triggerMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/666Include additional packs in foamConfigurePaths2017-12-21T16:02:06ZRoger AlmenarInclude additional packs in foamConfigurePathsSome packages are missing:
-KaHIP
-gperftoolsSome packages are missing:
-KaHIP
-gperftoolsv1712Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/3094include cloudFunction results in vtkCloud2024-02-02T15:21:59ZMark OLESENinclude cloudFunction results in vtkCloudIssue raised in [cfd-online](https://www.cfd-online.com/Forums/openfoam-post-processing/253820-write-cloudfunction-fields-vtk-during-runtime.html) - makes sense to also write things like Reynolds number etc.Issue raised in [cfd-online](https://www.cfd-online.com/Forums/openfoam-post-processing/253820-write-cloudfunction-fields-vtk-during-runtime.html) - makes sense to also write things like Reynolds number etc.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1587#include directive not working in snappyHexMeshDict with collated file handler2020-03-12T10:38:47ZMortesins#include directive not working in snappyHexMeshDict with collated file handler<!--
*** 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
The #include directive does not work properly inside snappyHexMeshDict when running with the collated file handler. It throws the following error:
```
[1] --> FOAM FATAL ERROR:
[1] Not implemented
[1]
[1] From function virtual Foam::Istream& Foam::ITstream::readRaw(char*, std::streamsize)
[1] in file db/IOstreams/Tstreams/ITstream.C at line 344.
```
### Steps to reproduce
1) Starting from the motorbike tutorial, move the refinementSurfaces settings to an external file. So the snappyHexMeshDict will look like this:
```
refinementSurfaces
{
#include "motorBikeRefinementDict"
}
```
and a new file called motorBikeRefinementDict should contain the following:
```
motorBike
{
// Surface-wise min and max refinement level
level (5 6);
// Optional specification of patch type (default is wall). No
// constraint types (cyclic, symmetry) etc. are allowed.
patchInfo
{
type wall;
inGroups (motorBikeGroup);
}
}
```
2) Change the file handler to be collated. NOTE: there is no issue with the uncollated format.
### Example case
I've attached:
[snappyHexMeshDict](/uploads/aae5cbd4178b3b0b076b4c285ccd861e/snappyHexMeshDict)
[motorBikeRefinementDict](/uploads/bc4dd73eba353d2d54bbe59faa5eae4f/motorBikeRefinementDict)
[controlDict](/uploads/787b9b9bbd556a2bc335126f5861187c/controlDict)
### What is the current *bug* behaviour?
Snappy crashes.
### What is the expected *correct* behavior?
The #include directive should be correctly parsed.
### Relevant logs and/or images
```
Create time
Overriding OptimisationSwitches according to controlDict
fileHandler (unregistered)
Overriding fileHandler to collated
I/O : collated (maxThreadFileBufferSize 0)
Threading not activated since maxThreadFileBufferSize = 0.
Writing may run slowly for large file sizes.
Create mesh for time = 0
Read mesh in = 0 s
Overall mesh bounding box : (-5 -4 0) (15 4 8)
Relative tolerance : 1e-06
Absolute matching distance : 2.29783e-05
[1]
[1]
[1] --> FOAM FATAL ERROR:
[1] Not implemented
[1]
[1] From function virtual Foam::Istream& Foam::ITstream::readRaw(char*, std::streamsize)
[1] in file db/IOstreams/Tstreams/ITstream.C at line 344.
[1]
FOAM parallel run aborting
[1]
[1] #0 Foam::error::printStack(Foam::Ostream&)Reading refinement surfaces.
Read refinement surfaces in = 0.33 s
Reading refinement shells.
Refinement level 4 for all cells inside refinementBox
Read refinement shells in = 0 s
Setting refinement level of surface to be consistent with shells.
at ??:?
[1] #1 Foam::error::abort() at ??:?
[1] #2 Foam::ITstream::readRaw(char*, long) at ??:?
[1] #3 Foam::readRawLabel(Foam::Istream&, int*, unsigned long) at ??:?
[1] #4 Foam::Istream& Foam::operator>><int, 2u>(Foam::Istream&, Foam::FixedList<int, 2u>&) at ??:?
[1] #5 Foam::refinementSurfaces::refinementSurfaces(Foam::searchableSurfaces const&, Foam::dictionary const&, int, bool) at ??:?
[1] #6 ? at ??:?
[1] #7 __libc_start_main in /lib64/libc.so.6
[1] #8 ? at ??:?
--------------------------------------------------------------------------
MPI_ABORT was invoked on rank 1 in communicator MPI_COMM_WORLD
with errorcode 1.
NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
You may or may not see output from other processes, depending on
exactly when Open MPI kills them.
--------------------------------------------------------------------------
```
### 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 : v1912
* Operating system : CentOS Linux 7
* Compiler : Gcc 4.8.5Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1740include in fvOption2020-06-22T14:36:16Zchristoph irrenfriedinclude in fvOption### Functionality to add/problem to solve
for automation purposes it would be convenient, if the "#include" would also be possible in the **fvOption** files
### Example
````c++
#include "${FOAM_CASE}/system/SetupDict"
momentumSource...### Functionality to add/problem to solve
for automation purposes it would be convenient, if the "#include" would also be possible in the **fvOption** files
### Example
````c++
#include "${FOAM_CASE}/system/SetupDict"
momentumSource
{
type meanVelocityForce;
selectionMode cellZone;
cellZone inletCellZone;
fields (U);
Ubar (0 $:BC.Uin 0); //<--- does not work!
}
````
The file **${FOAM_CASE}/system/SetupDict** reads:
````c++
/*--------------------------------*- C++ -*----------------------------------*\
| ========= | |
| \ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \ / O peration | @ Virtual Vehicle |
| \ / \ / A nd | Web: www.OpenFOAM.org |
| \/ \/ M anipulation | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
location "system";
object SetupDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
BC
{
Uin 0.060455;
}
````
Which causes the following error:
````c++
[0]
[1] [0]
[0] --> FOAM FATAL IO ERROR:
[0]
[1]
[1] --> FOAM FATAL IO ERROR:
[1] Entry 'type' not found in dictionary "IOstream.BC"
[1]
[1]
[1] file: [2]
[2]
Entry 'type' not found in dictionary "/data/P2P/channel_v01_3/system/fvOptions.BC"
[0]
[0]
[0] file: /data/P2P/channel_v01_3/system/fvOptions.BC
[0]
[0] From function bool Foam::dictionary::readEntry(const Foam::word&, T&, Foam::keyType::
option, bool) const [with T = Foam::word]
[0] in file [2] --> FOAM FATAL IO ERROR:
[2] Entry 'type' not found in dictionary "IOstream.BC"
IOstream.BC
[1]
[1] From function bool Foam::dictionary::readEntry(const Foam::word&, T&, Foam::keyType::
option, bool) const [with T = Foam::word]
[1] /software/OpenFOAM/OpenFOAM-v1912/src/OpenFOAM/lnInclude/dictionaryTemplates.C at line 33
4.
[0]
FOAM parallel run exiting
[0] [3]
[3]
[3] --> FOAM FATAL IO ERROR:
[3] Entry 'type' not found in dictionary "IOstream.BC"
[3]
[3]
[3] file: in file /software/OpenFOAM/OpenFOAM-v1912/src/OpenFOAM/lnInclude/dictionaryTemp
lates.C at line 334.
[1]
FOAM parallel run exiting
[1]
[2]
[2]
[2] file: IOstream.BC
[2]
[2] From function bool Foam::dictionary::readEntry(const Foam::word&, T&, Foam::keyType::
option, bool) const [with T = Foam::word]
[2] in file /software/OpenFOAM/OpenFOAM-v1912/src/OpenFOAM/lnInclude/dictionaryTemplates.
C at line 334.
[2]
FOAM parallel run exiting
[2]
IOstream.BC
[3]
[3] From function bool Foam::dictionary::readEntry(const Foam::word&, T&, Foam::keyType::
option, bool) const [with T = Foam::word]
[3] in file /software/OpenFOAM/OpenFOAM-v1912/src/OpenFOAM/lnInclude/dictionaryTemplates.
C at line 334.
[3]
FOAM parallel run exiting
[3]
--------------------------------------------------------------------------
MPI_ABORT was invoked on rank 1 in communicator MPI_COMM_WORLD
with errorcode 1.
NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
You may or may not see output from other processes, depending on
exactly when Open MPI kills them.
--------------------------------------------------------------------------
````
If I hard code the value for Ubar it works!
https://develop.openfoam.com/Development/openfoam/-/issues/2366include json in openfoam dictionaries2022-03-03T20:21:56ZHenning Scheuflerinclude json in openfoam dictionaries@mark
@kuti
Hi,
I created a functionEntry that allows embedding jsons in OpenFOAM dicts
https://github.com/HenningScheufler/ofjson
## Usage
```
#json "<case>/test.json";
```
cat test.json:
```json
{
"string": "string",
...@mark
@kuti
Hi,
I created a functionEntry that allows embedding jsons in OpenFOAM dicts
https://github.com/HenningScheufler/ofjson
## Usage
```
#json "<case>/test.json";
```
cat test.json:
```json
{
"string": "string",
"istream": "istream;",
"label": 10,
"scalar": 10.1,
"vector": [1.1, 2.2, 3.3],
"subDict": {
"sub_string": "string",
"sub_istream": "istream;",
"sub_label": 10,
"sub_scalar": 10.1
},
"scalarField": {
"type": "scalarField",
"value": [1.1, 2.2, 3.3, 4.4]
}
}
```
The standard OpenFOAM access patterns apply:
```
{
$string; // would return string
$scalar; // would return 10.1
}
```
Kind Regards,
Henninghttps://develop.openfoam.com/Development/openfoam/-/issues/369Incomplete cleanup of paraview environment2019-12-09T21:29:26ZMark OLESENIncomplete cleanup of paraview environment* LD_LIBRARY_PATH is not being cleaned at all when switching between paraview versions.
* PATH is being cleaned against the third-party `paraview-*`, although 3rd party paraview is installed as `ParaView-*`. The additional cleanup for Pa...* LD_LIBRARY_PATH is not being cleaned at all when switching between paraview versions.
* PATH is being cleaned against the third-party `paraview-*`, although 3rd party paraview is installed as `ParaView-*`. The additional cleanup for ParaView_DIR may not catch this (if it was unset elsewhere).Mark OLESENMark OLESEN2017-01-06https://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çin