[petsc-dev] circular dependencies SLEPc

Matthew Knepley knepley at gmail.com
Wed Jun 26 11:00:43 CDT 2019

On Wed, Jun 26, 2019 at 11:55 AM Jed Brown via petsc-dev <
petsc-dev at mcs.anl.gov> wrote:

> "Smith, Barry F. via petsc-dev" <petsc-dev at mcs.anl.gov> writes:
> >> On Jun 26, 2019, at 9:56 AM, Balay, Satish via petsc-dev <
> petsc-dev at mcs.anl.gov> wrote:
> >>
> >> On Wed, 26 Jun 2019, Jakub Kruzik via petsc-dev wrote:
> >>
> >>> Hello,
> >>>
> >>> as I mentioned in PR #1819, I would like to use SLEPc in PETSc.
> >>>
> >>> Currently when PETSc is configured with --download-slepc, it defines
> >>> PETSC_HAVE_SLEPC and each compilation of PETSc recompiles SLEPc.
> >>
> >> yes - slepc uses petsc, so when petsc is updated - its best to rebuild
> slepc
> >>
> >> You can ignore PETSC_HAVE_SLEPC flag [its just a build tool thingy]
> >> PETSc code does not use this flag - and there is no circular
> >> dependency.
> >>
> >>> The first way to use SLEPc is from an example. That should be easy,
> all we
> >>> need is to add -lslepc when compiling an example.
> >>
> >> Its best to use slepc examples as templates - and slepc makefiles [as
> examples].
> >>
> >> --download-slepc is a convinence feature to install petsc and slepc in
> >> a single go. It does not change how you would use slepc.
> >>
> >> Satish
> >>
> >>
> >>>
> >>> The other option is to use SLEPc inside PETSc code. I do not know how
> to
> >>> achieve this. One way could be to define PETSC_HAVE_SLEPC after the
> >>> compilation of SLEPc and again compile PETSc but this time linking
> with SLEPc.
> >>> Although, even if it works, it is ugly.
> >
> >    If you make SLEPc calls from PETSc source you should only need the
> SLEPc header files to compile the PETSc source; not the SLEPc library. So
> one way to accomplish this would be to do a "partial" install of SLEPc,
> build PETSc (that uses SLEPc) and then complete the SLEPc install. When
> --download-slepc is used this would mean during the SLEPc.py script it
> would copy over the SLEPc include files to the prefix location and after
> PETSc is built it would build the SLEPc libraries and move them to the
> prefix location.  The on iffy thing is that SLEPc include files may depend
> on generated PETSc include files (which are not fully generated until
> configure is done). Thus instead of having SLEPc.py move the SLEPc include
> to the prefix location it would need to post-pone that until just at the
> end of configure (we have other packages to do this). So when you ready to
> try this out let us know and we can help with the infrastructure. (it will
> avoid 2 builds of either PETSc or SLEPc).
> That is disgusting.
> If code in libpetsc.so depends on libslepc.so, then you'd have a circular
> dependency.
> You can implement and register a PC in SLEPc (it would go in libslepc.so).

I think this is the bad workflow solution. What Barry suggested will work
and be MUCH easier for a developer. Isn't
the point of our tools to make our lives easier, not to enforce rules that
make them harder?


What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener

https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20190626/f0b7d308/attachment-0001.html>

More information about the petsc-dev mailing list