Support arch installations of PETSc

@mark I have a tentative patch patch_for_pdir_parch_petsc for wmake/scripts/have_petsc The vast majority of PETSc users use this PETSC_DIR/PETSC_ARCH approach. You may want to include the patch before final release. Could you please take a look? I confirm it works from my side

Hi @szampini - definitely makes sense to use the PETSc-supplied values for pkgconfig. Not sure where your patch would fit into the slightly reworked form: develop branch have_petsc

If $PETSC_ARCH_PATH/lib/pkgconfig actually exists, I would think that the previous logic (isAbsolute etc) would have caught this before the pkgconfig could kick in.

BTW: since you are on-line, any tips for getting PETSc (3.13.2) to build without fortran? I'm compiling with a gcc-toolchain with my current platform being clang-10 and system openmpi but get this:

TESTING: FortranMPICheck from config.packages.MPI(config/BuildSystem/config/packages/MPI.py:432)                                        *******************************************************************************
         UNABLE to CONFIGURE with GIVEN OPTIONS    (see configure.log for details):
-------------------------------------------------------------------------------
Fortran error! mpi_init() could not be located!
*******************************************************************************

Ran with --with-fortran-bindings=0 but seems not to be enough.

Full config:

./configure --prefix=/home/mol/openfoam/OpenFOAM-com/ThirdParty/platforms/linux64Clang100DPInt32/petsc-3.13.2 --with-petsc-arch=DPInt32 --with-clanguage=C --with-fortran-bindings=0 --with-scalapack=0 --with-superlu_dist=0 --with-suitesparse=0 --download-f2cblaslapack=1 --with-cc=/usr/lib64/mpi/gcc/openmpi/bin/mpicc --with-cxx=/usr/lib64/mpi/gcc/openmpi/bin/mpicxx --with-shared-libraries --with-64-bit-indices=0 --with-precision=double

I cannot comment on the branch you posted. I'm using master. Should I use develop to have a more up-to-date foam (for other stuff I mean)? You can check yourself if it works if you configure PETSc without prefix installation (i.e. remove the --with-prefix=... option from configure) e.g

./configure PETSC_DIR=$PWD PETSC_ARCH=arch-test

petsc.h will always be located in $PETSC_DIR/include, but to include PETSc you need -I$PETSC_DIR/arch-test/include -I$PETSC_DIR.

For the fortran issue. Not sure what is going on, I need to see the configure.log. You can disable fortran completely by specifying --with-fc=0 at configure time. Disabling fortran bindings does not prevent PETSc to check for a fortran compiler, since it may compile external packages with Fortran.

If you have time to compile up a develop branch it would be helpful as we now finalize things. There are still some code chunks coming in, but nothing that would directly affect you.

The --with---with-fc=0 got the fortran sorted nicely - thanks!

