openfoam issueshttps://develop.openfoam.com/Development/openfoam/-/issues2024-01-20T15:12:18Zhttps://develop.openfoam.com/Development/openfoam/-/issues/3066masterUncollatedFileOperation compilation error on 23122024-01-20T15:12:18ZMatej FormanmasterUncollatedFileOperation compilation error on 2312### compilation problem.
I have: fetched the 2312 source code from master.
I have set my etc-darwin to take most of the libs fro the system (homebrew).
Compilation run with -j -l options.
``
Opt/src/OpenFOAM/primitives/ints/int32/int3...### compilation problem.
I have: fetched the 2312 source code from master.
I have set my etc-darwin to take most of the libs fro the system (homebrew).
Compilation run with -j -l options.
``
Opt/src/OpenFOAM/primitives/ints/int32/int32IO.o
make: *** [/Volumes/ofdisk/OpenFOAM-v2312/build/darwin64ClangDPInt32Opt/src/OpenFOAM/global/fileOperations/masterUncollatedFileOperation/masterUncollatedFileOperation.o] Error 1
make: *** Waiting for unfinished jobs....
Done logging to 'log.darwin64ClangDPInt32Opt'
``
my prefs.sh:
`
export projectDir="/Volumes/OFdisk/OpenFOAM-v2312"
export FOAM_CONFIG_ETC=etc-darwin
export WM_COMPILER_TYPE=system
export WM_COMPILER=Clang
export WM_PRECISION_OPTION=DP
export WM_LABEL_SIZE=32
export WM_COMPILE_OPTION=Opt
export WM_MPLIB=SYSTEMOPENMPI
export SCOTCH_VERSION=scotch-system
export fftw_version=fftw-system
export boost_version=boost-system
export cgal_version=cgal-system
export SCOTCH_ARCH_PATH=/usr/local/Cellar/scotch/7.0.4 ## 6.1.1 # run brew info scotch
export FFTW_ARCH_PATH=/usr/local/Cellar/fftw/3.3.10_1
export MPI_ARCH_PATH=/usr/local/Cellar/open-mpi/4.1.5
export BOOST_ARCH_PATH=/usr/local/Cellar/boost/1.82.0_1
export CGAL_ARCH_PATH=/usr/local/Cellar/cgal/5.6
export LDFLAGS="-L/usr/local/opt/readline/lib"
export CPPFLAGS="-I/usr/local/opt/readline/include"
export CXXFLAGS="-I/usr/local/Cellar/flex/2.6.4_2/include"
export FOAM_EXTRA_CXXFLAGS="-I/usr/local/Cellar/flex/2.6.4_2/include -DBOOST_MATH_DISABLE_FLOAT128"
export VTK_DIR="/usr/local/Cellar/vtk/9.2.5_1" # for runTimePostprocessing FO
export CMAKE_INCLUDE_PATH="/usr/local/Cellar/flex/2.6.4_2/include"
export CMAKE_LIBRARY_PATH="/usr/local/Cellar/flex/2.6.4_2/lib"
`Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/3015label 64 compilation failing2023-11-06T12:03:54ZPawan Ghildiyallabel 64 compilation failingHello,
While compiling the branch update-redistributePar with 64 label size, I encountered following error messagess
`M_DP -DWM_LABEL_SIZE=64 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof...Hello,
While compiling the branch update-redistributePar with 64 label size, I encountered following error messagess
`M_DP -DWM_LABEL_SIZE=64 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -Wno-attributes -Wno-unknown-pragmas -O3 -DNoRepository -ftemplate-depth-100 -I/home/pawan/OpenFOAM/OpenFOAM-v23.06-23W45-Redhat7.8/OpenFOAM-v23.06-23W45/build/linux64Gcc85DPInt64Opt/src/OpenFOAM -DHAVE_LIBZ -iquote. -IlnInclude -I/home/pawan/OpenFOAM/OpenFOAM-v23.06-23W45-Redhat7.8/OpenFOAM-v23.06-23W45/src/OpenFOAM/lnInclude -I/home/pawan/OpenFOAM/OpenFOAM-v23.06-23W45-Redhat7.8/OpenFOAM-v23.06-23W45/src/OSspecific/POSIX/lnInclude -fPIC -c primitives/chars/lists/charList.C -o /home/pawan/OpenFOAM/OpenFOAM-v23.06-23W45-Redhat7.8/OpenFOAM-v23.06-23W45/build/linux64Gcc85DPInt64Opt/src/OpenFOAM/primitives/chars/lists/charList.o
global/fileOperations/fileOperation/fileOperation.C:83:47: error: conflicting declaration 'Foam::label Foam::fileOperation::nProcsFilter_'
Foam::label Foam::fileOperation::nProcsFilter_(-1);
^
In file included from global/fileOperations/fileOperation/fileOperation.C:29:
global/fileOperations/fileOperation/fileOperation.H:158:20: note: previous declaration as 'int Foam::fileOperation::nProcsFilter_'
static int nProcsFilter_;
^~~~~~~~~~~~~`v2306Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2784Updates for missing library linkage (mingw, gold etc)2023-10-28T14:03:15ZMark OLESENUpdates for missing library linkage (mingw, gold etc)v2306Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2287mismatch in autoMap function?2021-12-10T13:05:39ZMark OLESENmismatch in autoMap function?Compiler warnings for newly added code:
```
filmPyrolysisRadiativeCoupledMixedFvPatchScalarField.H:222:26: warning: 'Foam::filmPyrolysisRadiativeCoupledMixedFvPatchScalarField::autoMap' hides overloaded virtual function [-Woverloaded-vi...Compiler warnings for newly added code:
```
filmPyrolysisRadiativeCoupledMixedFvPatchScalarField.H:222:26: warning: 'Foam::filmPyrolysisRadiativeCoupledMixedFvPatchScalarField::autoMap' hides overloaded virtual function [-Woverloaded-virtual]
virtual void autoMap
^
temperatureCoupledBase.H:205:22: note: hidden overloaded virtual function 'Foam::temperatureCoupledBase::autoMap' declared here: type mismatch at 1st parameter ('const Foam::FieldMapper &' vs 'const Foam::fvPatchFieldMapper &')
virtual void autoMap
^
filmPyrolysisRadiativeCoupledMixedFvPatchScalarField.H:228:26: warning: 'Foam::filmPyrolysisRadiativeCoupledMixedFvPatchScalarField::rmap' hides overloaded virtual function [-Woverloaded-virtual]
virtual void rmap
^
temperatureCoupledBase.H:211:22: note: hidden overloaded virtual function 'Foam::temperatureCoupledBase::rmap' declared here: type mismatch at 1st parameter ('const Foam::temperatureCoupledBase &' vs 'const fvPatchField<Foam::scalar> &' (aka 'const fvPatchField<double> &'))
virtual void rmap
^
```
There are a few more, but this is the gist of it. Warnings raised by clang-13v2112Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2254update of third-party packages for v21122022-06-27T09:34:39ZMark OLESENupdate of third-party packages for v2112Currently:
- ADIOS2-2.6.0
- CGAL-4.12.2
- ParaView-v5.9.1
- boost_1_66_0
- fftw-3.3.7
- openmpi-4.0.3
- scotch_6.1.0
- kahip-2.12
My thoughts:
- ADIOS: could probably bump to 2.7.1 (Jan 2021)
- CGAL: @andy is conservative there (been b...Currently:
- ADIOS2-2.6.0
- CGAL-4.12.2
- ParaView-v5.9.1
- boost_1_66_0
- fftw-3.3.7
- openmpi-4.0.3
- scotch_6.1.0
- kahip-2.12
My thoughts:
- ADIOS: could probably bump to 2.7.1 (Jan 2021)
- CGAL: @andy is conservative there (been bitten badly in the past), but can try moving to the latest bugfix 4.x version (4.14.2 - Nov 2019). Cannot/should not move to 5.x since this requires c++14 and thus breaks installation on centos7, SUSE 12 etc.
- ParaView: definitely want paraview 5.10 which has our various changes in it. Currently in a release candidate stage and should be finished in time.
- boost: no opinion. openSUSE still ships with 1_66_0 as well
- fftw: 3.3.10 bugfix version
- openmpi: either 4.0.6 as bugfix for the 4.0.x or try with 4.1.1 (latest stable)
- scotch: no change
- kahip: currently at 3.11 - need to see what has improved.
@Development : Wanted to get people's opinions about updating what we bundle as _ThirdParty_.
Do we drop shipping paraview sources anytime soon?
EDITS:
- paraview now at 5.10.0-RC2 (22 Nov)v2112https://develop.openfoam.com/Development/openfoam/-/issues/2147Compilation - linker issue2022-06-24T13:19:22ZVojtech BetakCompilation - linker issueDear developers,
I observe some compilation - linker issue when I am compiling OpenFOAM-v2106 on openSUSE Tumbelweed. The src directory is compiled without significant problems but the applications directory is not possible to compile a...Dear developers,
I observe some compilation - linker issue when I am compiling OpenFOAM-v2106 on openSUSE Tumbelweed. The src directory is compiled without significant problems but the applications directory is not possible to compile and end with the following error message
```
/usr/lib64/gcc/x86_64-suse-linux/11/../../../../x86_64-suse-linux/bin/ld: /home/betak/OpenFOAM/OpenFOAM-v2106/platforms/linux64GccDPInt32Opt/lib/libcompressibleTurbulenceModels.so: undefined reference to `Foam::fv::convectionScheme<Foam::SymmTensor<double> >::IstreamConstructorTablePtr_[abi:cxx11]'
/usr/lib64/gcc/x86_64-suse-linux/11/../../../../x86_64-suse-linux/bin/ld: /home/betak/OpenFOAM/OpenFOAM-v2106/platforms/linux64GccDPInt32Opt/lib/libfiniteVolume.so: undefined reference to `Foam::pointPatchField<Foam::SphericalTensor<double> >::dictionaryConstructorTablePtr_[abi:cxx11]'
/usr/lib64/gcc/x86_64-suse-linux/11/../../../../x86_64-suse-linux/bin/ld: /home/betak/OpenFOAM/OpenFOAM-v2106/platforms/linux64GccDPInt32Opt/lib/libreactionThermophysicalModels.so: undefined reference to `Foam::Reaction<Foam::polynomialTransport<Foam::species::thermo<Foam::hPolynomialThermo<Foam::icoPolynomial<Foam::specie, 8>, 8>, Foam::sensibleEnthalpy>, 8> >::dictionaryConstructorTablePtr_[abi:cxx11]'
```
To verify this issue, I have tried to compile an older version of OpenFOAM(OpenFOAM-v2012) and this compilation was successful
Thank a lot
With regards
Vojtech BetakMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2005objectiveManager::write hides overloaded virtual function2024-01-11T18:45:46ZMark OLESENobjectiveManager::write hides overloaded virtual functionclang complains about the `write()` method in objectiveManager, which masks the regIOobject write method.
possible corrections:
- a new name such as writeObjectives or something
- mark with 'using regIOobject::write' ?
@vaggelispclang complains about the `write()` method in objectiveManager, which masks the regIOobject write method.
possible corrections:
- a new name such as writeObjectives or something
- mark with 'using regIOobject::write' ?
@vaggelisphttps://develop.openfoam.com/Development/openfoam/-/issues/1807wmake findObjectDir fails for out-of-source2020-09-07T16:28:39ZMark OLESENwmake findObjectDir fails for out-of-sourceMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1757dash bug with string expansion and assignment of default values2020-11-26T13:55:23ZMark OLESENdash bug with string expansion and assignment of default valuesNoticed when compiling OpenFOAM-v2006 modules with ubuntu _bionic_ (18.04) that the module prefix is not being correctly set. Seems to be a weird bug in the `dash` shell expansions.
Starting from any non-root directory
```
echo "$PWD"
-...Noticed when compiling OpenFOAM-v2006 modules with ubuntu _bionic_ (18.04) that the module prefix is not being correctly set. Seems to be a weird bug in the `dash` shell expansions.
Starting from any non-root directory
```
echo "$PWD"
-> /home/user/openfoam/BuildEnv/scratch
```
dash 0.5.8-2.10 (bionic) shows this
```
unset test1
echo "${test1:=${PWD%/*}}"
-> /home/user/openfoam/BuildEnv/scratch <-- WHAT?? Not what we expected
```
The additional quotes cause incorrect expansion. Whereas
```
unset test1
echo ${test1:=${PWD%/*}}
-> /home/user/openfoam/BuildEnv <-- Expected
```
- bash and dash 0.5.10.2-6 (focal) work as expected, with/without quotes
- quoted expansion with `:-` works as expected.
Possible fixes?
- https://git.kernel.org/pub/scm/utils/dash/dash.git/commit/?id=48ca00863af909461d1372998bb90549f27abaaf
- https://git.kernel.org/pub/scm/utils/dash/dash.git/commit/?id=a29e9a1738a4e7040211842f3f3d90e172fa58ce
- https://git.kernel.org/pub/scm/utils/dash/dash.git/commit/?id=878514712c5d21f675c45d99d2f8a04098ea4a19
Possible workarounds
- use unqoted version, but risk fixing it on the next shellcheck
- explicit `if [ -z VAR ]; then ...; fi` construct
- with dirname as `: "${VAR:=$(dirname xxx)}`Mark OLESENMark OLESENhttps://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/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/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/1585runTimePostProcessing : Failed closing "librunTimePostProcessing.so" when run...2021-07-06T17:02:45ZSimone BnarunTimePostProcessing : Failed closing "librunTimePostProcessing.so" when run finishesContinuation or re-opening of #354
- Test Case: tutorials/incompressible/simpleFoam/windAroundBuildings
- Version : v1912
- OS: CentOS 7.4
- VTK: 8.2.0 (compiled from VTK sources with Spack)
- MPI: intel-mpi@2019.6.154
- Compiler: int...Continuation or re-opening of #354
- Test Case: tutorials/incompressible/simpleFoam/windAroundBuildings
- Version : v1912
- OS: CentOS 7.4
- VTK: 8.2.0 (compiled from VTK sources with Spack)
- MPI: intel-mpi@2019.6.154
- Compiler: intel@19.0.5.281
- systemGCC: 4.8.5
I successful compiled OpenFOAM v1912 with the off-screen feature implemented in VTK.
VTK has been compiled from sources, version 8.2, using the Spack vtk recipe.
The vtk package of spack has been patched by adding
`-DModule_vtkRenderingParallel=ON`
otherwise OpenFOAM fails to compile the runTimePostProcessing module.
To test the software, I run the windAroundBuildings test case.
After finishing the run, the following message is thrown for both single processor and for multiprocessor. However the image file is dumped in normal way and is fine.
```
--> FOAM Warning :
From function void Foam::dlLibraryTable::clear(bool)
in file db/dynamicLibrary/dlLibraryTable/dlLibraryTable.C at line 164
Failed closing "librunTimePostProcessing.so" with handle 0x2c893e0
Finalising parallel run
simpleFoam: symbol lookup error: /galileo/home/userinternal/sbna0000/spack/opt/spack/linux-centos7-broadwell/gcc-8.3.0/vtk-8.2.0-5edsni3orkxikqdmrrlp7ghdqp6lowv4/lib64/libvtkCommonExecutionModel-8.2.so.1: undefined symbol: _ZN33vtkFilteringInformationKeyManager13ClassFinalizeEv
```
I run
```
nm -D /galileo/home/userinternal/sbna0000/spack/opt/spack/linux-centos7-broadwell/gcc-8.3.0/vtk-8.2.0-5edsni3orkxikqdmrrlp7ghdqp6lowv4/lib64/libvtkCommonExecutionModel-8.2.so.1 | grep _ZN33vtkFilteringInformationKeyManager13ClassFinalizeEv
```
which returns _ZN33vtkFilteringInformationKeyManager13ClassFinalizeEv, so this function is there,
in the dynamic symbol table.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1541paraview 5.6.3 in 1912 compilation fail2020-01-23T16:24:40ZMatej Formanparaview 5.6.3 in 1912 compilation failOn VirtualBox, new latest Ubuntu installation following all prerequisites, having OpenFOAM-v1912 compiled,
in ThirdParty-v1912 running:
```
./makeParaView
```
returns:
```
./makeParaView: 64: local: -DWM_DP: bad variable name
./makePar...On VirtualBox, new latest Ubuntu installation following all prerequisites, having OpenFOAM-v1912 compiled,
in ThirdParty-v1912 running:
```
./makeParaView
```
returns:
```
./makeParaView: 64: local: -DWM_DP: bad variable name
./makeParaView: 64: -DOPENFOAM: bad variable name
```https://develop.openfoam.com/Development/openfoam/-/issues/542failed check for scotch header2017-07-20T10:00:40ZMark OLESENfailed check for scotch headerSystem scotch can be located under `/usr/include/scotch/scotch.h`
- Was originally logged under ThirdParty https://develop.openfoam.com/Development/ThirdParty-plus/issues/19System scotch can be located under `/usr/include/scotch/scotch.h`
- Was originally logged under ThirdParty https://develop.openfoam.com/Development/ThirdParty-plus/issues/19Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/780issue with cast (dictionarySearch) with SGI compiler2018-07-02T09:36:32ZMark OLESENissue with cast (dictionarySearch) with SGI compiler- as reported on the [cfd-online] forum,
db/dictionary/dictionarySearch.C(327): error: invalid type conversion:
"Foam::dictionary::const_searcher" to "const Foam::dictionary::searcher &"
return static_cast<const...- as reported on the [cfd-online] forum,
db/dictionary/dictionarySearch.C(327): error: invalid type conversion:
"Foam::dictionary::const_searcher" to "const Foam::dictionary::searcher &"
return static_cast<const searcher&>(finder);
The conversion should be OK (we use it for switching between const and non-const forms of the searcher), but obviously not the case for SGI.
[cfd-online]: https://www.cfd-online.com/Forums/openfoam-installation/199668-openfoam-v1712-installation-intel-mpt-kahip.htmlv1806Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/883major() / minor() conflicts with sys/sysmacros.h2018-06-20T00:04:13ZMark OLESENmajor() / minor() conflicts with sys/sysmacros.hmajor() and minor() are GNU macros in sys/sysmacros.h - generates warning on Ubuntu.major() and minor() are GNU macros in sys/sysmacros.h - generates warning on Ubuntu.v1806Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/886compiler warnings: unused variables2018-07-02T09:34:07ZPrashant Sonakarcompiler warnings: unused variablesCan we do anything about compiler warnings of unused variables?
1) applications/solvers/DNS/dnsFoam
- readTurbulenceProperties.H:28:18: warning: unused variable 'recRootN'
2) applications/solvers/combustion/fireFoam
- createFields.H:11...Can we do anything about compiler warnings of unused variables?
1) applications/solvers/DNS/dnsFoam
- readTurbulenceProperties.H:28:18: warning: unused variable 'recRootN'
2) applications/solvers/combustion/fireFoam
- createFields.H:117:6: warning: unused variable 'solvePrimaryRegion'
- createFields.H:122:6: warning: unused variable 'solvePyrolysisRegion'
3) src/finiteVolume/cfdTools/general/include/alphaControls.H:24:8:
- warning: unused variable 'scAlpha'
4) applications/solvers/incompressible/simpleFoam/overSimpleFoam
- createOversetFields.H:27:6: warning: unused variable 'adjustFringe'
- createOversetFields.H:31:6: warning: unused variable 'massFluxInterpolation'
5) applications/solvers/incompressible/simpleFoam/porousSimpleFoam
- createPorousZones.H:2:10: warning: variable 'pressureImplicitPorosity' set but not used
6) applications/solvers/lagrangian/reactingParcelFoam
- createFields.H:106:6: warning: unused variable 'solvePrimaryRegion'
@andy @Mattijs @mark @Sergiohttps://develop.openfoam.com/Development/openfoam/-/issues/232metisDecomp compile error2019-12-09T22:04:12ZAdminmetisDecomp compile errorWhen compiling OpenFOAM v1606, the following compilation error appears:
`metisDecomp.C:211:9: error: cannot convert ‘Foam::UList<float>::iterator {aka float*}’ to ‘real_t* {aka double*}’ for argument ‘9’ to ‘int METIS_PartGraphRecursi...When compiling OpenFOAM v1606, the following compilation error appears:
`metisDecomp.C:211:9: error: cannot convert ‘Foam::UList<float>::iterator {aka float*}’ to ‘real_t* {aka double*}’ for argument ‘9’ to ‘int METIS_PartGraphRecursive(idx_t*, idx_t*, idx_t*, idx_t*, idx_t*, idx_t*, idx_t*, idx_t*, real_t*, real_t*, idx_t*, idx_t*, idx_t*)’`
`metisDecomp.C:230:9: error: cannot convert ‘Foam::UList<float>::iterator {aka float*}’ to ‘real_t* {aka double*}’ for argument ‘9’ to ‘int METIS_PartGraphKway(idx_t*, idx_t*, idx_t*, idx_t*, idx_t*, idx_t*, idx_t*, idx_t*, real_t*, real_t*, idx_t*, idx_t*, idx_t*)’`
It seems that `REALTYPEWIDTH 64` in metis.h should correspond to `Field<scalar> processorWeights` in metisDecomp.C, while `REALTYPEWIDTH 32` corresponds to `Field<floatScalar> processorWeights`. So, in order to compile metisDecomp, I changed metisDecomp.C to have `Field<scalar>` instead of `Field<floatScalar>`(see below).
`$WM_THIRD_PARTY_DIR/platforms/linux64Gcc/metis-5.1.0/include/metis.h`
`#define REALTYPEWIDTH 64`
`$WM_PROJECT_DIR/src/parallel/decompose/metisDecomp/metisDecomp.C`
`Field<scalar> processorWeights`
For reference: this problem appears to be related to the bug report on the OpenFOAM fork's website: http://bugs.openfoam.org/view.php?id=2085.Version v1612Mark OLESENMark OLESEN