Development issueshttps://develop.openfoam.com/groups/Development/-/issues2024-03-27T13:36:50Zhttps://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 ithttps://develop.openfoam.com/Development/openfoam/-/issues/3115interFaceHeight not writing header information2024-03-12T07:45:18ZGuillén Campaña AlonsointerFaceHeight not writing header informationThe functionObject interfaceHeight does not write the header information.
To solve it the following lines should be added to the constructor:
if (Pstream::master())
{
writeFileHeader(fileID::heightFile);
writeFi...The functionObject interfaceHeight does not write the header information.
To solve it the following lines should be added to the constructor:
if (Pstream::master())
{
writeFileHeader(fileID::heightFile);
writeFileHeader(fileID::positionFile);
}Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/3114BUG: incorrect number of escape parcel information2024-03-07T17:13:18ZPrashant SonakarBUG: incorrect number of escape parcel informationAs discussed with Andy, the total parcels escaped through system is incorrect when all boundaries are 'rebound' whilst some of the boundaries are not walls
Cross ref - EP#2400As discussed with Andy, the total parcels escaped through system is incorrect when all boundaries are 'rebound' whilst some of the boundaries are not walls
Cross ref - EP#2400Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/3113meshShrinker and displacementMotionSolver motorbike tutorial documentation - ...2024-03-14T13:32:50ZJohnny JonesmeshShrinker and displacementMotionSolver motorbike tutorial documentation - details not foundHi there,
The meshShrinker displacementMotionSolver examples on the following page clearly show the 16 layers on a complex geometry but none of the tutorials they point to include this geometry and I have not been able to replicate it.
...Hi there,
The meshShrinker displacementMotionSolver examples on the following page clearly show the 16 layers on a complex geometry but none of the tutorials they point to include this geometry and I have not been able to replicate it.
https://www.openfoam.com/news/main-news/openfoam-v2312/pre-processing#snappy_layers
Can you please let me know where I can find the working snappyHexMesh file that enabled this motorbike mesh using the displacementMotionSolver.
Thanks!
JJhttps://develop.openfoam.com/Development/openfoam/-/issues/3112incidental allocations caused by profiling trigger2024-03-09T18:30:56ZMark OLESENincidental allocations caused by profiling triggerMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/3111Support for Radial Basis Function (RBF) based mesh deformation2024-03-21T11:43:48ZAqeel AhmedSupport for Radial Basis Function (RBF) based mesh deformation### Functionality to add/problem to solve
Large mesh deformations on complex meshes require specilized methods to avoid mesh quality issues.
It becomes challenging to control the mesh quality with existing displacement based mesh motion...### Functionality to add/problem to solve
Large mesh deformations on complex meshes require specilized methods to avoid mesh quality issues.
It becomes challenging to control the mesh quality with existing displacement based mesh motion solvers for large deformations.
In the OpenFOAM journal article [2] it was also mentioned that for large deformations advanced techniques could help. An extract form figure 12 caption: "These results highlight the need for advanced mesh motion techniques in OpenFOAM".
### Target audience
All practical FSI cases with complex meshes.
Mesh deformations with fine boundary layers.
### Proposal
RBF morphing techniques have proven to be robust for large variety of problems among others [2].
One of the motion solver using RFB is available in an another library solids4Foam [3]. However, this implementation relies on external library and is not maintained anymore. If possible, would really benefit the community if this could be implemented in OpenFOAM directly.
### What does success look like, and how can we measure that?
Ability to deform complex meshes with large deformations.
A minimal example is provided here:[flapDeformation.zip](/uploads/fa8541188d3a1c22eab91f2cc257a952/flapDeformation.zip)
[meshAndDefInfo.pdf](/uploads/239c5b577c90be8e7a96e22df3f367e6/meshAndDefInfo.pdf)
### Links / references
[1] OpenFOAM-preCICE: Coupling OpenFOAM with External Solvers for Multi-Physics Simulations. https://journal.openfoam.com/index.php/ofj/article/view/88
[2] CFD Methodology for Wind Turbines Fluid-Structure Interaction. https://theses.hal.science/tel-01562675
[3] https://github.com/solids4foam/solids4foam/tree/master/src/RBFMeshMotionSolverhttps://develop.openfoam.com/Development/openfoam/-/issues/3110ENH: Make desorption optional2024-03-14T05:22:13ZPrashant SonakarENH: Make desorption optionalCross ref - EP#2341
Existing sorption BC enables desorption as default mode.
It would be nice to have this as optional feature.
e.g. with bool allowDesorption [after line](https://develop.openfoam.com/Development/openfoam/-/blob/maste...Cross ref - EP#2341
Existing sorption BC enables desorption as default mode.
It would be nice to have this as optional feature.
e.g. with bool allowDesorption [after line](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/thermophysicalModels/reactionThermo/derivedFvPatchFields/speciesSorption/speciesSorptionFvPatchScalarField.C#L372)
```
if (!allowDesorption_)
{
dfldp_ = max(dfldp_, 0.0);
}
```Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/3109Odd use of ListListOps inplaceRenumber2024-02-29T15:35:33ZMark OLESENOdd use of ListListOps inplaceRenumberSighted in EnsightCellsIO.C - not clear what the compiler has even found.Sighted in EnsightCellsIO.C - not clear what the compiler has even found.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/3108Add globalIndex info to globalMeshData2024-03-09T18:31:08ZMark OLESENAdd globalIndex info to globalMeshDataRequested by @Mattijs - replace the total point/face/cell information with globalIndex to allow reuse in various other places without requiring communication each subsequent time.Requested by @Mattijs - replace the total point/face/cell information with globalIndex to allow reuse in various other places without requiring communication each subsequent time.v2406Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/3107ENH: replace raw pointers with unique_ptr in faMatrix and fvMatrix2024-03-05T18:19:21ZKutalmış BerçinENH: replace raw pointers with unique_ptr in faMatrix and fvMatrixPlaceholder to replace raw pointers residing in faMatrix and fvMatrix with the `std::unique_ptr`.
The motivation is to get the benefits that the `std::unique_ptr` offer over raw pointers such as automatic memory management, unshared own...Placeholder to replace raw pointers residing in faMatrix and fvMatrix with the `std::unique_ptr`.
The motivation is to get the benefits that the `std::unique_ptr` offer over raw pointers such as automatic memory management, unshared ownership, resource management and safety, and expressiveness.Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/3106snappyHexMesh parallel feature attraction2024-02-22T16:08:39ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsnappyHexMesh parallel feature attraction<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
snappyHexMesh is not parallel consistent
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Not sure. Visual inspection of code.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
Ideally same behaviour parallel/non-parallel
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2312|v2306|v2212|v2206|v2112 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2312
- Operating system :
- Hardware info :
- Compiler :
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->
Use mesh faces to access mesh face informationMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/3105redistributePar (with cyclicAMI) to more processors2024-03-18T12:15:41ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comredistributePar (with cyclicAMI) to more processors<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
Changing decomposeParDict to be more processors and running `redistributePar -parallel` hangs.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
```
cd tutorials/incompressible/pimpleFoam/laminar/mixerVesselAMI2D/mixerVesselAMI2D
decomposePar (into e.g. 4 processors)
```
In `system/controlDict` change to `startFrom latestTime` and `stopAt writeNow`. Change decomposeParDict to use more processors (e.g. 8) and `mpirun -np 8 redistributePar -parallel`. This hangs - processors that already have mesh get stuck in `Foam::fvMesh::init`. Processors that are new get stuck in earlier code:
```
15 0x00007f2c1eecb930 in Foam::IOobject::readAndCheckHeader(bool, Foam::word const&, bool, bool, bool) () from develop/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so
#16 0x00007f2c215fae69 in Foam::fvMesh::init(bool) () from develop/platforms/linux64GccDPInt32Opt/lib/libfiniteV
```
### Example case
See above.
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
### What is the current *bug* behaviour?
See above.
<!-- What actually happens -->
### What is the expected *correct* behavior?
Write redistributed mesh to new time directory, including on the new processors.
<!-- What you should see instead -->
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2312|v2306|v2212|v2206|v2112 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :v2312
- Operating system :
- Hardware info :
- Compiler :
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->
@markhttps://develop.openfoam.com/Development/openfoam/-/issues/3104Molecular diffusion in icoReactingMultiphaseInterFoam2024-02-21T13:26:23ZPhil NamesnikMolecular diffusion in icoReactingMultiphaseInterFoam### Summary
I'm working on evaporation of water and diffusion of water vapour in air and encountered a problem when using the icoReactingMultiphaseInterFoam solver with laminar flows. As a testcase I use a cuboidal 1D rod with dimension...### Summary
I'm working on evaporation of water and diffusion of water vapour in air and encountered a problem when using the icoReactingMultiphaseInterFoam solver with laminar flows. As a testcase I use a cuboidal 1D rod with dimensions 500 mm x 1 mm x 1 mm and a discretization of 2000 x 1 x 1 (simpleGrading 1,1,1). To keep it simple this rod is completely filled with air (at first no water phase is initialized). On the left end of the rod a fixedValue boundary condition is applied with a vapour mass fraction of 0.01, whereas on the right end a fixedValue of 0 is applied. All other boundaries are of type empty.
The expected behaviour is a diffusive transport of vapour species through air governed by Fick's second law. What actually happens is no transport at all.
### Steps to reproduce
Use a domain without any inflows or outflows and zero velocity leading to a dominant molecular diffusion. Set one vapour mass fraction boundary condition to a higher value than the rest of the domain. Switch to laminar model in turbulenceProperties and use `addDiffusion true;` in thermophysicalProperties.gas.
### Example case
[1D_diffusion.zip](/uploads/192c6df0d7b2a42a60e620bd89746a54/1D_diffusion.zip)
### What is the current _bug_ behaviour?
Molecular diffusion is not working in laminar cases in icoReactingMultiphaseInterFoam.
### What is the expected _correct_ behavior?
Water vapour diffuses from regions/boundaries with high vapour mass fraction to regions of lower mass fraction according to Fick's second law.
### Environment information
- OpenFOAM version : v2212
- Operating system : ubuntu
- Compiler : gcc
### Possible fixes
In `OpenFOAM-v2212/src/phaseSystemModels/multiphaseInter/phasesSystem/phaseModel/MultiComponentPhaseModel/MultiComponentPhaseModel.C:418` the mass diffusivity for the diffusion equation is calculated only using turbulent viscosity `nut()`. For laminar cases `nut()` is set to 0 leading to a deactivation of diffusion. Changing `nut()` to `nuEff()` solves the problem by calculating the diffusion coefficient based on both molecular and turbulent viscosity.https://develop.openfoam.com/Development/openfoam/-/issues/3103unable to use mpirun in precomplied windows version2024-03-04T06:18:45Z加成 唐unable to use mpirun in precomplied windows versionHi,It's maybe a stupid question and I'm new to openfoam. but I can't use mpi to run job in paraell in precomplied openfoam at windows platform.
I'm using `mpirundebug -normal -np 6 potentialFoam -parallel`
and I'm getting
```
Error enc...Hi,It's maybe a stupid question and I'm new to openfoam. but I can't use mpi to run job in paraell in precomplied openfoam at windows platform.
I'm using `mpirundebug -normal -np 6 potentialFoam -parallel`
and I'm getting
```
Error encountered:
Unsupported WM_MPLIB setting : MSMPI
```
and I already installed msmpi like
![image](/uploads/108b30df08e09bf572264bd473138d4e/image.png)
Thanks for helping!Pawan GhildiyalPawan Ghildiyalhttps://develop.openfoam.com/Development/openfoam/-/issues/3102BUG: wallHeatFlux: inconsistent handling of 'useNamePrefix'2024-02-14T13:40:52ZKutalmış BerçinBUG: wallHeatFlux: inconsistent handling of 'useNamePrefix'When the `useNamePrefix` option is enabled for the `wallHeatFlux` function object, the expected naming convention for the registered `volScalarField` is 'function-object-name:wallHeatFlux' (applicable for Linux).
During initialization (...When the `useNamePrefix` option is enabled for the `wallHeatFlux` function object, the expected naming convention for the registered `volScalarField` is 'function-object-name:wallHeatFlux' (applicable for Linux).
During initialization (`ctor`), the `volScalarField` is registered using the name `scopedName(typeName)`. However, because `read(dict)` is invoked after the field registration, the default name for `scopedName(typeName)` becomes simply `typeName`.
Consequently, downstream processes, such as within the `execute()` function, encounter a lookup error when attempting to find a field named `scopedName(typeName)`.
To address this issue, the `read(dict)` function should be executed prior to the field registration.Kutalmış BerçinKutalmış Berçinhttps://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.