Not sure if I am configuring/compiling things incorrectly. For our own builds (ThirdParty, when we don't have another petsc install available), I am setting --with-petsc-arch according to the OpenFOAM naming style (eg DPInt32) to make it easier for us to locate etc. But also installing with this encoded in the prefix (eg, --prefix=/some/path/linux64GccDPInt32/petsc-3.12.3).

If I do that, this prefixed dir only has an include/ with headers in the first level and a petsc/private subdirectory. No signs of a petsc arch.

See the description of the issue: if you do not build PETSc with the prefix option, you can have different PETSc installations sitting in the root of the PETSc source code, in different

PETSC_DIR/

PETSC_ARCH folders (one PETSC_ARCH for each different configuration, eg single precision, double precision, 64bit indices etc). All these are valid PETSc installations (although this is not "standard"), and we (PETSc developers) use it all of the time (we never "install" PETSc). To use any of these installations, you need to include $PETSC_DIR/include (which contains information which is installation agnostic) and

PETSC_DIR/

PETSC_ARCH/include (which contains specific customization of the installation) Libraries are located in

PETSC_DIR/

PETSC_ARCH/lib

you can test it using ./configure ...your configure options without prefix... PETSC_ARCH=arch-your-name-for-the-arch-here

I'll use develop

I confirm that also develop is broken for this case.

@sbna - any extra input?

assigned to @sbna and unassigned @mark

I am working on this

Thanks!

I made the following changes which work for both kind of installation:

I used the following snippet of code

# Library
[ -n "$library" ] || library=$(findLibrary \
  "$prefix/lib/$libName" \
  "$prefix/lib$WM_COMPILER_LIB_ARCH/$libName" \
  ) || {
  [ -n "$warn" ] && echo "$warn (no library)"
  return 2
}

instead of (it does not work for me)

# Library
# [ -n "$library" ] \
# || library=$(findLibrary -prefix="$prefix" -name="$libName") \
# || {
#    [ -n "$warn" ] && echo "$warn (no library)"
#    return 2
# }

and (PKG_CONFIG_PATH has to be set correctly)

elif hasAbsdir "$prefix"
then
    # header=$(findSystemInclude -name="$incName")
    # prefix=$(sysPrefix "$header")

    # No system header, attempt discovery with pkg-config
    if [ -z "$header" ] && [ $(pkg-config --exists "$pkgName" 2>/dev/null; echo $?) -eq 0 ]
    then
        header=$(pkg-config --cflags-only-I "$pkgName" | sed -e 's/^-[IL]//')
        library=$(pkg-config --libs-only-L "$pkgName" | sed -e 's/^-[IL]//')

        prefix="${header%/*}"     # Basename

        # Artifically adjust names (for later)
        [ -n "$header" ] && header="$header/$incName"
        [ -n "$library" ] && library="$library/$libName"
    else
        header=$(findFirstFile "$prefix/include/$incName")
        library="$(findExtLib $libName)"
    fi

is it necessary to include also the "elif isSystem "$prefix"" case?

@sbna What's wrong with adding a final check similar to the patch I have sent you? If none is found, we can look for the file $PETSC_ARCH_PATH/lib/pkgconfig/PETSc.pc

If found, process the file with pkg-config (no longer need the somewhat new option in pkgconfig --with-path) and produce the relevant includes/libraries to be linked?

There is nothing wrong with your solution. I simply modified the develop code in order to get a working solution. @mark are you fine with the solution proposed by @szampini? If yes, I can prepare a patch for the have_petsc file.

Hi @sbna I'm fine with anything that works, makes sense and isn't overly messy.

If you have a drop-in file replacement (based on develop) that I can test, this is easiest for me. Then I don't have to worry about modifying the wrong place, and can readily see the diff using git.
what PETSc configure options do I need to use for testing this? Below is a snippet from the ThirdParty makePETSC. It does not show any problem, nor does it create the petsc-arch directory.

    if [ "$WM_LABEL_SIZE" = 64 ]
    then
        configOpt="$configOpt --with-64-bit-indices=1"
    else
        configOpt="$configOpt --with-64-bit-indices=0"
    fi

    if [ "$WM_PRECISION_OPTION" = SP ]
    then
        configOpt="$configOpt --with-precision=single"
    else
        configOpt="$configOpt --with-precision=double"
    fi

    ./configure \
       --prefix="$PETSC_ARCH_PATH" \
       --with-petsc-arch="$archOpt" \
       --with-clanguage=C \
       --with-fc=0 \
       --with-scalapack=0 \
       --with-superlu_dist=0 \
       --with-suitesparse=0 \
       --download-f2cblaslapack=1 \
       $configOpt \

where $archOpt is "DPInt32" etc.

what PETSc configure options do I need to use for testing this? Below is a snippet from the ThirdParty makePETSC. It does not show any problem, nor does it create the petsc-arch directory.

simply remove the --prefix option. Your petsc installation will be located in $PETSC_DIR/DPInt32, where PETSC_DIR is the location where you have PETSc source code.

With this "inplace" installations, you need to include -I$PETSC_DIR/DPInt32/include -I$PETSC_DIR

have_petsc @mark here you find the "have_petsc" file patched to work for both kind of installation

mentioned in commit 2ae3518b

Hi @sbna and @szampini - thanks for you input. I think that I am now able to handle these cases. The solution looks a bit different from what you had, but seems to work.

The OpenFOAM changes are in have_petsc for OpenFOAM and locally in an extra loop in the Make/options

I confirm it worked smoothly, I'm closing the issue

closed

I am thankful. These types of config issues always feel quite opaque.

mentioned in issue #33

Support arch installations of PETSc

Child items

Activity

Admin message

Support arch installations of PETSc

Child items

Linked items

Activity