Re: petsc interface to other packages
On 07/11/17 04:12, Drew Parsons wrote:
On Mon, 2017-11-06 at 19:46 +0100, Matteo Semplice wrote:
Dear debian-science,
I am writing some code based on the pestc libraries using a
stable
distribution but, if I create a PetscPartitioner of type
PETSCPARTITIONERPARMETIS (I have libparmetis-dev and libparmetis4.0
installed) I get an error message at run-time asking me to "Please
reconfigure with --download-parmetis." Similarly, when calling
DMPlexCreateBoxMesh it asks to reconfigure with --download-triangle,
despite the dev and binary package for libtriangle being installed on
my
machine.
It is expected, or do I have missing link options in my makefile?
If it is not expected to link correctly to parmetis/triangle out of
the
box, I guess that those options are not activated in the standard
debian
build and I am wondering what is the best way to proceed. For
example,
if I downloaded the source package and compiled it locally as
described
in /usr/share/doc/petsc3.7.5-doc/README.Debian.gz, would it find
automatically the parmetis/triangle from the installed debian
package?
Hi Matteo,
Hi Drew,
thanks for the prompt reply.
you're caught by the inconvenient side effect of Debian's
free software policy. Parmetis is non-free, "can be freely used ... by
non-profit institutions...only", so it earns a second-class status in
Debian (it's hosted, but not considered part of the official release).
Since we prefer libraries to be included in the main archive where
possible, petsc has been built with parmetis support deactivated.
Otherwise it would have to be placed in the "contrib" archive, which is
a limbo where free software goes when it consorts with non-free
software. This would have a flow-on affect, forcing all client
packages to also end up in contrib, even if they are all free.
You've got 4 options:
1) scotch support is activated. scotch provides the same functionality
as parmetis. Can you use it instead?
In principle, yes, anything better than the "simple" partitioner would
be ok for me at present. In practice, however, it does not seem to work.
ierr = PetscPartitionerSetType(partitioner,
PETSCPARTITIONERPTSCOTCH);CHKERRQ(ierr);
causes a compile error:
$ make all
mpicxx -o mplexTest.o -c -g -O2
-fdebug-prefix-map=/build/petsc-XG7COe/petsc-3.7.5+dfsg1=.
-fstack-protector-strong -Wformat -Werror=format-security -fPIC
-Wdate-time -D_FORTIFY_SOURCE=2
-I/usr/lib/petscdir/3.7.5/x86_64-linux-gnu-real/include
-I/usr/lib/petscdir/3.7.5/x86_64-linux-gnu-real/include
-I/usr/include/hypre -I/usr/include/suitesparse -I/usr/include/superlu
-I/usr/include/scotch -I/usr/lib/x86_64-linux-gnu/hdf5/openmpi/include
-I/usr/lib/x86_64-linux-gnu/openmpi/include -Wdate-time
-D_FORTIFY_SOURCE=2 -g -Ofast `pwd`/mplexTest.cpp
/home/matteo/software/petscMplex/mplexTest.cpp: In function ‘int
main(int, char**)’:
/home/matteo/software/petscMplex/mplexTest.cpp:73:47: error:
‘PETSCPARTITIONERPTSCOTCH’ was not declared in this scope
ierr = PetscPartitionerSetType(partitioner,
PETSCPARTITIONERPTSCOTCH);CHKERRQ(ierr);
^~~~~~~~~~~~~~~~~~~~~~~~
/usr/lib/petsc/lib/petsc/conf/rules:412: recipe for target 'mplexTest.o'
failed
make: *** [mplexTest.o] Error 1
and similarly using the run-time option -petscpartitioner_type ptscotch
gives the runtime error
[0]PETSC ERROR: Unknown PetscPartitioner type: ptscotch
Here I guess that the issue is that petsc 3.7 does not include scotch
support
(http://www.mcs.anl.gov/petsc/petsc-3.7/docs/manualpages/DM/PetscPartitionerType.html),
whereas 3.8 does include it.
Unless I am doing something wrong here, for this option I would need 3.8
and since this is not in debian yet, I would need to compile it locally
from source.
2) scotch provides a compatibility interface that parmetis clients are
supposed to be able to link against, see libscotchparmetis-dev. I
haven't tested it specifically with PETSc, but let us know if it does
work.
- if this is a usage that our PETSc should be able to support, but
currently does not, then we can consider that a bug which should
be fixed
This would be probably the best solution for stable (and testing, if 3.8
will not get into it).
I installed libscotchparmetis-dev which replaced libparmetis-dev, but it
must not be sufficient, since
$ mpirun -np 3 ./mplexTest -mesh square.msh -petscpartitioner_type parmetis
gives again
[0]PETSC ERROR: Mesh partitioning needs external package support.
Please reconfigure with --download-parmetis.
I assume that this is due to parmetis support being deactivated in the
debian build.
I am willing to help out or test on this point.
3) Rebuild petsc locally, with parmetis support activated.
- this actually should not be difficult to do. We can write
the instructions into our petsc build scripts if needed.
Depending on the petsc config on the cluster I'll be making the real
runs on, I might end up having to build petsc in my home directory for
the final code, but I'd prefer a debian solution for the code
development since both myself and my collaborators are running debian
stable.
4) Convince us to push the entire body of libraries and client programs
out of main and into contrib.
The status of non-free software is a sensitive issue. It's
particularly starting to become acute in numerical software with the
growth in GPU exploitation. OpenCL is free, but nVidia's CUDA is non-
free and introduces similar problems to parmetis. And many of the
libraries have been developing their GPU support using cuda rather than
opencl....
I understand your concern, but this discussion is far above my knowledge
of the licensing issues...
If I can be of help for point (2), let me know.
Best,
Matteo
Reply to: