search

GEOS-DEV / thirdPartyLibs

Repository to build the GEOSX third party libraries
3 stars 12 forks source link

Add Scotch as a separate TPL target #192

Closed klevzoff closed 2 years ago

klevzoff commented 2 years ago

This PR configures Scotch as an (optional) standalone TPL rather than a sub-package of PETSc. This makes it usable directly from GEOSX, as an alternative to ParMETIS for mesh partitioning.

Unlike ParMETIS which just happens to depend on and include METIS in its source but is otherwise a separate library, Scotch is a single-source project that builds both the sequential (libscotch) and parallel (libptscotch) libraries. Therefore I decided to add it as a single subproject. Moreover, I'm not interested in figuring out complex CMake logic for non-MPI build that we don't even use, so it's not supported. However I may declare two separate targets in GEOSX, because I also have a use case for serial version.

As a caveat, Scotch seems to have a non-optional dependency on flex and bison, which was also the case before. Just like in case with Doxygen, we assume they are installed system-wide (and are of compatible versions). This PR does not attempt to rectify that; I expect this situation to be resolved eventually by moving to spack. In the meantime, systems that cannot provide these executables should set ENABLE_SCOTCH=OFF, just like they do with Doxygen.

As a subsequent PR I would like to upgrade Scotch to latest version, however that may require updating PETSc as well so it should be done separately.

Related to https://github.com/GEOSX/GEOSX/pull/1996

rrsettgast commented 2 years ago

@bmhan12 @wrtobin We are going to have to add scotch to our space configs, or is it already in there?

wrtobin commented 2 years ago

It isn't present as a dependency in our spack recipe at the moment:

https://github.com/GEOSX/GEOSX/blob/develop/scripts/uberenv/packages/geosx/package.py

If we're requiring it we'd just need to add the dependency itself, list any conflicts with variants if they introduce a conflicting dependency, and add the ENABLE_SCOTCH and SCOTCH_DIR vars to the spack-generated host-configs.

If we're not requiring it we'd need a variant to use to enable/disable the dependency as well.

klevzoff commented 2 years ago

If we're requiring it we'd just need to add the dependency itself, list any conflicts with variants if they introduce a conflicting dependency, and add the ENABLE_SCOTCH and SCOTCH_DIR vars to the spack-generated host-configs.

If we're not requiring it we'd need a variant to use to enable/disable the dependency as well.

I will address this in GEOSX PR. The current plan is to make it optional.

As an aside, it'd be kinda cool to have a CI job that uses a Spack build. Not sure how that would work, perhaps we could trigger a docker image rebuild step any time the package recipe file is modified (I think Azure can have jobs dependent on paths modified in a PR).