Development issueshttps://develop.openfoam.com/groups/Development/-/issues2024-03-28T11:36:24Zhttps://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/3118snappyHexMesh with cyclic BC: Had *** baffles to create but encountered *** ...2024-03-28T09:14:50ZGuanyang 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/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/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/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/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/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/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/2595FPE in snappyHexMesh : motorBike2024-03-19T15:07:40ZPawan GhildiyalFPE in snappyHexMesh : motorBikeHello,
OpenFOAM-v2206
Machine : AMD
Compiler : AMD
**64 bit and 32 label**
**wmake -show-cxx**
-std=c++14 -m64 -pthread -DOPENFOAM=2206 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unu...Hello,
OpenFOAM-v2206
Machine : AMD
Compiler : AMD
**64 bit and 32 label**
**wmake -show-cxx**
-std=c++14 -m64 -pthread -DOPENFOAM=2206 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter
-Wno-invalid-offsetof -Wno-undefined-var-template -Wno-unknown-warning-option -O3 -DNoRepository -ftemplate-depth-100 -march=znver3 -fPIC
_snappyHexMesh crashes with FPE error(motorBike case ). However it works if we set FOAM_SIGFPE as false. Same with streamlines FO in the tutorial (pitzDaily)_
If we remove this option -march=znver3 (AMD optimisation flag, similar to AVX in intel), then case works without issue and also no need to set FOAM_SIGFPE as false
Attaching the snappyHexMesh.log file which fail showing sig fault. [log.snappyHexMesh](/uploads/551185948652dbc412b67c21fd92062c/log.snappyHexMesh) fault.https://develop.openfoam.com/Development/openfoam/-/issues/2958Add -ffp-contract=off for Clang 14 and later2024-03-19T15:07:40ZGuanyang XueAdd -ffp-contract=off for Clang 14 and later### Summary
Clang 14 changed its floating-point behavior. Now the default is `-ffp-contract=on` even with `-O0`
### Steps to reproduce
FMA is enabled by default for Clang 14 and later. This doesn't seem like an issue for x86 (because ...### Summary
Clang 14 changed its floating-point behavior. Now the default is `-ffp-contract=on` even with `-O0`
### Steps to reproduce
FMA is enabled by default for Clang 14 and later. This doesn't seem like an issue for x86 (because of different CPU instructions to do FMA), but for arm64 things like `libsampling` can easily fail.
### Example case
`tutorials/incompressible/simpleFoam/backwardFacingStep2D` leads to infinite loop when running the `sample` function.
### What is the current *bug* behaviour?
A lot of tutorial cases using `libsampling` will be trapped in infinite loop. Any code related to computational geometry may get unexpected results.
### What is the expected *correct* behavior?
The floating-point calculation should strictly follow IEEE-754 to avoid any potential bug that is almost impossible to debug.
### Relevant logs and/or images
https://releases.llvm.org/14.0.0/tools/clang/docs/ReleaseNotes.html#floating-point-support-in-clang
### Environment information
- OpenFOAM version : Any
- Operating system : Any
- Hardware info : Most likely affecting arm64
- Compiler : Clang 14 and later
### Possible fixes
I don't know if it's possible to add flags in wmake rules based on compiler version. I would propose add `-ffp-contract=off` explicitly to the general Clang wmake rule as it doesn't change anything before Clang 13. For `Arm` and `Fujitsu`, it should be added automatically.v2406Mark OLESENMark OLESENhttps://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/2236Can't run decomposePar -fields after parallel snappyHexMesh due to lack of fa...2024-03-15T12:42:43ZRobin KnowlesCan't run decomposePar -fields after parallel snappyHexMesh due to lack of faceProcAddressing files<!--
*** 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
`decomposePar -fields` cannot be run _after_ parallel `snappyHexMesh` due to missing `faceProcAddressing` files.
### Steps to reproduce
- mesh the `motorbike` tutorial in parallel
- copy `0.orig` to `0`
- run `decomposePar -fields`
### What is the current *bug* behaviour?
`decomposePar -fields` fails with the error:
```
Processor 0: field transfer
--> FOAM FATAL ERROR: (openfoam-2106)
cannot find file "/home/openfoam/processor0/constant/polyMesh/faceProcAddressing"
From virtual Foam::autoPtr<Foam::ISstream> Foam::fileOperations::uncollatedFileOperation::readStream(Foam::regIOobject&, const Foam::fileName&, const Foam::word&, bool) const
in file global/fileOperations/uncollatedFileOperation/uncollatedFileOperation.C at line 542.
FOAM exiting
```
### What is the expected *correct* behavior?
`decomposePar -fields` should propagate the fields in the `0` (or any other specified time directory) to the existing processor directories, parsing any `include` directives, expressions &/or regex present in the boundary condition dictionaries.
### 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 : v2106
- Operating system : Ubuntu / Docker
- Hardware info : Mac
- Compiler : Pre-Compiled Binaries / Docker images
Related issue: #2235Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://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/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/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/1067Problem with wave boundary conditions2024-03-08T22:57:31ZJohan RoenbyProblem with wave boundary conditionsThe wave boundary conditions are introducing a small fraction of air in the water phase. This is illustrated in the attached video:
![streamFunWaveProblem](/uploads/e4972a4f225032115a5583500e15852c/streamFunWaveProblem.mp4)
which shows...The wave boundary conditions are introducing a small fraction of air in the water phase. This is illustrated in the attached video:
![streamFunWaveProblem](/uploads/e4972a4f225032115a5583500e15852c/streamFunWaveProblem.mp4)
which shows the 0.99 and 0.9999 alpha contours of the $FOAM_TUTORIALS/multiphase/interFoam/laminar/waveExampleStreamFunction case.
The case was run as is.
If run with interIsoFoam instead of interFoam, isoAdvector collects the small amount of air in the water phase into bubbles that rise to the surface. A work around is to run interIsoFoam with surfCellTol = 1e-2 in fvSolution.solvers."alpha.water.*". But really this seems to be a problem with the wave BC's and not with isoAdvector.
A Paraview state file used to generate the movie is attached here: [state2.pvsm](/uploads/0ae150172498bbf215446260ada7e1e5/state2.pvsm)v1812Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/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/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/2779OpenFOAM overset restart not working2024-02-28T12:15:17ZGabriel Barajasbarajasg@unican.esOpenFOAM overset restart not working**Summary**
Dear all,
If I run the floating Object tutorials with the deforming mesh approach, either with the _rigidBodyMeshMotion_ library or the _sixDoFRigidBodyMotion_ library, I can stop and restart the simulation and everything w...**Summary**
Dear all,
If I run the floating Object tutorials with the deforming mesh approach, either with the _rigidBodyMeshMotion_ library or the _sixDoFRigidBodyMotion_ library, I can stop and restart the simulation and everything works correctly. I enclose figures of both cases: in purple a simulation starting in 0.0s and ending in 6.0s, and in green a simulation starting in 1.0s (copied from the previous case) and ending in 6.0s.
Deforming Mesh + rigidBodyMeshMotion:
![deforming_rigidBodyMotion_1.5s](/uploads/b2c69cea59114aff9b1f196bbbdb1877/deforming_rigidBodyMotion_1.5s.png)
![deforming_rigidBodyMotion_4.5s](/uploads/3d020d36c5a95cd92e2d892010b62468/deforming_rigidBodyMotion_4.5s.png)
Deforming Mesh + sixDoFRigidBodyMotion:
![deformingMesh_6DoF_1.5s](/uploads/b1d6691d5153372a7ce7d841d08afd17/deformingMesh_6DoF_1.5s.png)
![deformingMesh_6DoF_4.5s](/uploads/e3a0bd519467085eb62955b598b1d1a9/deformingMesh_6DoF_4.5s.png)
But, when I I try to the same within the overset framework, it does not work:
![overset_6DoF_1.2s](/uploads/b5977f8947a31015ff67dea697abe711/overset_6DoF_1.2s.png)
I believe that the code is not reading correctly all the variables and probably using some default values that normally are zero, as if it was starting from a rest position.
**Steps to reproduce**
I enclose the case to reproduce the issue. First run the case normally, afterwards try to re-run it starting from the time t=1.0s.
Check the motion of the floating body in both cases.
**Example case**
[floatingBody.tar.xz](/uploads/6a915eca6e10f51ee77e9f99e38e2015/floatingBody.tar.xz)
Thanks,
Gabihttps://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.