openfoam issueshttps://develop.openfoam.com/Development/openfoam/-/issues2024-03-28T15:10:21Zhttps://develop.openfoam.com/Development/openfoam/-/issues/3128ENH: allow frozenFlow option for icoReactingMultiphaseInterFoam2024-03-28T15:10:21ZPrashant SonakarENH: allow frozenFlow option for icoReactingMultiphaseInterFoamSimilar to CHT solvers, please extend the frozenFlow option for the solver icoReactingMultiphaseInterFoam
corss reference: EP#2286Similar to CHT solvers, please extend the frozenFlow option for the solver icoReactingMultiphaseInterFoam
corss reference: EP#2286Andrew HeatherAndrew Heatherhttps://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/3126cellZoneSet does not allow 'set' input2024-03-27T10:33:08ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcellZoneSet does not allow 'set' input<!--
*** 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 -->
`cellZoneSet` does not support `set` input. This was introduced in merge request !674.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
E.g. in topoSet:
```
{
name c1;
type cellZoneSet;
action new;
source cellToCell;
set c0;
}
```
### What is the current *bug* behaviour?
Crash casting c0 to a cellZoneSet
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2312|v2306|v2212|v2206|v2112 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : >2312
### 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
-->
Generalise the *ZoneSet routines to add a topoSet.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/3125ACMI - unallocated autoPtr error when redistributing the mesh2024-03-28T14:52:58ZPrashant SonakarACMI - unallocated autoPtr error when redistributing the meshAttached case reproducing error in 2312 as well as develop line.
The case works when adding `AMIMethod nearestFaceAMI;` within blockMeshDict for ACMI definition.
[oscillatingInletACMI2D.tgz](/uploads/d484dd4e2a967211fb99cb2eac3b6...Attached case reproducing error in 2312 as well as develop line.
The case works when adding `AMIMethod nearestFaceAMI;` within blockMeshDict for ACMI definition.
[oscillatingInletACMI2D.tgz](/uploads/d484dd4e2a967211fb99cb2eac3b6f49/oscillatingInletACMI2D.tgz)Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/3124Feature request: vtkWrite with zlib/lzma compression2024-03-24T10:24:06ZAaronFeature request: vtkWrite with zlib/lzma compressionI'm using the vtkWrite, and noticed the sizes of the files can be dropped by ~40% by later reading the file in python-vtk, using SetCompressorTypeToZLib(), and exporting. Or around 55% using SetCompressorTypeToLZMA()
It could be helpful...I'm using the vtkWrite, and noticed the sizes of the files can be dropped by ~40% by later reading the file in python-vtk, using SetCompressorTypeToZLib(), and exporting. Or around 55% using SetCompressorTypeToLZMA()
It could be helpful to have either/both of these as an option in vtkWrite itself.https://develop.openfoam.com/Development/openfoam/-/issues/3121ENH: support temperature dependent properties2024-03-19T16:37:03ZPrashant SonakarENH: support temperature dependent propertiesAs discussed with @andy the code at [line](https://develop.openfoam.com/Development/openfoam/-/blob/develop/src/thermophysicalModels/radiation/radiationModels/viewFactor/viewFactor.C#L748) doesn't pass temperature field which is prerequi...As discussed with @andy the code at [line](https://develop.openfoam.com/Development/openfoam/-/blob/develop/src/thermophysicalModels/radiation/radiationModels/viewFactor/viewFactor.C#L748) doesn't pass temperature field which is prerequisite for the temperature dependent material properties
Cross ref - EP#2382Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/3120A new rigid body restraint that can be used with fvOption2024-03-27T13:36:50ZBuğra Uğur YazıcıA new rigid body restraint that can be used with fvOption### Functionality to add/problem to solve
Creating a restraint in rigid body simulations that utilizes calculated values from an _fvOption_. The concept is to acquire force and moment values from any _fvOption_ and easily apply them as ...### Functionality to add/problem to solve
Creating a restraint in rigid body simulations that utilizes calculated values from an _fvOption_. The concept is to acquire force and moment values from any _fvOption_ and easily apply them as external forces and moments. While the same functionality can be achieved by reading/writing to a dictionary, I believe this feature request will make it more elegant.
### Target audience
Ship Hydrodynamics, Offshore Wind Platforms etc.
### Proposal
Any ideas/suggestions are welcomed.
Inside dynamicMeshDict, the user should define the new type of restraint as follows:
```
restraints
{
force1 // Any name
{
type bodyForceMoment; // Just a suggestion :smile:
body aMasslessBody1; // massless body
// location (-3.386 0 0.21); // not required anymore since it will use massless bodies CoG
fvOptionsName virtualDisk1; // Name of the fvOption object, as specified in the fvOptions dictionary
}
force2 // Any name
{
type bodyForceMoment;
body aMasslessBody2; // massless body
fvOptionsName virtualDisk2; // Name of the fvOption object, as specified in the fvOptions dictionary
}
}
```
What should this bodyForceMoment restraint do?
- It should create a pointer to the fvOptions residing inside the object registry with the specified fvOptionsName in the restrained sub-dictionary.
- It should obtain the total force and moment from any fvOptions.
- Getting these values is also another unclear issue, but I suggest adding **getForce** and **getMoment** methods to the fvOptions. These methods should return the parameters corresponding to the total force and the total moment.
Finally, the restraint function may look like the following:
```
void Foam::RBD::restraints::bodyForceMoment::restrain
(
scalarField& tau,
Field<spatialVector>& fx,
const rigidBodyModelState& state
) const
{
// Create a pointer in bodyForceMoment constructor to fvOptions.
// Let's call it fvOptPtr
const vector force = fvOptPtr->getForce(); // Using the suggested method to get the force
const vector moment= fvOptPtr->getMoment(); // Using the suggested method to get the moment
// Accumulate the force for the restrained body
fx[bodyIndex_] += spatialVector(moment, force);
}
```
For this implementation, I don't know how to create a pointer to the fvOption object from the object registry. If someone can help me with this, I am ready to implement everything.https://develop.openfoam.com/Development/openfoam/-/issues/3118snappyHexMesh with cyclic BC: Had *** baffles to create but encountered *** ...2024-03-28T16:19:06ZGuanyang XuesnappyHexMesh with cyclic BC: Had *** baffles to create but encountered *** slave faces originating from patcheable faces.### Summary
Triggered this bug when trying to mesh a 3-directional cyclic base mesh. I DID NOT use parallel meshing (I know a lot of bugs are related to this). Tried to Google but can't find any similar cases.
### Steps to reproduce
I'...### Summary
Triggered this bug when trying to mesh a 3-directional cyclic base mesh. I DID NOT use parallel meshing (I know a lot of bugs are related to this). Tried to Google but can't find any similar cases.
### Steps to reproduce
I'm attaching a minimal case to reproduce. `meshwall.sh` uses `wall` for all 6 faces and can run successfully. But if you run `meshcyclic.sh` and start from a 3-directional cyclic base mesh, this bug will happen.
### Example case
Should take 1min to run. (Uploaded 2nd version for multiregion meshing)
[snappyHexMesh.zip](/uploads/84aa4dfa68c65d22b8c553170f55b60f/snappyHexMesh.zip)
### What is the current *bug* behaviour?
See logs.
### What is the expected *correct* behavior?
`snappyHexMesh` should support cyclic when meshing in serial based on other bug reports, right?
### Relevant logs and/or images
```
--> FOAM FATAL ERROR: (openfoam-2312)
Had 58069 baffles to create but encountered 56363 slave faces originating from patcheable faces.
From Foam::autoPtr<Foam::mapPolyMesh> Foam::meshRefinement::createZoneBaffles(const labelList &, List<labelPair> &, labelList &)
in file meshRefinement/meshRefinementBaffles.C at line 894.
FOAM aborting
```
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2312|v2306|v2212|v2206|v2112 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2312
- Operating system : ubuntu
- Hardware info : AMD
- Compiler : aocc
### Possible fixes
Tried to remove line 892-899 in `meshRefinementBaffles.C`. It can generate a mesh, but not properly snapped to the feature and generated extra triangles on the boundary patch. So the problem is from somewhere else.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/3114BUG: incorrect number of escape parcel information2024-03-07T17:13:18ZPrashant SonakarBUG: incorrect number of escape parcel informationAs discussed with Andy, the total parcels escaped through system is incorrect when all boundaries are 'rebound' whilst some of the boundaries are not walls
Cross ref - EP#2400As discussed with Andy, the total parcels escaped through system is incorrect when all boundaries are 'rebound' whilst some of the boundaries are not walls
Cross ref - EP#2400Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/3113meshShrinker and displacementMotionSolver motorbike tutorial documentation - ...2024-03-14T13:32:50ZJohnny JonesmeshShrinker and displacementMotionSolver motorbike tutorial documentation - details not foundHi there,
The meshShrinker displacementMotionSolver examples on the following page clearly show the 16 layers on a complex geometry but none of the tutorials they point to include this geometry and I have not been able to replicate it.
...Hi there,
The meshShrinker displacementMotionSolver examples on the following page clearly show the 16 layers on a complex geometry but none of the tutorials they point to include this geometry and I have not been able to replicate it.
https://www.openfoam.com/news/main-news/openfoam-v2312/pre-processing#snappy_layers
Can you please let me know where I can find the working snappyHexMesh file that enabled this motorbike mesh using the displacementMotionSolver.
Thanks!
JJhttps://develop.openfoam.com/Development/openfoam/-/issues/3111Support for Radial Basis Function (RBF) based mesh deformation2024-03-21T11:43:48ZAqeel AhmedSupport for Radial Basis Function (RBF) based mesh deformation### Functionality to add/problem to solve
Large mesh deformations on complex meshes require specilized methods to avoid mesh quality issues.
It becomes challenging to control the mesh quality with existing displacement based mesh motion...### Functionality to add/problem to solve
Large mesh deformations on complex meshes require specilized methods to avoid mesh quality issues.
It becomes challenging to control the mesh quality with existing displacement based mesh motion solvers for large deformations.
In the OpenFOAM journal article [2] it was also mentioned that for large deformations advanced techniques could help. An extract form figure 12 caption: "These results highlight the need for advanced mesh motion techniques in OpenFOAM".
### Target audience
All practical FSI cases with complex meshes.
Mesh deformations with fine boundary layers.
### Proposal
RBF morphing techniques have proven to be robust for large variety of problems among others [2].
One of the motion solver using RFB is available in an another library solids4Foam [3]. However, this implementation relies on external library and is not maintained anymore. If possible, would really benefit the community if this could be implemented in OpenFOAM directly.
### What does success look like, and how can we measure that?
Ability to deform complex meshes with large deformations.
A minimal example is provided here:[flapDeformation.zip](/uploads/fa8541188d3a1c22eab91f2cc257a952/flapDeformation.zip)
[meshAndDefInfo.pdf](/uploads/239c5b577c90be8e7a96e22df3f367e6/meshAndDefInfo.pdf)
### Links / references
[1] OpenFOAM-preCICE: Coupling OpenFOAM with External Solvers for Multi-Physics Simulations. https://journal.openfoam.com/index.php/ofj/article/view/88
[2] CFD Methodology for Wind Turbines Fluid-Structure Interaction. https://theses.hal.science/tel-01562675
[3] https://github.com/solids4foam/solids4foam/tree/master/src/RBFMeshMotionSolverhttps://develop.openfoam.com/Development/openfoam/-/issues/3110ENH: Make desorption optional2024-03-14T05:22:13ZPrashant SonakarENH: Make desorption optionalCross ref - EP#2341
Existing sorption BC enables desorption as default mode.
It would be nice to have this as optional feature.
e.g. with bool allowDesorption [after line](https://develop.openfoam.com/Development/openfoam/-/blob/maste...Cross ref - EP#2341
Existing sorption BC enables desorption as default mode.
It would be nice to have this as optional feature.
e.g. with bool allowDesorption [after line](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/thermophysicalModels/reactionThermo/derivedFvPatchFields/speciesSorption/speciesSorptionFvPatchScalarField.C#L372)
```
if (!allowDesorption_)
{
dfldp_ = max(dfldp_, 0.0);
}
```Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/3106snappyHexMesh parallel feature attraction2024-02-22T16:08:39ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsnappyHexMesh parallel feature attraction<!--
*** 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 -->
snappyHexMesh is not parallel consistent
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Not sure. Visual inspection of code.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
Ideally same behaviour parallel/non-parallel
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2312|v2306|v2212|v2206|v2112 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2312
- 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 mesh faces to access mesh face informationMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/3105redistributePar (with cyclicAMI) to more processors2024-03-18T12:15:41ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comredistributePar (with cyclicAMI) to more processors<!--
*** 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 -->
Changing decomposeParDict to be more processors and running `redistributePar -parallel` hangs.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
```
cd tutorials/incompressible/pimpleFoam/laminar/mixerVesselAMI2D/mixerVesselAMI2D
decomposePar (into e.g. 4 processors)
```
In `system/controlDict` change to `startFrom latestTime` and `stopAt writeNow`. Change decomposeParDict to use more processors (e.g. 8) and `mpirun -np 8 redistributePar -parallel`. This hangs - processors that already have mesh get stuck in `Foam::fvMesh::init`. Processors that are new get stuck in earlier code:
```
15 0x00007f2c1eecb930 in Foam::IOobject::readAndCheckHeader(bool, Foam::word const&, bool, bool, bool) () from develop/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so
#16 0x00007f2c215fae69 in Foam::fvMesh::init(bool) () from develop/platforms/linux64GccDPInt32Opt/lib/libfiniteV
```
### Example case
See above.
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
### What is the current *bug* behaviour?
See above.
<!-- What actually happens -->
### What is the expected *correct* behavior?
Write redistributed mesh to new time directory, including on the new processors.
<!-- 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 : v2312|v2306|v2212|v2206|v2112 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :v2312
- 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
-->
@markhttps://develop.openfoam.com/Development/openfoam/-/issues/3104Molecular diffusion in icoReactingMultiphaseInterFoam2024-02-21T13:26:23ZPhil NamesnikMolecular diffusion in icoReactingMultiphaseInterFoam### Summary
I'm working on evaporation of water and diffusion of water vapour in air and encountered a problem when using the icoReactingMultiphaseInterFoam solver with laminar flows. As a testcase I use a cuboidal 1D rod with dimension...### Summary
I'm working on evaporation of water and diffusion of water vapour in air and encountered a problem when using the icoReactingMultiphaseInterFoam solver with laminar flows. As a testcase I use a cuboidal 1D rod with dimensions 500 mm x 1 mm x 1 mm and a discretization of 2000 x 1 x 1 (simpleGrading 1,1,1). To keep it simple this rod is completely filled with air (at first no water phase is initialized). On the left end of the rod a fixedValue boundary condition is applied with a vapour mass fraction of 0.01, whereas on the right end a fixedValue of 0 is applied. All other boundaries are of type empty.
The expected behaviour is a diffusive transport of vapour species through air governed by Fick's second law. What actually happens is no transport at all.
### Steps to reproduce
Use a domain without any inflows or outflows and zero velocity leading to a dominant molecular diffusion. Set one vapour mass fraction boundary condition to a higher value than the rest of the domain. Switch to laminar model in turbulenceProperties and use `addDiffusion true;` in thermophysicalProperties.gas.
### Example case
[1D_diffusion.zip](/uploads/192c6df0d7b2a42a60e620bd89746a54/1D_diffusion.zip)
### What is the current _bug_ behaviour?
Molecular diffusion is not working in laminar cases in icoReactingMultiphaseInterFoam.
### What is the expected _correct_ behavior?
Water vapour diffuses from regions/boundaries with high vapour mass fraction to regions of lower mass fraction according to Fick's second law.
### Environment information
- OpenFOAM version : v2212
- Operating system : ubuntu
- Compiler : gcc
### Possible fixes
In `OpenFOAM-v2212/src/phaseSystemModels/multiphaseInter/phasesSystem/phaseModel/MultiComponentPhaseModel/MultiComponentPhaseModel.C:418` the mass diffusivity for the diffusion equation is calculated only using turbulent viscosity `nut()`. For laminar cases `nut()` is set to 0 leading to a deactivation of diffusion. Changing `nut()` to `nuEff()` solves the problem by calculating the diffusion coefficient based on both molecular and turbulent viscosity.https://develop.openfoam.com/Development/openfoam/-/issues/3103unable to use mpirun in precomplied windows version2024-03-04T06:18:45Z加成 唐unable to use mpirun in precomplied windows versionHi,It's maybe a stupid question and I'm new to openfoam. but I can't use mpi to run job in paraell in precomplied openfoam at windows platform.
I'm using `mpirundebug -normal -np 6 potentialFoam -parallel`
and I'm getting
```
Error enc...Hi,It's maybe a stupid question and I'm new to openfoam. but I can't use mpi to run job in paraell in precomplied openfoam at windows platform.
I'm using `mpirundebug -normal -np 6 potentialFoam -parallel`
and I'm getting
```
Error encountered:
Unsupported WM_MPLIB setting : MSMPI
```
and I already installed msmpi like
![image](/uploads/108b30df08e09bf572264bd473138d4e/image.png)
Thanks for helping!Pawan GhildiyalPawan Ghildiyalhttps://develop.openfoam.com/Development/openfoam/-/issues/3101AOCC link errors for utilities depending on CGAL in OpenFOAM 2306/23122024-02-27T13:17:33ZNing LiAOCC link errors for utilities depending on CGAL in OpenFOAM 2306/2312<!--
*** 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 compiling OpenFOAM 2306 or 2312 with the AMD AOCC 4.1 compiler, there are link errors with a few OpenFOAM utilities that depend on CGAL. Specifically, paths to the dependent gmp and mpfr libraries are somehow not properly injected into the build system resulting in failure at link time.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
We are seeing this from a Spack build:
> spack install -v openfoam@2306%aocc@4.1.0
I am undecided if this is an OpenFOAM issue or if this is an issue with its Spack recipe (so forgive me if this turns out to be the wrong place to file an issue). However, what I can say for sure is this problem did not exist in v2212 and earlier, and it was likely to be introduced by code changes in https://develop.openfoam.com/Development/openfoam/-/commit/74d65ed018b067065beb9353cc06cc35e52572ee. I'd like to have the developers' opinions on this.
### 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.
-->
```
ld.lld: error: undefined symbol: __gmpq_clear
>>> referenced by surfaceBooleanFeatures.C
>>> /tmp/root/spack-stage/spack-stage-openfoam-2306-temgrqjteus5nqfko72pqyrpz7hu5nre/spack-src/build/li
nux64AmdDPInt32-spack/applications/utilities/surface/surfaceBooleanFeatures/surfaceBooleanFeatures.o:(CGAL::Cartesian
KernelFunctors::Construct_point_3>::operator()(CGAL::Return_base_tag, CGAL::Gmpq c
onst&, CGAL::Gmpq const&, CGAL::Gmpq const&) const)
>>> referenced by surfaceBooleanFeatures.C
>>> /tmp/root/spack-stage/spack-stage-openfoam-2306-temgrqjteus5nqfko72pqyrpz7hu5nre/spack-src/build/li
nux64AmdDPInt32-spack/applications/utilities/surface/surfaceBooleanFeatures/surfaceBooleanFeatures.o:(CGAL::Cartesian
KernelFunctors::Construct_point_3>::operator()(CGAL::Return_base_tag, CGAL::Gmpq c
onst&, CGAL::Gmpq const&, CGAL::Gmpq const&) const)
>>> referenced by surfaceBooleanFeatures.C
>>> /tmp/root/spack-stage/spack-stage-openfoam-2306-temgrqjteus5nqfko72pqyrpz7hu5nre/spack-src/build/li
nux64AmdDPInt32-spack/applications/utilities/surface/surfaceBooleanFeatures/surfaceBooleanFeatures.o:(CGAL::PointC3>::~PointC3())
>>> referenced 549 more times
```
and repeated many times for other gmp/mpfr symbols
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2312|v2306
Operating system : tested on rocky 8 linux but should apply to other OS
Hardware info : any info that may help?
Compiler : AOCC 4.1 (based on clang 16.0)
-->
- OpenFOAM version : v2312|v2306
- Operating system : tested on rocky 8 linux but should apply to other OS
- Hardware info : not relevant
- Compiler : AOCC 4.1 (based on clang 16.0)
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->
I don't have a proper fix yet. My workaround is to patch the affected OpenFOAM utilities' `Make/options` files and replacing the `$(CGAL_LIBS)` there by an actual path containing the proper -L and -l options pointing to cgal/gmp/mpfr installations. Ideally the fix should be done at locations where the value of `$(CGAL_LIBS)` gets populated but I don't know how.https://develop.openfoam.com/Development/openfoam/-/issues/3100misleading doc typo2024-02-21T13:25:59Zzah pmisleading doc typoon this page:
https://www.openfoam.com/documentation/user-guide/3-running-applications/3.2-running-applications-in-parallel
it gives example of coeffs `n (2 2 1);`, and then then next line in simple method explains "Simple geometric...on this page:
https://www.openfoam.com/documentation/user-guide/3-running-applications/3.2-running-applications-in-parallel
it gives example of coeffs `n (2 2 1);`, and then then next line in simple method explains "Simple geometric decomposition in which the domain is split into pieces by direction, e.g. 2 pieces in the x direction, 1 in y etc."
but its actually 2 pieces in x, 2 in y, and 1 in z.
also would be nice to mention that the numbers should match the total number of subdomains: 2x2x1 = 4https://develop.openfoam.com/Development/openfoam/-/issues/3093Restart of lagrangian particles fails for reactingParcelFoam dependent on dom...2024-01-29T07:45:01ZUwe JanoskeRestart of lagrangian particles fails for reactingParcelFoam dependent on domain decomposition**Case particles impining on cube:**
Particles are impinging on a cube and form a liquid film with the solver reactingParcelFoam (V22/12).
The duration of the spray is 1000 s. The simulation (on single processor) shows the impingment and...**Case particles impining on cube:**
Particles are impinging on a cube and form a liquid film with the solver reactingParcelFoam (V22/12).
The duration of the spray is 1000 s. The simulation (on single processor) shows the impingment and the formation of a film and after approx. 1.5 the re-entrainment of particles back in the flow. The simulation is splitted in two simulations 0-1s and 1-2s which is a restart of the results for 1s (starting from latestTime).
The results show (see massfilm.jpg) different results based on single / parallel simulation:
- single processor: Mass of film increases after the restart (which was expected)
- 4 proc. (simple 4/1/1) which is a distribution where the particle positons for the injection in reactingCloudProperties are on one processor shows the same results, like on a single processor. The mass of film increases after the restart
- 4 proc. (simple 1/2/2) which is a distribution where the particle injection positions are not on one procesor fails. After the restart no particles are injected and the mass drops.
![massfilm](/uploads/842fe65009eb81231dfca4e2b4599866/massfilm.jpg)
This is a reproducible behaviour for the steps
1. Use endtime = 1 s in controlDict. Run reactingParcelFoam > log1
2. Change endtime = 2 s in controlDict. Run reactingParcelFoam > log2
3. Evaluate result: cat log1 log2 > log
4. ./auswert_particles and look at the mass in the system
This can be run for three different cases, single, parallel (1/2/2) and parallel (4/1/1) distribution in simple decomposition.
Summary:
I.e. dependent on domain decomposition the restart works or works not.
### Testcase
[testcase_cube.tar.gz](/uploads/51ff3d806fe99e599e02b7407b53a230/testcase_cube.tar.gz)
### Environment information
OpenFOAM version : v2212
Operating system : ubuntu
Hardware info : different systems
Compiler : gcc
### Possible fixes
If one removes uniform directory in processor?/1 in all directories and sets start of injection SOI in reactingCloudProperties equal 1 the particles seem to be calculated again independent on decomposition