Development issueshttps://develop.openfoam.com/groups/Development/-/issues2019-07-21T22:56:27Zhttps://develop.openfoam.com/Development/ThirdParty-common/-/issues/4CGAL wmake sets incorrect paths to MPFR and GMP2019-07-21T22:56:27ZSergiy KhanCGAL wmake sets incorrect paths to MPFR and GMPWhen compiling OpenFOAM v1606, the ./makeGcc script gets the MPFR and GMP libraries placed in the lib64/ sub-directory, while `$WM_PROJECT_DIR/wmake/rules/General/CGAL` sets paths explicitly to /lib.
`$ ls -al $WM_THIRD_PARTY_DIR/plat...When compiling OpenFOAM v1606, the ./makeGcc script gets the MPFR and GMP libraries placed in the lib64/ sub-directory, while `$WM_PROJECT_DIR/wmake/rules/General/CGAL` sets paths explicitly to /lib.
`$ ls -al $WM_THIRD_PARTY_DIR/platforms/linux64/gmp-5.1.2
include
lib64
share`
`$ ls -al $WM_THIRD_PARTY_DIR/platforms/linux64/mpfr-3.1.2
include
lib64
share`
`$ cat $WM_PROJECT_DIR/wmake/rules/General/CGAL
CGAL_INC = \
-I$(CGAL_ARCH_PATH)/include \
-I$(MPFR_ARCH_PATH)/include \
-I$(GMP_ARCH_PATH)/include \
-I$(BOOST_ARCH_PATH)/include`
`CGAL_LIBS = \
-L$(MPFR_ARCH_PATH)/lib \
-L$(GMP_ARCH_PATH)/lib \
-L$(BOOST_ARCH_PATH)/lib \
-L$(CGAL_ARCH_PATH)/lib \
-lCGAL \
-lmpfr`
The simple fix is to create symlinks like so:
`$ cd $WM_THIRD_PARTY_DIR
$ (cd platforms/linux64/gmp-5.1.2; ln -s lib64 lib)
$ (cd platforms/linux64/mpfr-3.1.2; ln -s lib64 lib)`Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/475Where are the mass transfer source terms in phase fraction equation in reacti...2019-01-08T14:44:40ZAdminWhere are the mass transfer source terms in phase fraction equation in reactingEulerFoam solver?In reactingEulerFoam from OF3.0.1, there are mass transfer between different phases. The phase fraction is estentially the continuity equations, and so there must be some source terms accounting for mass change of individual phases. In f...In reactingEulerFoam from OF3.0.1, there are mass transfer between different phases. The phase fraction is estentially the continuity equations, and so there must be some source terms accounting for mass change of individual phases. In fluid.solve(), actually I did not see these terms appearring in the RHS of the phase fraction equations. Is this a bug? or I dismiss something in the code?
BTW, the fluid.solve(); is from:
> twoPhaseSystem/twoPhaseSystem.C
Thank you.https://develop.openfoam.com/Development/ThirdParty-common/-/issues/3makeCGAL script not present in ThirdParty-v1606+.tgz2019-07-21T22:56:27ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commakeCGAL script not present in ThirdParty-v1606+.tgzAllwmake refers to ./makeCGAL but script is not included in pack.Allwmake refers to ./makeCGAL but script is not included in pack.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/476Absorptivity in constant/boundaryRadiationProperties (e.g. hotRadiationRoom)2017-05-18T16:12:16ZAdminAbsorptivity in constant/boundaryRadiationProperties (e.g. hotRadiationRoom)I guess the absorptivity in constant/boundaryRadiationProperties not to be used in this case.
I invalidated it and then executed this case, but no problems occurred.
Is this parameter really necessary to execute this case?
--
...I guess the absorptivity in constant/boundaryRadiationProperties not to be used in this case.
I invalidated it and then executed this case, but no problems occurred.
Is this parameter really necessary to execute this case?
--
Build: plus- e 6 c b e 0 b 1 1 9 2 3, v1606+https://develop.openfoam.com/Development/ThirdParty-common/-/issues/2unset shell functions failing in dash2019-07-21T22:56:27ZMark OLESENunset shell functions failing in dashneed "unset -f" instead of a plain "unset" to properly unset functions.
Eg, in makeCGAL
unset -f _foamAddLib ....
@matej @andy need "unset -f" instead of a plain "unset" to properly unset functions.
Eg, in makeCGAL
unset -f _foamAddLib ....
@matej @andy Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/477BUG: polyMesh construction from IOobject does not use instance. (it uses the ...2024-01-10T16:22:02ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comBUG: polyMesh construction from IOobject does not use instance. (it uses the Time::timeName() instead)Finds mesh files using findInstance which starts from timeName()Finds mesh files using findInstance which starts from timeName()Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/ThirdParty-common/-/issues/1scotch-6.0.4 build fails2019-07-21T22:56:27ZMark OLESENscotch-6.0.4 build failsSee https://gforge.inria.fr/tracker/index.php?func=detail&aid=19407&group_id=248&atid=1079See https://gforge.inria.fr/tracker/index.php?func=detail&aid=19407&group_id=248&atid=1079Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/478surface sample writing using Ostream2020-01-16T18:08:52ZMark OLESENsurface sample writing using OstreamThese should largely be using OSstream or even std::ostream since the output target is normally a file etc.These should largely be using OSstream or even std::ostream since the output target is normally a file etc.v1712Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/ThirdParty-common/-/issues/45warn instead of fail for missing scotch2020-06-26T08:08:24ZMark OLESENwarn instead of fail for missing scotchAs @johan_roenby suggested, warn instead of failing with a missing scotch.
Preferably also provide either a download location or download the required files.As @johan_roenby suggested, warn instead of failing with a missing scotch.
Preferably also provide either a download location or download the required files.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/479non-virtual methods on streams2017-07-08T09:17:18ZMark OLESENnon-virtual methods on streamsOFstream::name() and IFstream::name() are (intentionally/non-intentionally?) non-virtual.
- Implemented as virtual in Istream, ISstream, Ostream, OSstream, but not in IFstream, OFstream, ITstream.OFstream::name() and IFstream::name() are (intentionally/non-intentionally?) non-virtual.
- Implemented as virtual in Istream, ISstream, Ostream, OSstream, but not in IFstream, OFstream, ITstream.v1712Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/ThirdParty-common/-/issues/46add pkgconfig management/handling to makePETSC2020-06-26T08:05:52ZMark OLESENadd pkgconfig management/handling to makePETSCRelated to suggestion by @szampini - we should address pkgconfig contents when using makePETSC (as per the makeQT handling) to ensure things are movableRelated to suggestion by @szampini - we should address pkgconfig contents when using makePETSC (as per the makeQT handling) to ensure things are movableMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/480pointConstraints don't handle coupled points on inside of patch2017-06-29T20:38:04ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.compointConstraints don't handle coupled points on inside of patchThe constraint mechanism (for point motion) assumes that all coupled points are on the outside of 'normal' patches. Very occasionally this is not the case and it causes out-of-bounds access to the list of constraints (patchPatchPointCons...The constraint mechanism (for point motion) assumes that all coupled points are on the outside of 'normal' patches. Very occasionally this is not the case and it causes out-of-bounds access to the list of constraints (patchPatchPointConstraints_)Version v1706https://develop.openfoam.com/Development/openfoam/-/issues/481BlockMesh: Implicit initialization of member overwrites previous initialization2017-06-29T20:38:04ZAdminBlockMesh: Implicit initialization of member overwrites previous initializationin src/mesh/blockMesh/blockEdges/arcEdge/arcEdge.H the members are declared in the following order:
```
point p1_, p2_, p3_;
cylindricalCS cs_;
scalar angle_;
scalar radius_;
```
in the constructor calcAngle() ...in src/mesh/blockMesh/blockEdges/arcEdge/arcEdge.H the members are declared in the following order:
```
point p1_, p2_, p3_;
cylindricalCS cs_;
scalar angle_;
scalar radius_;
```
in the constructor calcAngle() is called which sets angle_ and radius_.
If scalar is anything but a primitive type the default constructor of angle_ and radius_ will be called after calcAngle returns, thus overwriting its results.
```
Foam::blockEdges::arcEdge::arcEdge
(
const pointField& points,
const label start,
const label end,
const point& pMid
)
:
blockEdge(points, start, end),
p1_(points_[start_]),
p2_(pMid),
p3_(points_[end_]),
cs_(calcAngle())
{}
```
The easy fix is to switch the declaration of the members in the.H file.
The more sane fix probably is to not alter any member variables before initialization is done.Version v1706https://develop.openfoam.com/Development/openfoam/-/issues/482-dict argument assumes name starting with './' is relative to the case (inste...2017-07-19T11:59:41ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.com-dict argument assumes name starting with './' is relative to the case (instead of pwd) directoryv1712Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/ThirdParty-common/-/issues/48Compilation of paraview5.6.3 does not start.2020-07-22T11:05:07Zsariew8Compilation of paraview5.6.3 does not start.$ ~/OpenFOAM/ThirdParty-common$ ./makeParaView \
./makeParaView: 64: local: -DWM_DP: bad variable name \
./makeParaView: 64: ./makeParaView: -DOPENFOAM: bad variable name
did i make another mistakes?$ ~/OpenFOAM/ThirdParty-common$ ./makeParaView \
./makeParaView: 64: local: -DWM_DP: bad variable name \
./makeParaView: 64: ./makeParaView: -DOPENFOAM: bad variable name
did i make another mistakes?Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/483strange ordering for geometricSurfacePatch Istream constructor2020-03-13T14:23:53ZMark OLESENstrange ordering for geometricSurfacePatch Istream constructor`geometricSurfacePatch(Istream& is, const label index)` expects type,name but the `<<` and `>>` operators both have name,type
Could result in unexpected behaviour somewhere.`geometricSurfacePatch(Istream& is, const label index)` expects type,name but the `<<` and `>>` operators both have name,type
Could result in unexpected behaviour somewhere.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/ThirdParty-common/-/issues/49issues with ptscotch and mingw2020-06-26T08:12:25ZMark OLESENissues with ptscotch and mingwAppears that we might need the following in the Makefile:
```
CCD = gcc -I$(MPI_ARCH_PATH)/include
```
@PawanAppears that we might need the following in the Makefile:
```
CCD = gcc -I$(MPI_ARCH_PATH)/include
```
@PawanMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/484PackedList is sometimes non-lazy2017-06-29T20:38:04ZMark OLESENPackedList is sometimes non-lazyThe `unset()` method never auto-vivifies, whereas the `set()` method *always* auto-vivifies. In the case where `set()` is called with a zero for its argument - eg, `set(index, 0)` - this should behave identically to an `unset()` and not ...The `unset()` method never auto-vivifies, whereas the `set()` method *always* auto-vivifies. In the case where `set()` is called with a zero for its argument - eg, `set(index, 0)` - this should behave identically to an `unset()` and not auto-vivify out-of-range entries.Version v1706Mark OLESENMark OLESENhttps://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
Thankshttps://develop.openfoam.com/Development/openfoam/-/issues/485Style : SHM prints extra info2017-06-29T20:38:03ZPrashant SonakarStyle : SHM prints extra infoPerhaps nonStringConnected.obj dumping should be active when debug mode?
@andyPerhaps nonStringConnected.obj dumping should be active when debug mode?
@andyVersion v1706Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.com