Development issueshttps://develop.openfoam.com/groups/Development/-/issues2020-04-22T20:57:59Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1577typo in FULLDEBUG2020-04-22T20:57:59ZPer Jørgensentypo in FULLDEBUGsrc/OpenFOAM/expressions/exprResult/exprResultGlobals.C line 206
sortToc -> sortedTocsrc/OpenFOAM/expressions/exprResult/exprResultGlobals.C line 206
sortToc -> sortedTocMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1534Wiki home: broken link to page "Submitting issues"2019-12-27T10:02:17ZGerasimos ChourdakisWiki home: broken link to page "Submitting issues"In the [wiki home](https://develop.openfoam.com/Development/openfoam/wikis/home), in the sentence:
```
Users can provide feedback by submitting *issues* or *feature requests*; please see [Submitting Issues](/Development/openfoam/wikis/p...In the [wiki home](https://develop.openfoam.com/Development/openfoam/wikis/home), in the sentence:
```
Users can provide feedback by submitting *issues* or *feature requests*; please see [Submitting Issues](/Development/openfoam/wikis/page-submitting-issues)
```
the [Submitting Issues](https://develop.openfoam.com/Development/openfoam/wikis/Submitting-issues) link is broken. Replace with:
```
Users can provide feedback by submitting *issues* or *feature requests*; please see [Submitting Issues](/Development/openfoam/wikis/Submitting-issues)
```https://develop.openfoam.com/Development/openfoam/-/issues/647ENH: turbulentMixingLengthDissipationRateInlet Cmu lookup for realizableKE2020-06-12T17:35:58ZAdminENH: turbulentMixingLengthDissipationRateInlet Cmu lookup for realizableKEIn turbulentMixingLengthDissipationRateInletFvPatchScalarField.C Cmu appears to be looked up or defaulted to a constant of 0.09...
```c
// Lookup Cmu corresponding to the turbulence model selected
const turbulenceModel& turbModel = ...In turbulentMixingLengthDissipationRateInletFvPatchScalarField.C Cmu appears to be looked up or defaulted to a constant of 0.09...
```c
// Lookup Cmu corresponding to the turbulence model selected
const turbulenceModel& turbModel = db().lookupObject<turbulenceModel>
(
IOobject::groupName
(
turbulenceModel::propertiesName,
internalField().group()
)
);
const scalar Cmu =
turbModel.coeffDict().lookupOrDefault<scalar>("Cmu", 0.09);
```
It looks like Cmu is being looked up from the turbulence dictionary in turbulenceProperties. However, for turbulence models like realizableKE where Cmu is not constant, I think Cmu should be looked up from the turbulence model itself. Am I reading this correctly? Thoughts?
\## Reattaching the author to the issue ticket: @graups ##v2006Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/692add additional information in header of decomposedBlockData2024-01-10T16:23:36ZMark OLESENadd additional information in header of decomposedBlockDataWe already have a `blocks` entry, but it would be quite convenient for downstream users (eg, paraview) if we also could pass along the underlying data-type in an easy to find place.
Eg,
FoamFile
{
version 2.0;
...We already have a `blocks` entry, but it would be quite convenient for downstream users (eg, paraview) if we also could pass along the underlying data-type in an easy to find place.
Eg,
FoamFile
{
version 2.0;
format binary;
class decomposedBlockData;
blocks 4;
object U;
dataClass volVectorField;
}
At the moment it is a bit of a pain to get at this information.
Would it be useful to have this dataClass information present as `IOobject::headerDataClassName()` with it being identical to `IOobject::headerClassName()` when `dataClass` isn't present?Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/163decomposePar does not softlink uniform if no fields decomposed2022-11-24T14:58:22ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comdecomposePar does not softlink uniform if no fields decomposedIf there are no fields to decompose the destination time directory never gets created and the softlinks get created in the wrong location.
If there are no fields to decompose the destination time directory never gets created and the softlinks get created in the wrong location.
https://develop.openfoam.com/Development/openfoam/-/issues/1213compressibleInterfoam + twoPhaseTransport2024-02-09T21:57:04ZAdmincompressibleInterfoam + twoPhaseTransport<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
-->
<!--
All text between these marker...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
Per compressibleInterPhaseTransportModel.H by setting switch to twoPhaseTransport should allow separate turbulence models for each phase (RAS, laminar, LES). Test case ...OpenFOAM-v1812/tutorials/multiphase/compressibleInterFoam/laminar/climbingRod provides further explanation but uses laminar turbulence models only. When the stress model is set to e.g. RAS the solver crashes.
### Steps to reproduce
Change the climbingRod test case to RAS and e.g. kOmegaSST, add omega.air, liquid.air, k.air, k.liquid, alphat.air, alphat.liquid to the 0 folder, update the fvSchemes and fvSolution files and run the case.
### Example case
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
[climbingRod.tar.gz](/uploads/03f55cb8fe6922114873583e5c64d8de/climbingRod.tar.gz)
### What is the current *bug* behaviour?
Solver crashes if the turbulence model is set to anything except laminar.
### What is the expected *correct* behavior?
Case should run, or the error messages should provide indication of how to fix the issues (i.e., the "bananas" approach should guide the user in what is missing).
### 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.
-->
![Selection_001](/uploads/f53d7990a742e1be3297a7cf6bda7228/Selection_001.png)
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
OpenFOAM version : v1812
Operating system : Ubuntu 16.04
Compiler : GCC
### Possible fixes
Perhaps use the switch (twoPhaseTransport) should direct the solver to use the turbulence models employed by reactingTwoPhaseEulerFoam, e.g. continuousGasKE?
\## Reattaching the author to the issue ticket: @GXA_William ##v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1155possible issues with conversion from gmsh2021-07-06T15:15:28ZMark OLESENpossible issues with conversion from gmshMentioned in the cfd-online forum https://www.cfd-online.com/Forums/openfoam-meshing/213553-meshing-error-bad-token-could-not-get-word.html by user Dewi Madden.
- could be an OpenFOAM parsing issue,
- or a syntax change in gmsh format
-...Mentioned in the cfd-online forum https://www.cfd-online.com/Forums/openfoam-meshing/213553-meshing-error-bad-token-could-not-get-word.html by user Dewi Madden.
- could be an OpenFOAM parsing issue,
- or a syntax change in gmsh format
- bad input,
- other
Diagnosis awaiting a file or two...Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/ThirdParty-common/-/issues/67Introducing MUI code coupling library into OpenFOAM2024-03-27T16:38:12ZWendi LiuIntroducing MUI code coupling library into OpenFOAM## Functionality to add/problem to solve
Integrate the code coupling library [Multiscale Universal Interface](https://mxui.github.io/) in OpenFOAM as a third-party library to couple OpenFOAM with other solvers or OpenFOAM with itself.
...## Functionality to add/problem to solve
Integrate the code coupling library [Multiscale Universal Interface](https://mxui.github.io/) in OpenFOAM as a third-party library to couple OpenFOAM with other solvers or OpenFOAM with itself.
## Target audience
Users who want to couple OpenFOAM with other solvers or OpenFOAM with itself.
## Proposal
A working general integration of MUI is proposed by applying the following patch to the ThirdParty repository.
[muiIntegrationTP.patch](/uploads/9b0637fcc8137a818b65f31875d6e40f/muiIntegrationTP.patch)
Below is a summarise of what have been added and modified.
- Modified `Allwmake` to include script to build MUI.
- Added build script `makeMUI.`
- Added MUI related patch file `etc/patches/MUI-2.0` to resolve ambiguity issue between MUI-v2.0 and OpenFOAM. We have merged the changes into the MUI repository, so that no patch files will be needed in future MUI releases.
- Updated `BUILD.md` and `SOURCES.md` to include MUI related documentations.
## Related issue
[openfoam issue #3127](https://develop.openfoam.com/Development/openfoam/-/issues/3127)
## What does success look like, and how can we measure that?
The Patch has been tested with the ThirdParty development repository (commit 7ff69fa1a733b45b069a387fd0c275b15b7f2150).
The proposed changes can be patched and tested as follows
- Clone Development Repositories
```
git clone https://develop.openfoam.com/Development/ThirdParty-common.git
git clone https://develop.openfoam.com/Development/openfoam.git
```
- Obtain the MUI source file in the ThirdParty Repository
```
cd ThirdParty-common/sources
mkdir mui && cd mui
wget https://github.com/MxUI/MUI/archive/refs/tags/2.0.tar.gz
tar -xf 2.0.tar.gz && rm 2.0.tar.gz
```
- Obtain and place patches in Repositories
- Patch
```
cd openfoam/
patch -p2 < muiIntegrationOF.patch
rm muiIntegrationOF.patch
cd ../ThirdParty-common/
patch -p2 < muiIntegrationTP.patch
rm muiIntegrationTP.patch
```
- Change permission of newly added files if needed
- Enable MUI support (MUI is disabled by default)
- Modify L37 of `openfoam/etc/config.sh` to change `mui_version=MUI-none` into `mui_version=MUI-2.0`
- Source and Allwmake
```
cd openfoam/
source etc/bashrc
./Allwmake -j 4
```
- Test MUI enabled OpenFOAM
```
cd openfoam/applications/test/coupling-MUI
./testCase/Allrun
cd openfoam/tutorials/basic/laplacianFoamMUI
./AllrunCoupled
```
If MUI library successfully integrated, the following log messages can be found for the `coupling-MUI` unit test.
```
...
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time
Create mesh for time = 0
```
If MUI library successfully integrated, the following log messages can be found for the `laplacianFoamMUI` tutorial.
```
....
MUI [lib_mpi_multidomain]: Rank: 2, "domain2" registered interface "interface_twoD_1" as 59a4e385
MUI [lib_mpi_multidomain]: Rank: 3, "domain2" registered interface "interface_twoD_1" as 59a4e385
MUI Info [lib_mpi_multidomain]: 1 distinct interface(s) found
MUI [lib_mpi_multidomain]: Setting up interface interface_twoD_1 [59a4e385] (rank ids are local to each interface)
MUI [comm_mpi.h]: Rank: 3, Identifier: mpi://domain2/interface_twoD_1, Domain size: 2, Peers: 2
MUI [comm_mpi.h]: Rank: 2, Identifier: mpi://domain2/interface_twoD_1, Domain size: 2, Peers: 2
MUI [comm_mpi.h]: Rank: 1, Identifier: mpi://domain1/interface_twoD_1, Domain size: 2, Peers: 2
MUI [comm_mpi.h]: Rank: 0, Identifier: mpi://domain1/interface_twoD_1, Domain size: 2, Peers: 2
MUI [lib_mpi_multidomain]: Rank: 2, "domain2" registered interface "interface_threeD_1" as 31f80b7e
MUI [lib_mpi_multidomain]: Rank: 1, "domain1" registered interface "interface_threeD_1" as 31f80b7e
MUI [lib_mpi_multidomain]: Rank: 3, "domain2" registered interface "interface_threeD_1" as 31f80b7e
MUI [lib_mpi_multidomain]: Rank: 0, "domain1" registered interface "interface_threeD_1" as 31f80b7e
MUI Info [lib_mpi_multidomain]: 1 distinct interface(s) found
MUI [lib_mpi_multidomain]: Setting up interface interface_threeD_1 [31f80b7e] (rank ids are local to each interface)
MUI [comm_mpi.h]: Rank: 0, Identifier: mpi://domain1/interface_threeD_1, Domain size: 2, Peers: 2
MUI [comm_mpi.h]: Rank: 3, Identifier: mpi://domain2/interface_threeD_1, Domain size: 2, Peers: 2
MUI [comm_mpi.h]: Rank: 2, Identifier: mpi://domain2/interface_threeD_1, Domain size: 2, Peers: 2
MUI [comm_mpi.h]: Rank: 1, Identifier: mpi://domain1/interface_threeD_1, Domain size: 2, Peers: 2
MUI [lib_mpi_multidomain]: Rank: 2, "domain2" registered interface "interface_T_1" as 4a5523ab
MUI [lib_mpi_multidomain]: Rank: 1, "domain1" registered interface "interface_T_1" as 4a5523ab
MUI [lib_mpi_multidomain]: Rank: 0, "domain1" registered interface "interface_T_1" as 4a5523ab
MUI [lib_mpi_multidomain]: Rank: 3, "domain2" registered interface "interface_T_1" as 4a5523ab
MUI Info [lib_mpi_multidomain]: 1 distinct interface(s) found
MUI [lib_mpi_multidomain]: Setting up interface interface_T_1 [4a5523ab] (rank ids are local to each interface)
MUI [comm_mpi.h]: Rank: 0, Identifier: mpi://domain1/interface_T_1, Domain size: 2, Peers: 2
MUI [comm_mpi.h]: Rank: 1, Identifier: mpi://domain1/interface_T_1, Domain size: 2, Peers: 2
MUI [comm_mpi.h]: Rank: 3, Identifier: mpi://domain2/interface_T_1, Domain size: 2, Peers: 2
MUI [comm_mpi.h]: Rank: 2, Identifier: mpi://domain2/interface_T_1, Domain size: 2, Peers: 2
Calculating temperature distribution
Calculating temperature distribution
Time = 0.005
Time = 0.005
MUI interface "domain1"/"interface_twoD_1" value committed: 1 at Iteration = 0
MUI interface "domain2"/"interface_twoD_1" value committed: 1 at Iteration = 0
MUI interface "domain1"/"interface_threeD_1" value committed: 2 at Iteration = 0
MUI interface "domain1"/"interface_T_1" value committed: 3 at Iteration = 0
MUI interface "domain2"/"interface_threeD_1" value committed: 2 at Iteration = 0
MUI interface "domain2"/"interface_T_1" value committed: 3 at Iteration = 0
DICPCG: Solving for T, Initial residual = 1, Final residual = 8.33243e-07, No Iterations 7
DICPCG: Solving for T, Initial residual = 0.00446911, Final residual = 7.14892e-07, No Iterations 4
DICPCG: Solving for T, Initial residual = 0.000148123, Final residual = 6.63323e-07, No Iterations 2
MUI interface "domain1"/"interface_twoD_1" value fetched: 1 at Iteration = 0
MUI interface "domain1"/"interface_threeD_1" value fetched: 2 at Iteration = 0
MUI interface "domain1"/"interface_T_1" value fetched: 3 at Iteration = 0
ExecutionTime = 0.07 s ClockTime = 0 s
Time = 0.01
MUI interface "domain1"/"interface_twoD_1" value committed: 1 at Iteration = 1
MUI interface "domain1"/"interface_threeD_1" value committed: 2 at Iteration = 1
MUI interface "domain1"/"interface_T_1" value committed: 3 at Iteration = 1
DICPCG: Solving for T, Initial residual = 0.203755, Final residual = 1.57027e-07, No Iterations 7
DICPCG: Solving for T, Initial residual = 0.00184337, Final residual = 2.32416e-07, No Iterations 4
DICPCG: Solving for T, Initial residual = 1, Final residual = 8.33243e-07, No Iterations 7
DICPCG: Solving for T, Initial residual = 5.70921e-05, Final residual = 2.8776e-07, No Iterations 2
DICPCG: Solving for T, Initial residual = 0.00446911, Final residual = 7.14892e-07, No Iterations 4
DICPCG: Solving for T, Initial residual = 0.000148123, Final residual = 6.63323e-07, No Iterations 2
MUI interface "domain2"/"interface_twoD_1" value fetched: 1 at Iteration = 0
MUI interface "domain2"/"interface_threeD_1" value fetched: 2 at Iteration = 0
MUI interface "domain2"/"interface_T_1" value fetched: 3 at Iteration = 0
ExecutionTime = 0.1 s ClockTime = 0 s
Time = 0.01
MUI interface "domain2"/"interface_twoD_1" value committed: 1 at Iteration = 1
MUI interface "domain2"/"interface_threeD_1" value committed: 2 at Iteration = 1
MUI interface "domain2"/"interface_T_1" value committed: 3 at Iteration = 1
MUI interface "domain1"/"interface_twoD_1" value fetched: 1 at Iteration = 1
MUI interface "domain1"/"interface_threeD_1" value fetched: 2 at Iteration = 1
MUI interface "domain1"/"interface_T_1" value fetched: 3 at Iteration = 1
ExecutionTime = 0.08 s ClockTime = 0 s
Time = 0.015
MUI interface "domain1"/"interface_twoD_1" value committed: 1 at Iteration = 2
MUI interface "domain1"/"interface_threeD_1" value committed: 2 at Iteration = 2
MUI interface "domain1"/"interface_T_1" value committed: 3 at Iteration = 2
DICPCG: Solving for T, Initial residual = 0.109922, Final residual = 4.92455e-07, No Iterations 6
DICPCG: Solving for T, Initial residual = 0.00104616, Final residual = 7.0666e-07, No Iterations 3
DICPCG: Solving for T, Initial residual = 3.13839e-05, Final residual = 1.66653e-07, No Iterations 2
DICPCG: Solving for T, Initial residual = 0.203755, Final residual = 1.57027e-07, No Iterations 7
DICPCG: Solving for T, Initial residual = 0.00184337, Final residual = 2.32416e-07, No Iterations 4
DICPCG: Solving for T, Initial residual = 5.70921e-05, Final residual = 2.8776e-07, No Iterations 2
MUI interface "domain2"/"interface_twoD_1" value fetched: 1 at Iteration = 1
MUI interface "domain2"/"interface_threeD_1" value fetched: 2 at Iteration = 1
MUI interface "domain2"/"interface_T_1" value fetched: 3 at Iteration = 1
ExecutionTime = 0.11 s ClockTime = 1 s
Time = 0.015
MUI interface "domain2"/"interface_twoD_1" value committed: 1 at Iteration = 2
MUI interface "domain2"/"interface_threeD_1" value committed: 2 at Iteration = 2
MUI interface "domain2"/"interface_T_1" value committed: 3 at Iteration = 2
DICPCG: Solving for T, Initial residual = 0.109922, Final residual = 4.92455e-07, No Iterations 6
MUI interface "domain1"/"interface_twoD_1" value fetched: 1 at Iteration = 2
MUI interface "domain1"/"interface_threeD_1" value fetched: 2 at Iteration = 2
MUI interface "domain1"/"interface_T_1" value fetched: 3 at Iteration = 2
ExecutionTime = 0.1 s ClockTime = 1 s
...
```https://develop.openfoam.com/Development/openfoam/-/issues/3127Introducing MUI code coupling library into OpenFOAM2024-03-28T11:36:24ZWendi LiuIntroducing MUI code coupling library into OpenFOAM## Functionality to add/problem to solve
Integrate the code coupling library [Multiscale Universal Interface](https://mxui.github.io/) in OpenFOAM as a third-party library to couple OpenFOAM with other solvers or OpenFOAM with itself.
...## Functionality to add/problem to solve
Integrate the code coupling library [Multiscale Universal Interface](https://mxui.github.io/) in OpenFOAM as a third-party library to couple OpenFOAM with other solvers or OpenFOAM with itself.
## Target audience
Users who want to couple OpenFOAM with other solvers or OpenFOAM with itself.
## Proposal
A working general integration of MUI is proposed by applying the following patch to the OpenFOAM repository.
[muiIntegrationOF.patch](/uploads/5522d607255cbd8e128d9e1e860ef0b4/muiIntegrationOF.patch)
Below is a summarise of what have been added and modified.
- Configure MUI inclusion in OpenFOAM.
* Added MUI related commands in the following files
+ `bin/tools/foamConfigurePaths`
+ `etc/config.csh/functions`
+ `etc/config.csh/setup`
+ `etc/config.csh/unset`
+ `etc/config.sh/functions`
+ `etc/config.sh/setup`
+ `etc/config.sh/unset`
* Created the following files to setup MUI include through ThirdParty installation. These files also act as switches for MUI inclusion. MUI is enabled by setting `mui_version=MUI-2.0` in these files and a global variable at compile time `export FOAM_USE_MUI=1` will be set. MUI is disabled by setting `mui_version=MUI-none` in these files. MUI will be disabled by default.
+ `etc/config.csh/mui`
+ `etc/config.sh/mui`
- There is a new folder named `mpi-MUI` in `src/Pstream` contains the MUI integrated Pstream. Make files `src/Pstream/Allwmake` and `src/Pstream/Allwclean` have been modified so that the newly created make files `src/Pstream/Allwmake-mpi-MUI` and `src/Pstream/Allwclean-mpi-MUI` can be called and `mpi-MUI` can be built once `FOAM_USE_MUI=1` is set.
- A new variable `extern MPI_Comm commWorld_;` has been added in `src/Pstream/mpi/PstreamGlobals.H`, `src/Pstream/mpi/PstreamGlobals.C` and `src/Pstream/mpi/UPstream.C` so that to facilitate the replacing of the default `MPI_COMM_WORLD` into the MUI enabled MPI communicator in `mpi-MUI` folder.
- The code piece of `MPI_Init_thread()` in `src/Pstream/mpi/UPstream.C` is proposed to be separated into a header file `mpiInitThread.H` so that to facilitate the MUI library to setup the MPI communicator in `mpi-MUI` folder. In this way, there is no need to modify codes in `src/Pstream/mpi/UPstream.C` directly.
- In `mpi-MUI` folder, there is only two header files `src/Pstream/mpi-MUI/mpiInitThread.H` that contains the MUI returned MPI communicator and `src/Pstream/mpi-MUI/PstreamGlobals.H` aiming to include `mui.h` header file. Once `mpi-MUI` folder is building, the `src/Pstream/Allwclean-mpi-MUI` will copy `UPstream.C` from `mpi` folder to `mpi-MUI` so that the two header files in `mpi-MUI` folder can be included. Other Pstream related header/source files will be used directly from the `mpi` folder as shown in `src/Pstream/mpi-MUI/Make/files`. The inclusion of `-I../mpi` has been put in `src/Pstream/mpi-MUI/Make/options` to enable the directly reuse of files in `mpi` folder. An alternative way to consider is to create soft links of these header/source files from the `mpi` folder.
- Created a new general purpose header file in creating MUI coupling interfaces
* `src/OpenFOAM/include/createCouplingMUI.H`
- There is a new solver in `applications/solvers/basic/laplacianFoamMUI` that shows how to utilise the integration and the way to compile a solver is also shown in the corresponding Make folder options file. Key to this is the inclusion of a new `mpi-MUI-rules` which is located in `wmake/rules/General` and effectively replaces the usual `mpi-rules` normally used. It is mostly the same file but just adds an extra line at the bottom `PINC += -I$(WM_THIRD_PARTY_DIR)/sources/mui/MUI-2.0/src`. There is a new file `wmake/scripts/have_mui` to detection/setup of MUI.
- There is a new tutorial case in `tutorials/basic/laplacianFoamMUI` that shows how to use the laplacianFoamMUI solver and a demo of couplingDict to set MUI coupling related variables.
- There is a new test code in `applications/test/coupling-MUI` that provide a unit test on MUI integration.
- Added MUI library related documentations in the following files in OpenFOAM
* `doc/Requirements.md`
## Related issue
[ThirdParty issue #67](https://develop.openfoam.com/Development/ThirdParty-common/-/issues/67)
## What does success look like, and how can we measure that?
The Patch has been tested with the OpenFOAM development repository (commit e651d63566897f00b049f56d461f48aedb9d129e).
The proposed changes can be patched and tested as follows
- Clone Development Repositories
```
git clone https://develop.openfoam.com/Development/ThirdParty-common.git
git clone https://develop.openfoam.com/Development/openfoam.git
```
- Obtain the MUI source file in the ThirdParty Repository
```
cd ThirdParty-common/sources
mkdir mui && cd mui
wget https://github.com/MxUI/MUI/archive/refs/tags/2.0.tar.gz
tar -xf 2.0.tar.gz && rm 2.0.tar.gz
```
- Obtain and place patches in Repositories
- Patch
```
cd openfoam/
patch -p2 < muiIntegrationOF.patch
rm muiIntegrationOF.patch
cd ../ThirdParty-common/
patch -p2 < muiIntegrationTP.patch
rm muiIntegrationTP.patch
```
- Change permission of newly added files if needed
- Enable MUI support (MUI is disabled by default)
- Modify L37 of `openfoam/etc/config.sh` to change `mui_version=MUI-none` into `mui_version=MUI-2.0`
- Source and Allwmake
```
cd openfoam/
source etc/bashrc
./Allwmake -j 4
```
- Test MUI enabled OpenFOAM
```
cd openfoam/applications/test/coupling-MUI
./testCase/Allrun
cd openfoam/tutorials/basic/laplacianFoamMUI
./AllrunCoupled
```
If MUI library successfully integrated, the following log messages can be found for the `coupling-MUI` unit test.
```
...
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time
Create mesh for time = 0
```
If MUI library successfully integrated, the following log messages can be found for the `laplacianFoamMUI` tutorial.
```
....
MUI [lib_mpi_multidomain]: Rank: 2, "domain2" registered interface "interface_twoD_1" as 59a4e385
MUI [lib_mpi_multidomain]: Rank: 3, "domain2" registered interface "interface_twoD_1" as 59a4e385
MUI Info [lib_mpi_multidomain]: 1 distinct interface(s) found
MUI [lib_mpi_multidomain]: Setting up interface interface_twoD_1 [59a4e385] (rank ids are local to each interface)
MUI [comm_mpi.h]: Rank: 3, Identifier: mpi://domain2/interface_twoD_1, Domain size: 2, Peers: 2
MUI [comm_mpi.h]: Rank: 2, Identifier: mpi://domain2/interface_twoD_1, Domain size: 2, Peers: 2
MUI [comm_mpi.h]: Rank: 1, Identifier: mpi://domain1/interface_twoD_1, Domain size: 2, Peers: 2
MUI [comm_mpi.h]: Rank: 0, Identifier: mpi://domain1/interface_twoD_1, Domain size: 2, Peers: 2
MUI [lib_mpi_multidomain]: Rank: 2, "domain2" registered interface "interface_threeD_1" as 31f80b7e
MUI [lib_mpi_multidomain]: Rank: 1, "domain1" registered interface "interface_threeD_1" as 31f80b7e
MUI [lib_mpi_multidomain]: Rank: 3, "domain2" registered interface "interface_threeD_1" as 31f80b7e
MUI [lib_mpi_multidomain]: Rank: 0, "domain1" registered interface "interface_threeD_1" as 31f80b7e
MUI Info [lib_mpi_multidomain]: 1 distinct interface(s) found
MUI [lib_mpi_multidomain]: Setting up interface interface_threeD_1 [31f80b7e] (rank ids are local to each interface)
MUI [comm_mpi.h]: Rank: 0, Identifier: mpi://domain1/interface_threeD_1, Domain size: 2, Peers: 2
MUI [comm_mpi.h]: Rank: 3, Identifier: mpi://domain2/interface_threeD_1, Domain size: 2, Peers: 2
MUI [comm_mpi.h]: Rank: 2, Identifier: mpi://domain2/interface_threeD_1, Domain size: 2, Peers: 2
MUI [comm_mpi.h]: Rank: 1, Identifier: mpi://domain1/interface_threeD_1, Domain size: 2, Peers: 2
MUI [lib_mpi_multidomain]: Rank: 2, "domain2" registered interface "interface_T_1" as 4a5523ab
MUI [lib_mpi_multidomain]: Rank: 1, "domain1" registered interface "interface_T_1" as 4a5523ab
MUI [lib_mpi_multidomain]: Rank: 0, "domain1" registered interface "interface_T_1" as 4a5523ab
MUI [lib_mpi_multidomain]: Rank: 3, "domain2" registered interface "interface_T_1" as 4a5523ab
MUI Info [lib_mpi_multidomain]: 1 distinct interface(s) found
MUI [lib_mpi_multidomain]: Setting up interface interface_T_1 [4a5523ab] (rank ids are local to each interface)
MUI [comm_mpi.h]: Rank: 0, Identifier: mpi://domain1/interface_T_1, Domain size: 2, Peers: 2
MUI [comm_mpi.h]: Rank: 1, Identifier: mpi://domain1/interface_T_1, Domain size: 2, Peers: 2
MUI [comm_mpi.h]: Rank: 3, Identifier: mpi://domain2/interface_T_1, Domain size: 2, Peers: 2
MUI [comm_mpi.h]: Rank: 2, Identifier: mpi://domain2/interface_T_1, Domain size: 2, Peers: 2
Calculating temperature distribution
Calculating temperature distribution
Time = 0.005
Time = 0.005
MUI interface "domain1"/"interface_twoD_1" value committed: 1 at Iteration = 0
MUI interface "domain2"/"interface_twoD_1" value committed: 1 at Iteration = 0
MUI interface "domain1"/"interface_threeD_1" value committed: 2 at Iteration = 0
MUI interface "domain1"/"interface_T_1" value committed: 3 at Iteration = 0
MUI interface "domain2"/"interface_threeD_1" value committed: 2 at Iteration = 0
MUI interface "domain2"/"interface_T_1" value committed: 3 at Iteration = 0
DICPCG: Solving for T, Initial residual = 1, Final residual = 8.33243e-07, No Iterations 7
DICPCG: Solving for T, Initial residual = 0.00446911, Final residual = 7.14892e-07, No Iterations 4
DICPCG: Solving for T, Initial residual = 0.000148123, Final residual = 6.63323e-07, No Iterations 2
MUI interface "domain1"/"interface_twoD_1" value fetched: 1 at Iteration = 0
MUI interface "domain1"/"interface_threeD_1" value fetched: 2 at Iteration = 0
MUI interface "domain1"/"interface_T_1" value fetched: 3 at Iteration = 0
ExecutionTime = 0.07 s ClockTime = 0 s
Time = 0.01
MUI interface "domain1"/"interface_twoD_1" value committed: 1 at Iteration = 1
MUI interface "domain1"/"interface_threeD_1" value committed: 2 at Iteration = 1
MUI interface "domain1"/"interface_T_1" value committed: 3 at Iteration = 1
DICPCG: Solving for T, Initial residual = 0.203755, Final residual = 1.57027e-07, No Iterations 7
DICPCG: Solving for T, Initial residual = 0.00184337, Final residual = 2.32416e-07, No Iterations 4
DICPCG: Solving for T, Initial residual = 1, Final residual = 8.33243e-07, No Iterations 7
DICPCG: Solving for T, Initial residual = 5.70921e-05, Final residual = 2.8776e-07, No Iterations 2
DICPCG: Solving for T, Initial residual = 0.00446911, Final residual = 7.14892e-07, No Iterations 4
DICPCG: Solving for T, Initial residual = 0.000148123, Final residual = 6.63323e-07, No Iterations 2
MUI interface "domain2"/"interface_twoD_1" value fetched: 1 at Iteration = 0
MUI interface "domain2"/"interface_threeD_1" value fetched: 2 at Iteration = 0
MUI interface "domain2"/"interface_T_1" value fetched: 3 at Iteration = 0
ExecutionTime = 0.1 s ClockTime = 0 s
Time = 0.01
MUI interface "domain2"/"interface_twoD_1" value committed: 1 at Iteration = 1
MUI interface "domain2"/"interface_threeD_1" value committed: 2 at Iteration = 1
MUI interface "domain2"/"interface_T_1" value committed: 3 at Iteration = 1
MUI interface "domain1"/"interface_twoD_1" value fetched: 1 at Iteration = 1
MUI interface "domain1"/"interface_threeD_1" value fetched: 2 at Iteration = 1
MUI interface "domain1"/"interface_T_1" value fetched: 3 at Iteration = 1
ExecutionTime = 0.08 s ClockTime = 0 s
Time = 0.015
MUI interface "domain1"/"interface_twoD_1" value committed: 1 at Iteration = 2
MUI interface "domain1"/"interface_threeD_1" value committed: 2 at Iteration = 2
MUI interface "domain1"/"interface_T_1" value committed: 3 at Iteration = 2
DICPCG: Solving for T, Initial residual = 0.109922, Final residual = 4.92455e-07, No Iterations 6
DICPCG: Solving for T, Initial residual = 0.00104616, Final residual = 7.0666e-07, No Iterations 3
DICPCG: Solving for T, Initial residual = 3.13839e-05, Final residual = 1.66653e-07, No Iterations 2
DICPCG: Solving for T, Initial residual = 0.203755, Final residual = 1.57027e-07, No Iterations 7
DICPCG: Solving for T, Initial residual = 0.00184337, Final residual = 2.32416e-07, No Iterations 4
DICPCG: Solving for T, Initial residual = 5.70921e-05, Final residual = 2.8776e-07, No Iterations 2
MUI interface "domain2"/"interface_twoD_1" value fetched: 1 at Iteration = 1
MUI interface "domain2"/"interface_threeD_1" value fetched: 2 at Iteration = 1
MUI interface "domain2"/"interface_T_1" value fetched: 3 at Iteration = 1
ExecutionTime = 0.11 s ClockTime = 1 s
Time = 0.015
MUI interface "domain2"/"interface_twoD_1" value committed: 1 at Iteration = 2
MUI interface "domain2"/"interface_threeD_1" value committed: 2 at Iteration = 2
MUI interface "domain2"/"interface_T_1" value committed: 3 at Iteration = 2
DICPCG: Solving for T, Initial residual = 0.109922, Final residual = 4.92455e-07, No Iterations 6
MUI interface "domain1"/"interface_twoD_1" value fetched: 1 at Iteration = 2
MUI interface "domain1"/"interface_threeD_1" value fetched: 2 at Iteration = 2
MUI interface "domain1"/"interface_T_1" value fetched: 3 at Iteration = 2
ExecutionTime = 0.1 s ClockTime = 1 s
...
```https://develop.openfoam.com/Development/openfoam/-/issues/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-27T12:37:28ZPrashant 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/3123BUG: externalWallHeatFluxTemperature: refValue=0 leads to FPE in mixedEnergy BC2024-03-21T16:37:25ZKutalmış BerçinBUG: externalWallHeatFluxTemperature: refValue=0 leads to FPE in mixedEnergy BCIn light of Jiri's failing test case:
In externalWallHeatFluxTemperature BC, the modes [`fixedPower`](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/thermoTools/derivedFvPatchFields/externalWallHeatFluxTemperature/e...In light of Jiri's failing test case:
In externalWallHeatFluxTemperature BC, the modes [`fixedPower`](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/thermoTools/derivedFvPatchFields/externalWallHeatFluxTemperature/externalWallHeatFluxTemperatureFvPatchScalarField.C?ref_type=heads#L334) and [`fixedHeatFlux`](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/thermoTools/derivedFvPatchFields/externalWallHeatFluxTemperature/externalWallHeatFluxTemperatureFvPatchScalarField.C?ref_type=heads#L345) set `refValue` to 0.
This upsets the cases where `rho` is interrogated as a function of `p` and `T` values, e.g. for the [`Foam::perfectGas<Specie>::rho`](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/thermophysicalModels/specie/equationOfState/perfectGas/perfectGasI.H?ref_type=heads#L78) when the `sonicFoam` is used (hence the `mixedEnergy` BC through the `e` field).
To overcome this issue, the `refValue` can be set to an arbitrary value since the `valueFraction=0` nullifies `refValue`'s effect for these two modes.Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/3122error when cross compile from opensuse to windows112024-03-28T04:54:08ZHAEJIN JIerror when cross compile from opensuse to windows11Hello.
An error occurred while following this link.
https://develop.openfoam.com/Development/openfoam/-/wikis/building/cross-compile-mingw#run-time-setup
These errors appeared.
/usr/lib/openfoam/OpenFOAM-v2212/platforms/linux64MingwDPI...Hello.
An error occurred while following this link.
https://develop.openfoam.com/Development/openfoam/-/wikis/building/cross-compile-mingw#run-time-setup
These errors appeared.
/usr/lib/openfoam/OpenFOAM-v2212/platforms/linux64MingwDPInt32Opt/lib/libOSspecific.o:fileMonitor.C:(.rdata+0x1364): relocation truncated to fit: IMAGE_REL_AMD64_REL32 against `.text$_ZN4Foam5token5resetEv'
I need detailed instructions on which OpenFOAM and ThirdParty versions and how to install them.
I am attaching the log file.
[log.linux64MingwDPInt32Opt](/uploads/3bbca1359e9abc59da2e7c0a0abfc69e/log.linux64MingwDPInt32Opt)
Thank you so much.
openfoam2306 version.Pawan GhildiyalPawan Ghildiyalhttps://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/3119cyclicAMI startup without 'value'2024-03-27T10:02:05ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcyclicAMI startup without 'value'<!--
*** 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 -->
cyclicAMI parallel start without 'value' entry can fail
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
E.g. `tutorials/incompressible/pimpleFoam/laminar/mixerVesselAMI2D/mixerVesselAMI2D`
- decompose into 4
- remove the 'value' entry from the processor*/0/U field for the cyclicAMI
- this will force the call to evaluate which will give e.g.
```
[3] --> FOAM FATAL ERROR: (openfoam-2401 patch=240220)
[3] From processor 0 : unallocated receive field. Expected size 36 on comm 0 with procs 4
[3]
[3]
[3] From static void Foam::mapDistributeBase::receive(Foam::label, const labelListList&, bool, const Foam::labelRange&, const Foam::UPtrList<Foam::List<T> >&, Foam::List<T>&, const CombineOp&, const negateO
p&, int, Foam::label) [with T = Foam::Vector<double>; CombineOp = Foam::eqOp<Foam::Vector<double> >; negateOp = Foam::flipOp; Foam::label = int; Foam::labelListList = Foam::List<Foam::List<int> >]
[3] in file /home/bigbuzz2/mattijs/OpenFOAM/OpenFOAM-plus/work/develop/src/OpenFOAM/lnInclude/mapDistributeBaseTemplates.C at line 350.
```
### 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
### 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
-->
- switch off local-consistency so it takes the old path.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://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/openfoam/-/issues/3117Can't introduce boundary conditions after snappyHexMesh2024-03-20T09:46:50ZRobert Manson-SawkoCan't introduce boundary conditions after snappyHexMeshHello,
My problem is likely between keyboard and the chair. I am comparing with motorBike tutorial, but I still can't find out what's going on. Could you please advise?
I am running a standard `snappyHexMesh` workflow. The meshing has ...Hello,
My problem is likely between keyboard and the chair. I am comparing with motorBike tutorial, but I still can't find out what's going on. Could you please advise?
I am running a standard `snappyHexMesh` workflow. The meshing has to be done in parallel and will introduce a new boundary condition, `structure`. I have IC/BC files in `0.orig` with some lovely no slip configuration raring to stop the flow. The geometry file is a legacy VTK, exported directly from ParaView after some modifications to original CAD files.
As per [this issue](https://develop.openfoam.com/Development/openfoam/-/issues/2236) I cannot run `decomposePar -fields` after `snappyHexMesh -overwrite` because the processor addressing no longer matches. When I `decomposePar` my fields before `snappHexMesh` step, `structure` is ignored as it doesn't exist at this point.
I noticed that motorBike uses `restore0Dir -processor`, but when I tried the same I get an error about missing interprocessor boundaries. I also tried `sed`-in my structure no slip to all relevant files, but also ended up with missing interprocessor boundaries.
The only thing which seems to work is a rather undignified redecompose:
```bash
reconstructParMesh -constant
cp -r 0.orig 0
decomposePar -force
```
I would prefer to avoid it as my largest mesh should remain decomposed for health and safety reasons.https://develop.openfoam.com/Development/openfoam/-/issues/3116when running in parallell openfoam2306 and later version don't have complete log2024-03-09T23:48:35Zre Sistwhen running in parallell openfoam2306 and later version don't have complete log<!--
*** 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 -->
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
'mpirun -v -np 4 snappyHexMesh -parallel'
```
/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: 2312 |
| \\ / A nd | Website: www.openfoam.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : _a9b451b3-20240213 OPENFOAM=2312 version=2312
Arch : "LSB;label=32;scalar=64"
Exec : snappyHexMesh -parallel
Date : Mar 09 2024
Time : 00:34:18
Host : laptop
PID : 17373
I/O : uncollated
```
### Example case
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
### What is the current *bug* behaviour?
<!-- What actually happens -->
### What is the expected *correct* behavior?
<!-- What you should see instead -->
get complete log.
### 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.
-->
Above
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2312|v2306|
Operating system : openSUSE
Hardware info :
Compiler :
-->
- OpenFOAM version :v2312|v2306
- Operating system :openSUSE 15.5
- 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
-->
openmpi issue, update fixed it