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/openfoam/-/issues/449"timeVaryingMappedFixedValue" cannot read files when I use mpirun2019-12-09T21:29:29ZAdmin"timeVaryingMappedFixedValue" cannot read files when I use mpirunHi,
The boundary condition "timeVaryingMappedFixedValue" refuses to read inlet files in boundaryData/inlet at each time steps when I use mpirun.
**1. I post what I saw from the screen: **
```
Starting time loop
streamLine stream...Hi,
The boundary condition "timeVaryingMappedFixedValue" refuses to read inlet files in boundaryData/inlet at each time steps when I use mpirun.
**1. I post what I saw from the screen: **
```
Starting time loop
streamLine streamLines:
Employing velocity field U
automatic track length specified through number of sub cycles : 5
Time = 1
timeVaryingFixedValueFvPatchField : Read 70 sample points from "/home/ofuser/wor
kingDir/run/pitzDailyExptInlet/processor0/../constant/boundaryData/inlet/points"
timeVaryingFixedValueFvPatchField : In directory "/home/ofuser/workingDir/run/pi
tzDailyExptInlet/processor0/../constant/boundaryData/inlet" found times
4
(
0
0.7
2
4
)
[0] checkTable : Reading startValues from "boundaryData/inlet/0.7"
[3] checkTable : Reading startValues from "boundaryData/inlet/0.7"
[2] checkTable : Reading startValues from "boundaryData/inlet/0.7"
[1] checkTable : Reading startValues from "boundaryData/inlet/0.7"
[3] checkTable : Reading endValues from "boundaryData/inlet/2"
[0] checkTable : Reading endValues from "boundaryData/inlet/2"
[2] checkTable : Reading endValues from "boundaryData/inlet/2"
[0]
[0]
[0] --> FOAM FATAL IO ERROR:
[0] file "../constant/boundaryData/inlet/2/U" does not exist
[0]
[0] file: ../constant/boundaryData/inlet/2/U at line 1.
[0]
[0] From function Foam::IFstream& Foam::IFstream::operator()() const
[0] in file db/IOstreams/Fstreams/IFstream.C at line 176.
[0]
FOAM parallel run exiting
[0]
--------------------------------------------------------------------------
MPI_ABORT was invoked on rank 0 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.
--------------------------------------------------------------------------
[1] checkTable : Reading endValues from "boundaryData/inlet/2"
[3]
[3]
[3] --> FOAM FATAL IO ERROR:
[3] file "../constant/boundaryData/inlet/2/U" does not exist
[3]
[3] file: ../constant/boundaryData/inlet/2/U at line 1.
[3]
[3] From function Foam::IFstream& Foam::IFstream::operator()() const
[3] in file db/IOstreams/Fstreams/IFstream.C at line 176.
[3]
FOAM parallel run exiting
[3]
[2]
[2]
[2] --> FOAM FATAL IO ERROR:
[2] file "../constant/boundaryData/inlet/2/U" does not exist
[2]
[2] file: ../constant/boundaryData/inlet/2/U at line 1.
[2]
[2] From function Foam::IFstream& Foam::IFstream::operator()() const
[2] in file db/IOstreams/Fstreams/IFstream.C at line 176.
[2]
FOAM parallel run exiting
[2]
[1]
[1]
[1] --> FOAM FATAL IO ERROR:
[1] file "../constant/boundaryData/inlet/2/U" does not exist
[1]
[1] file: ../constant/boundaryData/inlet/2/U at line 1.
[1] [default:26184] 1 more process has sent help message help-mpi-api.txt / mpi-
abort
[default:26184] Set MCA parameter "orte_base_help_aggregate" to 0 to see all hel
p / error messages[pitzDailyExptInlet.7z](/uploads/eb58a7f8a25df1966091c72985e38262/pitzDailyExptInlet.7z)
```
[pitzDailyExptInlet.7z](/uploads/9df573a34ff06fbb460b03bd7e9f71b4/pitzDailyExptInlet.7z)
**2. To reproduce the error, the steps are: **
*step 1*: clone pitzDailyExptInlet;
*step 2*: creat new files of others time steps by copying constant/boundaryData/inlet/0. So I have new directories and files like:
constant/boundaryData/inlet/0.7/U
constant/boundaryData/inlet/0.7/k
constant/boundaryData/inlet/0.7/epsilon
constant/boundaryData/inlet/2/U
constant/boundaryData/inlet/2/k
constant/boundaryData/inlet/2/epsilon
constant/boundaryData/inlet/4/U
constant/boundaryData/inlet/4/k
constant/boundaryData/inlet/4/epsilon
*step 3*: I run "blockMesh" "decomposePar" then "mpirun -np 4 simpleFoam -parallel"
**3. The version OpenFoam 3.0.x is used and the case is run in windows system (windows server 2012). **
* No errors are producted during "blockMesh", "decomposePar" in mpirun
* No errors are producted in sequential calculation.
* I have attached my test case.
Best Regards,AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/2203<time>/uniform/cumulativeContErr not region specific2021-12-15T19:11:38ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.com<time>/uniform/cumulativeContErr not region specific<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
the cumulativeContErr state inside uniform/ is not region-specific so multiple regions will clash.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
multiRegionHeater tutorial. Check time dump.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906|v1912|v2006|v2012|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2106
### Possible fixes
Add region
@andyMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/3008Time::findInstance cannot distinguish between failure and success2023-12-21T15:53:49ZMark OLESENTime::findInstance cannot distinguish between failure and successCurrently with the following type of code:
```
fileName inst =
(
runTime.findInstance
(
polyMesh::meshSubDir,
"some-file",
IOobject::READ_IF_PRESENT
)
);
```
It will return `"constant"` even if that pa...Currently with the following type of code:
```
fileName inst =
(
runTime.findInstance
(
polyMesh::meshSubDir,
"some-file",
IOobject::READ_IF_PRESENT
)
);
```
It will return `"constant"` even if that particular file cannot be found. This means we need an additional code
```
Foam::isFile(inst/polyMesh::meshSubDir/"some-file")
```
To check if we have a false positive.
One thought was some extra magic, for example:
```
fileName inst =
(
runTime.findInstance
(
polyMesh::meshSubDir,
"some-file",
IOobject::READ_IF_PRESENT,
"#magic-code#" // This is actually the stop instance, but give it some invalid name.
)
);
```
which would signal the internal logic to return an empty fileName on failure. The alternative would be to use `MUST_READ` within a try/catch block, but that is not particularly attractive either.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/791time-control function object does not respect underlying function object2020-03-13T13:46:29ZMark OLESENtime-control function object does not respect underlying function objectWhen a function-object uses `timeStart`, `timeEnd` to control its activation, these values are used to define if execution or writing occurs, but can also mean that the underlying `end()` function is never called.
This can be problematic...When a function-object uses `timeStart`, `timeEnd` to control its activation, these values are used to define if execution or writing occurs, but can also mean that the underlying `end()` function is never called.
This can be problematic if the `end()` method is being used to free up resources.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/420timeActivatedFileUpdate FO takes two iterations to come into effect2018-05-03T18:08:12ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comtimeActivatedFileUpdate FO takes two iterations to come into effect(Exchange 358)
- time to activate is exact so e.g. if time = 4.9999999 and activate time is set as 5 it will not trigger
- checking for changed files is done before executing FOs so change of file is not picked up until next time ste...(Exchange 358)
- time to activate is exact so e.g. if time = 4.9999999 and activate time is set as 5 it will not trigger
- checking for changed files is done before executing FOs so change of file is not picked up until next time step
- improvement: forcibly re-check modified files in timeActivatedFileUpdate:
cp(timeVsFile_[i].second(), destFile);
mv(destFile, fileToUpdate_);
lastIndex_ = i;
const_cast<Time&>(time_).Time::readModifiedObjects();
(make sure to call Time::readModifiedObjects, not objectRegistry one)
- other: if updated files are themselves FOs these need to do their action in their 'read' function or constructor. Alternative would be to know which FOs are new and execute only these. This sounds too convoluted.Version v1706Prashant SonakarPrashant Sonakarhttps://develop.openfoam.com/Development/openfoam/-/issues/2573throw FatalIOerror instead of FatalError in timeActivateFileUpdate2022-09-08T07:15:18ZMark OLESENthrow FatalIOerror instead of FatalError in timeActivateFileUpdateIn timeActivateFileUpdate, the filechecks emit a FatalError if any of the source files are missing on startup. By default this throw/catch is downgraded to a warning unless the user specifies a different error handling.
However, since th...In timeActivateFileUpdate, the filechecks emit a FatalError if any of the source files are missing on startup. By default this throw/catch is downgraded to a warning unless the user specifies a different error handling.
However, since this functionObject is intended as a control mechanism (similar to system/controlDict, for example), it makes more sense for a missing file to be really fatal. Elevating to an IOerror will do this for the default error handling.
cross-ref EP1968Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2257threaded collated writing (maxThreadFileBufferSize) fails at end of run2021-11-02T14:42:23ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comthreaded collated writing (maxThreadFileBufferSize) fails at end of 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 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 -->
Sometimes (slow disks) at the end of a run with collated+threaded it fails with sigsegv.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Take case (e.g. cavity), make mesh bigger and time step smaller. Change to write every timestep. Switch on threaded writing and collated. On machines with slow IO the processor0 will finish with an error (sigsegv).
### Example case
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
See above. All depends on how slow the IO is.
### What is the current *bug* behaviour?
<!-- What actually happens -->
See above.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906|v1912|v2006|v2012|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2106
- Operating system : linux
- Hardware info :
- Compiler :
### Possible fixes
Threaded writing uses a write thread. This gets passed all the data to write and it is now responsible for deleting the data after writing. This means that even e.g. header information cannot get passed in by reference since it might be out of scope when the writer is still writing.
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->
@markMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/ThirdParty-common/-/issues/12ThirdParty-plus makeLLVM2019-07-21T22:56:27ZRoger AlmenarThirdParty-plus makeLLVMIf you look at line 92, there is a test for variable WM_CC, but then variable CC is set as $WM_CC**X**, different from $WM_CC. Hence in my system it CC is set to empty. The same does not happen with $WM_CXX. Could this be a typo when wri...If you look at line 92, there is a test for variable WM_CC, but then variable CC is set as $WM_CC**X**, different from $WM_CC. Hence in my system it CC is set to empty. The same does not happen with $WM_CXX. Could this be a typo when writing $WM_CC?https://develop.openfoam.com/Development/ThirdParty-common/-/issues/26ThirdParty-plus FFTW version2018-12-19T11:26:51ZRoger AlmenarThirdParty-plus FFTW versionThe FFTW version that we have in our develop files (etc/config.sh/FFTW) has been withdrawn from the public domain.
See from www.fftw.org/release-notes.html:
FFTW 3.3.6-pl1 (withdrawn)
Jan 16th, 2017
Bugfix: FFTW 3.3.6 had the wrong...The FFTW version that we have in our develop files (etc/config.sh/FFTW) has been withdrawn from the public domain.
See from www.fftw.org/release-notes.html:
FFTW 3.3.6-pl1 (withdrawn)
Jan 16th, 2017
Bugfix: FFTW 3.3.6 had the wrong libtool version number, and generated shared libraries of the form libfftw3.so.2.6.6 instead of libfftw3.so.3.*.
We should probably move to -pl2 instead of –pl1 .v1712Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2353ThirdParty documentation inconsistency2022-02-11T19:02:44ZDarrin StephensThirdParty documentation inconsistency
### Summary
The ThirdParty SOURCES.md says that the ADIOS2 version for OpenFOAM-v2112 is 2.7.1. However the version set in
etc/config.sh/adios2 and etc/config.csh/adios2 is still 2.6.0.
### Possible fixes
Update the etc/config.sh/adio...
### Summary
The ThirdParty SOURCES.md says that the ADIOS2 version for OpenFOAM-v2112 is 2.7.1. However the version set in
etc/config.sh/adios2 and etc/config.csh/adios2 is still 2.6.0.
### Possible fixes
Update the etc/config.sh/adios2 and etc/config.sh/adios2 files to use version 2.7.1.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2479The spurious velocity is too large using isoAdvection2024-01-11T18:59:52ZJinghong SuThe spurious velocity is too large using isoAdvectionI am testing the movement of a 2D bubble under a Couette flow using the interFoam and interIsoFoam, finding that the spurious velocities produced by the isoAdvection plicRDF are even larger than those produced by the MULES.The bubble is ...I am testing the movement of a 2D bubble under a Couette flow using the interFoam and interIsoFoam, finding that the spurious velocities produced by the isoAdvection plicRDF are even larger than those produced by the MULES.The bubble is in a developed Couette flow and the Reynolds number is 100 and CFL=0.1. The density ratio between the air and water is set to be 1:10. The gravity is set to be zero.
interIsoFoam
![interIsoFoam](/uploads/714bd9cab52469f8bdde7eb3a9154d49/interIsoFoam.png)
interFoam
![interFoam](/uploads/3c77e660c2051fec70907da6c21f8da7/interFoam.png)
I wonder if the isoAdvection plicRDF in opefoam-v2012 is the same as the isoAdvection plicRDF-5 in the article "Validation of volume-of-fluid OpenFOAM® isoAdvector solvers using single bubble benchmarks".
The run file is attached below
[re100_bubble.zip](/uploads/f99c3ffbf1ede7a4fffe89337c35ba45/re100_bubble.zip)
- OpenFOAM version :Openfoam-v2012
- Operating system :entOS Linux release 7.4.1708 (Core)
- Hardware info :
- Compiler :gcc-4.9.4https://develop.openfoam.com/Development/openfoam/-/issues/2201The solver implantation fails in OpenFOAM-v20122021-09-08T07:43:36ZYiThe solver implantation fails in OpenFOAM-v2012<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
I copied the code of pimpleFoam solver into a new folder and renamed it as TKEFoam. I change the pimpleFoam.C into TKEFoam.C and I also change the file in the Make folder. When I run TKEFoam, I get this error:
*** Error in `TKEFoam': free(): invalid pointer: 0x0000000000e20048 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x81429)[0x7ff322bac429]
TKEFoam(_ZN4Foam5tokenD1Ev+0x75)[0x43a755]
... ...
### Steps to reproduce
1) create a new folder in OpenFOAM, my folder name is userdefined
2) copy the pimpleFoam code from the directory: applications/solvers/incompressible/pimpleFoam to the folder you create
3) modify the name of pimpleFoam.C as XXXFoam.C, the operation should be carried out in files in Make folder
4) modify the content: "EXE = $(FOAM_APPBIN)/pimpleFoam" as "EXE = $(FOAM_USER_APPBIN)/XXXFoam" in files
5) compile the code. Then use channel395 case to test the solver XXXFoam, the errors show up.
### What is the expected *correct* behavior?
Since the solver is the same as pimpleFoam, there should not be any error
### Relevant logs and/or images
![image](/uploads/0bbec8794e0db73570e988dd709cdc58/image.png)
### Environment information
OpenFOAM version : v1912|v2006|v2012
Compiler : intelhttps://develop.openfoam.com/Development/openfoam/-/issues/211The + sign in "OpenFOAM-v1606+" leads to a non-breaking error when building t...2016-09-30T10:47:52ZAdminThe + sign in "OpenFOAM-v1606+" leads to a non-breaking error when building the "PVReaders" plug-ins for ParaViewWhen building "OpenFOAM-v1606+" from source code, the following error appears when building `$FOAM_UTILITIES/postProcessing/graphics/PVReaders/PVblockMeshReader/PVblockMeshReader`:
```
[ 5%] Generating Documentation HTMLs from xmls
...When building "OpenFOAM-v1606+" from source code, the following error appears when building `$FOAM_UTILITIES/postProcessing/graphics/PVReaders/PVblockMeshReader/PVblockMeshReader`:
```
[ 5%] Generating Documentation HTMLs from xmls
Error FODC0002 in file:///home/ofuser/OpenFOAM/OpenFOAM-v1606: Error opening /home/ofuser/OpenFOAM/OpenFOAM-v1606: No such file or directory
Error FODC0002 in file:///applications/utilities/postProcessing/graphics/PVReaders/PVblockMeshReader/PVblockMeshReader/PVblockMeshReader_SM.xml: Error opening /applications/utilities/postProcessing/graphics/PVReaders/PVblockMeshReader/PVblockMeshReader/PVblockMeshReader_SM.xml: No such file or directory
```
The reason why this happens is because the `+ ` symbol is used as a path separator for the variable `input_xmls` in `ThirdParty-v1606+/platforms/linux64Gcc/ParaView-5.0.1/lib/cmake/paraview-5.0/generate_proxydocumentation.cmake`.
This isn't a problem when building from the git repository, given that `WM_PROJECT_VERSION=plus`.
----
Either way, I unfortunately haven't figured out a workaround for this. But as I've stated in the title, this is non-breaking error, i.e. it will still build without stopping.
https://develop.openfoam.com/Development/openfoam/-/issues/2996ThermoSurfaceFilm: absorbInteraction does not add energy to film sources2023-10-11T10:32:29ZKutalmış BerçinThermoSurfaceFilm: absorbInteraction does not add energy to film sourcesPrior to v2112, the `ThermoSurfaceFilm::absorbInteraction`:
film.addSources
(
pp.index(),
facei,
mass, // mass
mass*Ut, // tangential momentum
...Prior to v2112, the `ThermoSurfaceFilm::absorbInteraction`:
film.addSources
(
pp.index(),
facei,
mass, // mass
mass*Ut, // tangential momentum
mass*mag(Un), // impingement pressure
mass*p.hs() // energy
);
a9aa6cb0db838edd3b5305a7a511e5a9caa56094 inadvertently left the 'energy' term at zero for the `ThermoSurfaceFilm`:
film.addSources
(
pp.index(),
facei,
mass, // mass
mass*Ut, // tangential momentum
mass*mag(Un), // impingement pressure
0 // energy
);Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/887thermo sharing temperature2018-07-01T05:46:06ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comthermo sharing temperatureExplicitly use T. @Sergio Explicitly use T. @Sergio Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1423thermopysical library in calculating compressibility for burned products2019-09-18T20:56:21ZAdminthermopysical library in calculating compressibility for burned products<!--
*** 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
Library in evaluating compressibility of burned products is based on the properties of reactants not on those of products, probably by typing error.
See the source code of member function psib() in lines around 612 and 627 $src/thermophysicalModels/reactionThermo/psiuReactionThermo/heheuPsiThermo.C
### Steps to reproduce
Use XiFoam solver, and run a tutorial case, e.g. moriyoshiHomogeneous. Use very different values of molecular weight for reactants and products. Use constant density for both reactants and products. Compare the calculated burned density by the code and your input. You will notice they are different. Since the burned density (or psib() ) is recalcualted based on the molecular weight of reactants.
### Example case
Run tutorial moriyoshiHomogeneous, but change the molecualr weight of reactants and products to be very different values since the tuturial uses very similar values in constant/thermopysicalProperties.
### What is the current *bug* behaviour?
You will notice, the burned density is calculated based on the molecular wieght by reactants not by products.
### What is the expected *correct* behavior?
The burned density should be calculated based on the molecular wieght by products.
### Environment information
- OpenFOAM version :v1812
- Operating system :centos
- Hardware info :
- Compiler :gcc
### Possible fixes
The bug can be easily fixed by changing the keywords from reactants to products as follows in the file of member function psib() in $src/thermophysicalModels/reactionThermo/psiuReactionThermo/heheuPsiThermo.C as follows
forAll(psibCells, celli)
{
psibCells[celli] =
this->**cellProducts**(celli).psi(pCells[celli], TbCells[celli]);
}... forAll(ppsib, facei)
{
ppsib[facei] =
this->**patchFaceProducts**
(patchi, facei).psi(pp[facei], pTb[facei]);
}https://develop.openfoam.com/Development/openfoam/-/issues/2443thermophysicalFunctions/integratedNonUniformTable <revised>2022-04-15T02:07:26ZScurry GunHong KimthermophysicalFunctions/integratedNonUniformTable <revised><!--
*** 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 -->
This code-bug is a simple mistake, but it can produce a serious problem at least for me.
For several monthes, I've tried to test a tabulated thermo-data and found this bug.
Today I found there is a worng formula to integrate the tabulated data to calculate the enthalpy of specie, for example table(T, Cp).
The bug is in "integratedNonUniformTableThermophysicalFunction.C" under src/thermophysicalProperties/thermophysicalFunctions/integratedNonUniformTable/.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Just look the Constructor of "integratedNonUniformTable" or the fuction of "intfdT".
- integral formula:
Integral from Tst to Ti = Integral[i-1] + intfdT(Ti)*dT
- in "intfdT" function, it returns the full integral value from Tst to Ti.
return-value = intf_[i] + (fi + 0.5*lambda*(values()[i + 1].second() - fi))*dT
### Example case
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
- There are 2 tutorials in $FOAM_TUTORIALS, they use the thermo-type of tabulation.
multiphase/icoReactingMultiphaseInterFoam/inertMultiphaseMultiComponent
multiphase/icoReactingMultiphaseInterFoam/mixerVesselAMI2D
- the bug is related only to calculate the enthalpy of hTabulated-thermo.
Actually, two cases work. However if you use a large table of Cp, then a serious error occur to stop.
### What is the current *bug* behaviour?
- If the element-number of tabulated data is small, then it might not produce a serious problem.
Therefore, nobody notice any wrong result.
- for a large tabulated data, in most cases, the calculation must stop to say wrong temperature.
<!-- What actually happens -->
### What is the expected *correct* behavior?
<!-- What you should see instead -->
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2112|v2006|v1912|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2112(or any)
- Operating system : ubuntu
- Hardware info : any
- Compiler : any
### Possible fixes
- code:
https://www.openfoam.com/documentation/guides/latest/api/integratedNonUniformTableThermophysicalFunction_8C_source.html
- one simple suggestion for constructor "integratedNonUniformTable"
original code
for (label i = 1; i < intf_.size(); ++i)
{
intf_[i] = intf_[i-1] + intfdT(0, values()[i].first());
intfByT_[i] = intfByT_[i-1] + intfByTdT(0, values()[i].first());
}
suggestion
for (label i = 1; i < intf_.size(); ++i)
{
intf_[i] = intfdT(0, values()[i].first());
intfByT_[i] = intfByTdT(0, values()[i].first());
}
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->https://develop.openfoam.com/Development/openfoam/-/issues/2365thermoCoupleProbes tutorial crash2022-06-28T11:01:11ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comthermoCoupleProbes tutorial crash<!--
*** 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 -->
Tutorial heatTransfer/buoyantPimpleFoam/thermocoupleTestCase crashes
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
foamRunTutorials
### Example case
See above
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
### What is the current *bug* behaviour?
<!-- What actually happens -->
```
-> FOAM FATAL ERROR: (openfoam-2112)
T not found in table. Valid entries: 0()
```
### 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 : >v2112Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2344Thermal resistance layer(s) not accounted for in turbulentTemperatureRadCoupl...2022-04-14T12:24:14ZLieven VerveckenThermal resistance layer(s) not accounted for in turbulentTemperatureRadCoupledMixedFvPatchScalarField
### Summary
The thermal resistance layers are not properly taken into account in the turbulentTemperatureRadCoupledMixed boundary condition (possibly the same problem in other boundary conditions as well).
### Steps to reproduce
Add ...
### Summary
The thermal resistance layers are not properly taken into account in the turbulentTemperatureRadCoupledMixed boundary condition (possibly the same problem in other boundary conditions as well).
### Steps to reproduce
Add a thermal resistance, either as contactLayer or as contactLayers, to a multi-region heat heat transfer case.
### Example case
Any multi-region tutorial will do.
### What is the current *bug* behaviour?
The temperatures do not change when adding the resistance layer(s).
### What is the expected *correct* behavior?
~~A temperature difference between the two regions at the interface.~~
A change in temperatures of the interface and regions
### Environment information
- OpenFOAM version : v2112
- Operating system : CentOS
- Compiler : gcc
### Possible fixes
Possible fix attached as patch file (only tested in non-implicit mode). It was set up based on the v2012 version of the code.[turbulentTemperatureRadCoupledMixedFvPatchScalarField.patch](/uploads/80d9c93935f449426bf423c69adc2ed5/turbulentTemperatureRadCoupledMixedFvPatchScalarField.patch)