Development issueshttps://develop.openfoam.com/groups/Development/-/issues2020-06-11T15:03:07Zhttps://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 OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1472dynamicCode should use polling instead of re-checking only once2020-06-05T08:12:26ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comdynamicCode should use polling instead of re-checking only once### Functionality to add/problem to solve
db/dynamicLibrary/dynamicCode/dynamicCode.C in parallel can have that the library does not exist on all slave processors. It first checks at beginning and then waits 'fileModificationSkew' secon...### Functionality to add/problem to solve
db/dynamicLibrary/dynamicCode/dynamicCode.C in parallel can have that the library does not exist on all slave processors. It first checks at beginning and then waits 'fileModificationSkew' seconds and rechecks. If this fails the code will fail. Nicer if the check gets done multiple times before failing.
Alternatively send over the library (is this possible? is it cross-node compatible?)https://develop.openfoam.com/Development/openfoam/-/issues/1720missing compilation for some vtk conversion components2020-06-04T23:11:50ZMark OLESENmissing compilation for some vtk conversion componentsMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1716erroneous return from void method2020-06-04T23:11:50ZMark OLESENerroneous return from void methodPtrList append has a return, but the method is `void`
- long-standing bug (dating back to 2014), but obviously never exercised.PtrList append has a return, but the method is `void`
- long-standing bug (dating back to 2014), but obviously never exercised.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1713allow redirect of Warnings to stderr2020-05-26T05:39:14ZMark OLESENallow redirect of Warnings to stderrIf running without banners we set infoDetailLevel to suppress stdout, or use stderr instead (cf. issues #722, #893).
However WarningInFunction etc still land on stdout!
Instead of introducing yet another message stream, hijack the infoD...If running without banners we set infoDetailLevel to suppress stdout, or use stderr instead (cf. issues #722, #893).
However WarningInFunction etc still land on stdout!
Instead of introducing yet another message stream, hijack the infoDetailLevel for redirecting warnings to stderr for these cases.v2006Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1709improve flexibility of external wall temperature/heat flux2020-05-25T21:08:18ZMark OLESENimprove flexibility of external wall temperature/heat flux- make some components Function1 or PatchFunction1
- add expressions and/or coded versions
@Mattijs @sergio- make some components Function1 or PatchFunction1
- add expressions and/or coded versions
@Mattijs @sergiov2006https://develop.openfoam.com/Development/openfoam/-/issues/893Need stderr or equivalent alternative to Info2020-05-23T11:04:36ZMark OLESENNeed stderr or equivalent alternative to InfoIn some situations informative output gets in the way of desired output (eg, foamDictionary output - EP702).
We can avoid some of this output with `argList::noBanner()`. In the .org version they have replace this with a dedicated InfoHe...In some situations informative output gets in the way of desired output (eg, foamDictionary output - EP702).
We can avoid some of this output with `argList::noBanner()`. In the .org version they have replace this with a dedicated InfoHeader message stream, which handles the same problem. However, we may also to have a more general solution (cf. #881).
In similar cases it could also be helpful to have a Serr that only outputs on the master.
With dynamic code generation (eg `#calc`) the process generated copious quantities of output, all of which land on stdout.
Perhaps we need a version of `system()` with a `dup2()` to redirect.
@Mattijsv1812Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/722getApplication does not work with #calc statements in the controlDict2020-05-23T11:04:36ZRoger AlmenargetApplication does not work with #calc statements in the controlDictWhen there are #calc statements in the controlDict (either directly or as an #include), the function getApplication fails because the output from foamDictionary includes all the output statements from #calc.
This is fixed by adding a ta...When there are #calc statements in the controlDict (either directly or as an #include), the function getApplication fails because the output from foamDictionary includes all the output statements from #calc.
This is fixed by adding a tail -1 as follows to the getApplication function:
*foamDictionary -entry application -value system/controlDict | tail -1*
Examples of issue shown below:
[controlDict](/uploads/a24ecfdd4fc33ecb3b708d568a567744/controlDict)[input.txt](/uploads/adacd8e356f3237544fac31a6ab01ee3/input.txt)v1806Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1707RPM packages on the openSUSE build service do not have functional wmake2020-05-22T22:29:22ZAlberto PassalacquaRPM packages on the openSUSE build service do not have functional wmakeInstalling the openSUSE packages from the openSUSE science repository for Leap 15.1 does not seem to provide a working wmake.
This can be reproduced both using the openfoam1912 and sourcing /usr/lib/openfoam/openfoam1912/etc/bashrcInstalling the openSUSE packages from the openSUSE science repository for Leap 15.1 does not seem to provide a working wmake.
This can be reproduced both using the openfoam1912 and sourcing /usr/lib/openfoam/openfoam1912/etc/bashrchttps://develop.openfoam.com/Development/openfoam/-/issues/1708construct edge/fixed list from subset2020-05-22T12:24:32ZMark OLESENconstruct edge/fixed list from subset@Mattijs@MattijsMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1682interCondensatingEvaporatingFoam: pressure equation mass transfer source term2020-05-19T23:53:31ZDanial KhazaeiinterCondensatingEvaporatingFoam: pressure equation mass transfer source term### Summary
I was going through interCondensatingEvaporatingFoam equations derivation including constant phase change model. Considering the mass balance equation of the liquid phase (e.g. $`\alpha_{1}`$) and positive mass transfer defi...### Summary
I was going through interCondensatingEvaporatingFoam equations derivation including constant phase change model. Considering the mass balance equation of the liquid phase (e.g. $`\alpha_{1}`$) and positive mass transfer defined as being from the vapor to the liquid:
```math
\frac{\partial \left ( \alpha_{1}\rho_{1} \right )}{\partial t} + \bigtriangledown\cdot \left ( \alpha_{1}\rho_{1}\vec{U} \right ) = -\dot{m_{12}} + \dot{m_{21}}
```
with $`\dot{m_{12}} , \dot{m_{21}}> 0`$.
By summing over both phases one can derive the statement for total mass balance equation:
```math
\bigtriangledown\cdot \left ( \vec{U} \right ) = \left [ -\dot{m_{12}} + \dot{m_{21}} \right ] \left ( \frac{1}{\rho_{1}} - \frac{1}{\rho_{2}} \right )
```
Converting to the solver implementation notations, we have:
```math
\dot{m_{v}} = -\dot{m_{12}}
```
```math
\dot{m_{c}} = \dot{m_{21}}
```
Keeping in mind that the current implementation returns the mass transfer calculated for each phase with the correct sign, we can re-write the total mass balance equation with OpenFOAM notations as follow:
```math
\bigtriangledown\cdot \left ( \vec{U} \right ) = \left [ -\dot{m_{12}} + \dot{m_{21}} \right ] \left ( \frac{1}{\rho_{1}} - \frac{1}{\rho_{2}} \right ) = \dot{v_{21}} - \dot{v_{12}} = \dot{v_{c}} + \dot{v_{v}}
```
However, instead of $`\dot{v_{c}} + \dot{v_{v}}`$ the current pEqn implementation reads:
```
fvScalarMatrix p_rghEqn
(
fvc::div(phiHbyA)
- fvm::laplacian(rAUf, p_rgh)
==
vDotv - vDotc
);
```
Can you explain why the solver is using $`\dot{v_{v}} - \dot{v_{c}}`$?
It is worth to mention that the mass transfer source terms for alphaEqn and TEqn are following the correct analogy as the sign of the terms are consistent. However, there seems to be a another problem regarding how energy sources are calculated for TEqn which I try to explain below.
### Steps to reproduce
1. Run condensatingVessel tutorial with the current configuration
1. Run condensatingVessel tutorial with the coeffE = 0
The result is completely different.
### Example case
condensatingVessel
### What is the current *bug* behaviour?
When simulating a condensation only problem, the evaporation coefficient affects the solution.
### What is the expected *correct* behavior?
The evaporation coefficient should not affect the condensation only problems and vice-versa.
### Environment information
- OpenFOAM version : develop
- Operating system : Ubuntu
- Hardware info : irrelevant
- Compiler : gcc-7
### Possible fixes
The reason for this behaviour is that the constant model defines the evaporation and condensation sources simultaneously. Based on the implemented mass transfer mechanisms, a cell can only have one of the following conditions:
1. no phase change
2. evaporation
3. condensation
However, the current implementation includes phase change energy sources without considering the cell condition:
```
const volScalarField Vcoeff
(
coeffE_*mixture_.rho1()*limitedAlpha1*L
);
const volScalarField Ccoeff
(
coeffC_*mixture_.rho2()*limitedAlpha2*L
);
TSource =
fvm::Sp(Vcoeff, T) - Vcoeff*TSat
- fvm::Sp(Ccoeff, T) + Ccoeff*TSat;
```
I think the correct implementation should consider the cell condition as follow, e.g. we should not have evaporation energy source when the cell is actually condensing.
```
const volScalarField Vcoeff
(
coeffE_*mixture_.rho1()*limitedAlpha1*L*pos(T - TSat)
);
const volScalarField Ccoeff
(
coeffC_*mixture_.rho2()*limitedAlpha2*L*pos(TSat - T)
);
TSource =
fvm::Sp(Vcoeff, T) - Vcoeff*TSat
- fvm::Sp(Ccoeff, T) + Ccoeff*TSat;
```Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/issues/1694ThermalPhaseChangePhaseSystem.C Info statements for parallel run2020-05-19T23:51:55ZRobin KamenickyThermalPhaseChangePhaseSystem.C Info statements for parallel run<!--
*** 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
Eulerian-Eulerian phase change solvers do not provide the right information about wDmdt, iDmdt and Tf when running in parallel and ThermalPhaseChangePhaseSystem.C is used.
### Steps to reproduce
run $FOAM_TUTORIALS/heatTransfer/chtMultiRegionTwoPhaseEulerFoam/solidQuenching2D using one core and 4 cores.
The information about wDmdt written in log will start to differ right from the beginning. If more cores are used it can get more obvious depends which core writes the log. Apparently, we can not see the iDmdt because boiling/condensation in the bulk is off but should be easy to see in the same manner.
### Example case
A tutorial case can be used.
### What is the current *bug* behaviour?
Described in the summary section.
### What is the expected *correct* behavior?
The information written are meant to be min, mean and max values. Therefore these values are expected to be given as values on the whole domain not on "random" core.
### 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 : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v1906
- Operating system : Ubuntu 16.04.6 LTS
- Hardware info :
- Compiler : gcc
### Possible fixes
I assume that it happens just because of the functions (min, max, average) used to find/calculate the values.
Using v1912:
ThermalPhaseChangePhaseSystem.C:432..436
`
Info<< "Tf." << pair.name()
<< ": min = " << min(Tf.primitiveField())
<< ", mean = " << average(Tf.primitiveField())
<< ", max = " << max(Tf.primitiveField())
<< endl;`
ThermalPhaseChangePhaseSystem.C:443..448
`
Info<< "iDmdt." << pair.name()
<< ": min = " << min(iDmdt.primitiveField())
<< ", mean = " << average(iDmdt.primitiveField())
<< ", max = " << max(iDmdt.primitiveField())
<< ", integral = " << fvc::domainIntegrate(iDmdt).value()
<< endl;`
ThermalPhaseChangePhaseSystem.C:527..532
`
Info<< "wDmdt." << pair.name()
<< ": min = " << min(wDmdt.primitiveField())
<< ", mean = " << average(wDmdt.primitiveField())
<< ", max = " << max(wDmdt.primitiveField())
<< ", integral = " << fvc::domainIntegrate(wDmdt).value()
<< endl;`
In all these lines change functions min to gMin, max to gMax, average to gAverage.
I have not tried the code with the changes by myself.