OPM / opm-core

Collection of utilities, solvers and other components.
http://www.opm-project.org
GNU General Public License v3.0
44 stars 50 forks source link

Disabling PETSc check seems impossible. #712

Closed dr-robertk closed 9 years ago

dr-robertk commented 9 years ago

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 by petscsys.h. If I fix this issue manually (setting some links) then the following problem arises:

opm-core/opm/core/linalg/LinearSolverPetsc.cpp:194:69: error: too many arguments to function ‘PetscErrorCode KSPSetOperators(KSP, Mat, Mat)’
         KSPSetOperators( t.ksp, t.A, t.A, DIFFERENT_NONZERO_PATTERN );

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.

bska commented 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.

dr-robertk commented 9 years ago

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.

atgeirr commented 9 years ago

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.

bska commented 9 years ago

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)’
atgeirr commented 9 years ago

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.

dr-robertk commented 9 years ago

@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.

bska commented 9 years ago

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.

dr-robertk commented 9 years ago

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.

blattms commented 9 years ago

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 to TRUE. See the documentation for the CMAKE_DISABLE_FINDPACKAGE<pack‐ age> variable for more information."

" CMAKE_DISABLE_FINDPACKAGE Variable for disabling find_package() calls.

          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?

bska commented 9 years ago

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.

dr-robertk commented 9 years ago

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?

bska commented 9 years ago

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.

dr-robertk commented 9 years ago

Is this something that has to be implemented on the DUNE side or on the OPM side?

bska commented 9 years ago

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.

blattms commented 9 years ago

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
andlaus commented 9 years ago

this issue seems to be solved. please re-open if this is not the case...