Closed dr-robertk closed 9 years ago
The PETSc project itself recommends a different FindPETSc.cmake
module than what we have in our cmake/Modules
directory. From a cursory glance, this module seems to be aware of (and expose) PETSc versions so we could possibly leverage that to distinguish API calls if needed.
On the other hand, an option of the form "don't include PETSc even if available" must be implemented separately--possibly in the main CMakeLists.txt
or a wrapper module.
The option "don't include PACKAGE even if available" would probably also be desirable for other third party packages, such as SuperLU, UMFPACK, dune-*. My cmake knowledge is to basic to come up with a proper implementation for that feature.
I agree disabling would be a nice feature. Meanwhile, could you test the FindPETSc.cmake code @bska linked to above? If it works well we should adopt it, and you current problem would be solved.
If it works well we should adopt it
Note: We need additional code changes to work around the API changes that cause the build error
error: too many arguments to function ‘PetscErrorCode KSPSetOperators(KSP, Mat, Mat)’
You are of course right, did not think about that. So in order to support this fully we must get some of this into the config.h I guess.
@bska: The above mentioned FindPETSc.cmake needs two more files from the same repository (FindPackageMultipass.cmake and ResolveCompilerPaths.cmake). I tested with both, my system installed 3.5.1. version and a new manually installed 3.5.2 version. The test seems not ba able to recognize PETSc. That seems a bit strange. I don't know what exactly I have done worng. Maybe I should send Jed a mail.
The above mentioned
FindPETSc.cmake
needs [three] more files from the same repository
Ah, yes.
The latter is strictly speaking restricted to the Cygwin environment, but it appears to be unconditionally included.
The test seems not ba able to recognize PETSc. That seems a bit strange.
Agreed. It could be related to the operating system. The module does appear to assume a Debian packaging scheme although there is a little bit of RedHat thrown in for good measure. I don't know if you've done so yet, but you could try manually specifying PETSC_DIR
and/or PETSC_ARCH
for purpose of the system probe.
Right. For some reason the CorrectWindowsPaths.cmake was not triggered before.
Now I'm at least able to find my manually installed 3.4.5 and 3.5.2 version. The compile error only occurs with the 3.5.x versions, so we need a PETSc version macro to cover these kind of problems. As mentioned above these are frequent in PETSc, so this is needed anyway.
I do some further testing with my system version.
Concerning deactivating packages, let me quote the CMake documentation:
"Every non-REQUIRED find_package() call can be disabled by set‐
ting the variable CMAKE_DISABLE_FINDPACKAGE
" CMAKE_DISABLE_FINDPACKAGE
Every non-REQUIRED find_package() call in a project can be dis‐
abled by setting the variable CMAKE_DISABLE_FIND_PACKAGE_<Packa‐
geName> to TRUE. This can be used to build a project without an
optional package, although that package is installed.
This switch should be used during the initial CMake run. Other‐
wise if the package has already been found in a previous CMake
run, the variables which have been stored in the cache will
still be there. In the case it is recommended to remove the
cache variables for this package from the cache using the cache
editor or cmake -U
"
Have you tried cmake -DCMAKE_DISABLE_FIND_PACKAGE_PETSc or whatever case is needed?
CMAKE_DISABLE_FIND_PACKAGE_<package>
Ah, yes. Brilliant. We could still wrap that in a more palatable option but at least there is a general procedure for achieving the desired effect.
Sounds good. I was using the dune-control command to configure also the OPM modules. Is there an easy option such as --without-petsc that results in -DCMAKE_DISABLE_FIND_PACKAGE_PETSc?
Is there an easy option such as
--without-petsc
that results in-DCMAKE_DISABLE_FIND_PACKAGE_PETSc
?
There is not. That is the bit that's missing to make it complete.
Is this something that has to be implemented on the DUNE side or on the OPM side?
Is this something that has to be implemented on the DUNE side or on the OPM side?
I don't remember how (or if) dunecontrol configure
handles unknown flags so I can't comment on the Dune implications, but we definitely need to add some OPM-specific handling of --without-petsc
(or whatever we end up calling it) in cmake/Scripts/configure
and possibly in CMakeLists.txt
too.
The case of the option was wrong. For some reason the file is called FindPetsc.cmake. Therefore the option is -DCMAKE_DISABLE_FIND_PACKAGE_Petsc=True. Just put it into CMAKE_FLAGS and use dunecontrol. Here is my tested opts file deactivating PETSc:
CONFIGURE_FLAGS="CC=gcc-4.4 CXX=g++-4.4 F77=gfortran-4.4 FC=gfortran-4.4 --enable-parallel --enable-static --disable-shared --with-agmg=/home/mblatt/src/3rdParty/AGMG_3.1.2/SRC CFLAGS='-O0 -g -DDUNE_GRID_EXPERIMENTAL_GRID_EXTENSIONS' CPPLAGS='-O0 -g ' FCFLAGS='-O0 -g' FFLAGS='-O0 -g' CXXFLAGS='-g -O0 -Wall -Wextra' EIGEN3_ROOT=~/src/dune/opm-amg-opt/eigen3/"
BUILDDIR=opm-parallel
MAKEFLAGS=-j4
CMAKE_FLAGS="-DCMAKE_DISABLE_FIND_PACKAGE_Petsc=True -DERT_ROOT=/home/mblatt/src/dune/3rdParty/ert -DUSE_RUNPATH:BOOL=ON"
USE_CMAKE=yes
this issue seems to be solved. please re-open if this is not the case...
I have PETSc 3.5.1 installed on my system. First, the cmake PETSc check in opm-core is not able to locate the
petscconf.h
header which is included bypetscsys.h
. If I fix this issue manually (setting some links) then the following problem arises:Unfortunately, PETSc tends to change interfaces of such functions between minor releases a lot with the result of code breaking when different versions of PETSc are used. opm-core does not seem to have a proper strategy for that.
Thats why a simple way to disable the PETSc check, something like the "I know I have PETSc installed but I don't want to used it in OPM right now" switch seems to be missing.