Development issueshttps://develop.openfoam.com/groups/Development/-/issues2022-03-12T09:18:31Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2347refactor coordSet writers2022-03-12T09:18:31ZMark OLESENrefactor coordSet writerscross-ref EP1772
- this is a particularly older section of OpenFOAM code. Will restructure to more closely resemble the surface writers with internal time-state, etc.cross-ref EP1772
- this is a particularly older section of OpenFOAM code. Will restructure to more closely resemble the surface writers with internal time-state, etc.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2345snappyHexMesh blockLevel uses excessive memory2022-06-28T11:08:56ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsnappyHexMesh blockLevel uses excessive memory<!--
*** 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 -->
snappyHexMesh can automatically 'block' a small gap by specifying an optional `blockLevel`. This does a wall-distance like calculation and decides per cell if there is an 'opposite' surface as well. If the gap is too small (according to the blockLevel) the cell is marked for deletion.
The problem with the algorithm is that it walks from all surfaces over all of the mesh before in pass 2 deciding whether there is a combination of nearest surfaces that triggers cell deletion. This causes for large meshes and large numbers of surfaces there to be an excessive amount of wall-distance state being generated and compared.
<!-- How one can reproduce the issue - this is very important -->
### 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
-->
Tutorial mesh/snappyHexMesh/opposite_walls
It is hard to measure the memory usage though since there are only 3 surfaces and they are tiny.
### What is the current *bug* behaviour?
<!-- What actually happens -->
Memory usage scales with the number of surfaces. For e.g. a case with 100 stls it would store per cell and face 100 structures containing each a vector and some labels. This would cause the memory to run out.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
Memory usage should be limited.
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2112|v2106|v2012|v2006|v1912|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2112
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->
Currently : walk all surfaces out over the whole mesh. Pass 2: decide which combinations form a valid small gap.
Fix : do not walk beyond the size given by the originating surface (= 1/2<<blockLevel). This drastically limits the amount of information that needs to be stored.
See https://exchange.openfoam.com/node/1798Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://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)https://develop.openfoam.com/Development/openfoam/-/issues/2342volAverage volume output2022-01-31T08:36:25ZGabriel AxtmannvolAverage volume output
Volume output of a changing cellZone,for example a moving piston would be nice
Volume output of a changing cellZone,for example a moving piston would be nicehttps://develop.openfoam.com/Development/openfoam/-/issues/2339Docs: Debian 11.2 compile Patch Release OpenFOAM-9-202111222024-01-09T12:07:03ZPhilipDocs: Debian 11.2 compile Patch Release OpenFOAM-9-20211122Hello, maintaining documentation is challenging as code and host infrastructure advances, so you might appreciate feedback from someone looking at the documentation with fresh eyes. Here are some documentation issues I encountered while ...Hello, maintaining documentation is challenging as code and host infrastructure advances, so you might appreciate feedback from someone looking at the documentation with fresh eyes. Here are some documentation issues I encountered while compiling Patch Release OpenFOAM-9-20211122 on current Debian stable 11.2.
1. Good news -- currently Debian stable repository provides paraview 5.9.0-2 and libscotch 6.1 and libptscotch-6.1, so this might simplify the Third Party install process and instructions.
In particular the Debian comments in https://openfoam.org/download/source/third-party-software/ appear to be obsolete.
2. The documentation leaves me wondering whether compiling the third party tools are essential if newer libscotch and paraview are installed.
Running ./Allwmake does compile libscotch, perhaps an older version 6.0.9. It's possible that one wants exactly that version; if so it would be helpful to say so.
3. In the case that the user uses the repository paraview, it's not clear
a) Whether it is a concern that the following environment variables are set incorrectly,
b) Whether they are needed
c) Where (in/by which script) they are being created:
`ParaView_GL=mesa
ParaView_MAJOR=5.6
ParaView_VERSION=5.6.3
ParaView_DIR=/.../openfoam/ThirdParty-9/platforms/linux64Gcc/ParaView-5.6.3`
4. The documentation is clear about how to compile the official release. It is clear about compiling the dev version. It is not as clear about the patch releases. It appears to me that compiling the patch releases is most similar to compiling the dev version, with changes to directory names. No doubt this is perfectly clear for all to whom it is obvious.
5. In some projects, non-experts might be recommended to use the better tested official release unless a patch release addresses their problems. In other projects, the patch release is considered better than the first release. The OpenFOAM.org website structurally appears to favor the official release, guiding one to https://openfoam.org/download/9-source/ , and not clearly referring to the patch release, which appears like a news item in a link in the right margin. This together with (4) may give the impression that the patch releases are of lesser interest.
6. This might be out of scope here, but the documentation at openfoam.com, https://develop.openfoam.com/Development/openfoam/-/wikis/modules/visualization#do-i-really-need-the-paraview-plugins
suggests using "paraFoam -vtk"; the openfoam.org release of paraFoam does not appear to have that option -vtk; perhaps the .com release has that option.https://develop.openfoam.com/Development/openfoam/-/issues/2334STYLE: volFieldValue: prints empty lines2022-01-24T21:55:20ZKutalmış BerçinSTYLE: volFieldValue: prints empty lines<!--
*** 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 -->
In `$FOAM_TUTORIALS/incompressible/pisoFoam/RAS/cavity`, prior to the first time-step, many empty lines are being printed.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
```
cd $FOAM_TUTORIALS/incompressible/pisoFoam/RAS/cavity
./Allrun
```
Inspect `log.pisoFoam` prior to `Time = 0.005`.
### 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
-->
base0 = base
base1 = develop
api = 2112
patch = 0
HEAD = 0d3e84eb10
version = com
compiler = Clang (system)
= clang version 9.0.1
mpi = SYSTEMOPENMPI
= mpirun (Open MPI) 1.10.7.0.5e373bf1fd
OS = Description: openSUSE Leap 15.3
opts = linux64ClangDPInt32Opt
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->
The culprit is the [volFieldValue.C#L284](https://develop.openfoam.com/Development/openfoam/-/blob/develop/src/functionObjects/field/fieldValues/volFieldValue/volFieldValue.C#L284). Reconsidering it should resolve the issue.
@markv2206https://develop.openfoam.com/Development/openfoam/-/issues/2332reduce communication for globalIndex gather operations2022-02-11T19:03:12ZMark OLESENreduce communication for globalIndex gather operations- add in mpiGatherOp() to complement the gatherOp() static method
- populate globalIndex on master only: avoid gather/scatter list expense- add in mpiGatherOp() to complement the gatherOp() static method
- populate globalIndex on master only: avoid gather/scatter list expenseMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2329BUG: turbulentDigitalFilterInlet: Forward-stepwise option is inoperative2022-06-07T20:17:09ZKutalmış BerçinBUG: turbulentDigitalFilterInlet: Forward-stepwise option is inoperative<!--
*** 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
In `turbulentDigitalFilterInletFvPatchVectorField.C`, the following assignment operation is inoperative:
```
for (direction dir = 0; dir < pTraits<vector>::nComponents; ++dir)
{
U.component(dir) =
U0_.component(dir)*coeffs1FSM_[dir]
+ U.component(dir)*coeffs2FSM_[dir];
}
```
The LHS `U.component(dir) = ` is unassignable; therefore, the content of `U` has never been altered by the intended RHS operations.
For this reason, `DFM` was acting as a single-cell box rather than the `FSM` simplifications are in effect.
This situation should have adverse effects on integral scale syntheses (which is luckily not considerably important), and should not have any effect on Reynolds stresses or mean quantities.
### 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
-->
base0 = base
base1 = develop
api = 2112
patch = 0
HEAD = befbcfce24
version = com
compiler = Clang (system)
= clang version 9.0.1
mpi = SYSTEMOPENMPI
= mpirun (Open MPI) 1.10.7.0.5e373bf1fd
OS = Description: openSUSE Leap 15.3
opts = linux64ClangDPInt32Opt
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->
```
for (direction dir = 0; dir < pTraits<vector>::nComponents; ++dir)
{
U.replace
(
dir,
U0.component(dir)*coeffs1FSM_[dir] + U.component(dir)*coeffs2FSM_[dir]
);
}
```v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2328Mismatch between user and physical time when adapting the time precision2022-01-21T12:33:30ZIvor CliffordMismatch between user and physical time when adapting the time precision<!--
*** 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 am developing a new solver in which I derive from Foam::Time and override the virtual functions Foam::TimeState::userTimeToTime, etc. While doing this, I noticed that OpenFOAM unexpectedly increases the write precision, which seems to be due to mismatches between user- and physical time in OpenFOAM's time classes. See the proposed source of problem below.
### Steps to reproduce
This bug is not related to any specific usage of the code.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2112|v2106|v2012|v2006|v1912|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2112
- Operating system : Ubuntu 20.04
- Hardware info : Intel 64 bit
- Compiler : Gcc 8.2
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->
After some debugging, I think I found the issue. At [Time.C:1287](../9a2a22a03/src/OpenFOAM/db/Time/Time.C#L1287)
```c
// Tolerance used when testing time equivalence
const scalar timeTol =
max(min(pow(10.0, -precision_), 0.1*deltaT_), SMALL);
```
Here the physical time is used to define the tolerance for increasing the time precision, but a few lines down (1302) this is compared against the user time. This mismatch causes the precision to unexpectedly increase.
A second issue I noted is that, on line 1292, userDeltaT is determined using the function `timeToUserTime`. This is only correct if the user time is a linear function of the physical time. It would be better to calculate this as:
```c
const scalar userDeltaT = timeToUserTime(value()) - timeToUserTime(value() - deltaT_);
```Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2327fixedJump bc does not work for T2022-12-23T15:00:52ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfixedJump bc does not work for T<!--
*** 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 -->
fixedjump bc does not work for solving T
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
See attached case. Allrun. Check temperature across cyclic, cyclicAMI.
### What is the current *bug* behaviour?
<!-- What actually happens -->
Jump in he (which is what is solved for) is determined from jump instead of T+jump.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2112|v2106|v2012|v2006|v1912|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2112
[TJunctionFan.tgz](/uploads/bb2fcb741f75a4df3fc2fa906ab40ef1/TJunctionFan.tgz)Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2326Outdated links to Doxygen2022-01-14T14:34:46ZGerasimos ChourdakisOutdated links to DoxygenA few months ago, the documentation was moved:
```diff
- https://www.openfoam.com/documentation/cpp-guide/html/
+ https://www.openfoam.com/documentation/guides/latest/doc/
```
However, the links (also in v2112) are still pointing to th...A few months ago, the documentation was moved:
```diff
- https://www.openfoam.com/documentation/cpp-guide/html/
+ https://www.openfoam.com/documentation/guides/latest/doc/
```
However, the links (also in v2112) are still pointing to the old one, in these files:
- https://develop.openfoam.com/Development/openfoam/-/blob/master/etc/controlDict#L29
- https://develop.openfoam.com/Development/openfoam/-/blob/master/tutorials/incompressible/pimpleFoam/LES/decayIsoTurb/README.md#L13
- https://develop.openfoam.com/Development/openfoam/-/blob/master/tutorials/incompressible/simpleFoam/turbulentFlatPlate/README.md#L16
- https://develop.openfoam.com/Development/openfoam/-/blob/master/tutorials/verificationAndValidation/schemes/divergenceExample/README#L17
This issue could also be read as "the automatic redirection of the website does not work for specific pages", as the link to, e.g., [postProcess_8C.html](https://www.openfoam.com/documentation/cpp-guide/html/postProcess_8C.html) just redirects to the main page.
By the way, awesome feature of providing a `-doc` flag, as in `postProcess -doc`!
(I am not sure if I could have even directly contributed code here, as this is a trivial fix)https://develop.openfoam.com/Development/openfoam/-/issues/2325Extension to comfort library -> operative Temperature calculation2022-01-18T15:44:06ZTobias HolzmannExtension to comfort library -> operative Temperature calculation### Functionality to add/problem to solve
Hey everybody, I updated the comfort library to accommodate the calculation of the operative temperature.
This is actually very simple as it is the arithmetic mean value of the air temperature o...### Functionality to add/problem to solve
Hey everybody, I updated the comfort library to accommodate the calculation of the operative temperature.
This is actually very simple as it is the arithmetic mean value of the air temperature of each cell and the mean radiative temperature of each cell.
There are two options now:
a) No radiation model in use.
b) Radiation model in use
For a) is already working as the user either specify a single value (in the FO dictionary) or a constant radiation temperature is derived from all walls given inside the geometry (its the mean temperature of all walls followed by the VDI2078). Hence, the patch added is sufficient to calculate the operative temperature
For b) I will go to implement the black body radiation calculation based on the G field as the operative temperature is a hypothesis based on a black body room. So while a user specifies the radiation model, each cell can be evaluated for the black body radiation temperature and hence the operative temperature can be directly calculated (not given in this patch but will follow).
### Target audience
Civil and Pharma-Industries.
### Proposal
Simply use the patch given (simply a few lines added)
### What does success look like, and how can we measure that?
Difficult.
### Links / references
EN ISO 7730
ASHRAE-55
VDI2078
[comfort.C](/uploads/024f07f065fc9436e1683c629855879f/comfort.C)Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2324BUG: MappedFile: different fieldTable names are not possible in parallel or r...2022-04-08T14:50:49ZKutalmış BerçinBUG: MappedFile: different fieldTable names are not possible in parallel or restart runs<!--
*** 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
In MappedFile.C, `fieldTableName_` is written outside the `Coeffs` block when `MappedFile` writes out its metadata, say for `decomposePar`/`redistributePar` executions.
This does not cause any issues when `fieldTableName_` does not differ from the `entryName`, which is the default value.
However, when the simulation is being run in parallel or is being restarted, `fieldTable` entry is not being read by the caller, but the default value only. Therefore, any parallel or restart run in such configuration becomes problematic.
```
os.writeEntryIfDifferent
(
"fieldTable",
this->name(),
fieldTableName_
);
os.beginBlock(word(this->name() + "Coeffs"));
//--> fieldTableName_ should be written herein.
writeEntries(os);
os.endBlock();
```
### 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
-->
base0 = base
base1 = develop
api = 2112
patch = 0
HEAD = 34e226dfe3
version = com
compiler = Clang (system)
= clang version 9.0.1
mpi = SYSTEMOPENMPI
= mpirun (Open MPI) 1.10.7.0.5e373bf1fd
OS = Description: openSUSE Leap 15.3
opts = linux64ClangDPInt32Opt
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->
A tested potential-fix patch (FYI: @mark ): [0001-BUG-MappedFile-ensure-correct-fieldTableName-can-be-.patch](/uploads/605abe4f52315864cd4ddee9c79e227c/0001-BUG-MappedFile-ensure-correct-fieldTableName-can-be-.patch)Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2322bad variable use for lib configuration2022-01-11T17:02:31ZMark OLESENbad variable use for lib configurationsnuck in with 4a064645 as noted by @Mortesinssnuck in with 4a064645 as noted by @MortesinsMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2319processorField does not handle topology changes2022-12-23T15:01:01ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comprocessorField does not handle topology changes### Functionality to add/problem to solve
Take a case with different meshes in different time directories (e.g. run dynamic refinement / unrefinement or even a mesh modification application like subsetMesh). `postProcess -func processor...### Functionality to add/problem to solve
Take a case with different meshes in different time directories (e.g. run dynamic refinement / unrefinement or even a mesh modification application like subsetMesh). `postProcess -func processorField` will crash with sigsegv since it maintains a field which does not get mapped.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2318BUG: airRecirculationRoom: reactingParcelFoam throws FPE for h/T2022-03-30T10:43:51ZKutalmış BerçinBUG: airRecirculationRoom: reactingParcelFoam throws FPE for h/T<!--
*** 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 -->
`$FOAM_TUTORIALS/lagrangian/reactingParcelFoam/airRecirculationRoom` throws FPE for
```
Build : 34e226dfe3-20211220 OPENFOAM=2112 version=com
Arch : "LSB;label=32;scalar=64"
Exec : reactingParcelFoam -parallel
```
The same test case runs fine with `v2106`.
```
Build : c15bfde3cb-20210624 OPENFOAM=2106
Arch : "LSB;label=32;scalar=64"
Exec : reactingParcelFoam -parallel
```
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
```
cd $FOAM_TUTORIALS/lagrangian/reactingParcelFoam/airRecirculationRoom
./Allrun
```
A similar crashing case example can be found in EP1765, where the case throws negative temperature FATAL error.
### 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.
-->
```
diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
PIMPLE: iteration 1
smoothSolver: Solving for Ux, Initial residual = 0.81706851, Final residual = 1.0147201e-08, No Iterations 2
smoothSolver: Solving for Uy, Initial residual = 0.76799964, Final residual = 1.5325339e-08, No Iterations 2
smoothSolver: Solving for Uz, Initial residual = 0.44172895, Final residual = 6.39482e-09, No Iterations 2
DILUPBiCGStab: Solving for CO2, Initial residual = 9.114497e-08, Final residual = 9.114497e-08, No Iterations 0
DILUPBiCGStab: Solving for O2, Initial residual = 9.1708675e-06, Final residual = 7.6550065e-11, No Iterations 1
DILUPBiCGStab: Solving for H2O, Initial residual = 4.273067e-08, Final residual = 4.273067e-08, No Iterations 0
[4] #0 Foam::error::printStack(Foam::Ostream&) at ??:?
[4] #1 Foam::sigFpe::sigHandler(int) at ??:?
[4] #2 ? in /lib64/libpthread.so.0
[4] #3 Foam::scalarProduct<double, double>::type Foam::sumProd<double>(Foam::UList<double> const&, Foam::UList<double> const&) at ??:?
[4] #4 Foam::PBiCGStab::scalarSolve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const at ??:?
[4] #5 Foam::PBiCGStab::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const at ??:?
[4] #6 Foam::fvMatrix<double>::solveSegregated(Foam::dictionary const&) at ??:?
[4] #7 Foam::fvMatrix<double>::solveSegregatedOrCoupled(Foam::dictionary const&) at ??:?
[4] #8 Foam::fvMesh::solve(Foam::fvMatrix<double>&, Foam::dictionary const&) const at ??:?
[4] #9 ? at ??:?
[4] #10 __libc_start_main in /lib64/libc.so.6
[4] #11 ? at /home/abuild/rpmbuild/BUILD/glibc-2.31/csu/../sysdeps/x86_64/start.S:122
[pikachu:38369:0:38369] Caught signal 8 (Floating point exception: tkill(2) or tgkill(2))
```
### 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
-->
Problematic environment:
```
base0 = base
base1 = develop
api = 2112
patch = 0
HEAD = 34e226dfe3
version = com
compiler = Clang (system)
= clang version 9.0.1
mpi = SYSTEMOPENMPI
= mpirun (Open MPI) 1.10.7.0.5e373bf1fd
OS = Description: openSUSE Leap 15.3
opts = linux64ClangDPInt32Opt
```
Non-problematic environment:
```
base0 = release
base1 = v2106
api = 2106
patch = 0
HEAD = c15bfde3cb
version = v2106
compiler = Clang (system)
= clang version 9.0.1
mpi = SYSTEMOPENMPI
= mpirun (Open MPI) 1.10.7.0.5e373bf1fd
OS = Description: openSUSE Leap 15.3
opts = linux64ClangDPInt32Opt
```v2206https://develop.openfoam.com/Development/openfoam/-/issues/2317KinematicReynoldsNumber in cloudFunctionObject2022-01-11T17:02:31Ztakuya yamamotoKinematicReynoldsNumber in cloudFunctionObject## KinematicReynoldsNumber in cloudFunctionObject does not work
KinematicReynoldsNumber was implemented in cloudFunctionObject from v2106, but it was not activated.
### How to reproduce
Example: Run the tutorial: $FOAM_TUTORIALS/lagra...## KinematicReynoldsNumber in cloudFunctionObject does not work
KinematicReynoldsNumber was implemented in cloudFunctionObject from v2106, but it was not activated.
### How to reproduce
Example: Run the tutorial: $FOAM_TUTORIALS/lagrangian/icoUncoupledKinematicParcelFoam/hopper/hopperEmptying/ with
```
cloudFunctions
{
KinematicReynoldsNumber1
{
type KinematicReynoldsNumber;
}
}
```
in constant/kinematicCloudProperties.
### Error log
```
--> FOAM FATAL IO ERROR: (openfoam-2106)
Unknown cloudFunctionObject type KinematicReynoldsNumber
Valid cloudFunctionObject types :
11
(
facePostProcessing
particleCollector
particleErosion
particleTracks
particleTrap
patchCollisionDensity
patchInteractionFields
patchParticleHistogram
patchPostProcessing
removeParcels
voidFraction
)
```
### OpenFOAM version
v2106
### Possible fixes
line 63 in $FOAM_SRC/lagrangian/intermediate/parcels/include/makeParcelCloudFunctionObjects.H
```
makeCloudFunctionObjectType(VoidFraction, CloudType);
```
should be
```
makeCloudFunctionObjectType(VoidFraction, CloudType); \
makeCloudFunctionObjectType(KinematicReynoldsNumber, CloudType);
```Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2316Lambda2 fails immediately in SPDP2024-01-10T10:49:39ZAaronLambda2 fails immediately in SPDPThis is very easy to reproduce :-) Just insert the lines below into controlDict for the motorBike tutorial and solve in SPDP.
Or, run postProcess -func Lambda2 in SPDP.
Expected behavior: running in both precisions (the Q functionObjec...This is very easy to reproduce :-) Just insert the lines below into controlDict for the motorBike tutorial and solve in SPDP.
Or, run postProcess -func Lambda2 in SPDP.
Expected behavior: running in both precisions (the Q functionObject, for example, produces practically identical results in both.)
```
Lambda2
{
timeStart 0;
type Lambda2;
writeControl writeTime;
executeControl timeStep;
executeInterval 1;
}
```
```
~/Desktop/motorBike$ mpirun -np 6 postProcess -func Lambda2 -parallel
/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: 2112 |
| \\ / A nd | Website: www.openfoam.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : 145f29cc9a-20211221 OPENFOAM=2112 version=v2112
Arch : "LSB;label=32;scalar=32;solveScalar=64"
Exec : postProcess -func Lambda2 -parallel
Date : Jan 02 2022
Time : 23:31:35
Host : testing-laptop
PID : 12362
I/O : uncollated
WARNING: running without decomposeParDict "system/decomposeParDict"
Case : /home/testing/Desktop/motorBike
nProcs : 6
Hosts :
(
(testing-laptop 6)
)
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 5, maxFileModificationPolls 20)
allowSystemOperations : Allowing user-supplied system call operations
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time
Create mesh for time = 0
Time = 0
Reading fields:
volVectorField: U
Executing functionObjects
[0] #0 Foam::error::printStack(Foam::Ostream&)[3] #0 Foam::error::printStack(Foam::Ostream&)[1] #0 Foam::error::printStack(Foam::Ostream&)[4] #0 Foam::error::printStack(Foam::Ostream&)[5] #0 Foam::error::printStack(Foam::Ostream&)[2] #0 Foam::error::printStack(Foam::Ostream&) at ??:?
at ??:?
at ??:?
at ??:?
[4] #1 Foam::sigFpe::sigHandler(int)[0] #1 Foam::sigFpe::sigHandler(int)[1] #1 Foam::sigFpe::sigHandler(int)[3] #1 Foam::sigFpe::sigHandler(int) at at ??:???:?
[5] #1 [2] #1 Foam::sigFpe::sigHandler(int)Foam::sigFpe::sigHandler(int) at ??:?
[1] #2 ? at ??:?
[0] #2 ? at at ??:?
[3] #??:?
2 ?[4] #2 ? at ??:?
[2] #2 ? at ??:?
[5] #2 ? in /lib/x86_64-linux-gnu/libpthread.so.0
in /lib/x86_64-linux-gnu/libpthread.so.0
[1] #3 Foam::cubicEqn::roots() const in /lib/x86_64-linux-gnu/libpthread.so.0
in /lib/x86_64-linux-gnu/libpthread.so.0
[3] #3 Foam::cubicEqn::roots() const[4] #3 [0] #3 Foam::cubicEqn::roots() constFoam::cubicEqn::roots() const in /lib/x86_64-linux-gnu/libpthread.so.0
in /lib/x86_64-linux-gnu/libpthread.so.0
[5] #3 Foam::cubicEqn::roots() const[2] #3 Foam::cubicEqn::roots() const at ??:?
at ??:?
[1] #4 [3] #4 Foam::eigenValues(Foam::SymmTensor<float> const&)Foam::eigenValues(Foam::SymmTensor<float> const&) at ??:?
at ??:?
[0] #4 Foam::eigenValues(Foam::SymmTensor<float> const&)[4] #4 Foam::eigenValues(Foam::SymmTensor<float> const&) at ??:?
[2] #4 Foam::eigenValues(Foam::SymmTensor<float> const&) at ??:?
[5] #4 Foam::eigenValues(Foam::SymmTensor<float> const&) at ??:?
[1] #5 Foam::eigenValues(Foam::Field<Foam::Vector<float> >&, Foam::UList<Foam::SymmTensor<float> > const&) at ??:?
[3] #5 Foam::eigenValues(Foam::Field<Foam::Vector<float> >&, Foam::UList<Foam::SymmTensor<float> > const&) at ??:?
at ??:?
[0] #5 Foam::eigenValues(Foam::Field<Foam::Vector<float> >&, Foam::UList<Foam::SymmTensor<float> > const&)[4] #5 Foam::eigenValues(Foam::Field<Foam::Vector<float> >&, Foam::UList<Foam::SymmTensor<float> > const&) at ??:?
[2] #5 Foam::eigenValues(Foam::Field<Foam::Vector<float> >&, Foam::UList<Foam::SymmTensor<float> > const&) at ??:?
[5] #5 Foam::eigenValues(Foam::Field<Foam::Vector<float> >&, Foam::UList<Foam::SymmTensor<float> > const&) at ??:?
[1] #6 Foam::tmp<Foam::GeometricField<Foam::Vector<float>, Foam::fvPatchField, Foam::volMesh> > Foam::eigenValues<Foam::fvPatchField, Foam::volMesh>(Foam::GeometricField<Foam::SymmTensor<float>, Foam::fvPatchField, Foam::volMesh> const&) at ??:?
[3] #6 Foam::tmp<Foam::GeometricField<Foam::Vector<float>, Foam::fvPatchField, Foam::volMesh> > Foam::eigenValues<Foam::fvPatchField, Foam::volMesh>(Foam::GeometricField<Foam::SymmTensor<float>, Foam::fvPatchField, Foam::volMesh> const&) at ??:?
[4] #6 Foam::tmp<Foam::GeometricField<Foam::Vector<float>, Foam::fvPatchField, Foam::volMesh> > Foam::eigenValues<Foam::fvPatchField, Foam::volMesh>(Foam::GeometricField<Foam::SymmTensor<float>, Foam::fvPatchField, Foam::volMesh> const&) at ??:?
at ??:?
[2] #6 [0] #6 Foam::tmp<Foam::GeometricField<Foam::Vector<float>, Foam::fvPatchField, Foam::volMesh> > Foam::eigenValues<Foam::fvPatchField, Foam::volMesh>(Foam::GeometricField<Foam::SymmTensor<float>, Foam::fvPatchField, Foam::volMesh> const&)Foam::tmp<Foam::GeometricField<Foam::Vector<float>, Foam::fvPatchField, Foam::volMesh> > Foam::eigenValues<Foam::fvPatchField, Foam::volMesh>(Foam::GeometricField<Foam::SymmTensor<float>, Foam::fvPatchField, Foam::volMesh> const&) at ??:?
[5] #6 Foam::tmp<Foam::GeometricField<Foam::Vector<float>, Foam::fvPatchField, Foam::volMesh> > Foam::eigenValues<Foam::fvPatchField, Foam::volMesh>(Foam::GeometricField<Foam::SymmTensor<float>, Foam::fvPatchField, Foam::volMesh> const&) at ??:?
[1] #7 Foam::functionObjects::Lambda2::calc() at ??:?
[3] #7 Foam::functionObjects::Lambda2::calc() at ??:?
[4] #7 Foam::functionObjects::Lambda2::calc() at ??:?
[2] #7 Foam::functionObjects::Lambda2::calc() at ??:?
[5] #7 Foam::functionObjects::Lambda2::calc() at ??:?
[0] #7 Foam::functionObjects::Lambda2::calc() at ??:?
[1] #8 Foam::functionObjects::fieldExpression::execute() at ??:?
[3] #8 Foam::functionObjects::fieldExpression::execute() at ??:?
[4] #8 Foam::functionObjects::fieldExpression::execute() at ??:?
[2] #8 Foam::functionObjects::fieldExpression::execute() at ??:?
[5] #8 Foam::functionObjects::fieldExpression::execute() at ??:?
[0] #8 Foam::functionObjects::fieldExpression::execute() at ??:?
[1] #9 Foam::functionObjects::timeControl::execute() at ??:?
[2] #9 Foam::functionObjects::timeControl::execute() at ??:?
at ??:?
[3] #9 Foam::functionObjects::timeControl::execute()[4] #9 Foam::functionObjects::timeControl::execute() at ??:?
[5] #9 Foam::functionObjects::timeControl::execute() at ??:?
[0] #9 Foam::functionObjects::timeControl::execute() at ??:?
at ??:?
[2] #10 Foam::functionObjectList::execute()[1] #10 Foam::functionObjectList::execute() at ??:?
at ??:?
[4] #10 Foam::functionObjectList::execute()[3] #10 Foam::functionObjectList::execute() at ??:?
[5] #10 Foam::functionObjectList::execute() at ??:?
[0] #10 Foam::functionObjectList::execute() at ??:?
[2] #11 at ??:?
[3] #11 at ??:?
[4] #11 at ??:?
[1] #11 at ??:?
[5] #11 ????? at ??:?
[0] #11 in /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/bin/postProcess
[2] #12 in /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/bin/postProcess
[3] #12 in /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/bin/postProcess
[1] #12 in /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/bin/postProcess
[4] #12 ? in /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/bin/postProcess
[5] #12 ????? in /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/bin/postProcess
[2] #13 __libc_start_main in /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/bin/postProcess
[0] #12 in /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/bin/postProcess
[3] #13 __libc_start_main? in /lib/x86_64-linux-gnu/libc.so.6
[2] #14 in /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/bin/postProcess
[1] #13 __libc_start_main in /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/bin/postProcess
[4] #13 __libc_start_main in /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/bin/postProcess
[5] #13 __libc_start_main in /lib/x86_64-linux-gnu/libc.so.6
[3] #14 ? in /lib/x86_64-linux-gnu/libc.so.6
[1] #14 in /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/bin/postProcess
[0] #13 __libc_start_main in /lib/x86_64-linux-gnu/libc.so.6
[5] #14 in /lib/x86_64-linux-gnu/libc.so.6
[4] #14 ? in /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/bin/postProcess
[testing-laptop:12364] *** Process received signal ***
[testing-laptop:12364] Signal: Floating point exception (8)
[testing-laptop:12364] Signal code: (-6)
[testing-laptop:12364] Failing at address: 0x3e80000304c
[testing-laptop:12364] [ 0] /lib/x86_64-linux-gnu/libpthread.so.0(+0x12980)[0x7f8df5ea7980]
[testing-laptop:12364] [ 1] /lib/x86_64-linux-gnu/libpthread.so.0(raise+0xc7)[0x7f8df5ea7817]
[testing-laptop:12364] [ 2] /lib/x86_64-linux-gnu/libpthread.so.0(+0x12980)[0x7f8df5ea7980]
[testing-laptop:12364] [ 3] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZNK4Foam8cubicEqn5rootsEv+0x15a)[0x7f8df7174dda]
[testing-laptop:12364] [ 4] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam11eigenValuesERKNS_10SymmTensorIfEE+0x148)[0x7f8df702ee88]
[testing-laptop:12364] [ 5] ??/data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam11eigenValuesERNS_5FieldINS_6VectorIfEEEERKNS_5UListINS_10SymmTensorIfEEEE+0x4f)[0x7f8df75027ff]
[testing-laptop:12364] [ 6] ?/data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libfieldFunctionObjects.so(_ZN4Foam11eigenValuesINS_12fvPatchFieldENS_7volMeshEEENS_3tmpINS_14GeometricFieldINS_6VectorIfEET_T0_EEEERKNS4_INS_10SymmTensorIfEES7_S8_EE+0x280)[0x7f8dd212e1f0]
[testing-laptop:12364] [ 7] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libfieldFunctionObjects.so(_ZN4Foam15functionObjects7Lambda24calcEv+0x1e1)[0x7f8dd212adf1]
[testing-laptop:12364] [ 8] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libfieldFunctionObjects.so(_ZN4Foam15functionObjects15fieldExpression7executeEv+0xd)[0x7f8dd20e782d]
[testing-laptop:12364] [ 9] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam15functionObjects11timeControl7executeEv+0x54)[0x7f8df723b874]
[testing-laptop:12364] [10] in /lib/x86_64-linux-gnu/libc.so.6
[0] #14 /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam18functionObjectList7executeEv+0x1b7)[0x7f8df722e257]
[testing-laptop:12364] [11] postProcess(+0x4de36)[0x55df1c18de36]
[testing-laptop:12364] [12] postProcess(+0x4a5ab)[0x55df1c18a5ab]
[testing-laptop:12364] [13] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7f8df5ac5bf7]
[testing-laptop:12364] [14] postProcess(+0x4ae9a)[0x55df1c18ae9a]
[testing-laptop:12364] *** End of error message ***
in /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/bin/postProcess
[testing-laptop:12365] *** Process received signal ***
[testing-laptop:12365] Signal: Floating point exception (8)
[testing-laptop:12365] Signal code: (-6)
[testing-laptop:12365] Failing at address: 0x3e80000304d
[testing-laptop:12365] [ 0] /lib/x86_64-linux-gnu/libpthread.so.0(+0x12980)[0x7fb39d68f980]
[testing-laptop:12365] [ 1] /lib/x86_64-linux-gnu/libpthread.so.0(raise+0xc7)[0x7fb39d68f817]
[testing-laptop:12365] [ 2] /lib/x86_64-linux-gnu/libpthread.so.0(+0x12980)[0x7fb39d68f980]
[testing-laptop:12365] [ 3] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZNK4Foam8cubicEqn5rootsEv+0x15a)[0x7fb39e95cdda]
[testing-laptop:12365] [ 4] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam11eigenValuesERKNS_10SymmTensorIfEE+0x148)[0x7fb39e816e88]
[testing-laptop:12365] [ 5] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam11eigenValuesERNS_5FieldINS_6VectorIfEEEERKNS_5UListINS_10SymmTensorIfEEEE+0x4f)[0x7fb39ecea7ff]
[testing-laptop:12365] [ 6] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libfieldFunctionObjects.so(_ZN4Foam11eigenValuesINS_12fvPatchFieldENS_7volMeshEEENS_3tmpINS_14GeometricFieldINS_6VectorIfEET_T0_EEEERKNS4_INS_10SymmTensorIfEES7_S8_EE+0x280)[0x7fb3798eb1f0]
[testing-laptop:12365] [ 7] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libfieldFunctionObjects.so(_ZN4Foam15functionObjects7Lambda24calcEv+0x1e1)[0x7fb3798e7df1]
[testing-laptop:12365] [ 8] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libfieldFunctionObjects.so(_ZN4Foam15functionObjects15fieldExpression7executeEv+0xd)[0x7fb3798a482d]
[testing-laptop:12365] [ 9] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam15functionObjects11timeControl7executeEv+0x54)[0x7fb39ea23874]
[testing-laptop:12365] [10] in /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/bin/postProcess
[testing-laptop:12363] *** Process received signal ***
[testing-laptop:12363] Signal: Floating point exception (8)
[testing-laptop:12363] Signal code: (-6)
[testing-laptop:12363] Failing at address: 0x3e80000304b
[testing-laptop:12363] [ 0] /lib/x86_64-linux-gnu/libpthread.so.0(+0x12980)[0x7f4443ea4980]
[testing-laptop:12363] [ 1] /lib/x86_64-linux-gnu/libpthread.so.0(raise+0xc7)[0x7f4443ea4817]
[testing-laptop:12363] [ 2] in /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/bin/postProcess
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12980)[0x7f4443ea4980]
[testing-laptop:12363] [ 3] [testing-laptop:12367] *** Process received signal ***
[testing-laptop:12367] Signal: Floating point exception (8)
[testing-laptop:12367] Signal code: (-6)
[testing-laptop:12367] Failing at address: 0x3e80000304f
/data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam18functionObjectList7executeEv+0x1b7)[0x7fb39ea16257]
[testing-laptop:12365] [testing-laptop:12367] [ 0] /lib/x86_64-linux-gnu/libpthread.so.0(+0x12980)[0x[11] 7f9a11520980]
[testing-laptop:12367] [ 1] /lib/x86_64-linux-gnu/libpthread.so.0(raise+0xc7)[0x7f9a11520817]
[testing-laptop:12367] [ 2] postProcess(+0x4de36)[0x56424aaaae36]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12980)[0x7f9a11520980]
[testing-laptop:12367] [ 3] [testing-laptop:12365] [12] postProcess(+0x4a5ab)[0x56424aaa75ab]
[testing-laptop:12365] [13] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7fb39d2adbf7]
[testing-laptop:12365] [14] postProcess(+0x4ae9a)[0x56424aaa7e9a]
[testing-laptop:12365] *** End of error message ***
/data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZNK4Foam8cubicEqn5rootsEv+0x15a)[0x7f4445171dda]
[testing-laptop:12363] [ 4] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZNK4Foam8cubicEqn5rootsEv+0x15a)[0x7f9a127eddda]
[testing-laptop:12367] [ 4] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam11eigenValuesERKNS_10SymmTensorIfEE+0x148)[0x7f444502be88]
[testing-laptop:12363] [ 5] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam11eigenValuesERKNS_10SymmTensorIfEE+0x148)[0x7f9a126a7e88]
[testing-laptop:12367] [ 5] in ?/data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/bin/postProcess
[testing-laptop:12366] *** Process received signal ***
[testing-laptop:12366] Signal: Floating point exception (8)
[testing-laptop:12366] Signal code: (-6)
[testing-laptop:12366] Failing at address: 0x3e80000304e
/data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam11eigenValuesERNS_5FieldINS_6VectorIfEEEERKNS_5UListINS_10SymmTensorIfEEEE+0x4f)[0x7f44454ff7ff]
[testing-laptop:12363] [ 6] [testing-laptop:12366] [ 0] /lib/x86_64-linux-gnu/libpthread.so.0(+0x12980)[0x7fb8a2900980]
[testing-laptop:12366] [ 1] /lib/x86_64-linux-gnu/libpthread.so.0(raise+0xc7)[0x7fb8a2900817]
[testing-laptop:12366] [ 2] /lib/x86_64-linux-gnu/libpthread.so.0(+0x12980)[0x7fb8a2900980]
[testing-laptop:12366] [ 3] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam11eigenValuesERNS_5FieldINS_6VectorIfEEEERKNS_5UListINS_10SymmTensorIfEEEE+0x4f)[0x7f9a12b7b7ff]
[testing-laptop:12367] [ 6] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libfieldFunctionObjects.so(_ZN4Foam11eigenValuesINS_12fvPatchFieldENS_7volMeshEEENS_3tmpINS_14GeometricFieldINS_6VectorIfEET_T0_EEEERKNS4_INS_10SymmTensorIfEES7_S8_EE+0x280)[0x7f442013f1f0]
[testing-laptop:12363] [ 7] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libfieldFunctionObjects.so(_ZN4Foam11eigenValuesINS_12fvPatchFieldENS_7volMeshEEENS_3tmpINS_14GeometricFieldINS_6VectorIfEET_T0_EEEERKNS4_INS_10SymmTensorIfEES7_S8_EE+0x280)[0x7f99ed70b1f0]
[testing-laptop:12367] [ 7] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libfieldFunctionObjects.so(_ZN4Foam15functionObjects7Lambda24calcEv+0x1e1)[0x7f442013bdf1]
[testing-laptop:12363] [ 8] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libfieldFunctionObjects.so(_ZN4Foam15functionObjects7Lambda24calcEv+0x1e1)[0x7f99ed707df1]
[testing-laptop:12367] [ 8] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZNK4Foam8cubicEqn5rootsEv+0x15a)[0x7fb8a3bcddda]
[testing-laptop:12366] [ 4] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libfieldFunctionObjects.so(_ZN4Foam15functionObjects15fieldExpression7executeEv+0xd)[0x7f44200f882d]
[testing-laptop:12363] [ 9] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libfieldFunctionObjects.so(_ZN4Foam15functionObjects15fieldExpression7executeEv+0xd)[0x7f99ed6c482d]
[testing-laptop:12367] [ 9] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam11eigenValuesERKNS_10SymmTensorIfEE+0x148)[0x7fb8a3a87e88]
[testing-laptop:12366] [ 5] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam15functionObjects11timeControl7executeEv+0x54)[0x7f4445238874]
[testing-laptop:12363] [10] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam15functionObjects11timeControl7executeEv+0x54)[0x7f9a128b4874]
[testing-laptop:12367] [10] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam11eigenValuesERNS_5FieldINS_6VectorIfEEEERKNS_5UListINS_10SymmTensorIfEEEE+0x4f)[0x7fb8a3f5b7ff]
[testing-laptop:12366] [ 6] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam18functionObjectList7executeEv+0x1b7)[0x7f444522b257]
[testing-laptop:12363] [11] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam18functionObjectList7executeEv+0x1b7)[0x7f9a128a7257]
[testing-laptop:12367] [11] postProcess(+0x4de36)[0x55e50a97be36]
[testing-laptop:12363] [12] postProcess(+0x4de36)[0x55ab5571ce36]
[testing-laptop:12367] [12] postProcess(+0x4a5ab)[0x55e50a9785ab]
[testing-laptop:12363] [13] postProcess(+0x4a5ab)[0x55ab557195ab]
[testing-laptop:12367] [13] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7f4443ac2bf7]
[testing-laptop:12363] [14] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7f9a1113ebf7]
[testing-laptop:12367] [14] postProcess(+0x4ae9a)[0x55e50a978e9a]
[testing-laptop:12363] *** End of error message ***
postProcess(+0x4ae9a)[0x55ab55719e9a]
/data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libfieldFunctionObjects.so(_ZN4Foam11eigenValuesINS_12fvPatchFieldENS_7volMeshEEENS_3tmpINS_14GeometricFieldINS_6VectorIfEET_T0_EEEERKNS4_INS_10SymmTensorIfEES7_S8_EE+0x280)[0x7fb87eb4a1f0]
[testing-laptop:12366] [testing-laptop:12367] *** End of error message ***
[ 7] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libfieldFunctionObjects.so(_ZN4Foam15functionObjects7Lambda24calcEv+0x1e1)[0x7fb87eb46df1]
[testing-laptop:12366] [ 8] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libfieldFunctionObjects.so(_ZN4Foam15functionObjects15fieldExpression7executeEv+0xd)[0x7fb87eb0382d]
[testing-laptop:12366] [ 9] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam15functionObjects11timeControl7executeEv+0x54)[0x7fb8a3c94874]
[testing-laptop:12366] [10] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam18functionObjectList7executeEv+0x1b7)[0x7fb8a3c87257]
[testing-laptop:12366] [11] postProcess(+0x4de36)[0x55652ac94e36]
[testing-laptop:12366] [12] postProcess(+0x4a5ab)[0x55652ac915ab]
[testing-laptop:12366] [13] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7fb8a251ebf7]
[testing-laptop:12366] [14] postProcess(+0x4ae9a)[0x55652ac91e9a]
[testing-laptop:12366] *** End of error message ***
in /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/bin/postProcess
[testing-laptop:12362] *** Process received signal ***
[testing-laptop:12362] Signal: Floating point exception (8)
[testing-laptop:12362] Signal code: (-6)
[testing-laptop:12362] Failing at address: 0x3e80000304a
[testing-laptop:12362] [ 0] /lib/x86_64-linux-gnu/libpthread.so.0(+0x12980)[0x7fa49eeef980]
[testing-laptop:12362] [ 1] /lib/x86_64-linux-gnu/libpthread.so.0(raise+0xc7)[0x7fa49eeef817]
[testing-laptop:12362] [ 2] /lib/x86_64-linux-gnu/libpthread.so.0(+0x12980)[0x7fa49eeef980]
[testing-laptop:12362] [ 3] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZNK4Foam8cubicEqn5rootsEv+0x15a)[0x7fa4a01bcdda]
[testing-laptop:12362] [ 4] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam11eigenValuesERKNS_10SymmTensorIfEE+0x148)[0x7fa4a0076e88]
[testing-laptop:12362] [ 5] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam11eigenValuesERNS_5FieldINS_6VectorIfEEEERKNS_5UListINS_10SymmTensorIfEEEE+0x4f)[0x7fa4a054a7ff]
[testing-laptop:12362] [ 6] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libfieldFunctionObjects.so(_ZN4Foam11eigenValuesINS_12fvPatchFieldENS_7volMeshEEENS_3tmpINS_14GeometricFieldINS_6VectorIfEET_T0_EEEERKNS4_INS_10SymmTensorIfEES7_S8_EE+0x280)[0x7fa47b1811f0]
[testing-laptop:12362] [ 7] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libfieldFunctionObjects.so(_ZN4Foam15functionObjects7Lambda24calcEv+0x1e1)[0x7fa47b17ddf1]
[testing-laptop:12362] [ 8] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libfieldFunctionObjects.so(_ZN4Foam15functionObjects15fieldExpression7executeEv+0xd)[0x7fa47b13a82d]
[testing-laptop:12362] [ 9] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam15functionObjects11timeControl7executeEv+0x54)[0x7fa4a0283874]
[testing-laptop:12362] [10] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam18functionObjectList7executeEv+0x1b7)[0x7fa4a0276257]
[testing-laptop:12362] [11] postProcess(+0x4de36)[0x5609ed302e36]
[testing-laptop:12362] [12] postProcess(+0x4a5ab)[0x5609ed2ff5ab]
[testing-laptop:12362] [13] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7fa49eb0dbf7]
[testing-laptop:12362] [14] postProcess(+0x4ae9a)[0x5609ed2ffe9a]
[testing-laptop:12362] *** End of error message ***
--------------------------------------------------------------------------
mpirun noticed that process rank 2 with PID 0 on node testing-laptop exited on signal 8 (Floating point exception).
--------------------------------------------------------------------------
```Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2315Regarding upgrading from v2012 to v21122022-01-04T12:04:14ZAshutosh MauryaRegarding upgrading from v2012 to v2112Hello everyone,
This is not problem but just a question can I upgrade from v2012 to v2112 without reinstalling everything. Here is some reference for this https://develop.openfoam.com/Development/openfoam/-/wikis/precompiled/debian#upda...Hello everyone,
This is not problem but just a question can I upgrade from v2012 to v2112 without reinstalling everything. Here is some reference for this https://develop.openfoam.com/Development/openfoam/-/wikis/precompiled/debian#updates . If yes please provide detail explanation.
Thank youhttps://develop.openfoam.com/Development/openfoam/-/issues/2314OpenFOAM v2112 Ubuntu packages: segmentation faults2022-06-24T13:19:23ZGerasimos ChourdakisOpenFOAM v2112 Ubuntu packages: segmentation faultsI just installed OpenFOAM v2112 on Ubuntu from the official PPA repository. I started by installing it on Ubuntu 21.04, then upgraded to 21.10, and now I also tried in a clean Ubuntu 21.10 VM, which I used for the following.
When runnin...I just installed OpenFOAM v2112 on Ubuntu from the official PPA repository. I started by installing it on Ubuntu 21.04, then upgraded to 21.10, and now I also tried in a clean Ubuntu 21.10 VM, which I used for the following.
When running seemingly any application, I get a segmentation fault.
Running `blockMesh -help` on OpenFOAM v2112:
![Screenshot_from_2021-12-25_12-50-50](/uploads/4226588f8338f0a71a420bd6405c579a/Screenshot_from_2021-12-25_12-50-50.png)
Running the same on OpenFOAM v2106 (same system):
![Screenshot_from_2021-12-25_12-51-10](/uploads/5f20d7653b75a5136e42394bbc62a646/Screenshot_from_2021-12-25_12-51-10.png)
Running `blockMesh` on OpenFOAM v2112, with a v2112 tutorial case (`basic/potentialFoam/pitzDaily`):
![Screenshot_from_2021-12-25_12-57-48](/uploads/9f50ea1de92a7161ddf243d5a9d0c4fe/Screenshot_from_2021-12-25_12-57-48.png)
(this case works normally with v2106)
The dynamic libraries currently linked to blockMesh (if that may give any hints, same versions are picked by v2106):
![Screenshot_from_2021-12-25_12-53-20](/uploads/a665e148d5512243e4db42d922faa95b/Screenshot_from_2021-12-25_12-53-20.png)
(I am sorry for the screenshots instead of log files, setting up shared clipboard in VirtualBox is always a bit complicated.)Mark OLESENMark OLESEN