Development issueshttps://develop.openfoam.com/groups/Development/-/issues2021-07-07T09:55:27Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1724vtkCloud/double free or corruption2021-07-07T09:55:27ZRiccardo RossivtkCloud/double free or corruptionI've been testing the vtkCloud with the simplifiedSiwek tutorials and then used the function object with a customized solver based on interFoam with an added kinematicCloud.
The solver itself runs fine with and without the vtkCloud for ...I've been testing the vtkCloud with the simplifiedSiwek tutorials and then used the function object with a customized solver based on interFoam with an added kinematicCloud.
The solver itself runs fine with and without the vtkCloud for postprocessing, but when I include the function object I get this at the end of the simulation (still running fine and saving all the vtkCloud files as expected including the last one):
*** Error in `interLPTFoam': double free or corruption (!prev): 0x0000000002d27c50 ***
followed by:
======= Backtrace: =========
/lib64/libc.so.6(+0x7c619)[0x7f8b123d0619]
interLPTFoam(_ZN4Foam4wordD1Ev+0x43)[0x5bf4c3]
/lib64/libc.so.6(__cxa_finalize+0x9a)[0x7f8b1238cdda]
/gpfs/work/rfd_prod1/processing/Wam/projects/centrifugalSeparator/solvers/interLPTFoam/platforms/linux64IccDPInt32OptBDW/lib/libinterLPTLagrangianIntermediate.so(+0x2f97c3)[0x7f8b1afe17c3]
and then long list of string of errors related to many libraries not even used by the solver.
Any idea/suggestion?https://develop.openfoam.com/Development/openfoam/-/issues/1723MRF & interFoam issues2021-07-07T09:54:58ZYannickMRF & interFoam issues<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be ...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
When using a MRF in combination with interFoam while doing a two phase simulation there is the following issue:
A) The fluid inside the MRF-region gets the rotational velocity of the MRF even if there is no geometry inside. I tried to build the MRF-region with snappy and topoSet but the output is the same.
B) It's not possible to update the MRF-Omega while the simulation is running
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
1. Take the DTC-Hull template Case with interFoam (tutorials/multiphase/interFoam/RAS/DTCHull)
2. remove the hull geometry
3. edit the snappyHexMeshDict and add a cellzone for the MRF
4. add MRFProperties to constant and set the MRFRegion to the created cellzone, set omega to 100
<!-- How one can reproduce the issue - this is very important -->
### Example case
see attached case
[HullMRF.zip](/uploads/504189d0137a0353e72d9b363bc11787/HullMRF.zip)
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
### What is the current *bug* behaviour?
<!-- What actually happens -->
Fluid rotates inside the MRF region without physical reason. It is the same if there is a geometry inside the Region.
![Cylinder](/uploads/e1eb4e667db9e61afb24de139398bb81/Cylinder.png)
![CylinderRefine](/uploads/f9f11afe7020c0d12e26dea185bb96e8/CylinderRefine.png)
![CylinderRefineFromBelow](/uploads/d16ee5a51ce1d6cf89d218ebee84a698/CylinderRefineFromBelow.png)
### What is the expected *correct* behavior?
No roataional moving of the fluid caused to the MRF
<!-- 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
testet with : v1812 & v1912
ubuntu
<!--
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 & v1912
- Operating system :ubuntu
- Hardware info :
- Compiler :
<!--
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
-->
### Update 10.06.2020
We did some additional testing on that case
Modifications made
- We relpaced the Cylinder trough a searchableBox in SnappyHexMesh
- no refinement on the cellZone MRFRegion
- turn off all feature snapping
- moved the box completely in the water domain
Mesh is undisturbed and has a good quality
Variations made
- multiple omegas
In the attached pictures we see a strange curl velocities at the edges of region.
![CylinderunterwaterEdgesUy](/uploads/80c97953a08d63047d8f5ba67d612f09/CylinderunterwaterEdgesUy.png)
![CylinderunterwaterEdgesUx](/uploads/cf40832e71929e2e23d71cbc0855eaa8/CylinderunterwaterEdgesUx.png)
The last picture is showing some glyphs at the beginnig of the MRF.
Can it be, that there is something going on with the correctBoundaryVelocity when a cell has two or more faces with the nonRotating region?
![FlowLines2](/uploads/c6cdbbd6b5012ec0f32d393d73f50a25/FlowLines2.png)Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1721support more flexible installation paths for modules or user code2020-06-19T14:22:48ZMark OLESENsupport more flexible installation paths for modules or user code## The problem
When compiling additional modules or user code, we need more flexibility for
the installation locations. We currently have three possible locations:
1. user locations - eg, `$FOAM_USER_LIBBIN`
2. group locations - eg `$FO...## The problem
When compiling additional modules or user code, we need more flexibility for
the installation locations. We currently have three possible locations:
1. user locations - eg, `$FOAM_USER_LIBBIN`
2. group locations - eg `$FOAM_SITE_LIBBIN`
2. project locations - eg, `$FOAM_LIBBIN`
The difficulty is that project or site directories could be read-only, or the person compiling things might want to create a package for a group of users and it is difficult to fish these back out of their user directory.
## Target audience
Developer or packager wishing to harness OpenFOAM and possibly combine with some arbitrary other software. For example, if we wish to compile a module using an installed OpenFOAM code base but using some particular petsc, paraview, vtk version. We would like to work with pristine sources, but compile/recompile the interfaces as required and make them available as additional layers or system modules.
## Possible solution
To address this, it is proposed to introduce three additional make variables for the purposes of compilation:
- FOAM_MODULE_PREFIX - default is unset
- FOAM_MODULE_APPBIN - if unset and FOAM_MODULE_PREFIX is set, treat as `$(FOAM_MODULE_PREFIX)/bin`
- FOAM_MODULE_LIBBIN - if unset and FOAM_MODULE_PREFIX is set, treat as `$(FOAM_MODULE_PREFIX)/lib`
Contain the logic in the `wmake/rules/General` rules
- module-path-prefix : the logic described above
- module-path-user : use FOAM_USER_APPBIN, FOAM_USER_LIBBIN for the defaults
- module-path-group : use FOAM_SITE_APPBIN, FOAM_SITE_LIBBIN for the defaults
- module-path-project : use FOAM_APPBIN, FOAM_LIBBIN for the defaults
## For the developer
The above logic is indeed ugly, but should be clean enough to use for the developer.
It will require changes in the `Make/options` and `Make/files` files.
### before
| default location | Make/options | Make/files |
|------------------|--------------|------------|
| _user_ | | `LIB = $(FOAM_USER_LIBBIN)/libXYZ` |
| _group_ | | `LIB = $(FOAM_SITE_LIBBIN)/libXYZ` |
| _project_ (OpenFOAM) | | `LIB = $(FOAM_LIBBIN)/libXYZ` |
### after
| default location | Make/options | Make/files |
|------------------|--------------|------------|
| _user_ | `include $(GENERAL_RULES)/module-path-user` | `LIB = $(FOAM_MODULE_LIBBIN)/libXYZ` |
| _group_ | `include $(GENERAL_RULES)/module-path-group` | `LIB = $(FOAM_MODULE_LIBBIN)/libXYZ` |
| _project_ (OpenFOAM) | `include $(GENERAL_RULES)/module-path-project` | `LIB = $(FOAM_MODULE_LIBBIN)/libXYZ` |
## For the packager
If the above changes are implemented, it is then possible for the person compiling/packaging to specify different install locations. For example,
```
FOAM_MODULE_PREFIX=/path/my-install-location ./Allwmake
```
or
```
FOAM_MODULE_LIBBIN=$HOME/tmp-prefix/lib wmake libso
```
Some work has already been done (see commit aafe674f5f4748) to handle a `-prefix` argument to define `CMAKE_INSTALL_PREFIX`. Could simply extend that to set `FOAM_MODULE_PREFIX` as well.
Another possibility is would be to support `wmake -module-prefix=...` directly, which would free us from dependence on an `Allwmake` script.
## Open points
Using these mechanisms with an arbitrary prefix may require temporary addition of the bin directory to the PATH, if the module or utility is compiling tools for itself. Can probably address this on an individual basis.v2006Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1720missing compilation for some vtk conversion components2020-06-04T23:11:50ZMark OLESENmissing compilation for some vtk conversion componentsMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1719Postprocess utility gives fatal error when used to compute wallShearStress wi...2020-06-19T15:35:07ZRiccardo RossiPostprocess utility gives fatal error when used to compute wallShearStress with MPPICInterFoamWhen invoking the postprocess utility after the simulation is completed, the postprocess utility gives:
--> FOAM FATAL ERROR:
Unable to find turbulence model in the database
From function bool Foam::functionObjects::wallShearStres...When invoking the postprocess utility after the simulation is completed, the postprocess utility gives:
--> FOAM FATAL ERROR:
Unable to find turbulence model in the database
From function bool Foam::functionObjects::wallShearStress::execute()
in file wallShearStress/wallShearStress.C at line 217.
when used to compute the wall shear stress with MPPICInterFoam:
MPPICInterFoam -postProcess -func 'wallShearStress'
Can be reproduced using the twoPhasePachuka tutorial.v2012https://develop.openfoam.com/Development/openfoam/-/issues/1718Write particle positions using functionObjects2020-06-07T20:40:05ZRiccardo RossiWrite particle positions using functionObjectsI've searched extensively within the source code and online and looks like there isn't any method available to write the position of Lagrangian particles, perhaps appending some Lagrangian data to each position, in the same way as cutpla...I've searched extensively within the source code and online and looks like there isn't any method available to write the position of Lagrangian particles, perhaps appending some Lagrangian data to each position, in the same way as cutplanes and isosurfaces can be written using function objects, i.e. having a file written with a given frequency in the corresponding time folder within the postProcessing folder in vtk or vtp format.
It would be great to have a confirmation for this and, if so, to consider the development of such function object and spare the user from writing the whole solution in order to reconstruct and view the dynamics of particles with a decent frequency, especially for large meshes.https://develop.openfoam.com/Development/openfoam/-/issues/1717add shell syntax for modules2020-06-05T11:47:28ZMark OLESENadd shell syntax for modules- refactor/modify foamCreateModuleInclude to support shell output- refactor/modify foamCreateModuleInclude to support shell outputMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1716erroneous return from void method2020-06-04T23:11:50ZMark OLESENerroneous return from void methodPtrList append has a return, but the method is `void`
- long-standing bug (dating back to 2014), but obviously never exercised.PtrList append has a return, but the method is `void`
- long-standing bug (dating back to 2014), but obviously never exercised.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1714unload errors for fieldfunctions library2020-06-05T14:33:34ZMark OLESENunload errors for fieldfunctions libraryThe recent changes to phase-system turbulence libraries and subsequent change to the field function link options (commit 11965904b) appear to provoke an unload error. Seen for clang (10.0), but _not_ for gcc (7.5.0).
If I do a full or ...The recent changes to phase-system turbulence libraries and subsequent change to the field function link options (commit 11965904b) appear to provoke an unload error. Seen for clang (10.0), but _not_ for gcc (7.5.0).
If I do a full or partial revert of that commit, the error shifts to being not able to load the library (double entry for "laminar" as @Pawan reported).
Here is what the error currently looks like:
```
tutorials/heatTransfer/chtMultiRegionFoam/externalCoupledHeater/
$ foamListRegions
bottomWater
topAir
heater
leftSolid
rightSolid
--> FOAM Warning :
From void Foam::dlLibraryTable::clear(bool)
in file db/dynamicLibrary/dlLibraryTable/dlLibraryTable.C at line 164
Failed closing "fieldFunctionObjects" with handle 0xa8a170
```
In the tutorial test loop this is pure poison since output (stdout) is the input for the following changeDictionary.
For additional robustness, the warnings really should be redirected to stderr when the banner is suppressed.
Additionally, loading additional libraries should likely be suppressed in `foamListRegions` as well.
This means that the errors will disappear for that tutorial, but there still seems to be fundamental issue with the field function library.
@andyv2006Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/issues/1713allow redirect of Warnings to stderr2020-05-26T05:39:14ZMark OLESENallow redirect of Warnings to stderrIf running without banners we set infoDetailLevel to suppress stdout, or use stderr instead (cf. issues #722, #893).
However WarningInFunction etc still land on stdout!
Instead of introducing yet another message stream, hijack the infoD...If running without banners we set infoDetailLevel to suppress stdout, or use stderr instead (cf. issues #722, #893).
However WarningInFunction etc still land on stdout!
Instead of introducing yet another message stream, hijack the infoDetailLevel for redirecting warnings to stderr for these cases.v2006Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1712COMP: compilation issues with Gcc-4.8.52020-06-10T05:11:53ZPrashant SonakarCOMP: compilation issues with Gcc-4.8.5The code seems to break with segmentation fault with commit:
https://develop.openfoam.com/Development/openfoam/-/commit/435957ac871d6929edcd05b4fb275def981113ac
@markThe code seems to break with segmentation fault with commit:
https://develop.openfoam.com/Development/openfoam/-/commit/435957ac871d6929edcd05b4fb275def981113ac
@markhttps://develop.openfoam.com/Development/openfoam/-/issues/1711Warning message while running chtMultiRegionTwoPhaseEulerFoam:2020-06-05T14:34:05ZPawan GhildiyalWarning message while running chtMultiRegionTwoPhaseEulerFoam:Hello @andy @Sergio
After pulling the latest code from dev branch and fresh recompilation,following warnign message is being thrown once chtMultiRegionTwoPhaseEulerFoam is launched. Executable work fine though and simulation proceed w...Hello @andy @Sergio
After pulling the latest code from dev branch and fresh recompilation,following warnign message is being thrown once chtMultiRegionTwoPhaseEulerFoam is launched. Executable work fine though and simulation proceed without any issue.
**Case** : tutorials/heatTransfer/chtMultiRegionTwoPhaseEulerFoam/solidQuenching2D
`Duplicate entry laminar in runtime selection table TurbulenceModel
#0 /home/buzz2/pawan/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam5error14safePrintStackERSo+0x2b) [0x7fd797bf767b]
#1 /home/buzz2/pawan/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libtwoPhaseReactingTurbulenceModels.so(_ZN4Foam15TurbulenceModelINS_14GeometricFieldIdNS_12fvPatchFieldENS_7volMeshEEES4_NS_27compressibleTurbulenceModelENS_10phaseModelEE31adddictionaryConstructorToTableINS_12laminarModelINS_18ThermalDiffusivityINS_32PhaseCompressibleTurbulenceModelIS6_EEEEEEEC2ERKNS_4wordE+0xd3) [0x7fd79cee51c3]
#2 /home/buzz2/pawan/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libtwoPhaseReactingTurbulenceModels.so(+0x9ce20) [0x7fd79ced2e20]
#3 /lib64/ld-linux-x86-64.so.2(+0xfbfa) [0x7fd79e57dbfa]
#4 /lib64/ld-linux-x86-64.so.2(+0xfd06) [0x7fd79e57dd06]
#5 /lib64/ld-linux-x86-64.so.2(+0xeda) [0x7fd79e56eeda]
Duplicate entry RAS in runtime selection table TurbulenceModel
#0 /home/buzz2/pawan/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam5error14safePrintStackERSo+0x2b) [0x7fd797bf767b]
#1 /home/buzz2/pawan/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libtwoPhaseReactingTurbulenceModels.so(_ZN4Foam15TurbulenceModelINS_14GeometricFieldIdNS_12fvPatchFieldENS_7volMeshEEES4_NS_27compressibleTurbulenceModelENS_10phaseModelEE31adddictionaryConstructorToTableINS_8RASModelINS_15EddyDiffusivityINS_18ThermalDiffusivityINS_32PhaseCompressibleTurbulenceModelIS6_EEEEEEEEEC2ERKNS_4wordE+0xd3) [0x7fd79cee52d3]
#2 /home/buzz2/pawan/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libtwoPhaseReactingTurbulenceModels.so(+0x9cec6) [0x7fd79ced2ec6]
#3 /lib64/ld-linux-x86-64.so.2(+0xfbfa) [0x7fd79e57dbfa]
#4 /lib64/ld-linux-x86-64.so.2(+0xfd06) [0x7fd79e57dd06]
#5 /lib64/ld-linux-x86-64.so.2(+0xeda) [0x7fd79e56eeda]
Duplicate entry LES in runtime selection table TurbulenceModel
#0 /home/buzz2/pawan/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam5error14safePrintStackERSo+0x2b) [0x7fd797bf767b]
#1 /home/buzz2/pawan/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libtwoPhaseReactingTurbulenceModels.so(_ZN4Foam15TurbulenceModelINS_14GeometricFieldIdNS_12fvPatchFieldENS_7volMeshEEES4_NS_27compressibleTurbulenceModelENS_10phaseModelEE31adddictionaryConstructorToTableINS_8LESModelINS_15EddyDiffusivityINS_18ThermalDiffusivityINS_32PhaseCompressibleTurbulenceModelIS6_EEEEEEEEEC2ERKNS_4wordE+0xd3) [0x7fd79cee53e3]
#2 /home/buzz2/pawan/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libtwoPhaseReactingTurbulenceModels.so(+0x9cf6c) [0x7fd79ced2f6c]
#3 /lib64/ld-linux-x86-64.so.2(+0xfbfa) [0x7fd79e57dbfa]
#4 /lib64/ld-linux-x86-64.so.2(+0xfd06) [0x7fd79e57dd06]
#5 /lib64/ld-linux-x86-64.so.2(+0xeda) [0x7fd79e56eeda]
Duplicate entry Stokes in runtime selection table laminarModel
#0 /home/buzz2/pawan/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam5error14safePrintStackERSo+0x2b) [0x7fd797bf767b]
#1 /home/buzz2/pawan/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libtwoPhaseReactingTurbulenceModels.so(+0x9d012) [0x7fd79ced3012]
#2 /lib64/ld-linux-x86-64.so.2(+0xfbfa) [0x7fd79e57dbfa]
#3 /lib64/ld-linux-x86-64.so.2(+0xfd06) [0x7fd79e57dd06]
#4 /lib64/ld-linux-x86-64.so.2(+0xeda) [0x7fd79e56eeda]
Duplicate entry kEpsilon in runtime selection table RASModel
#0 /home/buzz2/pawan/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam5error14safePrintStackERSo+0x2b) [0x7fd797bf767b]
#1 /home/buzz2/pawan/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libtwoPhaseReactingTurbulenceModels.so(_ZN4Foam8RASModelINS_15EddyDiffusivityINS_18ThermalDiffusivityINS_32PhaseCompressibleTurbulenceModelINS_10phaseModelEEEEEEEE31adddictionaryConstructorToTableINS_9RASModels8kEpsilonIS7_EEEC2ERKNS_4wordE+0xd3) [0x7fd79cee5f63]
#2 /home/buzz2/pawan/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libtwoPhaseReactingTurbulenceModels.so(+0x9d0b8) [0x7fd79ced30b8]
#3 /lib64/ld-linux-x86-64.so.2(+0xfbfa) [0x7fd79e57dbfa]
#4 /lib64/ld-linux-x86-64.so.2(+0xfd06) [0x7fd79e57dd06]
#5 /lib64/ld-linux-x86-64.so.2(+0xeda) [0x7fd79e56eeda]
Duplicate entry kOmegaSST in runtime selection table RASModel
#0 /home/buzz2/pawan/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam5error14safePrintStackERSo+0x2b) [0x7fd797bf767b]
#1 /home/buzz2/pawan/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libtwoPhaseReactingTurbulenceModels.so(_ZN4Foam8RASModelINS_15EddyDiffusivityINS_18ThermalDiffusivityINS_32PhaseCompressibleTurbulenceModelINS_10phaseModelEEEEEEEE31adddictionaryConstructorToTableINS_9RASModels9kOmegaSSTIS7_EEEC2ERKNS_4wordE+0xd3) [0x7fd79cee6073]
#2 /home/buzz2/pawan/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libtwoPhaseReactingTurbulenceModels.so(+0x9d15e) [0x7fd79ced315e]
#3 /lib64/ld-linux-x86-64.so.2(+0xfbfa) [0x7fd79e57dbfa]
#4 /lib64/ld-linux-x86-64.so.2(+0xfd06) [0x7fd79e57dd06]
#5 /lib64/ld-linux-x86-64.so.2(+0xeda) [0x7fd79e56eeda]
Duplicate entry Smagorinsky in runtime selection table LESModel
#0 /home/buzz2/pawan/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam5error14safePrintStackERSo+0x2b) [0x7fd797bf767b]
#1 /home/buzz2/pawan/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libtwoPhaseReactingTurbulenceModels.so(_ZN4Foam8LESModelINS_15EddyDiffusivityINS_18ThermalDiffusivityINS_32PhaseCompressibleTurbulenceModelINS_10phaseModelEEEEEEEE31adddictionaryConstructorToTableINS_9LESModels11SmagorinskyIS7_EEEC2ERKNS_4wordE+0xd3) [0x7fd79cee72e3]
#2 /home/buzz2/pawan/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libtwoPhaseReactingTurbulenceModels.so(+0x9d49c) [0x7fd79ced349c]
#3 /lib64/ld-linux-x86-64.so.2(+0xfbfa) [0x7fd79e57dbfa]
#4 /lib64/ld-linux-x86-64.so.2(+0xfd06) [0x7fd79e57dd06]
#5 /lib64/ld-linux-x86-64.so.2(+0xeda) [0x7fd79e56eeda]
Duplicate entry kEqn in runtime selection table LESModel
#0 /home/buzz2/pawan/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam5error14safePrintStackERSo+0x2b) [0x7fd797bf767b]
#1 /home/buzz2/pawan/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libtwoPhaseReactingTurbulenceModels.so(_ZN4Foam8LESModelINS_15EddyDiffusivityINS_18ThermalDiffusivityINS_32PhaseCompressibleTurbulenceModelINS_10phaseModelEEEEEEEE31adddictionaryConstructorToTableINS_9LESModels4kEqnIS7_EEEC1ERKNS_4wordE+0xd3) [0x7fd79cee73f3]
#2 /home/buzz2/pawan/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libtwoPhaseReactingTurbulenceModels.so(+0x9d542) [0x7fd79ced3542]
#3 /lib64/ld-linux-x86-64.so.2(+0xfbfa) [0x7fd79e57dbfa]
#4 /lib64/ld-linux-x86-64.so.2(+0xfd06) [0x7fd79e57dd06]
#5 /lib64/ld-linux-x86-64.so.2(+0xeda) [0x7fd79e56eeda]
`https://develop.openfoam.com/Development/openfoam/-/issues/1710foamFormatConvert -overwrite option2020-05-20T16:06:34ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfoamFormatConvert -overwrite option### Functionality to add/problem to solve
If used with `-fileHandler collated` have option (-overwrite ?) to remove the original processor[0-9]* directories (since all information already inside the processorsDDD directory). For any oth...### Functionality to add/problem to solve
If used with `-fileHandler collated` have option (-overwrite ?) to remove the original processor[0-9]* directories (since all information already inside the processorsDDD directory). For any other action (e.g. ascii->binary) the foamFormatConvert overwrites the input file anyway.https://develop.openfoam.com/Development/openfoam/-/issues/1709improve flexibility of external wall temperature/heat flux2020-05-25T21:08:18ZMark OLESENimprove flexibility of external wall temperature/heat flux- make some components Function1 or PatchFunction1
- add expressions and/or coded versions
@Mattijs @sergio- make some components Function1 or PatchFunction1
- add expressions and/or coded versions
@Mattijs @sergiov2006https://develop.openfoam.com/Development/openfoam/-/issues/1708construct edge/fixed list from subset2020-05-22T12:24:32ZMark OLESENconstruct edge/fixed list from subset@Mattijs@MattijsMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1707RPM packages on the openSUSE build service do not have functional wmake2020-05-22T22:29:22ZAlberto PassalacquaRPM packages on the openSUSE build service do not have functional wmakeInstalling the openSUSE packages from the openSUSE science repository for Leap 15.1 does not seem to provide a working wmake.
This can be reproduced both using the openfoam1912 and sourcing /usr/lib/openfoam/openfoam1912/etc/bashrcInstalling the openSUSE packages from the openSUSE science repository for Leap 15.1 does not seem to provide a working wmake.
This can be reproduced both using the openfoam1912 and sourcing /usr/lib/openfoam/openfoam1912/etc/bashrchttps://develop.openfoam.com/Development/openfoam/-/issues/1706incorrect startLineNumber for primitiveEntry2020-05-15T14:38:59ZMark OLESENincorrect startLineNumber for primitiveEntryGood catch @MattijsGood catch @MattijsMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1705propose cgal update2020-06-05T16:29:40ZMark OLESENpropose cgal updateDuring recent builds, hit changes in the iterators (6691e6563c8d3d) for CGAL-4.14 and later.
While testing these, discovered that CGAL > 5.0 defaults to header-only builds. The current wmake/scripts do not detect this, nor do the wmake/...During recent builds, hit changes in the iterators (6691e6563c8d3d) for CGAL-4.14 and later.
While testing these, discovered that CGAL > 5.0 defaults to header-only builds. The current wmake/scripts do not detect this, nor do the wmake/rules properly handle this either. The build services are not yet breaking, but it is probably just a matter of a few more weeks/months before bleeding edge systems like spack start breaking.
For future-proofing,
- need to accept systems with CGAL headers and without CGAL libs as being OK (header-only)
- refine wmake rules for headers/library versions of CGAL
Transition. Propose bumping CGAL from 4.9.1 (current) to something slightly newer (eg, leap15.1 has 4.12.2) so that we avoid any version clashes with older ThirdParty installations. Adjust the third-party makeCGAL to use headers-only for OpenFOAM 2006. This also eliminates some gmp/mpfr dependencies.
@andy @Prashant Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1704issue with refineHexMesh running in parallel with cyclic boundary conditions2021-07-07T08:24:13Ztq1203issue with refineHexMesh running in parallel with cyclic boundary conditions<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be ...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
When the domain is split among processors such that cells on cyclic patches are not on the same processor, refineHexMesh cannot be used.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Use cyclic boundary conditions and set decomposeParDict such that the cells which are on cyclic boundaries are not on the same processor.
Run refineHexMesh on a cellset.
Observe the error of the form
"Cannot find point in pts1 matching point ### coord:(## ## ##) in pts0 when using tolerance ##" in the refineHexMesh log file.
### 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
-->
If your domain is a cube, and the patches perpendicular to the x axis are cyclic, then you cannot split the domain into sections along the x direction (e.g. (4 1 1) in decompseParDict). It seems like you can however split the domain along the y or z direction, since the cells with the cyclic faces will be on the same processor (e.g. (1 4 1) in decompseParDict).
### What is the expected *correct* behavior?
<!-- What you should see instead -->
It would be nice if there was either a usage warning in refineHexMesh with cyclic boundary conditions, or if the mesh splitting and cell face assignments could be worked out so that it was possible to use refineHexMesh in parallel with cyclic boundary conditions.
### 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.
-->
Here is a sample of the refineHexMesh log file
```
[3] Cannot find point in pts1 matching point 131 coord:(0.015625 0.5 -0.0166667) in pts0 when using tolerance 2.28455e-06
[3] Searching started from:0 in pts1
[3] Compared coord: (0.015625 -0.5 -0.0166667) at index 0 with difference to point 1
[3] Cannot find point in pts1 matching point 132 coord:(0.046875 0.5 -0.0166667) in pts0 when using tolerance 2.28455e-06
[3] Searching started from:0 in pts1
[3] Compared coord: (0.015625 -0.5 -0.0166667) at index 0 with difference to point 1.00049
[3] Compared coord: (0.046875 -0.5 -0.0166667) at index 1 with difference to point 1
[3] Cannot find point in pts1 matching point 15 coord:(0.015625 0.5 -0.05) in pts0 when using tolerance 2.28455e-06
[3] Searching started from:1 in pts1
[3] Compared coord: (0.046875 -0.5 -0.0166667) at index 1 with difference to point 1.00104
[3] Compared coord: (0.015625 -0.5 -0.05) at index 2 with difference to point 1
[3] Cannot find point in pts1 matching point 133 coord:(0.046875 0.5 -0.05) in pts0 when using tolerance 2.28455e-06
[3] Searching started from:2 in pts1
[3] Compared coord: (0.015625 -0.5 -0.05) at index 2 with difference to point 1.00049
[3] Compared coord: (0.046875 -0.5 -0.05) at index 3 with difference to point 1
```
### 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 : v1806
OS: centos
### 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 now, if you keep the cyclic cells on the same processor it seems to work.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/ThirdParty-common/-/issues/50error to compile ./makeParaView2020-06-10T15:52:37ZJoaquin Osseserror to compile ./makeParaViewI'm following all the instruction in the OpenFOAM webpage to install it on Ubuntu 20.04 version
First I did this as the instructions says;
cd $WM_THIRD_PARTY_DIR
./makeParaView
And I received this message;
./makeParaView: 64: local:...I'm following all the instruction in the OpenFOAM webpage to install it on Ubuntu 20.04 version
First I did this as the instructions says;
cd $WM_THIRD_PARTY_DIR
./makeParaView
And I received this message;
./makeParaView: 64: local: -DWM_DP: bad variable name
./makeParaView: 64: -DOPENFOAM: bad variable name
Thanks