Development issueshttps://develop.openfoam.com/groups/Development/-/issues2020-09-08T16:21:31Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1788interfaceHeight does not work in parallel2020-09-08T16:21:31ZzackinterfaceHeight does not work in parallel<!--
*** 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
interfaceHeight does not work with parallel solver.
### Steps to reproduce
Run with single and multiple processor. Single processor writes output where as parallel processor outputs an empty file.
### Example case
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
### What is the current *bug* behaviour?
<!-- What actually happens -->
### 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
OpenFOAM version: OpenFOAM v2006
Operating system: ubuntu 18.04
### 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/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/1968interfaceTrackingFvMesh does not implement two-step constructor2020-12-22T15:06:52ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.cominterfaceTrackingFvMesh does not implement two-step constructor<!--
*** 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 -->
Unallocated motionSolver in interfaceTrackingFvMesh
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
run
incompressible/pimpleFoam/laminar/contactAngleCavity
### What is the current *bug* behaviour?
<!-- What actually happens -->
log.pimpleFoam: unallocated autoPtr of type N4Foam12motionSolverE
### 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 : develop
@Prashant @andyMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://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/1185interFoam: bleeding at inlet2020-03-13T13:38:02ZPawan GhildiyalinterFoam: bleeding at inletHi @Sergio & @andy
This is reported by student of Exeter university
i)channel2D/3D case : run fine with 1612 but show bleeding of alpha at inlet
which then propagate in domain, in OF-1706 onwards version. **alpha at inlet is zer...Hi @Sergio & @andy
This is reported by student of Exeter university
i)channel2D/3D case : run fine with 1612 but show bleeding of alpha at inlet
which then propagate in domain, in OF-1706 onwards version. **alpha at inlet is zero
gradient** in default case set up . It looks zeroGradient BC at inlet causes bleeding after OF .
version 1612+ .
Can you have a look into it ?
See attached pdf file
[volumeFraction_Bleeding_2DChannel.pdf](/uploads/92fcfb9f52dfe1064f0072c42e91495f/volumeFraction_Bleeding_2DChannel.pdf)
**2D cases attached here :**
[channel_2D.zip](/uploads/db2432d92889b41af32484f8ef2a4711/channel_2D.zip)
> 3D cases attached here
[casefinal_3D.tar](/uploads/50924d540d9c7987bb487478dfb4749e/casefinal_3D.tar)
ii) **Suggested bc to avoid this bleeding**
using variableFlowRateHeight or interFaceCompression avoid bleeding at inlet and domain.https://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/1054interFoam with dynamic mesh refinement fails2018-11-07T12:48:56ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.cominterFoam with dynamic mesh refinement failsRun under valgrind:
[log.interFoam](/uploads/c14aec44ae7db576e36066640a24dbdf/log.interFoam)
@Prashant @andy
(Same happens for interIsoFoam @johan\_roenby )
Run under valgrind:
[log.interFoam](/uploads/c14aec44ae7db576e36066640a24dbdf/log.interFoam)
@Prashant @andy
(Same happens for interIsoFoam @johan\_roenby )
https://develop.openfoam.com/Development/openfoam/-/issues/1955interIsoFoam crashes with AMR with load balancing2021-06-28T12:59:36ZHenning ScheuflerinterIsoFoam crashes with AMR with load balancing### Summary
If interIsoFoam is combined with a AMR with load balancing as in:
https://github.com/HenningScheufler/multiDimAMR
isoAdvection crashes in syncProcPatches
### Steps to reproduce
run dambreakWithObstacle with interIsoFoam
...### Summary
If interIsoFoam is combined with a AMR with load balancing as in:
https://github.com/HenningScheufler/multiDimAMR
isoAdvection crashes in syncProcPatches
### Steps to reproduce
run dambreakWithObstacle with interIsoFoam
### Reason
In the current code, it is assumed that the boundary patches do not change which is not the case with load balancing.
procPatchLabels_ needs to be recalculated after the redistribution step
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1812 to of2006
Operating system : ubuntu
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :
- Operating system :
- Hardware info :
- Compiler :
### Possible fixes
```
// add
void Foam::advection::isoAdvection::setProcessorPatches()
{
const polyBoundaryMesh& patches = mesh_.boundaryMesh();
surfaceCellFacesOnProcPatches_.clear();
surfaceCellFacesOnProcPatches_.resize(patches.size());
// Append all processor patch labels to the list
procPatchLabels_.clear();
forAll(patches, patchi)
{
if
(
isA<processorPolyPatch>(patches[patchi])
&& patches[patchi].size() > 0
)
{
procPatchLabels_.append(patchi);
}
}
}
template < class SpType, class SuType >
void Foam::advection::isoAdvection::advect(const SpType& Sp, const SuType& Su)
{
DebugInFunction << endl;
if (mesh_.topoChanging()) // added
{
setProcessorPatches();
}
```
another solution would be to remove the procPatchLabels_:
and modify syncProcPatch
```
forAll(surfaceCellFacesOnProcPatches_, patchi)
{
if (isA<processorPolyPatch>(patches[patchi]) && patches[patchi].size())
{
```Henning ScheuflerHenning Scheuflerhttps://develop.openfoam.com/Development/openfoam/-/issues/911interIsoFoam crashes with nOuterCorrectors > 12018-12-20T18:06:59ZAdmininterIsoFoam crashes with nOuterCorrectors > 1Hello,
when using interIsoFoam (version OpenFOAM-plus develop-prerelease) with nOutercorrectors larger than 1, the solver crashes with the following error message:
> --> FOAM FATAL ERROR:
> previous iteration field
> IOobject: volSca...Hello,
when using interIsoFoam (version OpenFOAM-plus develop-prerelease) with nOutercorrectors larger than 1, the solver crashes with the following error message:
> --> FOAM FATAL ERROR:
> previous iteration field
> IOobject: volScalarField alpha.water readOpt: 0 writeOpt: 0 globalObject: 0 "/home/heinri8/OpenFOAM/OpenFOAM-plus/tutorials/multiphase/interIsoFoam/damBreak/0"
>
> not stored. Use field.storePrevIter() at start of iteration.
To reproduce this simply take the dambreak tutorial case and change nOuterCorrectors from 1 to 2 and start the Allrun script.
I assume there is a typo in the alphaEqn.H file on line 14. It states:
alpha1.prevIter();
It should probably be as following:
alpha.storePrevIter();
since the previous iteration is actually called later in the file on line 23.
Regards
MartinMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2016interIsoFoam runs into an endless loop2021-12-07T08:55:41ZMichael AllettointerIsoFoam runs into an endless loopHello,
when testing interIsofoam i found a parameter set for which it runs in an endless loop. I made same flags to find out where this happens and it is in the file plicRDF.c at line 470 in the while loop starting which while (resIter....Hello,
when testing interIsofoam i found a parameter set for which it runs in an endless loop. I made same flags to find out where this happens and it is in the file plicRDF.c at line 470 in the while loop starting which while (resIter.found()).
I uploaded a case file with an allrun script to reproduce the error. In my case it got stuck at the time 0.609626.
Best
Michael
[nOuter2nInner2nAlphaBounds6send.tar.gz](/uploads/3c1a44feb69d18bbfd79d2e4fdea9c97/nOuter2nInner2nAlphaBounds6send.tar.gz)https://develop.openfoam.com/Development/openfoam/-/issues/1302interIsoFoam with morphing meshes2019-07-02T09:26:33ZJohan RoenbyinterIsoFoam with morphing meshesSo far isoAdvector has not worked with morphing meshes.
A version of isoAdvection/interIsoFoam that works with morphing meshes has now been committed in the new branch feature-isoAdvectorWithMorphingMeshes
A test case demonstrating th...So far isoAdvector has not worked with morphing meshes.
A version of isoAdvection/interIsoFoam that works with morphing meshes has now been committed in the new branch feature-isoAdvectorWithMorphingMeshes
A test case demonstrating that it works can be found here:
[sphereInSqueezedMesh.tar.gz](/uploads/68d31fde5a917760b7a0a0bc852b97bd/sphereInSqueezedMesh.tar.gz)
Will someone with merge privilege look at this (@andy ,@mark )?v1906Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/140interpolation2DTable<Type>::write does not compile2023-12-07T19:01:56ZMark OLESENinterpolation2DTable<Type>::write does not compilehttps://develop.openfoam.com/Development/openfoam/-/issues/2817interpolation cell-point not working in processorCyclicPointPatchField (in no...2023-06-30T13:44:08ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.cominterpolation cell-point not working in processorCyclicPointPatchField (in nonBlocking mode)<!--
*** 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 -->
processorCyclicPointPatchField does not buffer local send data when running non-blocking. This gives memory errors on bigger cases (if running with cyclics where owner and neighbour might be on different processors)
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Run `incompressible/pimpleFoam/LES/periodicHill/transient` tutorial. At the postprocessing at the end it triggers a cell->point interpolation which under valgrind shows up the errors. Note that the only thing that matters is to have the processorCyclic patches + volPointInterpolation.
### Example case
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
See above
### What is the current *bug* behaviour?
<!-- What actually happens -->
Get NaN (1e-318) in last element of array when printing out the values. Get valgrind memory errors.
### 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 : 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 : v2212
- Operating system :
- Hardware info :
- Compiler :
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->
Use persistent buffer for transferring data (ideally only when running non-blocking)
@markMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1388Interpolation scheme for electric current / heat flux2020-03-13T13:20:48ZAdminInterpolation scheme for electric current / heat flux### Functionality to add/problem to solve
An electric current is calculated as
```math
J = \sigma\cdot\nabla\varphi.
```
The gradient of the electric potential can not be calculated using the Gauss theorem with LINEAR interpolation of...### Functionality to add/problem to solve
An electric current is calculated as
```math
J = \sigma\cdot\nabla\varphi.
```
The gradient of the electric potential can not be calculated using the Gauss theorem with LINEAR interpolation of the potential . A special interpolation scheme is necessary. As described below, the potential at the face needs to be weighted by the conductivity of both cells.
![gradient](/uploads/a3f4ad605e37e98d3d0c97aaae1c5002/gradient.png)
### Target audience
The mentioned interpolation scheme is necessary for computing the gradient of
* electric potential (i.e. electric current)
* temperature (i.e. heat flux)
### What does success look like, and how can we measure that?
I use the mentioned interpolation scheme for several years. It is already validated and published.
### Links / references
Weber, N.; Beckstein, P.; Galindo, V.; Starace, M.; Weier, T.: Electro-vortex flow simulation using coupled meshes, Computers and Fluids 168(2018) 101-109
It is Eqn. 16/17 in the [Arxiv version. ](https://arxiv.org/pdf/1707.06546.pdf)
### Funding
I can provide the source code.
\## Reattaching the author to the issue ticket: @dl6tud ##Sergio FerrarisSergio Ferrarishttps://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/openfoam/-/issues/1291In the same case, magneticFoam in this version does not return any results.2019-07-09T18:06:00ZAdminIn the same case, magneticFoam in this version does not return any results.<!--
*** 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
-->
<!--
All text between these marker...<!--
*** 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
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
'magneticFoam' in this version does not return any results but ofv6 seems to work properly for it.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
we execute 'Allrun' script in the case.
### 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
-->
for v1812[magSandboxFailure.zip](/uploads/a40f6c4e3576f97e1f4c4da61c935038/magSandboxFailure.zip)
---
for ofv6[magSandboxSuccess.zip](/uploads/7f2544852e5e54e233f4f2e41f6d0f7d/magSandboxSuccess.zip)
### What is the current *bug* behaviour?
<!-- What actually happens -->
--> FOAM FATAL ERROR:
cannot find file "/home/xxxx/OpenFOAM/xxxx-v1812/run/magSandbox/0/murf"
### 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.
-->
[log.zip](/uploads/6f108923bcfe39f2bf404b48bc96b2ae/log.zip)
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1812
Operating system : ubuntu
Hardware info : intel
Compiler : gcc-7.3.0
-->
OpenFOAM version :v1812
Operating system :ubuntu18.04
Compiler :gcc-7.3.0
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
-->Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://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/2095invalid/inconsistent math expression expansion2021-05-28T12:15:35ZMark OLESENinvalid/inconsistent math expression expansionIf embedded within a string, the math expr is properly evaluated:
```
fileName "${input${{ 2*10 }}}";
```
However, the following entry currently fails:
```
value ${{2*10}};
```
Error: _no entry or environment variable '2*10'_
Clearly ...If embedded within a string, the math expr is properly evaluated:
```
fileName "${input${{ 2*10 }}}";
```
However, the following entry currently fails:
```
value ${{2*10}};
```
Error: _no entry or environment variable '2*10'_
Clearly not what we expect.Mark OLESENMark OLESEN