Development issueshttps://develop.openfoam.com/groups/Development/-/issues2022-03-24T11:11:38Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2407label nBufferLayers in dynamicRefineFvMesh produce no diffence2022-03-24T11:11:38ZAlberto ceschinlabel nBufferLayers in dynamicRefineFvMesh produce no diffence<!--
*** 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
There is no working option to increase buffer layers between refinement levels.
### Steps to reproduce
In tutorial multiphase/interFoam/RAS/motorBike , that is using dynamicRefineFvMesh, increasing label nBufferLayers from 1 to 2 or more does not bring any difference.
### 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
-->
With
`nBufferLayers 3;`
![Screenshot_from_2022-03-11_15-18-09](/uploads/300931c9ad400cafc513eca3e430af2b/Screenshot_from_2022-03-11_15-18-09.png)
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2112|v2106|v2012|v2006|v1912|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2112
- Operating system : Ubuntu 18https://develop.openfoam.com/Development/openfoam/-/issues/2409atmBuoyancyTurbSource not working for RNGkEpsilon2023-12-18T08:37:25ZPetros AmpatzidisatmBuoyancyTurbSource not working for RNGkEpsilonTried to run the **atmForestStability** verification case with the RNGkEpsilon model. I got the following error:
`--> FOAM FATAL ERROR: (openfoam-2112) failed lookup of RNGkEpsilon:GbyNu (objectRegistry region0) available objects of typ...Tried to run the **atmForestStability** verification case with the RNGkEpsilon model. I got the following error:
`--> FOAM FATAL ERROR: (openfoam-2112) failed lookup of RNGkEpsilon:GbyNu (objectRegistry region0) available objects of type volScalarField::Internal: 20 (rhok ...)`
I think this is because **atmBuoyancyTurbSource** needs access to **GbyNu**.
In _kEpsilon.C_ line 248 `this->type() + ":GbyNu",` is missing from the respective _RNGkEpsilon.C_ file.
When this line is inserted in _RNGkEpsilon.C_ it seems to work.
I guess the same applies to the realizableKE.
Many thanksKutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2410snappyHexMesh : Layer addition on cyclic patch2022-03-14T14:39:26ZPrashant SonakarsnappyHexMesh : Layer addition on cyclic patchWhen adding layers on faces normal to cyclic patch, newly introduced patches doesn't seem to find correct 'BC' to handle cyclic.
Could this be handled?
[cavity.tgz](/uploads/152df3aad4a035177171bc2cf55eee51/cavity.tgz)
@MattijsWhen adding layers on faces normal to cyclic patch, newly introduced patches doesn't seem to find correct 'BC' to handle cyclic.
Could this be handled?
[cavity.tgz](/uploads/152df3aad4a035177171bc2cf55eee51/cavity.tgz)
@Mattijshttps://develop.openfoam.com/Development/openfoam/-/issues/2411MRF : divergent flow near interface when the rotating zone is unaligned2022-03-15T08:33:41ZHenrique GropelliMRF : divergent flow near interface when the rotating zone is unalignedHello!
When simulating a wind turbine with unaligned flow (turbine with tilt) I got a divergent flow near the interface of the non inertial zone and inertial zone.
![uy](/uploads/ef8a385359a1883f3f2776bece0d378d/uy.png)
I’m simulating in...Hello!
When simulating a wind turbine with unaligned flow (turbine with tilt) I got a divergent flow near the interface of the non inertial zone and inertial zone.
![uy](/uploads/ef8a385359a1883f3f2776bece0d378d/uy.png)
I’m simulating in a steady flow regime with MRF (multiple reference frame), when the turbine is aligned with the flow the flow is fully converged.
![tilt0yn](/uploads/cffe5439f6cea9432105bca5c544069b/tilt0yn.png)
I have set the patches excluding the blade patches as non rotating patches in MRFProperties.
I had tested in three different meshes with different refinements in the interface (57MM cells in “A” mesh, 62MM cells in “B” mesh, 97MM cells in “C” mesh) to better achieve an interface weight in AMI. But the three meshes diverged.
For a last attempt I simulated an unaligned flow in an aligned mesh, changing the velocity components, but diverged as before.
The mesh is a cylinder 15 diameters long and 5 diameters high. Inside the mesh is a mesh of 2 diameters long and 2 diameters high, which is the rotating zone.
I don't have a small example, this link contains the results and the mesh: https://drive.google.com/file/d/1RqzYC68v9YfBUidHXLHVgNwdBBvTcORP/view?usp=sharing
Openfoam v2006, gcc v8.3, centos.https://develop.openfoam.com/Development/openfoam/-/issues/2413Adjoint Smooth Sensitivities fails under WM_LABEL_SIZE=642024-01-11T18:58:45ZDiego PardoAdjoint Smooth Sensitivities fails under WM_LABEL_SIZE=64### Summary
Running the tutorial: $FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/sensitivityMaps/motorBike
With OpenFOAM compiled with **label size 64** (instead of the default 32) leads to an MPI error.
The only modification ...### Summary
Running the tutorial: $FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/sensitivityMaps/motorBike
With OpenFOAM compiled with **label size 64** (instead of the default 32) leads to an MPI error.
The only modification to the tutorial is running in 2 processors rather than 20.
### Steps to reproduce
Using OpenFOAM compiled with label size 64 (`export WM_LABEL_SIZE=64`), run the following tutorial:
$FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/sensitivityMaps/motorBike
I used only a 2 processor hierarchical decomposition:
```
numberOfSubdomains 2;
method hierarchical;
coeffs
{
n (2 1 1);
}
```
### What is the current *bug* behaviour?
MPI Error. The job does not finish.
### What is the expected *correct* behavior?
Successful job with 64 label size
### Relevant logs and/or images
I have attached the full log file: [log.adjointOptimisationFoam](/uploads/f44e8d6d1a5a494482f28f41b4b4bf49/log.adjointOptimisationFoam)
### Environment information
- OpenFOAM version : v2112
- Operating system : centos 8
- Compiler : gcc 8.4.0
### Possible fixes
The issue is somehow related to the inter-processor communication happening in the processorFaPatch.C
By changing the sender call
```
void Foam::processorFaPatch::initGeometry()
{
if (Pstream::parRun())
{
OPstream toNeighbProc
(
Pstream::commsTypes::blocking,
neighbProcNo() // ,
// 3*(sizeof(label) + size()*sizeof(vector)) <- Use automatically computed message size
);
...
...
}
```
And changing the recipient call
```
void Foam::processorFaPatch::calcGeometry()
{
if (Pstream::parRun())
{
{
IPstream fromNeighbProc
(
Pstream::commsTypes::blocking,
neighbProcNo() //,
// 3*(sizeof(label) + size()*sizeof(vector)) <- Use automatically computed message size
);
...
...
}
```
Appears to fix the issue. However I think this is only hiding the issue.https://develop.openfoam.com/Development/openfoam/-/issues/2414report number of cells/faces capped by limitVelocity2022-04-25T11:49:45ZMark OLESENreport number of cells/faces capped by limitVelocitycf. EP1841
Also report relative (%) of cells/faces affected.cf. EP1841
Also report relative (%) of cells/faces affected.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2415solidFoam does not allow changing time steps2022-05-06T11:06:56ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsolidFoam does not allow changing time steps### Functionality to add/problem to solve
solidFoam does not support e.g. setTimeStep FO.
### Proposal
Define a 'Courant' number and include time-step changing. The problem is that `time.setDeltaT(..)` is not called so there is no ca...### Functionality to add/problem to solve
solidFoam does not support e.g. setTimeStep FO.
### Proposal
Define a 'Courant' number and include time-step changing. The problem is that `time.setDeltaT(..)` is not called so there is no call to `functionObjects_.adjustTimeStep()`.
### What does success look like, and how can we measure that?
Run with `setTimeStep` FOhttps://develop.openfoam.com/Development/openfoam/-/issues/2416Wall on overset mesh causes p-U coupling issues2022-09-07T08:42:52ZJozsef NagyWall on overset mesh causes p-U coupling issues<!--
*** 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
I want to inject liquid into a 2D gap.
![image](/uploads/874bb6ca76fd8c4db182fce6c1b876af/image.png)
I want to add a wall on an overset mesh, which is supposed to act as a blockage.
![image](/uploads/c25dd89c61c539c0e8307b7a78e417ed/image.png)
Due to the contraction of the thickness of the gap I would assume, that the velocity in the area of the overset mesh with the wall will be increased (due to continuity). However, this is not the case.
I found this issue: https://develop.openfoam.com/Development/openfoam/-/issues/2341
and assumed that this could be some overInterDyMFoam problem with mass conservation. I tested the same flow with overPimpleDyMFoam and the same happens.
### Steps to reproduce
I uploaded four case files in a zip file. All four can be run with the one master Allrun script in v2112 (also v2012) in 1-2 minutes on on core.
### Example case
[reproducingCases.zip](/uploads/94a362cd067221ac2860a1b089ba516b/reproducingCases.zip)
### What is the current *bug* behaviour?
Here you can see the velocity profile:
![image](/uploads/329c5e7aa1c8098b0b679a585e18f5a0/image.png)
First gap is the simulation without the overset mesh (no contraction of thickness) and overPimpleDyMFoam.
Second gap is the simulation with the overset mesh (small contraction of thickness) and overPimpleDyMFoam.
Third gap is the simulation without the overset mesh (no contraction of thickness) and overInterDyMFoam.
Fourth gap is the simulation with the overset mesh (small contraction of thickness) and overInterDyMFoam.
Without an overset mesh, the results look good and reasonable. The moment I merge an overset mesh to the background mesh, the velocity "dissipates" in the area of the overset mesh.
The pressure behaves also incorrectly
![image](/uploads/4c0dabbdbbee27f3082c1532d96f460b/image.png)
without the overset mesh the pressure drop is reasonable. With the overset mesh the pressure drop disappears in the area of the overset mesh.
### What is the expected *correct* behavior?
Increase of velocity in region of contraction.
### Relevant logs and/or images
See above.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2112|v2106|v2012|v2006|v1912|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2112 (also v2012)
- Operating system : Ubuntu 18.04
- Hardware info : Intel CPU 6 cores (should not matter here)
- Compiler : GCC coming with OpenFOAM
### 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 am not sure. What i noticed is that I have to change the preconditioner between DILU and DIC depending whether I want to run the simulation with or without the overset mesh. In all cases the matrix solver is PBiCGStab though. Maybe this helps? I did try to fix this in the source code, but I am stuck. What I found is that the major impact is coming from pEqn.
In overPimpleDyMFoam the line:
U = cellMask*(HbyA - rAU*gradP);
In overInterDyMFoam the line:
U =
cellMask*
(
HbyA + rAU*fvc::reconstruct((phig - p_rghEqn.flux())/rAUf)
);
The multiplication with cellMask seems to introduce the errors. This might possibly be the source where the error comes out, possibly the cause is in some of the previous steps, where HbyA, rAU or phig are defined. This is where I am stuck.
### Final thoughts
Is this phenomenon
* my stupidity and ignorance (in this case I am sorry to waste you valuable time)
* a bug
* a feature
* something else
I am happy to support you with any help possibly, I know that you have a lot to do. Tell me, what I can test and I will execute the simulations and test.
Thank you!
Best regards,
JozsefSergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/issues/2417Compile error with mingw on OpenSUSE2022-08-16T09:08:40ZJK KimCompile error with mingw on OpenSUSEHello, I ran into a problem while compiling OpenFOAM for Windows.
I could not find anything about "mpi.h" except "export WM_MPLIB=MSMPI" in your [cross compile mingw](https://develop.openfoam.com/Development/openfoam/-/wikis/building/cr...Hello, I ran into a problem while compiling OpenFOAM for Windows.
I could not find anything about "mpi.h" except "export WM_MPLIB=MSMPI" in your [cross compile mingw](https://develop.openfoam.com/Development/openfoam/-/wikis/building/cross-compile-mingw).
Please have a look at the following log and help me.
Thank you in advance.
```
kimjk@localhost:~/OpenFOAM/OpenFOAM-v2112> foam
kimjk@localhost:~/OpenFOAM/OpenFOAM-v2112> ./Allwmake -s -l
Logging wmake -all output to 'log.linux64MingwDPInt32Opt'
gcc=/usr/bin/gcc
clang=
mpirun=
make=/usr/bin/make
cmake=
wmake=/home/kimjk/OpenFOAM/OpenFOAM-v2112/wmake/wmake
m4=/usr/bin/m4
flex=/usr/bin/flex
compiler=/usr/bin/x86_64-w64-mingw32-g++
x86_64-w64-mingw32-g++ (SUSE Linux) 10.3.0
========================================
2022-03-21 18:17:47 +0900
Starting compile OpenFOAM-v2112 Allwmake
Mingw system compiler
linux64MingwDPInt32Opt, with MSMPI msmpi
========================================
built wmake-bin (linux64Mingw) with linux64Gcc
built wmake-bin (win64Mingw) with linux64Mingw
Skip ThirdParty (no directory)
========================================
Compile OpenFOAM libraries
========================================
ln: OpenFOAM/lnInclude
ln: OSspecific/MSwindows/lnInclude
wmake libo (MSwindows)
wmake libo
wmake libo dummy (mpi=dummy)
wmake libo dummy
wmake OpenFOAM
wmake dummy (mpi=MSMPI)
wmake dummy
wmake mpi (mpi=MSMPI:msmpi)
wmake mpi
Ctoo: UOPwrite.C
In file included from UOPwrite.C:33:
PstreamGlobals.H:42:10: fatal error: mpi.h: No such file or directory
42 | #include <mpi.h>
| ^~~~~~~
compilation terminated.
make: *** [/home/kimjk/OpenFOAM/OpenFOAM-v2112/wmake/rules/General/transform:35: /home/kimjk/OpenFOAM/OpenFOAM-v2112/build/linux64MingwDPInt32OptMSMPI/src/Pstream/mpi/UOPwrite.o] Error 1
Done logging to 'log.linux64MingwDPInt32Opt'
kimjk@localhost:~/OpenFOAM/OpenFOAM-v2112>
```https://develop.openfoam.com/Development/openfoam/-/issues/2418Can't install openfoam on redhat 8.42022-03-30T19:34:16ZSebastian Echeverri RestrepoCan't install openfoam on redhat 8.4The installation of openfoam fails on Redhat 8.4. We are following the instructions found here:
https://develop.openfoam.com/Development/openfoam/-/wikis/precompiled/redhat
Here is the output
yum -y install dnf-plugins-core
Updating S...The installation of openfoam fails on Redhat 8.4. We are following the instructions found here:
https://develop.openfoam.com/Development/openfoam/-/wikis/precompiled/redhat
Here is the output
yum -y install dnf-plugins-core
Updating Subscription Management repositories.
Last metadata expiration check: 3:33:39 ago on Tue 22 Mar 2022 04:43:37 AM UTC.
Package dnf-plugins-core-4.0.21-4.el8_5.noarch is already installed.
Dependencies resolved.
Nothing to do.
Complete!
yum -y config-manager --set-enabled PowerTools
Updating Subscription Management repositories.
Error: No matching repo to modify: PowerTools.
yum -y install epel-release
Updating Subscription Management repositories.
Last metadata expiration check: 3:34:58 ago on Tue 22 Mar 2022 04:43:37 AM UTC.
Package epel-release-8-14.el8.noarch is already installed.
Dependencies resolved.
Nothing to do.
Complete!
dnf -y copr enable openfoam/openfoam
Updating Subscription Management repositories.
Enabling a Copr repository. Please note that this repository is not part
of the main distribution, and quality may vary.
The Fedora Project does not exercise any power over the contents of
this repository beyond the rules outlined in the Copr FAQ at
<https://docs.pagure.org/copr.copr/user_documentation.html#what-i-can-build-in-copr>,
and packages are not held to any quality or security level.
Please do not file bug reports about these packages in Fedora
Bugzilla. In case of problems, contact the owner of this repository.
Repository successfully enabled.
yum -y install openfoam2106 --installroot=/shared/apps/openfoam/yum
Unable to detect release version (use '--releasever' to specify release version)
Updating Subscription Management repositories.
Unable to read consumer identity
This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
Copr repo for openfoam owned by openfoam 7.0 kB/s | 3.3 kB 00:00
Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs) 5.6 B/s | 10 B 00:01
Errors during downloading metadata for repository 'rhel-8-for-x86_64-appstream-rpms':
- Status code: 404 for https://cdn.redhat.com/content/dist/rhel8/$releasever/x86_64/appstream/os/repodata/repomd.xml (IP: 95.101.56.251)
Error: Failed to download metadata for repo 'rhel-8-for-x86_64-appstream-rpms': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were triedhttps://develop.openfoam.com/Development/openfoam/-/issues/2419BUG: DEShybrid yields blending-factor fields different than blendingFactor FO2022-05-06T10:03:56ZKutalmış BerçinBUG: DEShybrid yields blending-factor fields different than blendingFactor FO### Summary
Found and explained by @Chiara.
The blending factor fields produced by `DESHybrid` scheme and other schemes + `blendingFactor` function object are opposite to each other. e.g.:
![image](/uploads/c91127f491ed84332852a91963b...### Summary
Found and explained by @Chiara.
The blending factor fields produced by `DESHybrid` scheme and other schemes + `blendingFactor` function object are opposite to each other. e.g.:
![image](/uploads/c91127f491ed84332852a91963b1ad51/image.png)
### Example case
The figure was created from the `periodicHill` tutorial, adding the following to the `controlDict`:
```
DebugSwitches
{
blendedSchemeBase 1;
}
functions
{
blendingFactorFO
{
// Mandatory entries
type blendingFactor;
libs (fieldFunctionObjects);
field U;
// Optional (inherited) entries
result blendingFactorField;
region region0;
enabled true;
log true;
writeControl writeTime;
}
...
}
```
### Environment information
HEAD: ea2bf0414dKutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2420tutorial "rigidBodyHull" crashes after applying "prescribedRotation" restrain...2022-03-23T08:11:25ZLu Xintutorial "rigidBodyHull" crashes after applying "prescribedRotation" restraint to the propeller<!--
*** 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 -->
The tutorial case crashes soon after applying a prescribed rotational motion to the propeller.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
append the following after the 'force' restraint
propellerRotation
{
type prescribedRotation;
body propeller;
referenceOrientation (1 0 0 0 1 0 0 0 1);
axis (1 0 0);
omega table
(
(0 (0 0 0))
(50.0 (10.0 0 0))
);
relax 0.5;
p 0.6;
i 0.6;
d 0.6;
}
### 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 -->
Program crashes
### What is the expected *correct* behavior?
<!-- What you should see instead -->
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2112|v2106|
Operating system : centos
Compiler : gcc
-->
- OpenFOAM version :v2112|v2106
- Operating system :centos
- Compiler :gcc
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->
The program runs well if the hull is only allowed to do translations.https://develop.openfoam.com/Development/openfoam/-/issues/2421processorLOD does not handle zero local elements2022-06-28T10:56:15ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comprocessorLOD does not handle zero local elements<!--
*** 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 -->
processorLOD does not handle zero local elements. E.g. if processorLODs::faceBox is used to pre-filter patches and the local number of patch faces is zero there is a division by zero.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Attached test case and code.
[processorLOD.tgz](/uploads/caee1abff1305c43fe732fdcdbada890/processorLOD.tgz)
### What is the current *bug* behaviour?
<!-- What actually happens -->
Division by zero
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2112|v2106|v2012|v2006|v1912|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2112Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2422Something wrong in humidityTemperatureCoupledMixed Boundary2022-05-06T10:12:05ZGonglin LiSomething wrong in humidityTemperatureCoupledMixed Boundary@Sergio
Dear Prof. Sergio,
Recently, I am using humidityTemperatureCoupledMixed Boundary and try to make some modification with different condensation model. However, some part of the code was confusion.
1. The default drop-wise type o...@Sergio
Dear Prof. Sergio,
Recently, I am using humidityTemperatureCoupledMixed Boundary and try to make some modification with different condensation model. However, some part of the code was confusion.
1. The default drop-wise type of condensation was modeled, but the units in the formula should be Celsius and not Kelvin. The attachment is provided in the email for confirmation.
[BERGMAN T L, LAVINE A S. Fundamentals of Heat and Mass Transfer, 8th Edition, 2017,page 632]
![Drop_Cond_Model_in_reference](/uploads/a6ee6cf571c55fd2a09e8ba389a814f3/Drop_Cond_Model_in_reference.png)
2. In lately .C file in [site, ](https://develop.openfoam.com/Development/openfoam/-/blob/OpenFOAM-v2112/src/thermophysicalModels/thermophysicalPropertiesFvPatchFields/liquidProperties/humidityTemperatureCoupledMixed/humidityTemperatureCoupledMixedFvPatchScalarField.C)
the "alpha" in line 740, the "valueFraction" in line 742 and the "refValue" in line 744 are hard to understand. May I get the physical meaning of these variables?
I try to use E-mail to connect the Prof. Sergio, but the email(s.ferraris@opencfd.co.uk) on website was not able to receive. I deeply appreciate your time and consideration for these issues, and any kind of information or instructions can help me a lot.Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2423The dummy Pstream library cannot be used in parallel mode2022-04-05T14:00:29ZSebastian Echeverri RestrepoThe dummy Pstream library cannot be used in parallel modeAfter installing openfoam 2112 on redhat 8.4 following issue https://develop.openfoam.com/Development/openfoam/-/issues/2418 , we get the following error when trying to run openfoam
--> FOAM FATAL ERROR: (openfoam-2112)
The dummy Pstrea...After installing openfoam 2112 on redhat 8.4 following issue https://develop.openfoam.com/Development/openfoam/-/issues/2418 , we get the following error when trying to run openfoam
--> FOAM FATAL ERROR: (openfoam-2112)
The dummy Pstream library cannot be used in parallel mode
From static bool Foam::UPstream::init(int&, char**&, bool)
in file UPstream.C at line 50.FOAM exiting
This fix did not work for us:
https://develop.openfoam.com/Development/openfoam/-/issues/1970
Any suggestions on how to fix the error
Here is the command that gives the error
`mpirun -np 8 snappyHexMesh -overwrite -parallel `
It seems to be related to running in parallel. The serial version works fine:
`snappyHexMesh -overwrite`https://develop.openfoam.com/Development/openfoam/-/issues/2424linking of twoPhaseProperties missing for windows version2022-04-01T09:12:47ZPrashant Sonakarlinking of twoPhaseProperties missing for windows versioncross reference: EP#1864
On Windows OpenFOAM 2112 version we get error as,
```
--> FOAM FATAL IO ERROR: (openfoam-2112)
Unknown patchField type constantAlphaContactAngle for patch type wall
Valid patchField types :
120
(
```
Could b...cross reference: EP#1864
On Windows OpenFOAM 2112 version we get error as,
```
--> FOAM FATAL IO ERROR: (openfoam-2112)
Unknown patchField type constantAlphaContactAngle for patch type wall
Valid patchField types :
120
(
```
Could be reproduced on tutorials/multiphase/interFoam/laminar/capillaryRise
Workaround:
- Load library by -lib twoPhaseProperties
- or via including it in controlDict
@markhttps://develop.openfoam.com/Development/openfoam/-/issues/2425BUG: blendingFactor FO overwrites DEShybrid:Factor2022-05-06T10:00:44ZKutalmış BerçinBUG: blendingFactor FO overwrites DEShybrid:Factor### Summary
The `blendingFactor` FO overwrites the `DEShybrid:Factor` field, which was written by enabling the debug switch `blendedSchemeBase`.
### Example case
With the `periodicHill` tutorial, test the following with and without t...### Summary
The `blendingFactor` FO overwrites the `DEShybrid:Factor` field, which was written by enabling the debug switch `blendedSchemeBase`.
### Example case
With the `periodicHill` tutorial, test the following with and without the `blendingFactorFO`, and compare `DEShybrid:Factor` fields elementwise:
```
DebugSwitches
{
blendedSchemeBase 1;
}
functions
{
blendingFactorFO
{
// Mandatory entries
type blendingFactor;
libs (fieldFunctionObjects);
field U;
// Optional (inherited) entries
result blendingFactorField;
region region0;
enabled true;
log true;
writeControl writeTime;
}
...
}
### Environment information
HEAD: ea2bf041Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2426lagrangian/reactingParcelFoam/verticalChannelLTS Failing in v21122022-05-06T10:03:42ZPrashant Sonakarlagrangian/reactingParcelFoam/verticalChannelLTS Failing in v2112Tutorial runs fine if we change:
- constant/thermo.incompressiblePoly -> Hf and Sf to 0 for H20
- constant/reactingCloud1Properties -> liquidEvaporationCoeffs -> enthalpyTransfer latentHeat;
@Sergio Could you please review if this is r...Tutorial runs fine if we change:
- constant/thermo.incompressiblePoly -> Hf and Sf to 0 for H20
- constant/reactingCloud1Properties -> liquidEvaporationCoeffs -> enthalpyTransfer latentHeat;
@Sergio Could you please review if this is required?https://develop.openfoam.com/Development/openfoam/-/issues/2427Increase flexibility of weightedFlux interpolation scheme2022-08-03T16:18:42ZGhost UserIncrease flexibility of weightedFlux interpolation scheme### Functionality to add/problem to solve
The weightedFlux interpolation scheme seems to need a pre-existing field/dictionary file to be able to get a value on the `patchNeighbourField()` function. This will appear when decomposing the ...### Functionality to add/problem to solve
The weightedFlux interpolation scheme seems to need a pre-existing field/dictionary file to be able to get a value on the `patchNeighbourField()` function. This will appear when decomposing the case, where each processor boundary condition will have a value.
This, however, is limiting the scheme since one needs to have the interpolation variable in a file and the interpolation field might have a dependency on another variable (temperature, time, etc...).
It would be beneficial to be able to do this with a `volScalarField` inside the code.
### Proposal
This scheme needs to obtain the value at the cell centre from a neighbour cell in another processor. This would make it suitable for having the interpolation variable with some dependency.
I have attached a test case showing that if no file exists, the `patchNeighbourField()` has a value of 0. And a possible fix.
The fix, however, does not seem very elegant. It is using the `syncTools` function `swapBoundaryCellList` which will "return" a field of the size of "nBoundaryFaces" which has substantial more information than needed.
[Case.zip](/uploads/56a31169b9164603f5bcb5cce43c1dcb/Case.zip)
### Links / references
Some references showing the interpolation of pressure with density:
https://onlinelibrary.wiley.com/doi/epdf/10.1002/fld.4055
https://www.sciencedirect.com/science/article/pii/S0141118706000812https://develop.openfoam.com/Development/openfoam/-/issues/2430missing weights in Cuthill-McKee2022-04-01T09:11:39ZMark OLESENmissing weights in Cuthill-McKee- by inspection, and description. The neighbour order is not actually weighted by connectivity at all.
- partial duplicate of #1376- by inspection, and description. The neighbour order is not actually weighted by connectivity at all.
- partial duplicate of #1376Mark OLESENMark OLESEN