Development issueshttps://develop.openfoam.com/groups/Development/-/issues2021-09-29T14:31:34Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2219fvMeshPrimitiveLduAddressing leaks memory2021-09-29T14:31:34ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfvMeshPrimitiveLduAddressing leaks 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 -->
fvMeshPrimitiveLduAddressing stores reference to lduSchedule
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Not tried but probably run anything with 'scheduled' instead of 'nonBlocking'.
### 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 : v2106Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2218output for FatalIOError missing line output2021-10-07T06:44:54ZMark OLESENoutput for FatalIOError missing line outputbroken by @mark, noticed by @Mattijs - will be fixed by @markbroken by @mark, noticed by @Mattijs - will be fixed by @markMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2215OS Error: libPVblockMeshReader_SM.so: undefined symbol2021-09-21T09:15:50ZSunag R AOS Error: libPVblockMeshReader_SM.so: undefined symbol
### What is the current *bug* behaviour?
Dear All,
I am working with OpenFOAM v5 and I am trying to automate the simulations based on input request provided to flask.
For this purpose, I have created a python file for flask and have ...
### What is the current *bug* behaviour?
Dear All,
I am working with OpenFOAM v5 and I am trying to automate the simulations based on input request provided to flask.
For this purpose, I have created a python file for flask and have provided the OpenFOAM function which needs to run by using pvpython. Manually, only with python it will run perfectly without any error.
But, with flask when I run the python file, I am getting this below error:
**OSError: /opt/openfoam5/platforms/linux64GccDPInt32Opt/lib/paraview-5.4/libPVblockMeshReader_SM.so: undefined symbol: _ZN12pqRenderView16staticMetaObjectE**
How to overcome this error.?
### Relevant logs and/or images
I tried looking at similar post where the solution was mentioned as to work with LD_Preload as in link provided:
[LD_Preload](https://discourse.paraview.org/t/not-able-to-load-openfoam-paraview-reader-pvfoamreader-when-using-pvbatch-or-pvpython/248/21)
**LD_PRELOAD=/opt/OpenFOAM/paraviewopenfoam54/lib/paraview-5.4/libvtkpqCore-pv5.4.1.so.1 /opt/OpenFOAM/paraviewopenfoam54/bin/pvpython**
But it gives the following error from LD_Preload:
**ERROR: ld.so: object '/opt/paraviewopenfoam54/lib/paraview-5.4/libvtkpqCore-pv5.4.1.so.1' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.**
### Environment information
- OpenFOAM version : v5
- Operating system : ubuntu 18.04
- Hardware info :
- Compiler :Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2214one error about a parameter in PilchErdman model for droplet breakup2021-10-05T10:50:18ZXiaoerone error about a parameter in PilchErdman model for droplet breakupHello,
In the Pilch Erdman model in OF, there is one error about the exponent of 0.25 for We > 25, see below. It should be -0.25. In the original paper by Pilch and Erdman in 1987, there was not correct for this parameter. The correct ...Hello,
In the Pilch Erdman model in OF, there is one error about the exponent of 0.25 for We > 25, see below. It should be -0.25. In the original paper by Pilch and Erdman in 1987, there was not correct for this parameter. The correct one can be found in the Eq. 2.20 from the book: https://www.routledge.com/Atomization-and-Sprays/Lefebvre-McDonell/p/book/9781498736251
else if (We > 45)
{
// bag-and-stamen breakup - eq (10)
taubBar = 14.1*pow(We - 12.0, 0.25);
}https://develop.openfoam.com/Development/openfoam/-/issues/2213Losing heat in chtMultiRegionFoam2021-10-27T17:02:47ZPhilLosing heat in chtMultiRegionFoam[testCase.tar.gz](/uploads/330b7bba05e4f410af5c7723976b234b/testCase.tar.gz)
<!--
*** 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...[testCase.tar.gz](/uploads/330b7bba05e4f410af5c7723976b234b/testCase.tar.gz)
<!--
*** 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 -->
While running a conjugate heat transfer case with chtMultiRegionFoam, I noticed that the temperature in one of the regions is not being kept constant as would be expected by the setup. This seems to have been introduced during v2012 (and persists with v2106) but was working fine in v2006.
Over the time period of the example case, the temperature loses approx 0.5% of the correct value.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
For the example case, simply run the bash script provided (./run). The probe files in the postProcessing folder demonstrate the issue.
### 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
-->
Simple two region problem involving only solids.
[testCase.tar.gz](/uploads/330b7bba05e4f410af5c7723976b234b/testCase.tar.gz)
### What is the current *bug* behaviour?
<!-- What actually happens -->
The example 1D case is very simple / not particularly physically realistic but demonstrates the issue. In region 2, I have set it up so that the initial temperature is very small (1e-6) and applied zero gradient boundaries at either end.
The temperature in region 2 should remain constant, but it reduces instead.
I have included the temperature probe file for region 2 (postProcessing/probes2/block2/0/T) produced by v2006 and v2012. The v2006 results are what I would expect, given double precision, whereas the v2012 results are strange.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
Temperature in region 2 remains constant.
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906|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 : 2012 and 2106
- Operating system : Debian 9.4 Virtual Machine
- Hardware info : PC (sorry, don't know any info that would be useful here)
- Compiler : gcc and g++ 6.3.0
### 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
-->https://develop.openfoam.com/Development/openfoam/-/issues/2212BUG: QRMatrix: Prepended zero-valued rows lead to wrong QR decompositions2022-05-31T17:21:42ZKutalmış BerçinBUG: QRMatrix: Prepended zero-valued rows lead to wrong QR decompositions<!--
*** 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 -->
Matrices prepended with zero-valued rows lead to wrong QR decompositions. (Appended zero rows are fine). e.g.:
```
A =
4 3
(
(0 0 0)
(1 2 3)
(5 6 7)
(9 10 11)
)
```
Reduced QR decomposition produces the following wrong R matrix:
```
R =
3 3
(
(0 0 0)
(-1 11.8322 13.3534)
(-5 -8.88178e-16 0.828079)
)
```
rather than the correct R matrix:
```
R =
[[-1.03440804e+01 -1.17941852e+01 -1.32442899e+01]
[ 0.00000000e+00 -9.47204446e-01 -1.89440889e+00]
[ 0.00000000e+00 0.00000000e+00 7.10058168e-15]]
)
```
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Compile and execute: [Test-A.zip](/uploads/64467bec8b3ee0d1c93a0668fa27c311/Test-A.zip)
### 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
-->
```
api = 2107
patch = 0
HEAD = 72e67c7d1b
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
```Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2211PatchFunction1Types::ConstantField<Type>::getValue should not guard against z...2021-09-16T13:39:36ZVuko VukcevicPatchFunction1Types::ConstantField<Type>::getValue should not guard against zero length<!--
*** 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 -->
I think the guard against zero-sized lists in `Foam::PatchFunction1Types::ConstantField<Type>::getValue` is unnecessary and causes a subtle bug. This is the exact line in the repository: https://develop.openfoam.com/Development/openfoam/-/blob/master/src/meshTools/PatchFunction1/ConstantField/ConstantField.C#L94
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
This surfaced when we did a decomposition and reconstruction with `externalWallHeatFluxTemperature` BC. The decomposition is such that it gives a zero-sized patch on `processor0`, and on reconstruction, the `uniformValue_` is set to `0` and not set from the dictionary because the length is zero.
You should be able to reproduce this easily on the attached case with the following steps:
1. Run `blockMesh`,
2. Observe that the `movingWall` BC for `0/T` is `externalWallHeatFluxTemperature` with `h constant 42;` for heat transfer coefficient,
3. Run `decomposePar`,
4. Observe that the `movingWall` BC for `processor0/0/T` has the same definition as the reconstructed one, although there are zero faces on this patch.
5. Run `reconstructPar -withZero`,
6. Observe that the `movingWall` BC for `0/T` changed from `h constant 42;` to `h constant 0;`, which is a bug.
### 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
-->
[reproduce.tar.gz](/uploads/a3e416885a127e7e5339f678ccb2ad25/reproduce.tar.gz)
### What is the current *bug* behaviour?
<!-- What actually happens -->
`PatchFunction1Types::ConstantField<Type>::getValue` leaves `uniformValue_` member initialized to `Zero` if the list (patch) has zero-size.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
`PatchFunction1Types::ConstantField<Type>::getValue` should initialize `uniformValue_` member correctly from the dictionary, even for zero-sized lists.
### 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
- OpenFOAM version : v2012
- Operating system : ubuntu 20.04
- Hardware info : x86_64
- Compiler : gcc 9.3.0
### Possible fixes
Removing the `if (len)` check fixes the issue. I _think_ that this is completely safe since it's ok to perform operations on zero-sized lists (namely `List<Type>::setSize(0)` and `List<Type>::operator=(...)`).Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2210iso-surface (topo) can generate zero-size faces2021-11-17T19:46:34ZMark OLESENiso-surface (topo) can generate zero-size facesFlagged in EP1578 as being related to distance-surface sampling, but it actually related to small topological cuts.Flagged in EP1578 as being related to distance-surface sampling, but it actually related to small topological cuts.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2208Doxygen : issue with generation of documentation2024-01-09T12:07:47ZPawan GhildiyalDoxygen : issue with generation of documentationDiscussed with Andy and Kuti:
Still facing some issue there while compiling doxygen for OpenFOAM-v2106
for customer
! Misplaced alignment tab character &.
l.1406 \[ &
\frac{\pi}{4} (d_i + d_j)^2 u_{ij} \mathrm{exp} \l...Discussed with Andy and Kuti:
Still facing some issue there while compiling doxygen for OpenFOAM-v2106
for customer
! Misplaced alignment tab character &.
l.1406 \[ &
\frac{\pi}{4} (d_i + d_j)^2 u_{ij} \mathrm{exp} \left[ - C_1 \fra...
?Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/2205extractEulerianParticles in interFoam didn't work2024-01-09T12:11:57ZMichael YoungextractEulerianParticles in interFoam didn't workWhen I ran the tutorial($FOAM_TUTORIALS/multiphase/interFoam/laminar/vofToLagrangian/eulerianInjection) in parallel, command "reconstructPar" was followed by "Reconstructing lagrangian fields for cloud eulerianParticleCloud
--> FOAM FATA...When I ran the tutorial($FOAM_TUTORIALS/multiphase/interFoam/laminar/vofToLagrangian/eulerianInjection) in parallel, command "reconstructPar" was followed by "Reconstructing lagrangian fields for cloud eulerianParticleCloud
--> FOAM FATAL ERROR: (openfoam-2106) Cell not found for particle position".
It seems to be a bug in extractEulerianParticles module developed in interFoam.
Hope it to be resolved.https://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/2202foamMonitor: Get the correct number of columns and allow the usage of process...2021-10-05T10:50:10Zs1291foamMonitor: Get the correct number of columns and allow the usage of process substitution pipesHello,
In the [foamMonitor](https://develop.openfoam.com/Development/openfoam/-/blob/master/bin/foamMonitor) script, we can see in the line [140](https://develop.openfoam.com/Development/openfoam/-/blob/master/bin/foamMonitor#L140) that...Hello,
In the [foamMonitor](https://develop.openfoam.com/Development/openfoam/-/blob/master/bin/foamMonitor) script, we can see in the line [140](https://develop.openfoam.com/Development/openfoam/-/blob/master/bin/foamMonitor#L140) that NCOLS will be 0 if the input file contains trailing blank lines. So instead, I propose the following patch:
```
NCOLS=$(tac $FILE | grep -m 1 '.' | awk '{ print NF}')
```
This will guarantee to return the right number of columns without sacrificing performance (I've tested it with an input file with ~ 40 million lines, and the execution time is similar to the previous case using tail command).
In addition, in line [132](https://develop.openfoam.com/Development/openfoam/-/blob/master/bin/foamMonitor#L132)
Why should one restrict that to regular files only? We can use the `-e` flag instead to allow pipes using [process substitution](https://www.wikiwand.com/en/Process_substitution), for instance. (This is very useful when you plot over ssh). So line [132](https://develop.openfoam.com/Development/openfoam/-/blob/master/bin/foamMonitor#L132) should be:
```
[ -e $1 ] || usage "File $1 does not exit"
```
**EDIT**:
Because reading from a pipe is a destructive operation, we need to add the following if condition after line [132](https://develop.openfoam.com/Development/openfoam/-/blob/master/bin/foamMonitor#L132):
```
# check if the input is a named pipe
if [ -p "$1" ]
then
# store the pipe to a temporary file
FILE=$(mktemp)
cat "$1" > "$FILE"
else
FILE="$1"
fi
```
Thanks,
S.OUCHENEKutalmış BerçinKutalmış Berçinhttps://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/2200system mpi libpath can preempt ThirdParty location2021-09-09T16:14:15ZMark OLESENsystem mpi libpath can preempt ThirdParty locationMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2199coneInjection fails to atomize in all injector positions.2021-09-07T07:55:40ZJairo Andrés GutiérrezconeInjection fails to atomize in all injector positions.<!--
*** 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 -->
I am working with sprayFoam using a Multi-point cone injection atomization (16 injectors). They are set radially mimicking a rotary atomizer. A massRossin Rammler distribution is used. Depending on the injectionModels configuration (massTotal - SOI - parcelsPerSecond - duration), some injectors do not inject parcels or inject a much lower number of them. In all cases, Injector 1 works well, as the problem gradually appears from injectors down the list.
The attached figure presents an example of part of the problem:
- Increasing the parcelsPerInjector helps to improve the behaviour.
- Decreasing the totalMass helps to improve the behaviour.
![aachemBombBug](/uploads/b158690b6fe5ff69fc41f7b5a6492e9f/aachemBombBug.jpeg)
### Steps to reproduce
I am attaching with this report a modified "AachenBomb" case. To reproduce, go to the sprayCloudProperties file, line 86, where I have highlighted some massTotal and parcelsPerSecond values that generate the problem.
This is the example case:
[aachenBomb.zip](/uploads/65e39525858de81bce338cce11dc599a/aachenBomb.zip)
### Example case
<!-- What actually happens -->
### What is the expected *correct* behaviour?
The expected behaviour is having all the injectors of the coneInjection working, even when a low number of parcels (nParcels per timestep is lower than the # of Injectors) is injected per time-step.
<!-- 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 : 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 : 2012
- Operating system : Ubuntu 18.04 LTS
- Hardware info : Core I7 - 7th gen.
- Compiler :
### Possible fixes
I think the error is caused when the number of added parcels (per timestep) is lower than the number of injectors.
When the totalMass to inject is decreased, the dt increases (as the momentum source for the gas phase decreases) and more parcels are injected per time step. When ParcelsToInject is increased, more parcels are injected per second, until this value is greater than the number of injectors.
I am not sure exactly where in the code, but there should be a loop stating forAll(positionAxis_....) forcing the first parcel to be injected in injector 1, and the second to injector 2, and so. Thefore, I think the order of injection per time-step should be randomized.
<!--
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
-->Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2198Sloshing2D tutorial crashing in openfoam20122021-10-27T21:15:35ZBart VermeulenSloshing2D tutorial crashing in openfoam2012<!--
*** 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
The sloshing2D tutorial case is crashing with a floating point exception.
### Steps to reproduce
Run the sloshing2D tutorial case.
### Example case
See the sloshing2D case included in the openfoam2012 release, located at tutorials/incompressible/pimpleFoam/laminar/sloshing2D
### What is the current *bug* behaviour?
Run crashes with floating point exception. When run in the 2006 version the tutorial runs with no issue.
### What is the expected *correct* behavior?
Tutorial is expected to run with no issue.
### Relevant logs and/or images
tail of output of pimpleFoam
```
Courant Number mean: 0.0219597 max: 1.05238
Time = 0.48
PIMPLE: iteration 1
Maximal capillary Courant number: 4.01058
Free surface curvature: min = -0.103997, max = 0.0975977, average = -3.99992e-05
Free surface continuity error : sum local = 0.0197539, global = 1.75478e-11
DICPCG: Solving for cellMotionUx, Initial residual = 0, Final residual = 0, No Iterations 0
DICPCG: Solving for cellMotionUy, Initial residual = 0.457312, Final residual = 5.64373e-09, No Iterations 48
smoothSolver: Solving for Ux, Initial residual = 0.0427553, Final residual = 1.82027e-10, No Iterations 3
smoothSolver: Solving for Uy, Initial residual = 0.0483463, Final residual = 8.64354e-11, No Iterations 3
GAMG: Solving for p, Initial residual = 0.208065, Final residual = 8.26681e-09, No Iterations 21
time step continuity errors : sum local = 8.53615e-12, global = -3.40791e-12, cumulative = -1.51755e-10
GAMG: Solving for p, Initial residual = 0.0254321, Final residual = 7.7193e-09, No Iterations 16
time step continuity errors : sum local = 9.91592e-12, global = 4.01099e-12, cumulative = -1.47744e-10
GAMG: Solving for p, Initial residual = 0.00370436, Final residual = 4.97571e-09, No Iterations 16
time step continuity errors : sum local = 6.30442e-12, global = -2.5717e-12, cumulative = -1.50316e-10
PIMPLE: iteration 2
Free surface continuity error : sum local = 0.0314803, global = 7.36567e-10
DICPCG: Solving for cellMotionUx, Initial residual = 0, Final residual = 0, No Iterations 0
DICPCG: Solving for cellMotionUy, Initial residual = 0.74463, Final residual = 9.73061e-09, No Iterations 49
smoothSolver: Solving for Ux, Initial residual = 0.017863, Final residual = 1.36831e-10, No Iterations 4
smoothSolver: Solving for Uy, Initial residual = 0.0240514, Final residual = 2.23125e-10, No Iterations 4
GAMG: Solving for p, Initial residual = 0.129237, Final residual = 9.01299e-09, No Iterations 21
time step continuity errors : sum local = 9.515e-12, global = 3.51329e-12, cumulative = -1.46802e-10
GAMG: Solving for p, Initial residual = 0.0444841, Final residual = 9.74374e-09, No Iterations 18
time step continuity errors : sum local = 7.47935e-12, global = -2.77065e-12, cumulative = -1.49573e-10
GAMG: Solving for p, Initial residual = 0.00602138, Final residual = 7.04264e-09, No Iterations 16
time step continuity errors : sum local = 5.44304e-12, global = 2.03037e-12, cumulative = -1.47543e-10
PIMPLE: iteration 3
Free surface continuity error : sum local = 0.0307808, global = 7.89252e-10
DICPCG: Solving for cellMotionUx, Initial residual = 0, Final residual = 0, No Iterations 0
DICPCG: Solving for cellMotionUy, Initial residual = 0.827931, Final residual = 6.51922e-09, No Iterations 49
smoothSolver: Solving for Ux, Initial residual = 0.00918507, Final residual = 1.91392e-10, No Iterations 4
smoothSolver: Solving for Uy, Initial residual = 0.011106, Final residual = 1.70839e-10, No Iterations 4
GAMG: Solving for p, Initial residual = 0.188214, Final residual = 5.6468e-09, No Iterations 21
time step continuity errors : sum local = 5.19288e-12, global = 3.17129e-12, cumulative = -1.44371e-10
GAMG: Solving for p, Initial residual = 0.0291086, Final residual = 8.36559e-09, No Iterations 16
time step continuity errors : sum local = 8.81108e-12, global = -5.34691e-12, cumulative = -1.49718e-10
GAMG: Solving for p, Initial residual = 0.00488945, Final residual = 7.43674e-09, No Iterations 15
time step continuity errors : sum local = 7.90801e-12, global = 4.81474e-12, cumulative = -1.44903e-10
PIMPLE: iteration 4
Free surface continuity error : sum local = 0.00477103, global = 4.35966e-11
DICPCG: Solving for cellMotionUx, Initial residual = 0, Final residual = 0, No Iterations 0
DICPCG: Solving for cellMotionUy, Initial residual = 0.0896289, Final residual = 6.78209e-09, No Iterations 47
smoothSolver: Solving for Ux, Initial residual = 0.00788484, Final residual = 2.09289e-12, No Iterations 3
smoothSolver: Solving for Uy, Initial residual = 0.00482004, Final residual = 1.00621e-12, No Iterations 3
GAMG: Solving for p, Initial residual = 0.149903, Final residual = 7.07337e-09, No Iterations 18
time step continuity errors : sum local = 1.05058e-11, global = 6.34139e-12, cumulative = -1.38562e-10
GAMG: Solving for p, Initial residual = 0.027082, Final residual = 8.70494e-09, No Iterations 16
time step continuity errors : sum local = 1.45241e-11, global = 8.70469e-12, cumulative = -1.29857e-10
GAMG: Solving for p, Initial residual = 0.00467499, Final residual = 8.92156e-09, No Iterations 13
time step continuity errors : sum local = 1.51271e-11, global = -9.2286e-12, cumulative = -1.39086e-10
PIMPLE: iteration 5
Free surface continuity error : sum local = 0.0287436, global = -8.29794e-10
DICPCG: Solving for cellMotionUx, Initial residual = 0, Final residual = 0, No Iterations 0
DICPCG: Solving for cellMotionUy, Initial residual = 0.551951, Final residual = 7.17263e-09, No Iterations 51
smoothSolver: Solving for Ux, Initial residual = 0.0113926, Final residual = 4.32554e-10, No Iterations 5
smoothSolver: Solving for Uy, Initial residual = 0.0139625, Final residual = 1.39168e-10, No Iterations 7
GAMG: Solving for p, Initial residual = 0.0598591, Final residual = 4.9069e-09, No Iterations 20
time step continuity errors : sum local = 7.71824e-12, global = -4.4745e-12, cumulative = -1.4356e-10
GAMG: Solving for p, Initial residual = 0.0327082, Final residual = 5.9765e-09, No Iterations 16
time step continuity errors : sum local = 9.03766e-12, global = 5.26532e-12, cumulative = -1.38295e-10
GAMG: Solving for p, Initial residual = 0.0268987, Final residual = 8.39761e-09, No Iterations 15
time step continuity errors : sum local = 1.28788e-11, global = -7.44382e-12, cumulative = -1.45739e-10
PIMPLE: iteration 6
Free surface continuity error : sum local = 0.0346845, global = -7.9425e-10
DICPCG: Solving for cellMotionUx, Initial residual = 0, Final residual = 0, No Iterations 0
DICPCG: Solving for cellMotionUy, Initial residual = 0.809593, Final residual = 7.7121e-09, No Iterations 52
smoothSolver: Solving for Ux, Initial residual = 0.0133566, Final residual = 8.67802e-10, No Iterations 17
smoothSolver: Solving for Uy, Initial residual = 0.0189276, Final residual = 5.5088e-10, No Iterations 17
GAMG: Solving for p, Initial residual = 0.315144, Final residual = 5.3234e-09, No Iterations 6
time step continuity errors : sum local = 15973, global = -27168.6, cumulative = -27168.6
GAMG: Solving for p, Initial residual = 0.00485725, Final residual = 6.75073e-09, No Iterations 17
time step continuity errors : sum local = 42937.3, global = 26776.7, cumulative = -391.905
GAMG: Solving for p, Initial residual = 2.02096e-15, Final residual = 2.02096e-15, No Iterations 0
time step continuity errors : sum local = 4.27168e+10, global = -1.42809e+10, cumulative = -1.42809e+10
PIMPLE: iteration 7
Free surface continuity error : sum local = 8.3222e+10, global = -7.14045e+10
DICPCG: Solving for cellMotionUx, Initial residual = 0, Final residual = 0, No Iterations 0
DICPCG: Solving for cellMotionUy, Initial residual = 1, Final residual = 7.14591e-09, No Iterations 52
smoothSolver: Solving for Ux, Initial residual = 0.70222, Final residual = 2.92166e-10, No Iterations 15
smoothSolver: Solving for Uy, Initial residual = 0.604349, Final residual = 5.74197e-10, No Iterations 13
#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::sigFpe::sigHandler(int) at ??:?
#2 ? in /lib/x86_64-linux-gnu/libpthread.so.0
#3 Foam::GAMGSolver::scale(Foam::Field<double>&, Foam::Field<double>&, Foam::lduMatrix const&, Foam::FieldField<Foam::Field, double> const&, Foam::UPtrList<Foam::lduInterfaceField const> const&, Foam::Field<double> const&, unsigned char) const at ??:?
#4 Foam::GAMGSolver::Vcycle(Foam::PtrList<Foam::lduMatrix::smoother> const&, Foam::Field<double>&, Foam::Field<double> const&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::PtrList<Foam::Field<double> >&, Foam::PtrList<Foam::Field<double> >&, unsigned char) const at ??:?
#5 Foam::GAMGSolver::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const at ??:?
#6 Foam::fvMatrix<double>::solveSegregated(Foam::dictionary const&) at ??:?
#7 Foam::fvMatrix<double>::solveSegregatedOrCoupled(Foam::dictionary const&) at ??:?
#8 Foam::fvMesh::solve(Foam::fvMatrix<double>&, Foam::dictionary const&) const at ??:?
#9 ? in ~/OpenFOAM/OpenFOAM-v2012/platforms/linux64GccDPInt32Opt/bin/pimpleFoam
#10 __libc_start_main in /lib/x86_64-linux-gnu/libc.so.6
#11 ? in ~/OpenFOAM/OpenFOAM-v2012/platforms/linux64GccDPInt32Opt/bin/pimpleFoam
Floating point exception (core dumped)
```
### 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 :v2012
- Operating system :Ubuntu
- Hardware info :Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz
- Compiler :gcc
### 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
-->Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2197aarch64/debian package/docker image OF21062021-09-10T12:00:23ZGiuseppe Giaquintoaarch64/debian package/docker image OF2106### Functionality to add/problem to solve
Some day ago I build a docker image for linux/arm64 for my M1 mac, but it was a real pain because there are no debian packages with precompiled binaries so I would ask if it was possible to add ...### Functionality to add/problem to solve
Some day ago I build a docker image for linux/arm64 for my M1 mac, but it was a real pain because there are no debian packages with precompiled binaries so I would ask if it was possible to add such debian package and make an official docker image for arm64.
### Links / references
[my docker images](https://hub.docker.com/repository/docker/giuseppegq20/openfoam2106)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2196bad distributed roots specification causes odd error2021-12-01T17:49:25ZMark OLESENbad distributed roots specification causes odd errorReported in EP1660, if decomposeParDict has distributed true, but has an empty `roots ()` entry, we get very odd error messages.
@martin.wertherReported in EP1660, if decomposeParDict has distributed true, but has an empty `roots ()` entry, we get very odd error messages.
@martin.wertherMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2195IOobject : add relative path function2021-10-01T15:36:47ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comIOobject : add relative path function### Functionality to add/problem to solve
IOobject has objectPath() to obtain the complete path. It would be nice to have a relative (to the <case>) path, especially for warning/error messages.### Functionality to add/problem to solve
IOobject has objectPath() to obtain the complete path. It would be nice to have a relative (to the <case>) path, especially for warning/error messages.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2194iglooWithFridges tutorial set-up2021-12-10T15:24:19ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comiglooWithFridges tutorial set-up<!--
*** 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 -->
heatTransfer/buoyantBoussinesqSimpleFoam/iglooWithFridges tutorial contains commented out code to run in parallel with collated file format. This does not run.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Set 'parallel true' at top of script.
### What is the current *bug* behaviour?
<!-- What actually happens -->
- wrong directory ('processors' instead of 'processors2')
- reconstructParMesh run without -fileHandler collated
### 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 : v2106Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.com