Development issueshttps://develop.openfoam.com/groups/Development/-/issues2020-06-19T20:59:31Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1264Memory leak2020-06-19T20:59:31ZAdminMemory leaksuspecting a memory leak in openfoam-dev when compiled on a cluster using gcc 4.9.3 and openmpi 1.8.6
```
==39345== LEAK SUMMARY:
==39345== definitely lost: 0 bytes in 0 blocks
==39345== indirectly lost: 0 bytes in 0 blocks
==39345...suspecting a memory leak in openfoam-dev when compiled on a cluster using gcc 4.9.3 and openmpi 1.8.6
```
==39345== LEAK SUMMARY:
==39345== definitely lost: 0 bytes in 0 blocks
==39345== indirectly lost: 0 bytes in 0 blocks
==39345== possibly lost: 538 bytes in 12 blocks
==39345== still reachable: 2,056 bytes in 3 blocks
==39345== suppressed: 0 bytes in 0 blocks
==39345== Reachable blocks (those to which a pointer was found) are not shown.
==39345== To see them, rerun with: --leak-check=full --show-reachable=yes
==39345==
==39345== For counts of detected and suppressed errors, rerun with: -v
==39345== ERROR SUMMARY: 12 errors from 12 contexts (suppressed: 8 from 6)
```
\## Reattaching the author to the issue ticket: @mmahmed ##https://develop.openfoam.com/Development/openfoam/-/issues/1266May need independent MPI initialize/finalize2019-04-11T14:39:59ZMark OLESENMay need independent MPI initialize/finalizeAs discussed with @Mattijs, but also of interest for @sbna
When Pstream initializes MPI, it checks for a previous initialization of MPI and skips if not required. It then also skips attaching transfer buffers. On finalize, it does simil...As discussed with @Mattijs, but also of interest for @sbna
When Pstream initializes MPI, it checks for a previous initialization of MPI and skips if not required. It then also skips attaching transfer buffers. On finalize, it does similar checks.
This means that MPI initialization outside of OpenFOAM will result in the buffers not being setup.
Exiting OpenFOAM will finalize MPI, even if OpenFOAM was not the one who initialized it.
Need the following:
- if an external app initialized, still initialize our buffers
- only finalize if OpenFOAM was also the one initializing, but always clean up our buffers if we created then.
Open question: when MPI was initialized elsewhere, are there any potential conflict when calling freePstreamCommunicator?Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1267The 'function object' does not write out the results of 'volFieldValue' if 's...2019-07-03T19:32:25ZAdminThe 'function object' does not write out the results of 'volFieldValue' if 'solidificationMeltingSource' is used.<!--
*** 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
-->
<!--
All text between these marker...<!--
*** 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
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
After calculation using solidificationMeltingSource, the time change of the liquid phase (eg. sMS:alpha1 field) fails to written out by function object utility.
### Steps to reproduce
> $ buoyantPimpleFoam
>
> (after the end)
>
> $ buoyantPimpleFoma -postProcess
### Example case
After expanding this attached file, execute 'Allrun' script file!
[solidificationMeltingSourceTest.tar.gz](/uploads/556b79b4ce57806740507da6e5ce49f6/solidificationMeltingSourceTest.tar.gz)
### What is the current *bug* behaviour?
<!-- What actually happens -->
### What is the expected *correct* behavior?
<!-- What you should see instead -->
### Relevant logs and/or images
In case of the calculation simultaneously with solver
>volFieldValue meltingFranctions write:
>
> sum(PCM) of sMS1:alpha1 = 475.61726
>
>End
>
>(no problem)
---
When executed as post-processing
>volFieldValue meltingFranctions write:
>
> sum(PCM) of sMS1:alpha1 = 0
>
>
>End
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
OpenFOAM version :v1812
Operating system :ubuntu18.04
Compiler :gcc-7.3.0
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
-->https://develop.openfoam.com/Development/openfoam/-/issues/1268avoid use of gatherList (e.g. fvMeshDistribute)2019-11-08T07:11:42ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comavoid use of gatherList (e.g. fvMeshDistribute)### Functionality to add/problem to solve
Currently in the code it sometimes uses a gatherList to collect data from other processors. This becomes expensive for large numbers of processors.
### Proposal
Replace with an allToAll type ...### Functionality to add/problem to solve
Currently in the code it sometimes uses a gatherList to collect data from other processors. This becomes expensive for large numbers of processors.
### Proposal
Replace with an allToAll type wrapper.https://develop.openfoam.com/Development/openfoam/-/issues/1269possible regression in uniformFixedValuePointPatch?2019-04-08T15:04:14ZMark OLESENpossible regression in uniformFixedValuePointPatch?In tutorials/basic/overLaplacianDyMFoam/heatTransfer I'm getting some very odd output which I think could be related to this commit: 0987898f5c1678
I initially thought it might be related to the generic point patches since reconstructPa...In tutorials/basic/overLaplacianDyMFoam/heatTransfer I'm getting some very odd output which I think could be related to this commit: 0987898f5c1678
I initially thought it might be related to the generic point patches since reconstructPar was failing when fill-nan is set. The values it reconstructs for the pointDisplacement right1 boundary are scalars, not vectors.
Backtracking some more, it seems that the original decomposed fields are a bit *odd*.
In 1812:
processor0/0/pointDisplacement.right1
right1
{
type uniformFixedValue;
value nonuniform 0();
uniformValue constant (0 0 0);
}
In develop:
processor0/0/pointDisplacement.right1
right1
{
type uniformFixedValue;
uniformValue ( 0 0 0 );
}
At later times this looks different again. Eg, processor0/0.5/pointDisplacement.right1
1812:
right1
{
type uniformFixedValue;
value nonuniform 0();
uniformValue constant (0 0 0);
}
develop:
right1
{
type uniformFixedValue;
value nonuniform 0();
uniformValue nonuniform 0();
}
When this is reconstructed, the generic point patch process the entries quite badly. Even the output for `value` does not look correct.
@PrashantMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1270incorrect default location for project site binaries2019-12-09T22:37:28ZMark OLESENincorrect default location for project site binaries`FOAM_SITE_APPBIN` and `FOAM_SITE_LIBBIN` are still using WM_PROJECT_VERSION instead of FOAM_API`FOAM_SITE_APPBIN` and `FOAM_SITE_LIBBIN` are still using WM_PROJECT_VERSION instead of FOAM_APIMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1271foamToVTK writes to undecomposed case2019-12-09T22:37:28ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfoamToVTK writes to undecomposed case### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
On any case:
```
decomposePar
cd processor0
foamToVTK
```
this will create ../VTK since it uses the globalPath but does not check for parallel runn...### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
On any case:
```
decomposePar
cd processor0
foamToVTK
```
this will create ../VTK since it uses the globalPath but does not check for parallel running.
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
-->
```
const fileName outputDir(runTime.globalPath()/vtkDirName);
```
should check for `Pstream::parRun()` and use `runTime.path()` if not parallelMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1272adjustTimeStep/writeInterval conflict2021-07-06T15:32:23ZAdminadjustTimeStep/writeInterval conflictI'm running a very simple test case using interPhaseChangeFoam and found out that monitors written every writeInterval based on adjustableRunTime conflict with the adjustTimeStep option.
For example, if monitors are not used and a max C...I'm running a very simple test case using interPhaseChangeFoam and found out that monitors written every writeInterval based on adjustableRunTime conflict with the adjustTimeStep option.
For example, if monitors are not used and a max Courant of 0.5 is specified, the solver runs fine with a time step size of the order of 1e-4 after an initial transient regime from the specified time step size of 1e-6.
If monitors are activated with a writeInterval of 1e-3, the case runs initially fine but then the time step size drops suddenly to 1e-28.
\## Reattaching the author to the issue ticket: @Ricky\-11 ##Prashant SonakarPrashant Sonakarhttps://develop.openfoam.com/Development/openfoam/-/issues/1273odd timeset for ensight collated output2019-12-09T22:37:28ZMark OLESENodd timeset for ensight collated outputAs noted by @Prashant - there seem to be too many timesets when sampling.As noted by @Prashant - there seem to be too many timesets when sampling.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1274decomposePar -allRegions produces different results than decomposePar -region...2019-07-04T11:47:18ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comdecomposePar -allRegions produces different results than decomposePar -region XXX<!--
*** 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
-->
<!--
All text between these marker...<!--
*** 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
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
heatTransfer/chtMultiRegionFoam/windshieldDefrost
Set system/decomposeParDict to scotch
```decomposePar -allRegions```
vs
```
decomposePar -region exterior
decomposePar -region ice
decomposePar -region cabin
```
- eg `simple` method produces exactly the same decompositions
- we compile scotch with `SCOTCH_DETERMINISTIC`
bug or feature of scotch?https://develop.openfoam.com/Development/openfoam/-/issues/1275faceCorrected snGrad needs update on surface field orientation2020-03-13T13:36:07ZSergio FerrarisfaceCorrected snGrad needs update on surface field orientationfaceCorrected used in the laplacian lacks oriented flag for +=faceCorrected used in the laplacian lacks oriented flag for +=https://develop.openfoam.com/Development/openfoam/-/issues/1277Calculated pressures change based on domain elevation using interFoam and int...2019-08-19T21:29:30ZAdminCalculated pressures change based on domain elevation using interFoam and interIsoFoam.### Summary
Calculated pressures change based on domain elevation using interFoam and interIsoFoam. As the domain is moved up in the gravity direction, pressures decrease with negative pressures forming within the water phase.
### Step...### Summary
Calculated pressures change based on domain elevation using interFoam and interIsoFoam. As the domain is moved up in the gravity direction, pressures decrease with negative pressures forming within the water phase.
### Steps to reproduce
Reproducible using weirOverflow tutorial (~/tutorials/multiphase/interFoam/RAS/weirOverflow)
Case 1:
Run weirOverflow tutorial without any changes.
Case 2:
Change the location of the weirOverflow domain by adding 500 to all Y-values in the blockMeshDict (y is the gravity direction for this tutorial).
Run both cases to 60 seconds. Create isoVolumes of the water phase (a=0.5). Color by "p" with a range -1 to 0. Case 2 will have negative pressures in the water phase near the free-surface. Comparison of pressures at bottom of water column also differ.
### Example case
Reproducible using weirOverflow tutorial (~/tutorials/multiphase/interFoam/RAS/weirOverflow)
### What is the current *bug* behaviour?
The pressures in the domain change based on the location of the domain with respect to the gravity direction.
### What is the expected *correct* behavior?
I think "p" should be independent of the domain location?
### Relevant logs and/or images
See attached for image comparing Case 1 and Case 2. Also reproduced in a different domain to further highlight the issue in attached image "Example2".
![Example1_weirOverflow](/uploads/2442f52530949ac7851815710e5e0747/Example1_weirOverflow.PNG)
![Example2](/uploads/67403ba302f755c15dcdc3a00094c041/Example2.PNG)
### Environment information
Have reproduced on 2 systems
OpenFOAM version : v1806|v1812
Operating system : ubuntu|openSUSE
Compiler : gcc|intel
### Possible fixes
Not sure....https://develop.openfoam.com/Development/openfoam/-/issues/1280inconsistent emissivity for externalWallHeatFluxTemperatureFvPatchScalarField2019-12-09T22:37:28ZMark OLESENinconsistent emissivity for externalWallHeatFluxTemperatureFvPatchScalarField- emissivity is partly ignored (hpTa) when there is no solid resistance- emissivity is partly ignored (hpTa) when there is no solid resistanceMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1281fv::convectionScheme does not accept all schemes2021-07-06T15:33:30ZAdminfv::convectionScheme does not accept all schemesThe reacting solvers like the combustion solvers, Lagrangian solvers or heat transfer solvers use a fv::convectionScheme object for the convection term of species mass fraction and energy instead of fvm::div:
https://develop.openfoam.co...The reacting solvers like the combustion solvers, Lagrangian solvers or heat transfer solvers use a fv::convectionScheme object for the convection term of species mass fraction and energy instead of fvm::div:
https://develop.openfoam.com/search?utf8=%E2%9C%93&search=fv%3A%3AconvectionScheme&group_id=&project_id=5&search_code=true&repository_ref=develop#L1
This prevents the use of certain discretization schemes like "linear". For example, in the $FOAM_TUTORIALS/combustion/reactingFoam/laminar/counterFlowFlame2D case, replace
div(phi,Yi_h) Gauss limitedLinear 1;
with
div(phi,Yi_h) Gauss linear;
The error will read:
--> FOAM FATAL IO ERROR:
Unknown discretisation scheme linear
Valid schemes are :
12
(
Gamma
MUSCL
Minmod
SuperBee
limitedCubic
limitedLimitedLinear
limitedLinear
limitedLinear01
multivariateIndependent
multivariateSelection
upwind
vanLeer
)
Is this the intended behavior? Having the ability to choose schemes like "linear" or "cubic" might be advantageous for very fine meshes or DNS-like simulations.
\## Reattaching the author to the issue ticket: @g3 ##https://develop.openfoam.com/Development/openfoam/-/issues/1282dynamicCode does not work with the Intel compiler2023-12-07T19:00:15ZAdmindynamicCode does not work with the Intel compilerIf "blockMesh" is executed in the tutorial $FOAM_TUTORIALS/basic/potentialFoam/cylinder using an OpenFOAM version compiled with the Intel compiler, the following error message will appear:
codeStreamTemplate.C(35): error: invalid line n...If "blockMesh" is executed in the tutorial $FOAM_TUTORIALS/basic/potentialFoam/cylinder using an OpenFOAM version compiled with the Intel compiler, the following error message will appear:
codeStreamTemplate.C(35): error: invalid line number
#line 0 "/path/to/system/blockMeshDict.#codeStream"
I tested this with Intel2018 and 2019 and OpenFOAM v1712 and v1812 on two different systems and the error happens with all instances where dynamicCode is used.
The generated code in cylinder/dynamicCode/_1c19e29ae18c779aa836a14631d6419f303e3d9d/codeStreamTemplate.C in line 35 reads:
#line 0 "/path/to/cylinder/system/blockMeshDict.#codeStream"
The Intel compiler complains about the "0". If instead "blockMesh" is run with an OpenFOAM version compiled with clang or gcc, the same code is generated but the compiler does not complain. A quick fix would be to remove the following line:
https://develop.openfoam.com/Development/OpenFOAM-plus/blob/master/src/OpenFOAM/db/dynamicLibrary/dynamicCode/dynamicCodeContext.C#L129Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1283SegFault / bad allocation if same limited scheme is used in grad and div2020-01-16T18:13:02ZAdminSegFault / bad allocation if same limited scheme is used in grad and divIn the tutorial case $FOAM_TUTORIALS/incompressible/pimpleFoam/laminar/planarPoiseuille/, in system/fvSchemes replace
gradSchemes
{
default Gauss linear;
}
by
gradSchemes
{
default Gauss lim...In the tutorial case $FOAM_TUTORIALS/incompressible/pimpleFoam/laminar/planarPoiseuille/, in system/fvSchemes replace
gradSchemes
{
default Gauss linear;
}
by
gradSchemes
{
default Gauss limitedLinear phi 1;
}
and in divSchemes, replace
div(phi,U) Gauss linearUpwind grad(U);
by
div(phi,U) Gauss limitedLinear 1;
If pimpleFoam is executed, the solver crashes right after the output "PIMPLE: iteration 1" with an error message like this (tested with OpenFOAM v1812):
new cannot satisfy memory request.
This does not necessarily mean you have run out of virtual memory.
It could be due to a stack violation caused by e.g. bad use of pointers or an out of date shared library
\## Reattaching the author to the issue ticket: @g3 ##Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1284dry-run-write overwrites mesh2019-04-15T09:58:33ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comdry-run-write overwrites mesh<!--
*** 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
-->
<!--
All text between these marker...<!--
*** 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
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
dry-run-write overwrites mesh with the dry-run write.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1286foamToEnsight leaks memory2020-07-28T15:15:56ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfoamToEnsight 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
-->
<!--
All text between these marker...<!--
*** 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
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
valgrind reports some in-use memory after finishing. E.g. foamToVTK does not.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
valgrind --leak-check=full foamToEnsight
```
==3683== HEAP SUMMARY:
==3683== in use at exit: 171 bytes in 4 blocks
==3683== total heap usage: 67,611 allocs, 67,607 frees, 6,829,195 bytes allocated
==3683==
==3683== 143 (72 direct, 71 indirect) bytes in 1 blocks are definitely lost in loss record 4 of 4
==3683== at 0x4C2A6F0: operator new(unsigned long) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==3683== by 0x6921081: Foam::IOobjectList::IOobjectList(Foam::objectRegistry const&, Foam::fileName const&, Foam::fileName const&, Foam::IOobject::readOption, Foam::IOobject::writeOption, bool) (in /home/preston2/mattijs/OpenFOAM/work/develop/OpenFOAM-plus/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so)
==3683== by 0x44F58C: main (in /home/preston2/mattijs/OpenFOAM/work/develop/OpenFOAM-plus/platforms/linux64GccDPInt32Opt/bin/foamToEnsight)
```
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
OpenFOAM version : developMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1287sumDirection function in surfaceFieldValue FO does not write down the values,...2019-12-09T22:37:29ZMatej FormansumDirection function in surfaceFieldValue FO does not write down the values, just zeros**sunDirection** function used on **faceZone** on orthogonalMesh samples **phi** in surfaceFieldValue FO.
FaceZone is set of internal faces.
It writes the field (vtk) with real flux values in individual cells.
However, into the text f...**sunDirection** function used on **faceZone** on orthogonalMesh samples **phi** in surfaceFieldValue FO.
FaceZone is set of internal faces.
It writes the field (vtk) with real flux values in individual cells.
However, into the text file where it should write the sum, only zeros are entered.
I did alter the direction specification from ortho direction to see if it gets better, but no.
The reported value is still zero.https://develop.openfoam.com/Development/openfoam/-/issues/1289sixDoF restraint 'tabulatedAxialAngularSpring' does not read tabulated files ...2019-04-18T16:22:01ZAdminsixDoF restraint 'tabulatedAxialAngularSpring' does not read tabulated files properlyDear all,
I am struggling to use sixDoF restraint 'tabulatedAxialAngularSpring', which is to impose a constant resistant torque on turbine shaft to simulate the reaction from a generator geared to turbine.
Have tested .dat files in m...Dear all,
I am struggling to use sixDoF restraint 'tabulatedAxialAngularSpring', which is to impose a constant resistant torque on turbine shaft to simulate the reaction from a generator geared to turbine.
Have tested .dat files in many ways, but still not successful. The error info is always 'error in IOstream "xxx.dat" for operation Istram::operator()'.
No examples can be found from official tutorials using 'tabulatedAxialAngularSpring', and no discussions can be found from internet.
However, I do believe 'tabulatedAxialAngularSpring' is a great option and should work properly in someway.