Development issueshttps://develop.openfoam.com/groups/Development/-/issues2022-04-26T16:11:08Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1168injectionModels: inconsistent keyword: UMag/Umag2022-04-26T16:11:08ZPrashant SonakarinjectionModels: inconsistent keyword: UMag/UmagconeNozzle injection seem to require UMag, while rest models need Umag.coneNozzle injection seem to require UMag, while rest models need Umag.v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2216interCondensatingEvaporatingFoam: interfaceHeatResistance model failing for c...2021-10-29T07:57:20ZMoritz MuthinterCondensatingEvaporatingFoam: interfaceHeatResistance model failing for condensation cases### Summary
I initialized a stefans problem case inside a rectangular domain with a small liquid film on the bottom wall and a vapour phase above the film. The film was set to a temperature 10K below the saturation temperature while the ...### Summary
I initialized a stefans problem case inside a rectangular domain with a small liquid film on the bottom wall and a vapour phase above the film. The film was set to a temperature 10K below the saturation temperature while the vapour was at saturation temperature. The phase change model used was the interfaceHeatResistance model. The top wall is hot and the bottom wall cold, gravity is off. Condensation should appear and the film should grow, while the evaporation massflux should be zero.
The condensation mass flux, which can be viewed in ParaView, seems to produce the correct value but there is also an evaporation mass flux, which is none zero. Also there is a strange behavior within the interface area calculation, which seems to randomly add parts of the walls. If i reversed the temperature setting and looked at an evaporation case the right behavior with growing vapour phase occurred.
### Steps to reproduce
Run the attached testcase, look at the mass fluxes and alpha-field in ParaView, especially at the interface.
### Example case
The example case is attached. [Example_case.zip](/uploads/4b1b23eb3154eb27a9cb0ac217df36e5/Example_case.zip)
### What is the current *bug* behaviour?
The solver produces an evaporation mass flux which isn't set to zero for a condensation case (T < Tsat). For information: In the reversed case (evaporation) the condensation mass flux is set to zero. Also the solver uses an wrong interface area with parts of the side walls.
### What is the expected *correct* behavior?
The evaporation mass flux should be set to zero in the case of a condensation case. And the liquid film should grow depending on the analytic solution for the Stefans problem. The interface area, which the solver uses, should only be the interface between the liquid and the vapour phase.https://develop.openfoam.com/Development/openfoam/-/issues/3115interFaceHeight not writing header information2024-03-12T07:45:18ZGuillén Campaña AlonsointerFaceHeight not writing header informationThe functionObject interfaceHeight does not write the header information.
To solve it the following lines should be added to the constructor:
if (Pstream::master())
{
writeFileHeader(fileID::heightFile);
writeFi...The functionObject interfaceHeight does not write the header information.
To solve it the following lines should be added to the constructor:
if (Pstream::master())
{
writeFileHeader(fileID::heightFile);
writeFileHeader(fileID::positionFile);
}Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2008Interfacial Composition Model formulation2021-07-09T16:06:52ZHamidreza NorouziInterfacial Composition Model formulation<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
The problem is related to the phase equilibrium formulation in reactingEulerFoam...<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
The problem is related to the phase equilibrium formulation in reactingEulerFoam. The phase equilibrium for saturated and NRTL models are defined based on the mole-fraction while the solver uses mass fraction basis for its calculations.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
### Example case
in file src/phaseSystemModels/reactingEulerFoam/interfacialCompositionModels/interfaceCompositionModels/NonRandomTwoLiquid/NonRandomTwoLiquid.C
Line 208 or 215, the code uses the following equation to calculate specie mass fraction in the vapor phase (Yf) :
return
this->otherThermo_.composition().Y(speciesName)
*speciesModel1_->Yf(speciesName, Tf)
*gamma1_;
the correct equilibrium based on activity model is based on the mole fraction in pahses:
gamma_i * x_i Ps = y_i * P (Eq. 1)
where both y_i and x_i are mole fraction of component i in liquid and vapor phase.
In the code, the mole fraction of the vapor phase is converted to the mass fraction (the return value of Yf method) when we use speciesModel1_->Yf(speciesName, Tf), since in that method the return value is multiplied by Wi/W. However, the conversion of liquid phase mass fraction (otherThermo_.composition().Y(speciesName)) to mole fraction dose not occur. the correct form of the return value is
return
this->otherThermo_.composition().Y(speciesName)
* otherThermo_.composition().W
/ otherThermo_.composition().Wi(species1Index_)
*speciesModel1_->Yf(speciesName, Tf)
*gamma1_;
<!--
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 -->
### 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 : v2006 | V2012 etc
Operating system : ubuntu
Hardware info : AMD threadripper
Compiler : gcc
### Possible fixes
in file src/phaseSystemModels/reactingEulerFoam/interfacialCompositionModels/interfaceCompositionModels/NonRandomTwoLiquid/NonRandomTwoLiquid.C
Line 208 should be changed to
dimensionedScalar Wi (
"Wi",
dimMass/dimMoles,
otherThermo_.composition().Wi(species1Index_)
);
return
this->otherThermo_.composition().Y(speciesName)
* otherThermo_.composition().W /Wi
*speciesModel1_->Yf(speciesName, Tf)
*gamma1_;
Line 215 should be changed to
dimensionedScalar Wi (
"Wi",
dimMass/dimMoles,
otherThermo_.composition().Wi(species2Index_)
);
return
this->otherThermo_.composition().Y(speciesName)
* otherThermo_.W() / Wi
*speciesModel2_->Yf(speciesName, Tf)
*gamma2_;Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2182interFoam for wave simulation fails in Debug but not in Opt2021-10-27T12:49:23ZValerio GraziosointerFoam for wave simulation fails in Debug but not in Opt<!--
*** 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 -->
When running a wave tank simulation with interFoam, if using openfoam compiled with WM_COMPILE_OPTION=Opt everything is ok. When using openfoam compiled with WM_COMPILE_OPTION=Debug the simulation crashes during the first timestep
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
1) run Allrun script (mesh preparation)
2) run the attached case with "interFoam" with openfoam v2106 (verified also for v1812) compiled with WM_COMPILE_OPTION=Debug
### 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 attachment
### What is the current *bug* behaviour?
<!-- What actually happens -->
The code crashes
### What is the expected *correct* behavior?
<!-- What you should see instead -->
It should run until Time=25
### 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.
-->
```
/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: v2106 |
| \\ / A nd | Website: www.openfoam.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : _c15bfde3cb-20210624 OPENFOAM=2106
Arch : "LSB;label=32;scalar=64"
Exec : interFoam
Date : Aug 16 2021
Time : 03:23:02
Host : valerio-Z370-HD3P
PID : 190691
I/O : uncollated
Case : ~/OpenFOAM/Tanks/2021/RobustControl/Hemisphere_WEC/40N
nProcs : 1
trapFpe: Floating point exception trapping enabled (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster (fileModificationSkew 5, maxFileModificationPolls 20)
allowSystemOperations : Allowing user-supplied system call operations
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time
Create mesh for time = 0
Selecting dynamicFvMesh dynamicMotionSolverFvMesh
Selecting motion solver: sixDoFRigidBodyMotion
Applying solid body motion to entire mesh
Selecting sixDoFSolver Newmark
Translational constraint tensor (0 0 0 0 0 0 0 0 1)
Rotational constraint tensor (0 0 0 0 0 0 0 0 0)
PIMPLE: Operating solver in PISO mode
Reading field p_rgh
Reading field U
Reading/calculating face flux field phi
Reading transportProperties
Selecting incompressible transport model Newtonian
Selecting incompressible transport model Newtonian
Selecting turbulence model type laminar
Selecting laminar stress model Stokes
Reading g
Reading hRef
Calculating field g.h
No MRF models present
No finite volume options present
GAMGPCG: Solving for pcorr, Initial residual = 0, Final residual = 0, No Iterations 0
GAMGPCG: Solving for pcorr, Initial residual = 0, Final residual = 0, No Iterations 0
GAMGPCG: Solving for pcorr, Initial residual = 0, Final residual = 0, No Iterations 0
time step continuity errors : sum local = 0, global = 0, cumulative = 0
Constructing face velocity Uf
Courant Number mean: 0 max: 0
Starting time loop
forces forces:
rho: rhoInf
Freestream density (rhoInf) set to 1000
Not including porosity effects
Courant Number mean: 0 max: 0
Interface Courant Number mean: 0 max: 0
Time = 0.001
PIMPLE: iteration 1
forces forces:
rho: rho
Not including porosity effects
Restraint Spring: attachmentPt - anchor (0 0 2.678) spring length 2.678 force (-0 -0 -16.0364)
Restraint PTO: attachmentPt - anchor (0 0 2.678) spring length 2.678 control force (0 0 0.0024) control force raw0.0024 nTimes4
6-DoF rigid body motion
Centre of rotation: (0 0 -0.131)
Centre of mass: (0 0 -0.131)
Orientation: (1 0 0 0 1 0 0 0 1)
Linear velocity: (0 0 -1.46985e-05)
Angular velocity: (0 0 0)
Selecting waveModel shallowWaterAbsorption
--> FOAM FATAL ERROR: (openfoam-2106)
Field<vector> f1(5085) and Field<vector> f2(0)
for operation f1 = s & f2
From void Foam::checkFields(const Foam::UList<T>&, const Foam::UList<Key>&, const char*) [with Type1 = Foam::Vector<double>; Type2 = Foam::Vector<double>]
in file ~/OpenFOAM/OpenFOAM-v2106/src/OpenFOAM/lnInclude/FieldM.H at line 58.
FOAM aborting
#0 Foam::error::printStack(Foam::Ostream&) at ~/OpenFOAM/OpenFOAM-v2106/src/OSspecific/POSIX/printStack/printStack.C:237
#1 Foam::error::exitOrAbort(int, bool) at ~/OpenFOAM/OpenFOAM-v2106/src/OpenFOAM/lnInclude/error.C:261
#2 Foam::error::abort() at ~/OpenFOAM/OpenFOAM-v2106/src/OpenFOAM/lnInclude/error.C:297
#3 Foam::Ostream& Foam::operator<< <Foam::error>(Foam::Ostream&, Foam::errorManip<Foam::error>) in ~/OpenFOAM/OpenFOAM-v2106/platforms/linux64GccDPInt32Debug/bin/interFoam
#4 void Foam::checkFields<Foam::Vector<double>, Foam::Vector<double> >(Foam::UList<Foam::Vector<double> > const&, Foam::UList<Foam::Vector<double> > const&, char const*) in ~/OpenFOAM/OpenFOAM-v2106/platforms/linux64GccDPInt32Debug/bin/interFoam
#5 void Foam::dot<Foam::Tensor<double>, double, (unsigned char)9, Foam::Vector<double> >(Foam::Field<Foam::innerProduct<Foam::Tensor<double>, Foam::Vector<double> >::type>&, Foam::VectorSpace<Foam::Tensor<double>, double, (unsigned char)9> const&, Foam::UList<Foam::Vector<double> > const&) at ~/OpenFOAM/OpenFOAM-v2106/src/OpenFOAM/lnInclude/FieldFunctions.C:827
#6 Foam::tmp<Foam::Field<Foam::innerProduct<Foam::Tensor<double>, Foam::Vector<double> >::type> > Foam::operator&<Foam::Tensor<double>, double, (unsigned char)9, Foam::Vector<double> >(Foam::VectorSpace<Foam::Tensor<double>, double, (unsigned char)9> const&, Foam::UList<Foam::Vector<double> > const&) at ~/OpenFOAM/OpenFOAM-v2106/src/OpenFOAM/lnInclude/FieldFunctions.C:827
#7 Foam::waveModel::initialiseGeometry() at ~/OpenFOAM/OpenFOAM-v2106/src/waveModels/waveModel/waveModel.C:94 (discriminator 1)
#8 Foam::waveModel::readDict(Foam::dictionary const&) at ~/OpenFOAM/OpenFOAM-v2106/src/waveModels/waveModel/waveModel.C:323 (discriminator 2)
#9 Foam::waveModels::waveAbsorptionModel::readDict(Foam::dictionary const&) at ~/OpenFOAM/OpenFOAM-v2106/src/waveModels/waveAbsorptionModels/base/waveAbsorptionModel/waveAbsorptionModel.C:80
#10 Foam::waveModels::shallowWaterAbsorption::readDict(Foam::dictionary const&) at ~/OpenFOAM/OpenFOAM-v2106/src/waveModels/waveAbsorptionModels/derived/shallowWaterAbsorption/shallowWaterAbsorption.C:115
#11 Foam::waveModels::shallowWaterAbsorption::shallowWaterAbsorption(Foam::dictionary const&, Foam::fvMesh const&, Foam::polyPatch const&, bool) at ~/OpenFOAM/OpenFOAM-v2106/src/waveModels/waveAbsorptionModels/derived/shallowWaterAbsorption/shallowWaterAbsorption.C:104
#12 Foam::waveModel::addpatchConstructorToTable<Foam::waveModels::shallowWaterAbsorption>::New(Foam::dictionary const&, Foam::fvMesh const&, Foam::polyPatch const&) at ~/OpenFOAM/OpenFOAM-v2106/src/waveModels/lnInclude/waveModel.H:184 (discriminator 2)
#13 Foam::waveModel::New(Foam::word const&, Foam::fvMesh const&, Foam::polyPatch const&) at ~/OpenFOAM/OpenFOAM-v2106/src/waveModels/waveModel/waveModelNew.C:81
#14 Foam::waveModel::lookupOrCreate(Foam::polyPatch const&, Foam::fvMesh const&, Foam::word const&) at ~/OpenFOAM/OpenFOAM-v2106/src/waveModels/waveModel/waveModelNew.C:98 (discriminator 1)
#15 Foam::waveVelocityFvPatchVectorField::updateCoeffs() at ~/OpenFOAM/OpenFOAM-v2106/src/waveModels/derivedFvPatchFields/waveVelocity/waveVelocityFvPatchVectorField.C:112
#16 Foam::fvPatchField<Foam::Vector<double> >::evaluate(Foam::UPstream::commsTypes) at ~/OpenFOAM/OpenFOAM-v2106/src/finiteVolume/lnInclude/fvPatchField.C:340
#17 Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>::Boundary::evaluate() in ~/OpenFOAM/OpenFOAM-v2106/platforms/linux64GccDPInt32Debug/bin/interFoam
#18 Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>::correctBoundaryConditions() in ~/OpenFOAM/OpenFOAM-v2106/platforms/linux64GccDPInt32Debug/bin/interFoam
#19 Foam::dynamicMotionSolverFvMesh::update() at ~/OpenFOAM/OpenFOAM-v2106/src/dynamicFvMesh/dynamicMotionSolverFvMesh/dynamicMotionSolverFvMesh.C:135
#20 ? in ~/OpenFOAM/OpenFOAM-v2106/platforms/linux64GccDPInt32Debug/bin/interFoam
#21 __libc_start_main in /lib/x86_64-linux-gnu/libc.so.6
#22 ? in ~/OpenFOAM/OpenFOAM-v2106/platforms/linux64GccDPInt32Debug/bin/interFoam
```
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906|v1912|v2006|v2012|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :v1812 | v2106
- Operating system :ubuntu (mint)
- Hardware info :Intel i7
- Compiler :gcc
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->
It seems that the inner product vector * tensor ,fails a dimension check because the second operand (tensor) is "seen" with 0 dimension, while it is not. Maybe a problem with the template for the double type in the Debug case??[WaveTank_s.tar.gz](/uploads/1bce0558586853ce59222151f8476815/WaveTank_s.tar.gz)Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2297interFoam problems with refinement at fluid surface2023-03-02T12:26:19ZHans MeierinterFoam problems with refinement at fluid surface<!--
*** 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
-->
### Summary
When running an interFoam case with two phases (water and air) with a refinement that crosses the surface as shown in picture 3, immediately after start a strange "explosion" like "dynamite fishing" occurs one cell above the surface within the refined cells along the refinement boundary, see picture 4.
The case has been derived from tutorials/multiphase/interFoam/RAS/floatingObject, simplified (no floating body any more, no water in the corner to fall into the basin at start), and modified with the said refinement.
A workaround for this simple case is to avoid local z-refinements close to the water surface.
But if I add a complex floating body with snappyHexMesh in a much larger case, this inescapably leads to refinements close to the surface resulting in high velocities in the smallest cells and thus high courant numbers. The only workaround is to add an initial calm down phase before the real action starts, but this obviously eats up a lot of CPU time.
### Steps to reproduce
Run the example case with openFoam 2106. In allrun script different refinements may be selected by commenting/uncommenting: "none" (leading to pictures 1&2), "center" (leading to pictures 3&4), "block" and "all".
Refinement "center" is pre-selected.
### Example case
[refinement-issue.tbz](/uploads/a3f0dfffc5ec8d5df4d2bc14bef1e362/refinement-issue.tbz)
### What is the current *bug* behaviour?
We get U values other than (close to) zero in cells one cell above the surface within the refined cells along the refinement boundary causing something that looks like a compression wave spreading from there. See Picture 4.
### What is the expected *correct* behavior?
Nothing happens. Picture 4 should be all blue just as Picture 2.
### Relevant logs and/or images
![alpha.0009](/uploads/26289c7e277d05e191cc2fdb0a311802/alpha.0009.png)
Picture 1: Cells and alpha.water with non-refined mesh.
![U.0009](/uploads/ee1fe33304bb9ee4737b560f64589507/U.0009.png)
Picture 2: U values after 0.1s - nothing happens as expected.
![alpha.0000](/uploads/ec62aea9637df72d0c4782fec47a840f/alpha.0000.png)
Picture 3: Cells and alpha.water with refined mesh.
![U.0008](/uploads/1f85eef5c40a543f7f31ddbfd6f87f4d/U.0008.png)
Picture 4: U values after 0.1s - High U values up to 2 m/s in cells one cell above water surface along the boundary of refinement.
### Environment information
- OpenFOAM version : 2106 (docker image opencfd/openfoam2106-run)
- Operating system : Ubuntu 20.04.3 LTS
### Possible fixes
None yet.https://develop.openfoam.com/Development/openfoam/-/issues/1014intertia of triangle returns full tensor (instead of symmetric one)2022-04-26T16:11:09ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comintertia of triangle returns full tensor (instead of symmetric one)v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/ThirdParty-common/-/issues/67Introducing MUI code coupling library into OpenFOAM2024-03-27T16:38:12ZWendi LiuIntroducing MUI code coupling library into OpenFOAM## Functionality to add/problem to solve
Integrate the code coupling library [Multiscale Universal Interface](https://mxui.github.io/) in OpenFOAM as a third-party library to couple OpenFOAM with other solvers or OpenFOAM with itself.
...## Functionality to add/problem to solve
Integrate the code coupling library [Multiscale Universal Interface](https://mxui.github.io/) in OpenFOAM as a third-party library to couple OpenFOAM with other solvers or OpenFOAM with itself.
## Target audience
Users who want to couple OpenFOAM with other solvers or OpenFOAM with itself.
## Proposal
A working general integration of MUI is proposed by applying the following patch to the ThirdParty repository.
[muiIntegrationTP.patch](/uploads/9b0637fcc8137a818b65f31875d6e40f/muiIntegrationTP.patch)
Below is a summarise of what have been added and modified.
- Modified `Allwmake` to include script to build MUI.
- Added build script `makeMUI.`
- Added MUI related patch file `etc/patches/MUI-2.0` to resolve ambiguity issue between MUI-v2.0 and OpenFOAM. We have merged the changes into the MUI repository, so that no patch files will be needed in future MUI releases.
- Updated `BUILD.md` and `SOURCES.md` to include MUI related documentations.
## Related issue
[openfoam issue #3127](https://develop.openfoam.com/Development/openfoam/-/issues/3127)
## What does success look like, and how can we measure that?
The Patch has been tested with the ThirdParty development repository (commit 7ff69fa1a733b45b069a387fd0c275b15b7f2150).
The proposed changes can be patched and tested as follows
- Clone Development Repositories
```
git clone https://develop.openfoam.com/Development/ThirdParty-common.git
git clone https://develop.openfoam.com/Development/openfoam.git
```
- Obtain the MUI source file in the ThirdParty Repository
```
cd ThirdParty-common/sources
mkdir mui && cd mui
wget https://github.com/MxUI/MUI/archive/refs/tags/2.0.tar.gz
tar -xf 2.0.tar.gz && rm 2.0.tar.gz
```
- Obtain and place patches in Repositories
- Patch
```
cd openfoam/
patch -p2 < muiIntegrationOF.patch
rm muiIntegrationOF.patch
cd ../ThirdParty-common/
patch -p2 < muiIntegrationTP.patch
rm muiIntegrationTP.patch
```
- Change permission of newly added files if needed
- Enable MUI support (MUI is disabled by default)
- Modify L37 of `openfoam/etc/config.sh` to change `mui_version=MUI-none` into `mui_version=MUI-2.0`
- Source and Allwmake
```
cd openfoam/
source etc/bashrc
./Allwmake -j 4
```
- Test MUI enabled OpenFOAM
```
cd openfoam/applications/test/coupling-MUI
./testCase/Allrun
cd openfoam/tutorials/basic/laplacianFoamMUI
./AllrunCoupled
```
If MUI library successfully integrated, the following log messages can be found for the `coupling-MUI` unit test.
```
...
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time
Create mesh for time = 0
```
If MUI library successfully integrated, the following log messages can be found for the `laplacianFoamMUI` tutorial.
```
....
MUI [lib_mpi_multidomain]: Rank: 2, "domain2" registered interface "interface_twoD_1" as 59a4e385
MUI [lib_mpi_multidomain]: Rank: 3, "domain2" registered interface "interface_twoD_1" as 59a4e385
MUI Info [lib_mpi_multidomain]: 1 distinct interface(s) found
MUI [lib_mpi_multidomain]: Setting up interface interface_twoD_1 [59a4e385] (rank ids are local to each interface)
MUI [comm_mpi.h]: Rank: 3, Identifier: mpi://domain2/interface_twoD_1, Domain size: 2, Peers: 2
MUI [comm_mpi.h]: Rank: 2, Identifier: mpi://domain2/interface_twoD_1, Domain size: 2, Peers: 2
MUI [comm_mpi.h]: Rank: 1, Identifier: mpi://domain1/interface_twoD_1, Domain size: 2, Peers: 2
MUI [comm_mpi.h]: Rank: 0, Identifier: mpi://domain1/interface_twoD_1, Domain size: 2, Peers: 2
MUI [lib_mpi_multidomain]: Rank: 2, "domain2" registered interface "interface_threeD_1" as 31f80b7e
MUI [lib_mpi_multidomain]: Rank: 1, "domain1" registered interface "interface_threeD_1" as 31f80b7e
MUI [lib_mpi_multidomain]: Rank: 3, "domain2" registered interface "interface_threeD_1" as 31f80b7e
MUI [lib_mpi_multidomain]: Rank: 0, "domain1" registered interface "interface_threeD_1" as 31f80b7e
MUI Info [lib_mpi_multidomain]: 1 distinct interface(s) found
MUI [lib_mpi_multidomain]: Setting up interface interface_threeD_1 [31f80b7e] (rank ids are local to each interface)
MUI [comm_mpi.h]: Rank: 0, Identifier: mpi://domain1/interface_threeD_1, Domain size: 2, Peers: 2
MUI [comm_mpi.h]: Rank: 3, Identifier: mpi://domain2/interface_threeD_1, Domain size: 2, Peers: 2
MUI [comm_mpi.h]: Rank: 2, Identifier: mpi://domain2/interface_threeD_1, Domain size: 2, Peers: 2
MUI [comm_mpi.h]: Rank: 1, Identifier: mpi://domain1/interface_threeD_1, Domain size: 2, Peers: 2
MUI [lib_mpi_multidomain]: Rank: 2, "domain2" registered interface "interface_T_1" as 4a5523ab
MUI [lib_mpi_multidomain]: Rank: 1, "domain1" registered interface "interface_T_1" as 4a5523ab
MUI [lib_mpi_multidomain]: Rank: 0, "domain1" registered interface "interface_T_1" as 4a5523ab
MUI [lib_mpi_multidomain]: Rank: 3, "domain2" registered interface "interface_T_1" as 4a5523ab
MUI Info [lib_mpi_multidomain]: 1 distinct interface(s) found
MUI [lib_mpi_multidomain]: Setting up interface interface_T_1 [4a5523ab] (rank ids are local to each interface)
MUI [comm_mpi.h]: Rank: 0, Identifier: mpi://domain1/interface_T_1, Domain size: 2, Peers: 2
MUI [comm_mpi.h]: Rank: 1, Identifier: mpi://domain1/interface_T_1, Domain size: 2, Peers: 2
MUI [comm_mpi.h]: Rank: 3, Identifier: mpi://domain2/interface_T_1, Domain size: 2, Peers: 2
MUI [comm_mpi.h]: Rank: 2, Identifier: mpi://domain2/interface_T_1, Domain size: 2, Peers: 2
Calculating temperature distribution
Calculating temperature distribution
Time = 0.005
Time = 0.005
MUI interface "domain1"/"interface_twoD_1" value committed: 1 at Iteration = 0
MUI interface "domain2"/"interface_twoD_1" value committed: 1 at Iteration = 0
MUI interface "domain1"/"interface_threeD_1" value committed: 2 at Iteration = 0
MUI interface "domain1"/"interface_T_1" value committed: 3 at Iteration = 0
MUI interface "domain2"/"interface_threeD_1" value committed: 2 at Iteration = 0
MUI interface "domain2"/"interface_T_1" value committed: 3 at Iteration = 0
DICPCG: Solving for T, Initial residual = 1, Final residual = 8.33243e-07, No Iterations 7
DICPCG: Solving for T, Initial residual = 0.00446911, Final residual = 7.14892e-07, No Iterations 4
DICPCG: Solving for T, Initial residual = 0.000148123, Final residual = 6.63323e-07, No Iterations 2
MUI interface "domain1"/"interface_twoD_1" value fetched: 1 at Iteration = 0
MUI interface "domain1"/"interface_threeD_1" value fetched: 2 at Iteration = 0
MUI interface "domain1"/"interface_T_1" value fetched: 3 at Iteration = 0
ExecutionTime = 0.07 s ClockTime = 0 s
Time = 0.01
MUI interface "domain1"/"interface_twoD_1" value committed: 1 at Iteration = 1
MUI interface "domain1"/"interface_threeD_1" value committed: 2 at Iteration = 1
MUI interface "domain1"/"interface_T_1" value committed: 3 at Iteration = 1
DICPCG: Solving for T, Initial residual = 0.203755, Final residual = 1.57027e-07, No Iterations 7
DICPCG: Solving for T, Initial residual = 0.00184337, Final residual = 2.32416e-07, No Iterations 4
DICPCG: Solving for T, Initial residual = 1, Final residual = 8.33243e-07, No Iterations 7
DICPCG: Solving for T, Initial residual = 5.70921e-05, Final residual = 2.8776e-07, No Iterations 2
DICPCG: Solving for T, Initial residual = 0.00446911, Final residual = 7.14892e-07, No Iterations 4
DICPCG: Solving for T, Initial residual = 0.000148123, Final residual = 6.63323e-07, No Iterations 2
MUI interface "domain2"/"interface_twoD_1" value fetched: 1 at Iteration = 0
MUI interface "domain2"/"interface_threeD_1" value fetched: 2 at Iteration = 0
MUI interface "domain2"/"interface_T_1" value fetched: 3 at Iteration = 0
ExecutionTime = 0.1 s ClockTime = 0 s
Time = 0.01
MUI interface "domain2"/"interface_twoD_1" value committed: 1 at Iteration = 1
MUI interface "domain2"/"interface_threeD_1" value committed: 2 at Iteration = 1
MUI interface "domain2"/"interface_T_1" value committed: 3 at Iteration = 1
MUI interface "domain1"/"interface_twoD_1" value fetched: 1 at Iteration = 1
MUI interface "domain1"/"interface_threeD_1" value fetched: 2 at Iteration = 1
MUI interface "domain1"/"interface_T_1" value fetched: 3 at Iteration = 1
ExecutionTime = 0.08 s ClockTime = 0 s
Time = 0.015
MUI interface "domain1"/"interface_twoD_1" value committed: 1 at Iteration = 2
MUI interface "domain1"/"interface_threeD_1" value committed: 2 at Iteration = 2
MUI interface "domain1"/"interface_T_1" value committed: 3 at Iteration = 2
DICPCG: Solving for T, Initial residual = 0.109922, Final residual = 4.92455e-07, No Iterations 6
DICPCG: Solving for T, Initial residual = 0.00104616, Final residual = 7.0666e-07, No Iterations 3
DICPCG: Solving for T, Initial residual = 3.13839e-05, Final residual = 1.66653e-07, No Iterations 2
DICPCG: Solving for T, Initial residual = 0.203755, Final residual = 1.57027e-07, No Iterations 7
DICPCG: Solving for T, Initial residual = 0.00184337, Final residual = 2.32416e-07, No Iterations 4
DICPCG: Solving for T, Initial residual = 5.70921e-05, Final residual = 2.8776e-07, No Iterations 2
MUI interface "domain2"/"interface_twoD_1" value fetched: 1 at Iteration = 1
MUI interface "domain2"/"interface_threeD_1" value fetched: 2 at Iteration = 1
MUI interface "domain2"/"interface_T_1" value fetched: 3 at Iteration = 1
ExecutionTime = 0.11 s ClockTime = 1 s
Time = 0.015
MUI interface "domain2"/"interface_twoD_1" value committed: 1 at Iteration = 2
MUI interface "domain2"/"interface_threeD_1" value committed: 2 at Iteration = 2
MUI interface "domain2"/"interface_T_1" value committed: 3 at Iteration = 2
DICPCG: Solving for T, Initial residual = 0.109922, Final residual = 4.92455e-07, No Iterations 6
MUI interface "domain1"/"interface_twoD_1" value fetched: 1 at Iteration = 2
MUI interface "domain1"/"interface_threeD_1" value fetched: 2 at Iteration = 2
MUI interface "domain1"/"interface_T_1" value fetched: 3 at Iteration = 2
ExecutionTime = 0.1 s ClockTime = 1 s
...
```https://develop.openfoam.com/Development/openfoam/-/issues/3127Introducing MUI code coupling library into OpenFOAM2024-03-28T11:36:24ZWendi LiuIntroducing MUI code coupling library into OpenFOAM## Functionality to add/problem to solve
Integrate the code coupling library [Multiscale Universal Interface](https://mxui.github.io/) in OpenFOAM as a third-party library to couple OpenFOAM with other solvers or OpenFOAM with itself.
...## Functionality to add/problem to solve
Integrate the code coupling library [Multiscale Universal Interface](https://mxui.github.io/) in OpenFOAM as a third-party library to couple OpenFOAM with other solvers or OpenFOAM with itself.
## Target audience
Users who want to couple OpenFOAM with other solvers or OpenFOAM with itself.
## Proposal
A working general integration of MUI is proposed by applying the following patch to the OpenFOAM repository.
[muiIntegrationOF.patch](/uploads/5522d607255cbd8e128d9e1e860ef0b4/muiIntegrationOF.patch)
Below is a summarise of what have been added and modified.
- Configure MUI inclusion in OpenFOAM.
* Added MUI related commands in the following files
+ `bin/tools/foamConfigurePaths`
+ `etc/config.csh/functions`
+ `etc/config.csh/setup`
+ `etc/config.csh/unset`
+ `etc/config.sh/functions`
+ `etc/config.sh/setup`
+ `etc/config.sh/unset`
* Created the following files to setup MUI include through ThirdParty installation. These files also act as switches for MUI inclusion. MUI is enabled by setting `mui_version=MUI-2.0` in these files and a global variable at compile time `export FOAM_USE_MUI=1` will be set. MUI is disabled by setting `mui_version=MUI-none` in these files. MUI will be disabled by default.
+ `etc/config.csh/mui`
+ `etc/config.sh/mui`
- There is a new folder named `mpi-MUI` in `src/Pstream` contains the MUI integrated Pstream. Make files `src/Pstream/Allwmake` and `src/Pstream/Allwclean` have been modified so that the newly created make files `src/Pstream/Allwmake-mpi-MUI` and `src/Pstream/Allwclean-mpi-MUI` can be called and `mpi-MUI` can be built once `FOAM_USE_MUI=1` is set.
- A new variable `extern MPI_Comm commWorld_;` has been added in `src/Pstream/mpi/PstreamGlobals.H`, `src/Pstream/mpi/PstreamGlobals.C` and `src/Pstream/mpi/UPstream.C` so that to facilitate the replacing of the default `MPI_COMM_WORLD` into the MUI enabled MPI communicator in `mpi-MUI` folder.
- The code piece of `MPI_Init_thread()` in `src/Pstream/mpi/UPstream.C` is proposed to be separated into a header file `mpiInitThread.H` so that to facilitate the MUI library to setup the MPI communicator in `mpi-MUI` folder. In this way, there is no need to modify codes in `src/Pstream/mpi/UPstream.C` directly.
- In `mpi-MUI` folder, there is only two header files `src/Pstream/mpi-MUI/mpiInitThread.H` that contains the MUI returned MPI communicator and `src/Pstream/mpi-MUI/PstreamGlobals.H` aiming to include `mui.h` header file. Once `mpi-MUI` folder is building, the `src/Pstream/Allwclean-mpi-MUI` will copy `UPstream.C` from `mpi` folder to `mpi-MUI` so that the two header files in `mpi-MUI` folder can be included. Other Pstream related header/source files will be used directly from the `mpi` folder as shown in `src/Pstream/mpi-MUI/Make/files`. The inclusion of `-I../mpi` has been put in `src/Pstream/mpi-MUI/Make/options` to enable the directly reuse of files in `mpi` folder. An alternative way to consider is to create soft links of these header/source files from the `mpi` folder.
- Created a new general purpose header file in creating MUI coupling interfaces
* `src/OpenFOAM/include/createCouplingMUI.H`
- There is a new solver in `applications/solvers/basic/laplacianFoamMUI` that shows how to utilise the integration and the way to compile a solver is also shown in the corresponding Make folder options file. Key to this is the inclusion of a new `mpi-MUI-rules` which is located in `wmake/rules/General` and effectively replaces the usual `mpi-rules` normally used. It is mostly the same file but just adds an extra line at the bottom `PINC += -I$(WM_THIRD_PARTY_DIR)/sources/mui/MUI-2.0/src`. There is a new file `wmake/scripts/have_mui` to detection/setup of MUI.
- There is a new tutorial case in `tutorials/basic/laplacianFoamMUI` that shows how to use the laplacianFoamMUI solver and a demo of couplingDict to set MUI coupling related variables.
- There is a new test code in `applications/test/coupling-MUI` that provide a unit test on MUI integration.
- Added MUI library related documentations in the following files in OpenFOAM
* `doc/Requirements.md`
## Related issue
[ThirdParty issue #67](https://develop.openfoam.com/Development/ThirdParty-common/-/issues/67)
## What does success look like, and how can we measure that?
The Patch has been tested with the OpenFOAM development repository (commit e651d63566897f00b049f56d461f48aedb9d129e).
The proposed changes can be patched and tested as follows
- Clone Development Repositories
```
git clone https://develop.openfoam.com/Development/ThirdParty-common.git
git clone https://develop.openfoam.com/Development/openfoam.git
```
- Obtain the MUI source file in the ThirdParty Repository
```
cd ThirdParty-common/sources
mkdir mui && cd mui
wget https://github.com/MxUI/MUI/archive/refs/tags/2.0.tar.gz
tar -xf 2.0.tar.gz && rm 2.0.tar.gz
```
- Obtain and place patches in Repositories
- Patch
```
cd openfoam/
patch -p2 < muiIntegrationOF.patch
rm muiIntegrationOF.patch
cd ../ThirdParty-common/
patch -p2 < muiIntegrationTP.patch
rm muiIntegrationTP.patch
```
- Change permission of newly added files if needed
- Enable MUI support (MUI is disabled by default)
- Modify L37 of `openfoam/etc/config.sh` to change `mui_version=MUI-none` into `mui_version=MUI-2.0`
- Source and Allwmake
```
cd openfoam/
source etc/bashrc
./Allwmake -j 4
```
- Test MUI enabled OpenFOAM
```
cd openfoam/applications/test/coupling-MUI
./testCase/Allrun
cd openfoam/tutorials/basic/laplacianFoamMUI
./AllrunCoupled
```
If MUI library successfully integrated, the following log messages can be found for the `coupling-MUI` unit test.
```
...
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time
Create mesh for time = 0
```
If MUI library successfully integrated, the following log messages can be found for the `laplacianFoamMUI` tutorial.
```
....
MUI [lib_mpi_multidomain]: Rank: 2, "domain2" registered interface "interface_twoD_1" as 59a4e385
MUI [lib_mpi_multidomain]: Rank: 3, "domain2" registered interface "interface_twoD_1" as 59a4e385
MUI Info [lib_mpi_multidomain]: 1 distinct interface(s) found
MUI [lib_mpi_multidomain]: Setting up interface interface_twoD_1 [59a4e385] (rank ids are local to each interface)
MUI [comm_mpi.h]: Rank: 3, Identifier: mpi://domain2/interface_twoD_1, Domain size: 2, Peers: 2
MUI [comm_mpi.h]: Rank: 2, Identifier: mpi://domain2/interface_twoD_1, Domain size: 2, Peers: 2
MUI [comm_mpi.h]: Rank: 1, Identifier: mpi://domain1/interface_twoD_1, Domain size: 2, Peers: 2
MUI [comm_mpi.h]: Rank: 0, Identifier: mpi://domain1/interface_twoD_1, Domain size: 2, Peers: 2
MUI [lib_mpi_multidomain]: Rank: 2, "domain2" registered interface "interface_threeD_1" as 31f80b7e
MUI [lib_mpi_multidomain]: Rank: 1, "domain1" registered interface "interface_threeD_1" as 31f80b7e
MUI [lib_mpi_multidomain]: Rank: 3, "domain2" registered interface "interface_threeD_1" as 31f80b7e
MUI [lib_mpi_multidomain]: Rank: 0, "domain1" registered interface "interface_threeD_1" as 31f80b7e
MUI Info [lib_mpi_multidomain]: 1 distinct interface(s) found
MUI [lib_mpi_multidomain]: Setting up interface interface_threeD_1 [31f80b7e] (rank ids are local to each interface)
MUI [comm_mpi.h]: Rank: 0, Identifier: mpi://domain1/interface_threeD_1, Domain size: 2, Peers: 2
MUI [comm_mpi.h]: Rank: 3, Identifier: mpi://domain2/interface_threeD_1, Domain size: 2, Peers: 2
MUI [comm_mpi.h]: Rank: 2, Identifier: mpi://domain2/interface_threeD_1, Domain size: 2, Peers: 2
MUI [comm_mpi.h]: Rank: 1, Identifier: mpi://domain1/interface_threeD_1, Domain size: 2, Peers: 2
MUI [lib_mpi_multidomain]: Rank: 2, "domain2" registered interface "interface_T_1" as 4a5523ab
MUI [lib_mpi_multidomain]: Rank: 1, "domain1" registered interface "interface_T_1" as 4a5523ab
MUI [lib_mpi_multidomain]: Rank: 0, "domain1" registered interface "interface_T_1" as 4a5523ab
MUI [lib_mpi_multidomain]: Rank: 3, "domain2" registered interface "interface_T_1" as 4a5523ab
MUI Info [lib_mpi_multidomain]: 1 distinct interface(s) found
MUI [lib_mpi_multidomain]: Setting up interface interface_T_1 [4a5523ab] (rank ids are local to each interface)
MUI [comm_mpi.h]: Rank: 0, Identifier: mpi://domain1/interface_T_1, Domain size: 2, Peers: 2
MUI [comm_mpi.h]: Rank: 1, Identifier: mpi://domain1/interface_T_1, Domain size: 2, Peers: 2
MUI [comm_mpi.h]: Rank: 3, Identifier: mpi://domain2/interface_T_1, Domain size: 2, Peers: 2
MUI [comm_mpi.h]: Rank: 2, Identifier: mpi://domain2/interface_T_1, Domain size: 2, Peers: 2
Calculating temperature distribution
Calculating temperature distribution
Time = 0.005
Time = 0.005
MUI interface "domain1"/"interface_twoD_1" value committed: 1 at Iteration = 0
MUI interface "domain2"/"interface_twoD_1" value committed: 1 at Iteration = 0
MUI interface "domain1"/"interface_threeD_1" value committed: 2 at Iteration = 0
MUI interface "domain1"/"interface_T_1" value committed: 3 at Iteration = 0
MUI interface "domain2"/"interface_threeD_1" value committed: 2 at Iteration = 0
MUI interface "domain2"/"interface_T_1" value committed: 3 at Iteration = 0
DICPCG: Solving for T, Initial residual = 1, Final residual = 8.33243e-07, No Iterations 7
DICPCG: Solving for T, Initial residual = 0.00446911, Final residual = 7.14892e-07, No Iterations 4
DICPCG: Solving for T, Initial residual = 0.000148123, Final residual = 6.63323e-07, No Iterations 2
MUI interface "domain1"/"interface_twoD_1" value fetched: 1 at Iteration = 0
MUI interface "domain1"/"interface_threeD_1" value fetched: 2 at Iteration = 0
MUI interface "domain1"/"interface_T_1" value fetched: 3 at Iteration = 0
ExecutionTime = 0.07 s ClockTime = 0 s
Time = 0.01
MUI interface "domain1"/"interface_twoD_1" value committed: 1 at Iteration = 1
MUI interface "domain1"/"interface_threeD_1" value committed: 2 at Iteration = 1
MUI interface "domain1"/"interface_T_1" value committed: 3 at Iteration = 1
DICPCG: Solving for T, Initial residual = 0.203755, Final residual = 1.57027e-07, No Iterations 7
DICPCG: Solving for T, Initial residual = 0.00184337, Final residual = 2.32416e-07, No Iterations 4
DICPCG: Solving for T, Initial residual = 1, Final residual = 8.33243e-07, No Iterations 7
DICPCG: Solving for T, Initial residual = 5.70921e-05, Final residual = 2.8776e-07, No Iterations 2
DICPCG: Solving for T, Initial residual = 0.00446911, Final residual = 7.14892e-07, No Iterations 4
DICPCG: Solving for T, Initial residual = 0.000148123, Final residual = 6.63323e-07, No Iterations 2
MUI interface "domain2"/"interface_twoD_1" value fetched: 1 at Iteration = 0
MUI interface "domain2"/"interface_threeD_1" value fetched: 2 at Iteration = 0
MUI interface "domain2"/"interface_T_1" value fetched: 3 at Iteration = 0
ExecutionTime = 0.1 s ClockTime = 0 s
Time = 0.01
MUI interface "domain2"/"interface_twoD_1" value committed: 1 at Iteration = 1
MUI interface "domain2"/"interface_threeD_1" value committed: 2 at Iteration = 1
MUI interface "domain2"/"interface_T_1" value committed: 3 at Iteration = 1
MUI interface "domain1"/"interface_twoD_1" value fetched: 1 at Iteration = 1
MUI interface "domain1"/"interface_threeD_1" value fetched: 2 at Iteration = 1
MUI interface "domain1"/"interface_T_1" value fetched: 3 at Iteration = 1
ExecutionTime = 0.08 s ClockTime = 0 s
Time = 0.015
MUI interface "domain1"/"interface_twoD_1" value committed: 1 at Iteration = 2
MUI interface "domain1"/"interface_threeD_1" value committed: 2 at Iteration = 2
MUI interface "domain1"/"interface_T_1" value committed: 3 at Iteration = 2
DICPCG: Solving for T, Initial residual = 0.109922, Final residual = 4.92455e-07, No Iterations 6
DICPCG: Solving for T, Initial residual = 0.00104616, Final residual = 7.0666e-07, No Iterations 3
DICPCG: Solving for T, Initial residual = 3.13839e-05, Final residual = 1.66653e-07, No Iterations 2
DICPCG: Solving for T, Initial residual = 0.203755, Final residual = 1.57027e-07, No Iterations 7
DICPCG: Solving for T, Initial residual = 0.00184337, Final residual = 2.32416e-07, No Iterations 4
DICPCG: Solving for T, Initial residual = 5.70921e-05, Final residual = 2.8776e-07, No Iterations 2
MUI interface "domain2"/"interface_twoD_1" value fetched: 1 at Iteration = 1
MUI interface "domain2"/"interface_threeD_1" value fetched: 2 at Iteration = 1
MUI interface "domain2"/"interface_T_1" value fetched: 3 at Iteration = 1
ExecutionTime = 0.11 s ClockTime = 1 s
Time = 0.015
MUI interface "domain2"/"interface_twoD_1" value committed: 1 at Iteration = 2
MUI interface "domain2"/"interface_threeD_1" value committed: 2 at Iteration = 2
MUI interface "domain2"/"interface_T_1" value committed: 3 at Iteration = 2
DICPCG: Solving for T, Initial residual = 0.109922, Final residual = 4.92455e-07, No Iterations 6
MUI interface "domain1"/"interface_twoD_1" value fetched: 1 at Iteration = 2
MUI interface "domain1"/"interface_threeD_1" value fetched: 2 at Iteration = 2
MUI interface "domain1"/"interface_T_1" value fetched: 3 at Iteration = 2
ExecutionTime = 0.1 s ClockTime = 1 s
...
```https://develop.openfoam.com/Development/openfoam/-/issues/1387Iso surface truncated by new "topo" method2020-12-20T14:06:24ZAdminIso surface truncated by new "topo" methodDuring the same run in an external aerodynamics application, I have tried to use the new isoSurfaceTopo method to extract and visualize turbulent structures via Lambda2, which resulted in a troncated iso-surface near the object, as shown...During the same run in an external aerodynamics application, I have tried to use the new isoSurfaceTopo method to extract and visualize turbulent structures via Lambda2, which resulted in a troncated iso-surface near the object, as shown in the picture attached (orange is Lambda2 via standard isoSurface and blue Lambda2 via isoSurfaceTopo).
![isoSurfaceTopoComparison](/uploads/332d5bd542ea4b4ce71eba275065dfe9/isoSurfaceTopoComparison.png)
\## Reattaching the author to the issue ticket: @Ricky-11 ##
\## Reattached image ##Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2942issue in ideasunvtofoam with meshes with 1D groups2023-07-12T12:13:41Zfranco otaolaissue in ideasunvtofoam with meshes with 1D groups<!--
*** 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 -->
ideasunvtofoam is one of the approaches to import meshes created from salome. Nevertheless if the mesh has 1D element groups, the ideasunvtofoam will crash without the possibility of importing the mesh. This bug has been here since several versions of OpenFOAM [](https://www.cfd-online.com/Forums/openfoam-meshing/72848-ideasunvtofoam-fails.html#post803660)
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Try to import a mesh that had 1D element groups before being exported from salome to UNV format. This will break the importation procedure
### 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
-->
Trying to import the example.unv mesh should make the ideasunvtofoam to crash (I don't have access to OF right now).[example.unv](/uploads/55076d287a81e6b46335fb7e566ed34e/example.unv)
I leave the same mesh but without the edge group exported which should work correctly for ideasunvtofoam [exampleWithoutEdgesGroups.unv](/uploads/c7460e7b2c0c9288801c77d33ac6bbe7/exampleWithoutEdgesGroups.unv)
### What is the current *bug* behaviour?
<!-- What actually happens -->
ideasunvtofoam crashes without leaving any possibility to import the mesh to OF
### What is the expected *correct* behavior?
<!-- What you should see instead -->
ideasunvtofoam should ignore this groups and import the mesh as it would not have themhttps://develop.openfoam.com/Development/openfoam/-/issues/2816Issue in wallHeatFlux evaluation - with readFields2023-06-26T08:17:40ZPrashant SonakarIssue in wallHeatFlux evaluation - with readFieldsAttached modified tutorial gives error while executing postProcess step in develop branch.
It works when:
- with readFields disabled, and wallHeatFlux FO having region=region0
- with readFields enabled and wallHeatFlux FO without region ...Attached modified tutorial gives error while executing postProcess step in develop branch.
It works when:
- with readFields disabled, and wallHeatFlux FO having region=region0
- with readFields enabled and wallHeatFlux FO without region keyword
[buoyantCavity.tgz](/uploads/f0ac85ce292468c3c0678283a01cf338/buoyantCavity.tgz)
The same error happens in other (larger) case with v2212 as well.Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1704issue with refineHexMesh running in parallel with cyclic boundary conditions2021-07-07T08:24:13Ztq1203issue with refineHexMesh running in parallel with cyclic boundary conditions<!--
*** 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 the domain is split among processors such that cells on cyclic patches are not on the same processor, refineHexMesh cannot be used.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Use cyclic boundary conditions and set decomposeParDict such that the cells which are on cyclic boundaries are not on the same processor.
Run refineHexMesh on a cellset.
Observe the error of the form
"Cannot find point in pts1 matching point ### coord:(## ## ##) in pts0 when using tolerance ##" in the refineHexMesh log 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
-->
If your domain is a cube, and the patches perpendicular to the x axis are cyclic, then you cannot split the domain into sections along the x direction (e.g. (4 1 1) in decompseParDict). It seems like you can however split the domain along the y or z direction, since the cells with the cyclic faces will be on the same processor (e.g. (1 4 1) in decompseParDict).
### What is the expected *correct* behavior?
<!-- What you should see instead -->
It would be nice if there was either a usage warning in refineHexMesh with cyclic boundary conditions, or if the mesh splitting and cell face assignments could be worked out so that it was possible to use refineHexMesh in parallel with cyclic boundary conditions.
### 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.
-->
Here is a sample of the refineHexMesh log file
```
[3] Cannot find point in pts1 matching point 131 coord:(0.015625 0.5 -0.0166667) in pts0 when using tolerance 2.28455e-06
[3] Searching started from:0 in pts1
[3] Compared coord: (0.015625 -0.5 -0.0166667) at index 0 with difference to point 1
[3] Cannot find point in pts1 matching point 132 coord:(0.046875 0.5 -0.0166667) in pts0 when using tolerance 2.28455e-06
[3] Searching started from:0 in pts1
[3] Compared coord: (0.015625 -0.5 -0.0166667) at index 0 with difference to point 1.00049
[3] Compared coord: (0.046875 -0.5 -0.0166667) at index 1 with difference to point 1
[3] Cannot find point in pts1 matching point 15 coord:(0.015625 0.5 -0.05) in pts0 when using tolerance 2.28455e-06
[3] Searching started from:1 in pts1
[3] Compared coord: (0.046875 -0.5 -0.0166667) at index 1 with difference to point 1.00104
[3] Compared coord: (0.015625 -0.5 -0.05) at index 2 with difference to point 1
[3] Cannot find point in pts1 matching point 133 coord:(0.046875 0.5 -0.05) in pts0 when using tolerance 2.28455e-06
[3] Searching started from:2 in pts1
[3] Compared coord: (0.015625 -0.5 -0.05) at index 2 with difference to point 1.00049
[3] Compared coord: (0.046875 -0.5 -0.05) at index 3 with difference to point 1
```
### 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 : v1806
OS: centos
### 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
-->
For now, if you keep the cyclic cells on the same processor it seems to work.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2698jouleHeating and electric contact resistance is delivering wrong results - co...2023-02-03T15:48:26ZAndreas SchützenbergerjouleHeating and electric contact resistance is delivering wrong results - comparison between openFoam, Comsol and theory - turbulentTemperatureRadCoupledMixedThe description of the problem is in the attachted pdf file.
OpenFOAM version : v2212
Operating system : ubuntu
solver: chtMultiRegionSimpleFoam
[bug_jouleheating.pdf](/uploads/ea26a9667581e90cf77eb97d0c20024a/bug_...The description of the problem is in the attachted pdf file.
OpenFOAM version : v2212
Operating system : ubuntu
solver: chtMultiRegionSimpleFoam
[bug_jouleheating.pdf](/uploads/ea26a9667581e90cf77eb97d0c20024a/bug_jouleheating.pdf)[stab_joule.zip](/uploads/5ead128f3cad12a49668f60893c7c7d6/stab_joule.zip)https://develop.openfoam.com/Development/openfoam/-/issues/1285keepParticle is ignored by postPatch2022-12-23T14:56:06ZAdminkeepParticle is ignored by postPatchI'm not sure if this is an actual issue or if I missed something in the code, but consider the following:
The cloudFunctionObjects have a hook "postPatch" to allow users to run code if a particle hits a patch:
https://develop.openfoam....I'm not sure if this is an actual issue or if I missed something in the code, but consider the following:
The cloudFunctionObjects have a hook "postPatch" to allow users to run code if a particle hits a patch:
https://develop.openfoam.com/Development/OpenFOAM-plus/blob/master/src/lagrangian/intermediate/submodels/CloudFunctionObjects/CloudFunctionObject/CloudFunctionObject.H#L160
This hook has a parameter "keepParticle" if the user wants to remove the particle due to e.g. some custom model.
The hook is called here:
https://develop.openfoam.com/Development/OpenFOAM-plus/blob/master/src/lagrangian/intermediate/parcels/Templates/KinematicParcel/KinematicParcel.C#L385
The value of "keepParticle" is not used. Right after the hook, the standard patch interaction code is called. Let's say the user chose "rebound". Then the following code is called:
https://develop.openfoam.com/Development/OpenFOAM-plus/blob/master/src/lagrangian/intermediate/submodels/Kinematic/PatchInteractionModel/LocalInteraction/LocalInteraction.C#L260
Here, the value of keepParticle is uconditionally set to "true", ignoring the previous value.
To summarize: postPatch may set "keepParticle" to false, but this value is not used until the patch interaction models overwrite this value. Therefore postPatch has no effect on removing particles and the parameter "keepParticle" in postPatch seems to be ignored.
\## Reattaching the author to the issue ticket: @g3 ##v2306Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2400kOmegaSST model with wrong omegaWallFunction2022-04-15T12:49:36ZSh NokOmegaSST model with wrong omegaWallFunctionThis reference, [https://turbmodels.larc.nasa.gov/sst.html](url), states that the boundary condition recommended in the original "Standard" Menter SST Two-Equation Model (SST) reference for omega at wall, is ![omega_wall_boundary_conditi...This reference, [https://turbmodels.larc.nasa.gov/sst.html](url), states that the boundary condition recommended in the original "Standard" Menter SST Two-Equation Model (SST) reference for omega at wall, is ![omega_wall_boundary_condition](/uploads/f3a558083b3f09dd640b0fe96051099a/omega_wall_boundary_condition.png) , which is 10 times higher than what is implemented in the omegaWallFunction boundary condition and used in tutorials. Below is the screenshot of part of the link provided, which mentions recommended
omega boundary condition.
![Boundary_Conditions](/uploads/2db5839def26e0247776a7564ea150b4/Boundary_Conditions.png)
It can be solved by setting beta1, 10 times lower than the default value; As is showed below.
![beta1_correction](/uploads/55ab5625a21a3e4c6f1df1e89ffa1337/beta1_correction.png)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/2682Large time step continuity error in first time step with reactingFoam2023-01-24T20:50:07ZJan GärtnerLarge time step continuity error in first time step with reactingFoam### Summary
Large time step continuity error in reactingFoam due to missing old time in thermo::psi field.
When running the tutorial tutorials/combustion/reactingFoam/laminar/counterFlowFlame2D, a large time step continuity error appea...### Summary
Large time step continuity error in reactingFoam due to missing old time in thermo::psi field.
When running the tutorial tutorials/combustion/reactingFoam/laminar/counterFlowFlame2D, a large time step continuity error appears in the first iteration. This is independent if it starts from 0 or from a later time step.
The error could be traced back to the `thermo.correct()` function called in the energy equation. There the values of the fields, especially the compressibility psi, are overwritten with new values based on the newly calculated temperature and known pressure. Even though `GeometricField<>::primitiveFieldRef()` is called the old time field is **not** updated because no current old time pointer exists, see also `void Foam::GeometricField<Type, PatchField, GeoMesh>::storeOldTimes()`.
This can be prevented by forcing an oldTime pointer to exist by calling in thermo::correct() `this->psi_.oldTime()`, as had been done in e.g. OpenFOAM 5.x. Adding this line to the thermo::correct() function of hePsiThermo.C would reduce the observed error!
### Steps to reproduce
Run tutorials/combustion/reactingFoam/laminar/counterFlowFlame2D and observe the time continuity error in the first time step. Then add the line
```
this->psi_.oldTime
```
to hePsiThermo::correct() and the error is reduced. It is also possible to check by printing out the number of old time values stored of psi before the energy equation, after the energy equation and after the pressure equation. It clearly shows, that only after it is solved for in the pressure equation with `fvm::ddt(psi,p)` it has the old time fields.
### Relevant logs and/or images
#### Example output of the first time step
```
Starting time loop
Courant Number mean: 2.73409e-05 max: 0.00175681
deltaT = 1.19999e-06
Time = 1.19999e-06
diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
PIMPLE: iteration 1
DILUPBiCGStab: Solving for O2, Initial residual = 1, Final residual = 1.02704e-09, No Iterations 1
DILUPBiCGStab: Solving for H2O, Initial residual = 0, Final residual = 0, No Iterations 0
DILUPBiCGStab: Solving for CH4, Initial residual = 1, Final residual = 1.0339e-09, No Iterations 1
DILUPBiCGStab: Solving for CO2, Initial residual = 0, Final residual = 0, No Iterations 0
DILUPBiCGStab: Solving for h, Initial residual = 1, Final residual = 4.10484e-09, No Iterations 1
min/max(T) = 293, 2000
DICPCG: Solving for p, Initial residual = 1, Final residual = 0.0488686, No Iterations 5
diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
time step continuity errors : sum local = 0.000333765, global = -0.000330463, cumulative = -0.000330463
DICPCG: Solving for p, Initial residual = 0.0147831, Final residual = 6.72619e-07, No Iterations 12
diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
time step continuity errors : sum local = 0.000331263, global = -0.000331263, cumulative = -0.000661725
ExecutionTime = 0.04 s ClockTime = 0 s
```
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2212|v2206|v2112|v2106|v2012 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2012
- Operating system : Ubuntu 22.04
- Hardware info : AMD Ryzen 7 2700X Eight-Core Processor
- Compiler : GCC 9.5.0
### Possible fixes
Change `hePsiThermo.C` to:
```
template<class BasicPsiThermo, class MixtureType>
void Foam::hePsiThermo<BasicPsiThermo, MixtureType>::correct()
{
DebugInFunction << endl;
// force old time
this->psi_.oldTime();
calculate
(
this->p_,
this->T_,
this->he_,
this->psi_,
this->mu_,
this->alpha_,
false // No need to update old times
);
DebugInFunction << "Finished" << endl;
}
```Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1833layerAdditionRemoval polyTopoChanger not working properly while used with dis...2020-09-08T18:41:46ZLucas Silva CytrangulolayerAdditionRemoval polyTopoChanger not working properly while used with displacementLayeredMotion solver<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
I found an issue while trying to use the displacementLayeredMotion solver with the layerAdditionRemoval functionality. Basically, I'm trying to use it for a toy case, which i have two moving walls, with a predetermined displacement in a certain direction, where I want to add and remove the cells to simulate the movement of these walls. Initially everything works fine, until a certain topology change is needed, at this moment the layerAdditionRemoval polyTopoChanger seems to fail to construct the new group of cells at the left side of the domain (the side that is expanding).
### Steps to reproduce
The case is attached with an Allrun.
### 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
-->
[retangularLayerAdditionRemoval.tar.xz](/uploads/f06099a8d0c75608a95ca20f4945f9cc/retangularLayerAdditionRemoval.tar.xz)
### What is the current *bug* behaviour?
<!-- What actually happens -->
While constructing a new group of cells due to the layerAdditionRemoval, it fails, constructing wrong oriented cells with negative volume.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
The expected result should be something like this:
![layerADDrm](/uploads/ac7c7be4f520c8b70ccfb880ca965990/layerADDrm.mp4)
### 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.
-->
The final part of the log:
```logs
Time = 0.62
PIMPLE: iteration 1
solving for zone: top
solving for zone: LAR1
solving for zone: LAR2
solving for zone: botton
Executing mesh motion
Point usage OK.
Upper triangular ordering OK.
Topological cell zip-up check OK.
Face vertices OK.
Face-face connectivity OK.
Mesh topology OK.
Boundary openness (0 -8.5572e-18 -7.54804e-16) OK.
Max cell openness = 0 OK.
Max aspect ratio = 1.62737 OK.
Minimum face area = 1. Maximum face area = 1.62737. Face area magnitudes OK.
Min volume = 1. Max volume = 1.62737. Total volume = 11500. Cell volumes OK.
Mesh non-orthogonality Max: 0 average: 0
Non-orthogonality check OK.
Face pyramids OK.
Max skewness = 1.42143e-14 OK.
Mesh geometry OK.
Mesh OK.
ExecutionTime = 15.6 s ClockTime = 16 s
Time = 0.63
PIMPLE: iteration 1
Executing mesh topology update
solving for zone: top
solving for zone: LAR1
solving for zone: LAR2
solving for zone: botton
solving for zone: top
solving for zone: LAR1
solving for zone: LAR2
solving for zone: botton
Point usage OK.
Upper triangular ordering OK.
Topological cell zip-up check OK.
Face vertices OK.
Face-face connectivity OK.
Mesh topology OK.
Boundary openness (0 -9.8212e-18 -7.50515e-17) OK.
***High aspect ratio cells found, Max aspect ratio: 5.50745e+99, number of cells 125
Minimum face area = 0.326117. Maximum face area = 1.95509. Face area magnitudes OK.
***Zero or negative cell volume detected. Minimum negative volume: -0.326117, Number of negative volume cells: 125
Mesh non-orthogonality Max: 180 average: 9.58925
***Number of non-orthogonality errors: 220.
***Error in face pyramids: 750 faces are incorrectly oriented.
Max skewness = 2.63864e-14 OK.
Failed 4 mesh geometry checks.
Failed 1 mesh checks.
ExecutionTime = 16.14 s ClockTime = 17 s
Time = 0.64
PIMPLE: iteration 1
--> FOAM FATAL ERROR:
negative cell volume. Error in mesh motion before topological change.
V:
11500
(
list with cells volume
)
From function virtual bool Foam::layerAdditionRemoval::changeTopology() const
in file layerAdditionRemoval/layerAdditionRemoval.C at line 220.
FOAM aborting
#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::error::abort() at ??:?
#2 Foam::layerAdditionRemoval::changeTopology() const at ??:?
#3 Foam::polyTopoChanger::changeTopology() const at ??:?
#4 Foam::polyTopoChanger::changeMesh(bool, bool, bool, bool) at ??:?
#5 Foam::dynamicMotionSolverTopoFvMesh::update() at ??:?
#6 ? in ~/OpenFOAM/OpenFOAM-v1812/platforms/linux64GccDPInt32Opt/bin/moveDynamicMesh
#7 __libc_start_main in /lib/x86_64-linux-gnu/libc.so.6
#8 ? in ~/OpenFOAM/OpenFOAM-v1812/platforms/linux64GccDPInt32Opt/bin/moveDynamicMesh
Aborted (core dumped)
```
### 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 : v1812 | v2006
- Operating system : Ubuntu 18.04.5 LTS
### 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/2767Let user define the output field name in the wallShearStress FO2023-04-27T08:13:12ZTimofey MukhaLet user define the output field name in the wallShearStress FO### Functionality to add/problem to solve
Would it be OK to extend the functionality of the `wallShearStress` FO to support other output field names rather than `wallShearStress`?
The latter would still be the default, thus not braking ...### Functionality to add/problem to solve
Would it be OK to extend the functionality of the `wallShearStress` FO to support other output field names rather than `wallShearStress`?
The latter would still be the default, thus not braking any workflows or tutorials.
I realize that not a lot of people will need that, but I guess it cannot hurt? The reason I want this implemented is that my WMLES library also uses `wallShearStress`, and if one also uses the FO, there is a name collision, which leads to a nasty looking crash, as discovered by Tobias.
### Proposal
Add an optional `field` or `fieldName` keyword for the user to set, and use that in the constructor, which allocates the `volVectorField`.
### Funding
I am reasonably sure I can implement this myself without any help. Impact on code maintenance should be negligible.