Development issueshttps://develop.openfoam.com/groups/Development/-/issues2020-06-18T18:31:52Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1733fvDOM with PBiCGStab solver for Ii2020-06-18T18:31:52ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfvDOM with PBiCGStab solver for Ii<!--
*** 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 ...<!--
*** 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 -->
fvDOM matrix not very convergent
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
take /tutorials/heatTransfer/buoyantPimpleFoam/thermocoupleTestCase
Change in system/fvSolution the solver for the radiation to:
```
solver PBiCGStab;
preconditioner DILU;
tolerance 1e-4;
relTol 0;
minIter 10;
```
It works with minIter set to 1.
@Sergio https://develop.openfoam.com/Development/openfoam/-/issues/939Negative Normal Components in UPrime2Mean Patch Fields - channel395DFSEM2020-06-16T16:22:58ZKutalmış BerçinNegative Normal Components in UPrime2Mean Patch Fields - channel395DFSEMHi,
**Problem**: I observed **negative** values in the normal components of UPrime2Mean, e.g. u'u', on *patch fields* (not internal fields) in a tutorial as well as in-house case. These components, however, are by definition positive.
...Hi,
**Problem**: I observed **negative** values in the normal components of UPrime2Mean, e.g. u'u', on *patch fields* (not internal fields) in a tutorial as well as in-house case. These components, however, are by definition positive.
**MWE**: Please run `OpenFOAM-v1712/channel395DFSEM` tutorial with `UPrime2Mean` on. For an arbitrary instant of solution, executing
`postProcess -func minMaxComponents'(UPrime2Mean)' -latestTime` yields:
```
...
Executing functionObjects
fieldMinMax minMaxComponents(UPrime2Mean) write:
min(UPrime2Mean) = (-110.6187451010895 -71.67069008796911 -57.02833388170411 -15.05621144511252 -12.23325724312694 -8.60988994091587) in cell 17517 at location (0 1.869010129293147 3.122436600824001)
max(UPrime2Mean) = (6.906486416596863 1.071684114359736 0.9375168777607903 0.7322488089670033 0.1589319170416081 1.301374985649687) in cell 1529601 at location (50.83096913508285 1.891711244092694 0.3256528970184543)
...
```
As can be seen, negative values appear in the UPrime2Mean normal components. Manual inspection showed me that these negative values exist in patch fields, rather than internal fields.
Kind regards,v2006Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/399running oscillatingInletACMI2D under valgrind reports 'in use at exit: 2,172 ...2020-06-16T16:14:56ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comrunning oscillatingInletACMI2D under valgrind reports 'in use at exit: 2,172 bytes in 6 blocks'Not sure if this is a real problem. Re-run with all the memory tracing.Not sure if this is a real problem. Re-run with all the memory tracing.https://develop.openfoam.com/Development/openfoam/-/issues/413AMI debug information does not include patch name; makes multi-AMI cases hard...2020-06-16T15:57:33ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comAMI debug information does not include patch name; makes multi-AMI cases hard to debugmoveDynamicMesh -checkAMI
checkMesh -allGeometry
write the AMI weight fields without the actual patch name so with multiple AMIs it overwrites the info.moveDynamicMesh -checkAMI
checkMesh -allGeometry
write the AMI weight fields without the actual patch name so with multiple AMIs it overwrites the info.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1686Function object "energySpectrum"2020-06-15T16:36:05ZSeo Dong-HoFunction object "energySpectrum"Hello
I have installed OpenFOAM v1812 into Ubuntu 16.04 LTS. OpenFOAM itself seemed to be working well (there was no problem with testing a "cavity" problem using icoFoam). I also tested a "Decay of homogeneous isotropic turbulence" tut...Hello
I have installed OpenFOAM v1812 into Ubuntu 16.04 LTS. OpenFOAM itself seemed to be working well (there was no problem with testing a "cavity" problem using icoFoam). I also tested a "Decay of homogeneous isotropic turbulence" tutorial as itself without any modification, but function object "energySpectrum" did not work. In fact, OpeFOAM did not generate a file "energySpectrum.dat" in each time directory even though other results seemed to be O.K.
I have already tried to do many things to fix it, but it did not work yet.
Your prompt assistance will be appreciated.
Thank you.https://develop.openfoam.com/Development/openfoam/-/issues/1728sampling/slicing with "crinkle cut"2020-06-15T10:14:20ZMark OLESENsampling/slicing with "crinkle cut"- question raised on cfd-online (https://www.cfd-online.com/Forums/openfoam-post-processing/227873-surface-vtk-crinkle-cut.html)
Might be of general interest.- question raised on cfd-online (https://www.cfd-online.com/Forums/openfoam-post-processing/227873-surface-vtk-crinkle-cut.html)
Might be of general interest.https://develop.openfoam.com/Development/openfoam/-/issues/647ENH: turbulentMixingLengthDissipationRateInlet Cmu lookup for realizableKE2020-06-12T17:35:58ZAdminENH: turbulentMixingLengthDissipationRateInlet Cmu lookup for realizableKEIn turbulentMixingLengthDissipationRateInletFvPatchScalarField.C Cmu appears to be looked up or defaulted to a constant of 0.09...
```c
// Lookup Cmu corresponding to the turbulence model selected
const turbulenceModel& turbModel = ...In turbulentMixingLengthDissipationRateInletFvPatchScalarField.C Cmu appears to be looked up or defaulted to a constant of 0.09...
```c
// Lookup Cmu corresponding to the turbulence model selected
const turbulenceModel& turbModel = db().lookupObject<turbulenceModel>
(
IOobject::groupName
(
turbulenceModel::propertiesName,
internalField().group()
)
);
const scalar Cmu =
turbModel.coeffDict().lookupOrDefault<scalar>("Cmu", 0.09);
```
It looks like Cmu is being looked up from the turbulence dictionary in turbulenceProperties. However, for turbulence models like realizableKE where Cmu is not constant, I think Cmu should be looked up from the turbulence model itself. Am I reading this correctly? Thoughts?
\## Reattaching the author to the issue ticket: @graups ##v2006Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1630Possible inconsistency in documentation2020-06-12T17:35:40ZMathieu OlivierPossible inconsistency in documentationThis is not a critical issue, but I feel it deserves some attention.
In file src/TurbulenceModels/turbulenceModels/derivedFvPatchFields/wallFunctions/omegaWallFunctions/omegaWallFunction/omegaWallFunctionFvPatchScalarField.H, it is stat...This is not a critical issue, but I feel it deserves some attention.
In file src/TurbulenceModels/turbulenceModels/derivedFvPatchFields/wallFunctions/omegaWallFunctions/omegaWallFunction/omegaWallFunctionFvPatchScalarField.H, it is stated in the documentation (at the beginning of the file) that the default value of the "blended" switch is set to "false". However, by looking at the constructors in omegaWallFunctionFvPatchScalarField.C, it seems that the default value is rather set to "true". Am I missing something?
Thank you!
Mathieu Olivierv2006Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/834Micro change in nutUBlendedWallFunction?2020-06-12T17:34:59ZKutalmış BerçinMicro change in nutUBlendedWallFunction?Hi,
Please consider `Foam::nutTestUBlendedWallFunctionFvPatchScalarField::calcUTau`:
```c
tmp<scalarField> tuTaup(new scalarField(patch().size(), 0.0));
scalarField& uTaup = tuTaup.ref();
const scalarField& nutw = *this;
...Hi,
Please consider `Foam::nutTestUBlendedWallFunctionFvPatchScalarField::calcUTau`:
```c
tmp<scalarField> tuTaup(new scalarField(patch().size(), 0.0));
scalarField& uTaup = tuTaup.ref();
const scalarField& nutw = *this;
forAll(uTaup, facei)
{
scalar ut = sqrt((nutw[facei] + nuw[facei])*magGradU[facei]);
if (mag(ut) > ROOTVSMALL)
{
scalar error = GREAT;
label iter = 0;
while (iter++ < 10 && error > 0.001)
{
scalar yPlus = y[facei]*ut/nuw[facei];
scalar uTauVis = magUp[facei]/yPlus;
scalar uTauLog = kappa_*magUp[facei]/log(E_*yPlus);
scalar utNew = pow(pow(uTauVis, n_) + pow(uTauLog, n_), 1.0/n_);
error = mag(ut - utNew)/(ut + ROOTVSMALL);
ut = 0.5*(ut + utNew);
}
}
uTaup[facei] = ut;
}
return tuTaup;
```
Without sacrificing readability, wouldn't be possible to remove `new scalarField(patch().size(), 0.0)` and simplify the rest accordingly?
```c
const scalarField& nutw = *this;
tmp<scalarField> tuTaup = sqrt((nutw + nuw)*magGradU);
scalarField& uTaup = tuTaup.ref();
forAll(uTaup, facei)
{
if (mag(uTaup[facei]) > ROOTVSMALL)
{
scalar error = GREAT;
label iter = 0;
while (error > 0.001 && iter++ < 10)
{
scalar yPlus = y[facei]*uTaup[facei]/nuw[facei];
scalar uTauVis = magUp[facei]/yPlus;
scalar uTauLog = kappa_*magUp[facei]/log(E_*yPlus);
scalar utNew = pow(pow(uTauVis, n_) + pow(uTauLog, n_), 1.0/n_);
error = mag(uTaup[facei] - utNew)/(uTaup[facei] + ROOTVSMALL);
uTaup[facei] = 0.5*(uTaup[facei] + utNew);
}
}
}
return tuTaup;
```
Also, in `while (iter++ < 10 && error > 0.001)`, I observed for a typical channel case I run that `error > 0.001` becomes `False` quicker than `iter++ < 10`. Might be wiser to swap `error` and `iter`, so that `while` exits without testing `iter` redundantly when `error < 0.001`?v2006Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1594columeAverage2020-06-12T17:30:26Zzein elserfycolumeAverageI am using openFoam version 1906 on ubuntu 14.06 operating system and i have tried to use one of the new functions (columnAverage) but it seems that something is wrong with it. I used it in order to perform a spatial average in the span-...I am using openFoam version 1906 on ubuntu 14.06 operating system and i have tried to use one of the new functions (columnAverage) but it seems that something is wrong with it. I used it in order to perform a spatial average in the span-wise direction (z-direction) but the results are not correct.
The function is added to controlDict
``
` columnAverage
{
type columnAverage;
libs ("libfieldFunctionObjects.so");
writeControl writeTime;
patches (front);
fields (p pPrime2Mean wallShearStressMean);
}`
I have the front plane is normal to z-direction,so i choose the front plane as a patches in the columnAverage function
The result of pPrime2Mean wallShearStressMean are shown below
pPrime
![Pprime](/uploads/4175845d08a3119c7d8cc4916ee98c84/Pprime.JPG)
WallShearStressMean
![wallshear_stress_mean](/uploads/724adad7592a0392735afdf6232f5e5c/wallshear_stress_mean.JPG)
The columnAverage results seems to be incorrect
![Pprimecolumn](/uploads/10773ccda50dac9c5cb81dc4d8100eb1/Pprimecolumn.JPG)
![wallshear_stress_meancolumn](/uploads/41fe99af62f8a59dfc2b1e7aff6cff33/wallshear_stress_meancolumn.JPG)v2006Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1698Hyperlink Not Right: Readme of Tutorial "Steady flow over a 2D backward facin...2020-06-12T09:03:58ZHello WorldHyperlink Not Right: Readme of Tutorial "Steady flow over a 2D backward facing step"There is a link at openfoam/tutorials/incompressible/simpleFoam/backwardFacingStep2D/README
openfoam.com/documentation/cpp-guide/html/verification-validation-turbulent-backward-facing-step.html
This link does not work.There is a link at openfoam/tutorials/incompressible/simpleFoam/backwardFacingStep2D/README
openfoam.com/documentation/cpp-guide/html/verification-validation-turbulent-backward-facing-step.html
This link does not work.Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1640timeVaryingMappedFixedValue does not work with collated file format2020-06-11T15:03:07ZTimofey MukhatimeVaryingMappedFixedValue does not work with collated file format<!--
*** 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 ...<!--
*** 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 -->
timeVaryingMappedFixedValue will crash if the collated fileHandler is used.
It attemts to search for relevant files in the uncollated processor# directories.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Grab the pitzDailyExptInlet tutorial, switch the fileHandler to collated, decompose and run in parallel.
### Relevant logs and/or images
Here is the log from pitzDailyExptInlet
```
/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: v1912 |
| \\ / A nd | Website: www.openfoam.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : _f3950763fe-20191219 OPENFOAM=1912
Arch : "LSB;label=32;scalar=64"
Exec : simpleFoam -parallel
Date : Mar 17 2020
Time : 11:07:42
Host : DESKTOP-MPTRIAD
PID : 2403
I/O : uncollated
Case : /home/timofey/OpenFOAM/timofey-v1912/run/pitzDailyExptInlet
nProcs : 4
Hosts :
(
(DESKTOP-MPTRIAD 4)
)
Pstream initialized with:
floatTransfer : 0
nProcsSimpleSum : 0
commsType : nonBlocking
polling iterations : 0
trapFpe: Floating point exception trapping enabled (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster (fileModificationSkew 10)
allowSystemOperations : Allowing user-supplied system call operations
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time
Overriding OptimisationSwitches according to controlDict
fileHandler (unregistered)
Overriding fileHandler to collated
I/O : collated (maxThreadFileBufferSize 0)
Threading not activated since maxThreadFileBufferSize = 0.
Writing may run slowly for large file sizes.
Create mesh for time = 0
SIMPLE: convergence criteria
field p tolerance 0.01
field U tolerance 0.001
field "(k|epsilon|omega)" tolerance 0.001
Reading field p
Reading field U
Reading/calculating face flux field phi
Selecting incompressible transport model Newtonian
Selecting turbulence model type RAS
Selecting RAS turbulence model kEpsilon
RAS
{
RASModel kEpsilon;
turbulence on;
printCoeffs on;
Cmu 0.09;
C1 1.44;
C2 1.92;
C3 0;
sigmak 1;
sigmaEps 1.3;
}
No MRF models present
No finite volume options present
Starting time loop
streamLine streamLines:
Employing velocity field U
automatic track length specified through number of sub cycles : 5
Time = 1
[1]
[1]
[1] --> FOAM FATAL IO ERROR:
[1] file "/home/timofey/OpenFOAM/timofey-v1912/run/pitzDailyExptInlet/processor1/../constant/boundaryData/inlet/points" does not exist
[1]
[1] file: /home/timofey/OpenFOAM/timofey-v1912/run/pitzDailyExptInlet/processor1/../constant/boundaryData/inlet/points at line 1.
[1]
[1] From function Foam::IFstream& Foam::IFstream::operator()() const
[1] in file db/IOstreams/Fstreams/IFstream.C at line 220.
[1]
FOAM parallel run exiting
[1]
[2]
[2]
[2] --> FOAM FATAL IO ERROR:
[2] file "/home/timofey/OpenFOAM/timofey-v1912/run/pitzDailyExptInlet/processor2/../constant/boundaryData/inlet/points" does not exist
[2]
[2] file: /home/timofey/OpenFOAM/timofey-v1912/run/pitzDailyExptInlet/processor2/../constant/boundaryData/inlet/points at line 1.
[2]
[2] From function Foam::IFstream& Foam::IFstream::operator()() const
[2] in file db/IOstreams/Fstreams/IFstream.C at line 220.
[2]
FOAM parallel run exiting
[2]
[3]
[3]
[3] --> FOAM FATAL IO ERROR:
[3] file "/home/timofey/OpenFOAM/timofey-v1912/run/pitzDailyExptInlet/processor3/../constant/boundaryData/inlet/points" does not exist
[3]
[3] file: /home/timofey/OpenFOAM/timofey-v1912/run/pitzDailyExptInlet/processor3/../constant/boundaryData/inlet/points at line 1.
[3]
[3] From function Foam::IFstream& Foam::IFstream::operator()() const
[3] in file db/IOstreams/Fstreams/IFstream.C at line 220.
[3]
FOAM parallel run exiting
[3]
[0]
[0]
[0] --> FOAM FATAL IO ERROR:
[0] file "/home/timofey/OpenFOAM/timofey-v1912/run/pitzDailyExptInlet/processor0/../constant/boundaryData/inlet/points" does not exist
[0]
[0] file: /home/timofey/OpenFOAM/timofey-v1912/run/pitzDailyExptInlet/processor0/../constant/boundaryData/inlet/points at line 1.
[0]
[0] From function Foam::IFstream& Foam::IFstream::operator()() const
[0] in file db/IOstreams/Fstreams/IFstream.C at line 220.
[0]
FOAM parallel run exiting
[0]
--------------------------------------------------------------------------
MPI_ABORT was invoked on rank 1 in communicator MPI_COMM_WORLD
with errorcode 1.
NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
You may or may not see output from other processes, depending on
exactly when Open MPI kills them.
--------------------------------------------------------------------------
[DESKTOP-MPTRIAD:02401] 3 more processes have sent help message help-mpi-api.txt / mpi-abort
[DESKTOP-MPTRIAD:02401] Set MCA parameter "orte_base_help_aggregate" to 0 to see all help / error messages
```
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v1912
- Operating system : Windows 10 WLS: Ubuntu
- Hardware info : Irrelevant
- Compiler : gcc
Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/ThirdParty-common/-/issues/50error to compile ./makeParaView2020-06-10T15:52:37ZJoaquin Osseserror to compile ./makeParaViewI'm following all the instruction in the OpenFOAM webpage to install it on Ubuntu 20.04 version
First I did this as the instructions says;
cd $WM_THIRD_PARTY_DIR
./makeParaView
And I received this message;
./makeParaView: 64: local:...I'm following all the instruction in the OpenFOAM webpage to install it on Ubuntu 20.04 version
First I did this as the instructions says;
cd $WM_THIRD_PARTY_DIR
./makeParaView
And I received this message;
./makeParaView: 64: local: -DWM_DP: bad variable name
./makeParaView: 64: -DOPENFOAM: bad variable name
Thankshttps://develop.openfoam.com/Development/openfoam/-/issues/1712COMP: compilation issues with Gcc-4.8.52020-06-10T05:11:53ZPrashant SonakarCOMP: compilation issues with Gcc-4.8.5The code seems to break with segmentation fault with commit:
https://develop.openfoam.com/Development/openfoam/-/commit/435957ac871d6929edcd05b4fb275def981113ac
@markThe code seems to break with segmentation fault with commit:
https://develop.openfoam.com/Development/openfoam/-/commit/435957ac871d6929edcd05b4fb275def981113ac
@markhttps://develop.openfoam.com/Development/openfoam/-/issues/1673small error in rotatedBoxToCell documentation2020-06-08T14:54:22ZJaap Stolksmall error in rotatedBoxToCell documentationIn the rotatedBoxToCell documentation:
>>>
k ( 0.0 0.0 100);
>>>
should be:
>>>
k ( 0.0 0.0 200);
>>>
To be consistent with the text above it, indicating a 200 box height. (the -100 starting point does not affect the box ...In the rotatedBoxToCell documentation:
>>>
k ( 0.0 0.0 100);
>>>
should be:
>>>
k ( 0.0 0.0 200);
>>>
To be consistent with the text above it, indicating a 200 box height. (the -100 starting point does not affect the box height)v2006Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1718Write particle positions using functionObjects2020-06-07T20:40:05ZRiccardo RossiWrite particle positions using functionObjectsI've searched extensively within the source code and online and looks like there isn't any method available to write the position of Lagrangian particles, perhaps appending some Lagrangian data to each position, in the same way as cutpla...I've searched extensively within the source code and online and looks like there isn't any method available to write the position of Lagrangian particles, perhaps appending some Lagrangian data to each position, in the same way as cutplanes and isosurfaces can be written using function objects, i.e. having a file written with a given frequency in the corresponding time folder within the postProcessing folder in vtk or vtp format.
It would be great to have a confirmation for this and, if so, to consider the development of such function object and spare the user from writing the whole solution in order to reconstruct and view the dynamics of particles with a decent frequency, especially for large meshes.https://develop.openfoam.com/Development/openfoam/-/issues/1705propose cgal update2020-06-05T16:29:40ZMark OLESENpropose cgal updateDuring recent builds, hit changes in the iterators (6691e6563c8d3d) for CGAL-4.14 and later.
While testing these, discovered that CGAL > 5.0 defaults to header-only builds. The current wmake/scripts do not detect this, nor do the wmake/...During recent builds, hit changes in the iterators (6691e6563c8d3d) for CGAL-4.14 and later.
While testing these, discovered that CGAL > 5.0 defaults to header-only builds. The current wmake/scripts do not detect this, nor do the wmake/rules properly handle this either. The build services are not yet breaking, but it is probably just a matter of a few more weeks/months before bleeding edge systems like spack start breaking.
For future-proofing,
- need to accept systems with CGAL headers and without CGAL libs as being OK (header-only)
- refine wmake rules for headers/library versions of CGAL
Transition. Propose bumping CGAL from 4.9.1 (current) to something slightly newer (eg, leap15.1 has 4.12.2) so that we avoid any version clashes with older ThirdParty installations. Adjust the third-party makeCGAL to use headers-only for OpenFOAM 2006. This also eliminates some gmp/mpfr dependencies.
@andy @Prashant Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1711Warning message while running chtMultiRegionTwoPhaseEulerFoam:2020-06-05T14:34:05ZPawan GhildiyalWarning message while running chtMultiRegionTwoPhaseEulerFoam:Hello @andy @Sergio
After pulling the latest code from dev branch and fresh recompilation,following warnign message is being thrown once chtMultiRegionTwoPhaseEulerFoam is launched. Executable work fine though and simulation proceed w...Hello @andy @Sergio
After pulling the latest code from dev branch and fresh recompilation,following warnign message is being thrown once chtMultiRegionTwoPhaseEulerFoam is launched. Executable work fine though and simulation proceed without any issue.
**Case** : tutorials/heatTransfer/chtMultiRegionTwoPhaseEulerFoam/solidQuenching2D
`Duplicate entry laminar in runtime selection table TurbulenceModel
#0 /home/buzz2/pawan/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam5error14safePrintStackERSo+0x2b) [0x7fd797bf767b]
#1 /home/buzz2/pawan/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libtwoPhaseReactingTurbulenceModels.so(_ZN4Foam15TurbulenceModelINS_14GeometricFieldIdNS_12fvPatchFieldENS_7volMeshEEES4_NS_27compressibleTurbulenceModelENS_10phaseModelEE31adddictionaryConstructorToTableINS_12laminarModelINS_18ThermalDiffusivityINS_32PhaseCompressibleTurbulenceModelIS6_EEEEEEEC2ERKNS_4wordE+0xd3) [0x7fd79cee51c3]
#2 /home/buzz2/pawan/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libtwoPhaseReactingTurbulenceModels.so(+0x9ce20) [0x7fd79ced2e20]
#3 /lib64/ld-linux-x86-64.so.2(+0xfbfa) [0x7fd79e57dbfa]
#4 /lib64/ld-linux-x86-64.so.2(+0xfd06) [0x7fd79e57dd06]
#5 /lib64/ld-linux-x86-64.so.2(+0xeda) [0x7fd79e56eeda]
Duplicate entry RAS in runtime selection table TurbulenceModel
#0 /home/buzz2/pawan/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam5error14safePrintStackERSo+0x2b) [0x7fd797bf767b]
#1 /home/buzz2/pawan/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libtwoPhaseReactingTurbulenceModels.so(_ZN4Foam15TurbulenceModelINS_14GeometricFieldIdNS_12fvPatchFieldENS_7volMeshEEES4_NS_27compressibleTurbulenceModelENS_10phaseModelEE31adddictionaryConstructorToTableINS_8RASModelINS_15EddyDiffusivityINS_18ThermalDiffusivityINS_32PhaseCompressibleTurbulenceModelIS6_EEEEEEEEEC2ERKNS_4wordE+0xd3) [0x7fd79cee52d3]
#2 /home/buzz2/pawan/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libtwoPhaseReactingTurbulenceModels.so(+0x9cec6) [0x7fd79ced2ec6]
#3 /lib64/ld-linux-x86-64.so.2(+0xfbfa) [0x7fd79e57dbfa]
#4 /lib64/ld-linux-x86-64.so.2(+0xfd06) [0x7fd79e57dd06]
#5 /lib64/ld-linux-x86-64.so.2(+0xeda) [0x7fd79e56eeda]
Duplicate entry LES in runtime selection table TurbulenceModel
#0 /home/buzz2/pawan/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam5error14safePrintStackERSo+0x2b) [0x7fd797bf767b]
#1 /home/buzz2/pawan/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libtwoPhaseReactingTurbulenceModels.so(_ZN4Foam15TurbulenceModelINS_14GeometricFieldIdNS_12fvPatchFieldENS_7volMeshEEES4_NS_27compressibleTurbulenceModelENS_10phaseModelEE31adddictionaryConstructorToTableINS_8LESModelINS_15EddyDiffusivityINS_18ThermalDiffusivityINS_32PhaseCompressibleTurbulenceModelIS6_EEEEEEEEEC2ERKNS_4wordE+0xd3) [0x7fd79cee53e3]
#2 /home/buzz2/pawan/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libtwoPhaseReactingTurbulenceModels.so(+0x9cf6c) [0x7fd79ced2f6c]
#3 /lib64/ld-linux-x86-64.so.2(+0xfbfa) [0x7fd79e57dbfa]
#4 /lib64/ld-linux-x86-64.so.2(+0xfd06) [0x7fd79e57dd06]
#5 /lib64/ld-linux-x86-64.so.2(+0xeda) [0x7fd79e56eeda]
Duplicate entry Stokes in runtime selection table laminarModel
#0 /home/buzz2/pawan/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam5error14safePrintStackERSo+0x2b) [0x7fd797bf767b]
#1 /home/buzz2/pawan/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libtwoPhaseReactingTurbulenceModels.so(+0x9d012) [0x7fd79ced3012]
#2 /lib64/ld-linux-x86-64.so.2(+0xfbfa) [0x7fd79e57dbfa]
#3 /lib64/ld-linux-x86-64.so.2(+0xfd06) [0x7fd79e57dd06]
#4 /lib64/ld-linux-x86-64.so.2(+0xeda) [0x7fd79e56eeda]
Duplicate entry kEpsilon in runtime selection table RASModel
#0 /home/buzz2/pawan/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam5error14safePrintStackERSo+0x2b) [0x7fd797bf767b]
#1 /home/buzz2/pawan/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libtwoPhaseReactingTurbulenceModels.so(_ZN4Foam8RASModelINS_15EddyDiffusivityINS_18ThermalDiffusivityINS_32PhaseCompressibleTurbulenceModelINS_10phaseModelEEEEEEEE31adddictionaryConstructorToTableINS_9RASModels8kEpsilonIS7_EEEC2ERKNS_4wordE+0xd3) [0x7fd79cee5f63]
#2 /home/buzz2/pawan/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libtwoPhaseReactingTurbulenceModels.so(+0x9d0b8) [0x7fd79ced30b8]
#3 /lib64/ld-linux-x86-64.so.2(+0xfbfa) [0x7fd79e57dbfa]
#4 /lib64/ld-linux-x86-64.so.2(+0xfd06) [0x7fd79e57dd06]
#5 /lib64/ld-linux-x86-64.so.2(+0xeda) [0x7fd79e56eeda]
Duplicate entry kOmegaSST in runtime selection table RASModel
#0 /home/buzz2/pawan/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam5error14safePrintStackERSo+0x2b) [0x7fd797bf767b]
#1 /home/buzz2/pawan/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libtwoPhaseReactingTurbulenceModels.so(_ZN4Foam8RASModelINS_15EddyDiffusivityINS_18ThermalDiffusivityINS_32PhaseCompressibleTurbulenceModelINS_10phaseModelEEEEEEEE31adddictionaryConstructorToTableINS_9RASModels9kOmegaSSTIS7_EEEC2ERKNS_4wordE+0xd3) [0x7fd79cee6073]
#2 /home/buzz2/pawan/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libtwoPhaseReactingTurbulenceModels.so(+0x9d15e) [0x7fd79ced315e]
#3 /lib64/ld-linux-x86-64.so.2(+0xfbfa) [0x7fd79e57dbfa]
#4 /lib64/ld-linux-x86-64.so.2(+0xfd06) [0x7fd79e57dd06]
#5 /lib64/ld-linux-x86-64.so.2(+0xeda) [0x7fd79e56eeda]
Duplicate entry Smagorinsky in runtime selection table LESModel
#0 /home/buzz2/pawan/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam5error14safePrintStackERSo+0x2b) [0x7fd797bf767b]
#1 /home/buzz2/pawan/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libtwoPhaseReactingTurbulenceModels.so(_ZN4Foam8LESModelINS_15EddyDiffusivityINS_18ThermalDiffusivityINS_32PhaseCompressibleTurbulenceModelINS_10phaseModelEEEEEEEE31adddictionaryConstructorToTableINS_9LESModels11SmagorinskyIS7_EEEC2ERKNS_4wordE+0xd3) [0x7fd79cee72e3]
#2 /home/buzz2/pawan/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libtwoPhaseReactingTurbulenceModels.so(+0x9d49c) [0x7fd79ced349c]
#3 /lib64/ld-linux-x86-64.so.2(+0xfbfa) [0x7fd79e57dbfa]
#4 /lib64/ld-linux-x86-64.so.2(+0xfd06) [0x7fd79e57dd06]
#5 /lib64/ld-linux-x86-64.so.2(+0xeda) [0x7fd79e56eeda]
Duplicate entry kEqn in runtime selection table LESModel
#0 /home/buzz2/pawan/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam5error14safePrintStackERSo+0x2b) [0x7fd797bf767b]
#1 /home/buzz2/pawan/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libtwoPhaseReactingTurbulenceModels.so(_ZN4Foam8LESModelINS_15EddyDiffusivityINS_18ThermalDiffusivityINS_32PhaseCompressibleTurbulenceModelINS_10phaseModelEEEEEEEE31adddictionaryConstructorToTableINS_9LESModels4kEqnIS7_EEEC1ERKNS_4wordE+0xd3) [0x7fd79cee73f3]
#2 /home/buzz2/pawan/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libtwoPhaseReactingTurbulenceModels.so(+0x9d542) [0x7fd79ced3542]
#3 /lib64/ld-linux-x86-64.so.2(+0xfbfa) [0x7fd79e57dbfa]
#4 /lib64/ld-linux-x86-64.so.2(+0xfd06) [0x7fd79e57dd06]
#5 /lib64/ld-linux-x86-64.so.2(+0xeda) [0x7fd79e56eeda]
`https://develop.openfoam.com/Development/openfoam/-/issues/1714unload errors for fieldfunctions library2020-06-05T14:33:34ZMark OLESENunload errors for fieldfunctions libraryThe recent changes to phase-system turbulence libraries and subsequent change to the field function link options (commit 11965904b) appear to provoke an unload error. Seen for clang (10.0), but _not_ for gcc (7.5.0).
If I do a full or ...The recent changes to phase-system turbulence libraries and subsequent change to the field function link options (commit 11965904b) appear to provoke an unload error. Seen for clang (10.0), but _not_ for gcc (7.5.0).
If I do a full or partial revert of that commit, the error shifts to being not able to load the library (double entry for "laminar" as @Pawan reported).
Here is what the error currently looks like:
```
tutorials/heatTransfer/chtMultiRegionFoam/externalCoupledHeater/
$ foamListRegions
bottomWater
topAir
heater
leftSolid
rightSolid
--> FOAM Warning :
From void Foam::dlLibraryTable::clear(bool)
in file db/dynamicLibrary/dlLibraryTable/dlLibraryTable.C at line 164
Failed closing "fieldFunctionObjects" with handle 0xa8a170
```
In the tutorial test loop this is pure poison since output (stdout) is the input for the following changeDictionary.
For additional robustness, the warnings really should be redirected to stderr when the banner is suppressed.
Additionally, loading additional libraries should likely be suppressed in `foamListRegions` as well.
This means that the errors will disappear for that tutorial, but there still seems to be fundamental issue with the field function library.
@andyv2006Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/issues/1717add shell syntax for modules2020-06-05T11:47:28ZMark OLESENadd shell syntax for modules- refactor/modify foamCreateModuleInclude to support shell output- refactor/modify foamCreateModuleInclude to support shell outputMark OLESENMark OLESEN