Development issueshttps://develop.openfoam.com/groups/Development/-/issues2023-12-07T05:40:02Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2442chtMultiRegionFoam with anistropic diffusivity2023-12-07T05:40:02ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comchtMultiRegionFoam with anistropic diffusivity### Functionality to add/problem to solve
chtMultiRegionFoam/solidFoam supports anisotropic diffusivity. This gets calculated by converting at startup the thermo properties into the coordinate system.
It does not recalculate the proper...### Functionality to add/problem to solve
chtMultiRegionFoam/solidFoam supports anisotropic diffusivity. This gets calculated by converting at startup the thermo properties into the coordinate system.
It does not recalculate the properties
- if the thermo properties change (e.g. temperature varying alpha)
- if the coordinate system changes (e.g. cylindrical coordinate system, pivoting across second axis)
### Target audience
Anyone using cht with changing solid properties.
### Proposal
Two possibilities:
- have option to update/correct coordinate system and update anisotropic diffusivity accordingly
- not cache aniAlphas but calculate it on-the-fly
@mark @Sergiohttps://develop.openfoam.com/Development/openfoam/-/issues/2441Give subclasses of pyrolysisChemistryModel to the solid concentrations2022-06-23T08:41:34ZBernhard GschaiderGive subclasses of pyrolysisChemistryModel to the solid concentrationsWhile the reaction rates can be easily read or manipulated by subclasses of this class they can not access the initial solid concentrations (not event for reading)
This is fixed by the attached trivial patch by moving the field from `pr...While the reaction rates can be easily read or manipulated by subclasses of this class they can not access the initial solid concentrations (not event for reading)
This is fixed by the attached trivial patch by moving the field from `private`to `protected`
[0003-Allow-accesing-the-solid-concentrations-from-sub-cla.patch](/uploads/4b46d356bfbd65e567d44f4797f159be/0003-Allow-accesing-the-solid-concentrations-from-sub-cla.patch)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2440Parser for chemical reactions silently accepts faulty equations2022-06-23T08:41:34ZBernhard GschaiderParser for chemical reactions silently accepts faulty equations
### Summary
The parser for chemical reactions accepts chemical reactions with typos, ignores the parts it doesn't understand and the simulations then run with chemical reactions that are different from what the user expects
The two m...
### Summary
The parser for chemical reactions accepts chemical reactions with typos, ignores the parts it doesn't understand and the simulations then run with chemical reactions that are different from what the user expects
The two main issues are
- punctuation tokens that don't make sense
- species that are not in the species list are ignored
### Steps to reproduce
Use the tutorial case `combustion/fireFoam/LES/simplePMMApanel` and edit the file `constant/reactions` to modify the reaction in
```
reactions
{
methaneReaction
{
type irreversibleArrheniusReaction;
reaction "CH4 + 2O2 = CO2 + 2H2O";
A 5.2e16;
beta 0;
Ta 14906;
}
}
```
Possible problems are
```
reaction "CH4 + 2O2 = CO2 - 2H2O";
```
(wrong punctuation token) and
```
reaction "CH4 + 2O2 = COO2 + 2H2O";
```
(unknown species COO2).
### What is the current *bug* behaviour?
The simulation runs without a hint that there is a problem but the used chemical equation is fundamentally different)
### What is the expected *correct* behavior?
Program should crash while reading the faulty equation to give the user a chance to fix it
### Environment information
- OpenFOAM version : any OF version of the last year. Tested on the current git-version
- Operating system :
- Hardware info :
- Compiler :
### Possible fixes
Attached there are 2 patches to fix these problems. One to fail on unknown punctuation tokens. The other one to fail if there is an unknown species (this patch slightly changes the API of the speciesCoeffs-class because for solid reactions when calling the base class the parser should **not** fail for unknown species because these might be from the "other" phase
[0001-Failing-on-extra-punctuation-tokens-in-chemical-equa.patch](/uploads/597174737fe7a34add8b46e9e6351617/0001-Failing-on-extra-punctuation-tokens-in-chemical-equa.patch)[0002-Fail-for-unknown-species.patch](/uploads/3123211e6c89b382c24b490f1986ec2e/0002-Fail-for-unknown-species.patch)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2439WM_SCHEDULER breaks compilation generated sources (flex, bison etc)2022-06-03T11:43:26ZBernhard GschaiderWM_SCHEDULER breaks compilation generated sources (flex, bison etc)
### Summary
When using a wrapper for the compiler with WM_SCHEDULER the compilation of sources where another utility generates the sources breaks
### Steps to reproduce
I use `ccache` speed up re-compilation. When I enable it and co...
### Summary
When using a wrapper for the compiler with WM_SCHEDULER the compilation of sources where another utility generates the sources breaks
### Steps to reproduce
I use `ccache` speed up re-compilation. When I enable it and compile a library I get an error message for one of the flex-files
```
> export WM_SCHEDULER=ccache
> wmake libso src/fileFormats
ccache flex -+ -f -o /slowdata/OpenFOAMInstallations/OpenFOAM-Ubuntu/OpenFOAM-plus/build/linux64Clang120DPInt32Opt/src/fileFormats/stl/STLAsciiParseFlex.L.C stl/STLAsciiParseFlex.L '&&' clang++ -std=c++14 -m64 -pthread -DOPENFOAM=2202 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -Wno-undefined-var-template -Wno-unknown-warning-option -O3 -DNoRepository -ftemplate-depth-100 -iquote. -IlnInclude -I/slowdata/OpenFOAMInstallations/OpenFOAM-Ubuntu/OpenFOAM-plus/src/OpenFOAM/lnInclude -I/slowdata/OpenFOAMInstallations/OpenFOAM-Ubuntu/OpenFOAM-plus/src/OSspecific/POSIX/lnInclude -fPIC -Wno-old-style-cast -Wno-unused-local-typedefs -Wno-tautological-undefined-compare -Wno-shift-negative-value -Wno-null-pointer-arithmetic -Wno-null-pointer-subtraction -Wno-unknown-warning-option -Wno-deprecated-copy-with-user-provided-copy -Wno-tautological-overlap-compare -Wno- -c /slowdata/OpenFOAMInstallations/OpenFOAM-Ubuntu/OpenFOAM-plus/build/linux64Clang120DPInt32Opt/src/fileFormats/stl/STLAsciiParseFlex.L.C -o /slowdata/OpenFOAMInstallations/OpenFOAM-Ubuntu/OpenFOAM-plus/build/linux64Clang120DPInt32Opt/src/fileFormats/stl/STLAsciiParseFlex.o
/usr/bin/flex: can't open &&
/usr/bin/m4:stdin:7265: ERROR: end of file in string
```
### Example case
Not applicable
### What is the current *bug* behaviour?
Compilation fails for this and similar files (Lemon, Bison etc)
### What is the expected *correct* behavior?
Compilation should work
### 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 : current git-version. But also any other release from the last years
- Operating system : Ubuntu 18.04
- Compiler : Clang 12 (but happens with other compilers as well)
The problem **might** be that Ubuntu doesn't use for `/bin/sh` not `bash` like most distros but they use `dash`which has some small incompatibilities and one of them might be a different treatment of `'&&'` that is used if WM_SCHEDULER is set
### Possible fixes
Attached there is a patch that fixes this by moving the WM_SCHEDULER immediately before the compiler call not the call of the utility that generates the source code. This makes sense as utilities like ccache (or distcc - which is the other application for WM_SCHEDULER that I've seen) only know how to wrap the compiler calls anyway
[0001-WM_SCHEDULER-breaks-compilation.patch](/uploads/096193d2b341d208d8c696eb835a4506/0001-WM_SCHEDULER-breaks-compilation.patch)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2438sets started to produce different number of output files2022-04-12T15:00:43ZKutalmış Berçinsets started to produce different number of output filesI am not sure the following change was intentional or not. Some of my VV cases started to break down at the level of plot production, hence realised the following behaviour change.
Minimal test case: [sample-issue.zip](/uploads/ff257560...I am not sure the following change was intentional or not. Some of my VV cases started to break down at the level of plot production, hence realised the following behaviour change.
Minimal test case: [sample-issue.zip](/uploads/ff2575606f95a03105b084492172cc29/sample-issue.zip) - to reproduce the issue, just execute `Allrun` and inspect `postProcessing` content for different HEADs.
The following `system/sample` file yields different number of output files for v2112 (14aeaf8dab) vs dev (d7c873902c) for the minimal test case:
```
type sets;
libs (sampling);
fields
(
U
turbulenceProperties:k
turbulenceProperties:R
);
...
```
For v2112 (14aeaf8dab) or for the develop at least six weeks ago (1a55829ef9), three files were produced:
```
y_turbulenceProperties:k.xy
y_turbulenceProperties:R.xy
y_U.xy
```
For dev (d7c873902c), a single file was produced:
```
y_turbulenceProperties:k_U_turbulenceProperties:R.xy
```
Could you tell me if this output change is intentional or not? @andy @mark @Prashanthttps://develop.openfoam.com/Development/openfoam/-/issues/2437Loading external library (preCICE coupling library)2022-04-23T07:49:26ZPaul BrousseauLoading external library (preCICE coupling library)Hi,
We are trying to use the coupling-codes-library preCICE with Openfoam-v2112, compiled from source and without `thirdParty`, on a cluster with this distribution:
```
Distributor ID: CentOS
Description: CentOS Linux release 7.8.2003 ...Hi,
We are trying to use the coupling-codes-library preCICE with Openfoam-v2112, compiled from source and without `thirdParty`, on a cluster with this distribution:
```
Distributor ID: CentOS
Description: CentOS Linux release 7.8.2003 (Core)
Release: 7.8.2003
Codename: Core
```
PreCICE developers seem to think that our Openfoam compilation is the cause of the problem. Indeed this error occurs when loading the external library in the `controlDict`:
```
#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::sigFpe::sigHandler(int) at ??:?
#2 ? in /lib64/libpthread.so.0
#3 ? in /opt/ohpc/pub/libs/gnu8/openmpi3/trilinos/12.14.1/lib/libteuchoscore.so.12
#4 ? in /lib64/ld-linux-x86-64.so.2
#5 ? in /lib64/ld-linux-x86-64.so.2
#6 ? in /lib64/ld-linux-x86-64.so.2
#7 ? in /lib64/ld-linux-x86-64.so.2
#8 ? in /lib64/libdl.so.2
#9 ? in /lib64/ld-linux-x86-64.so.2
#10 ? in /lib64/libdl.so.2
#11 dlopen in /lib64/libdl.so.2
#12 Foam::dlOpen(Foam::fileName const&, bool) at ??:?
#13 Foam::dlOpen(Foam::fileName const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&) at ??:?
#14 Foam::dlLibraryTable::openLibrary(Foam::fileName const&, bool) at ??:?
#15 Foam::dlLibraryTable::open(Foam::fileName const&, bool) at ??:?
#16 bool Foam::dlLibraryTable::open<Foam::HashTable<Foam::autoPtr<Foam::functionObject> (*)(Foam::word const&, Foam::Time const&, Foam::dictionary const&), Foam::word, Foam::Hash<Foam::word> >*>(Foam::dictionary const&, Foam::word const&, Foam::HashTable<Foam::autoPtr<Foam::functionObject> (*)(Foam::word const&, Foam::Time const&, Foam::dictionary const&), Foam::word, Foam::Hash<Foam::word> >* const&, bool) at ??:?
#17 Foam::functionObject::New(Foam::word const&, Foam::Time const&, Foam::dictionary const&) at ??:?
#18 Foam::functionObjectList::read() at ??:?
#19 Foam::Time::run() const at ??:?
#20 ? at ??:?
#21 __libc_start_main in /lib64/libc.so.6
#22 ? at ??:?
Exception en point flottant
```
In fact, simply loading the preCICE library (and not using it) makes OF crashes. Of course, OF works well alone.
Do you have any guess on where to look and how to debug this ?
Thanks !
Paulhttps://develop.openfoam.com/Development/openfoam/-/issues/2436extended capability of redistributePar2022-06-15T09:52:04ZMark OLESENextended capability of redistributeParCurrently does not properly handle point fields (pointMesh) or area/edge fields (finiteArea)
Ref: EP1722 (@mark and @mattijs)Currently does not properly handle point fields (pointMesh) or area/edge fields (finiteArea)
Ref: EP1722 (@mark and @mattijs)https://develop.openfoam.com/Development/openfoam/-/issues/2435Minor error with mappedFile PatchFunction12022-04-08T14:50:49ZBen MalinMinor error with mappedFile PatchFunction1
### Summary
When a field name is specified other than the default, the format of the write function is incorrect
### Steps to reproduce
Run a case using the PatchFunction1 mappedFile with a non-default fieldTable entry. The result is...
### Summary
When a field name is specified other than the default, the format of the write function is incorrect
### Steps to reproduce
Run a case using the PatchFunction1 mappedFile with a non-default fieldTable entry. The result is then output in the format:
```
patch
{
type ...;
fieldTable "[non-default name]";
value
{
type mappedField;
...
}
}
```
If this result is then used to run another case, the fieldTable entry gets missed and an error will be thrown that the field can't be found at constant/boundaryData/patch/...
The correct behavior is:
```
patch
{
type ...;
value
{
type mappedField;
fieldTable "[non-default name]";
...
}
}
```
### Possible fixes
Easy fix, minor change to writeData function. Just need to move the os.writeEntryIfDifferent("fieldTable") to be within the os.beginBlock(word(this->name() + "Coeffs")) section.https://develop.openfoam.com/Development/openfoam/-/issues/2434Issue when Executing Simulation in Parallel2024-01-03T14:11:37ZTamas EgeresiIssue when Executing Simulation in Parallel### Summary
Recently I updated my system to Ubuntu 21.10. Then I installed the pre-compiled OpenFOAM v2112 based on the information on the webpage. When I started any case from the tutorials in parallel mode, it diverged rapidly. I've a...### Summary
Recently I updated my system to Ubuntu 21.10. Then I installed the pre-compiled OpenFOAM v2112 based on the information on the webpage. When I started any case from the tutorials in parallel mode, it diverged rapidly. I've attached the log.simpleFoam from the motorBike case.
In order to overcome of this problem, I changed maxThreadFileBufferSize from 0 to 1e9 in the global controlDict. The motorBike case went smoothly after this.
However, the more complex solvers such as compressibleInterDyMFoam in the sphereDrop setup or the DTCHullMoving setup diverged immediately no matter how I set maxThreadFileBufferSize. I also attached those 2 log files (log.compressibleInterDyMFoam and log.interFoam).
To reproduce this behavior, use Ubuntu 21.10 with motorBike or sphereDrop tutorial. You can check that maxThreadFileBufferSize is set to 0 in $FOAM_ETC/controlDict initially.
### Relevant logs and/or images
[log.simpleFoam](/uploads/c1c36b5cf2e8bb78743226b28302f2ea/log.simpleFoam)
[log.compressibleInterDyMFoam](/uploads/728a1b88dc28519ba6b8aafae4bf5f3c/log.compressibleInterDyMFoam)
[log.interFoam](/uploads/e456021e437ad5f5c1f5d27c8de5dcfd/log.interFoam)
### Environment information
OpenFOAM version : v2112
Operating system : ubuntu 21.10
Hardware info : Intel(R) Core(TM) i9-10900 CPU @ 2.80GHz
Compiler : gcc
- OpenFOAM version : v2112
- Operating system : ubuntu 21.10
- Hardware info : Intel(R) Core(TM) i9-10900 CPU @ 2.80GHz
- Compiler : gcc
### Possible fixes
Partially fixing: I changed maxThreadFileBufferSize from 0 to 1e9 which fixed 1 of the 3 cases.https://develop.openfoam.com/Development/openfoam/-/issues/2433issue with compiling runTimePostprocessing:2022-04-30T14:49:01ZPawan Ghildiyalissue with compiling runTimePostprocessing:Hi @mark
Operating system: Redhat7.9
I compiled VTK-9.2 from Paraview as shipped with ThirdParty/sources/Paraview-5.10.0.
with mesa+llvm successfully.
`./makeVTK -mpi=0 -osmesa -mesa-prefix /home/pawan/OpenFOAM/OpenFOAM-v2112/Thi...Hi @mark
Operating system: Redhat7.9
I compiled VTK-9.2 from Paraview as shipped with ThirdParty/sources/Paraview-5.10.0.
with mesa+llvm successfully.
`./makeVTK -mpi=0 -osmesa -mesa-prefix /home/pawan/OpenFOAM/OpenFOAM-v2112/ThirdParty/platforms/linux64Gcc/mesa-17.1.1`
However while compiling the runTimePostProcessing, it fail ![Untitled](/uploads/ec2ccd42f2c1139416de84e9f2a74646/Untitled.png)https://develop.openfoam.com/Development/openfoam/-/issues/2432Parallel simulation diverges always2022-03-31T19:14:05ZTamas EgeresiParallel simulation diverges alwaysDear Support,
All of my parallel cases diverges when running them on my workstation. I've tested all of the available OpenFOAM.com OpenFOAM versions, and all of them gives the same problem. Hovewer, when I run the OpenFOAM.org OpenFOAM ...Dear Support,
All of my parallel cases diverges when running them on my workstation. I've tested all of the available OpenFOAM.com OpenFOAM versions, and all of them gives the same problem. Hovewer, when I run the OpenFOAM.org OpenFOAM version 9, it goes without any problem.
My system is:
LSB Version: core-11.1.0ubuntu3-noarch:security-11.1.0ubuntu3-noarch
Distributor ID: Ubuntu
Description: Ubuntu 21.10
Release: 21.10
Codename: impish
I've attached my log file for the motorBike test case.
[log.simpleFoam](/uploads/be3b40d4632233e19212b1f61bab6a09/log.simpleFoam)https://develop.openfoam.com/Development/openfoam/-/issues/2431dynamicMotionSolverFvMeshAMI + surface sampler2022-03-31T10:19:51ZPrashant SonakardynamicMotionSolverFvMeshAMI + surface samplerfoamToEnSight and foamToVTK works fine with https://develop.openfoam.com/Development/openfoam/-/issues/2396, however attached a case [rotatingFanInRoom.tgz](/uploads/ff5be755b89b72e1d3bf2f49d39fa945/rotatingFanInRoom.tgz) which fails to ...foamToEnSight and foamToVTK works fine with https://develop.openfoam.com/Development/openfoam/-/issues/2396, however attached a case [rotatingFanInRoom.tgz](/uploads/ff5be755b89b72e1d3bf2f49d39fa945/rotatingFanInRoom.tgz) which fails to grab cut-plane proper cells. A few candidates are missing from cut-plane as discussed with @mark
![issue-candidates-missing](/uploads/2c1c51b1c5d22d7a87560e25bbcbd3b8/issue-candidates-missing.png)https://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 OLESENhttps://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/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/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/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/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/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/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.com