[petsc-dev] circular dependencies SLEPc

[Matthew Knepley]

On Wed, Jun 26, 2019 at 1:48 PM Balay, Satish via petsc-dev <
petsc-dev at mcs.anl.gov> wrote:

> Even if SLEPc were merged to PETSc - we would normally avoid circular
> dependencies between components - i.e avoid slepc calls from pc/ksp
> [this would break --with-single-library=0 build]
>

Totally agree. However, in a single repo, we could just relocate the code
in the tree, preserving all the other development structures.
Is there a way we can make it look like that (like BuildSystem) without
actually merging all the way? Would that make more sense
for the SLEPc developers?

   Matt


> Satish
>
> On Wed, 26 Jun 2019, Fande Kong via petsc-dev wrote:
>
> > It would be great if SLEPc can be merged into PETSc. Just like what we
> did
> > for TAO. Then we do not have all these issues at all.
> >
> > Any particular reason we can not merge SLEPc into PETSc?
> >
> > Fande,
> >
> > On Wed, Jun 26, 2019 at 11:22 AM Jed Brown via petsc-dev <
> > petsc-dev at mcs.anl.gov> wrote:
> >
> > > Matthew Knepley <knepley at gmail.com> writes:
> > >
> > > > On Wed, Jun 26, 2019 at 1:05 PM Jed Brown <jed at jedbrown.org> wrote:
> > > >
> > > >> Matthew Knepley <knepley at gmail.com> writes:
> > > >>
> > > >> > On Wed, Jun 26, 2019 at 12:45 PM Jed Brown <jed at jedbrown.org>
> wrote:
> > > >> >
> > > >> >> Matthew Knepley <knepley at gmail.com> writes:
> > > >> >>
> > > >> >> >> 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?
> > > >> >>
> > > >> >> Circular dependencies with a special build process is an enormous
> > > >> >> development and distribution tax.
> > > >> >>
> > > >> >
> > > >> > The difference in the arguments here is that there are very
> specific
> > > >> > problems with the "right" way,
> > > >> > namely that I need to deal with two different repos, two testing
> > > systems,
> > > >> > release schedules, etc.
> > > >> > Whereas the taxes above are currently theoretical.
> > > >>
> > > >> It isn't remotely theoretical.
> > > >>
> > > >> You could propose merging SLEPc into the PETSc repository (similar
> to
> > > >> what we did with TAO a while back) if you think "PETSc" code will
> > > >> frequently need to depend on SLEPc, but creating a circular
> dependency
> > > >> between separate packages is worse than having code in Vec that
> depends
> > > >> on DM.
> > > >>
> > > >
> > > > I think there will be very frequent dependencies. I would say this is
> > > > a very convenient stopgap that is preferable to making anyone work in
> > > > both places at once.  That is a very real development nightmare.
> > >
> > > As a concrete issue unrelated from packaging/distribution (which is
> very
> > > important), what happens when a PETSc interface used by SLEPc changes
> in
> > > a branch?  If the repositories are separate and you have this circular
> > > dependency, the PETSc build and tests fail until SLEPc updates to the
> > > new interface and that lands in 'master' where PETSc can use it.  But
> > > the SLEPc updates can't land until the branch with this new change is
> > > merged in PETSc, so you have to do custom testing and synchronize these
> > > merges.  Stop-the-world disruption is not okay, full stop.
> > >
> > > I think it's up to Jose whether closer integration is desirable.
> > >
> >
>
>

-- 
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/0902a2c5/attachment.html>