[petsc-dev] --download and spack

[Balay, Satish]

On Sun, 21 Oct 2018, Jed Brown wrote:

> "Balay, Satish" <balay at mcs.anl.gov> writes:
> 
> > On Sun, 21 Oct 2018, Jed Brown wrote:
> >
> >> "Balay, Satish" <balay at mcs.anl.gov> writes:
> >> 
> >> > On Sun, 21 Oct 2018, Jed Brown wrote:
> >> >
> >> >> "Balay, Satish" <balay at mcs.anl.gov> writes:
> >> >> 
> >> >> > I don't think spack is really a replacemet for --download-package yet.
> >> >> >
> >> >> > For one - it has some initial setup hump users have to go over. [how
> >> >> > does one specify compilers, and my prebuilt MPI?]
> >> >> 
> >> >> The configuration profile is somewhat clumsy, but lots of facilities do
> >> >> it.  If PETSc were to support using spack for prerequisites, we would
> >> >> probably want PETSc to be able to set it up.
> >> >> 
> >> >> > And then - we would need to update petsc support in spack to be as
> >> >> > externsive wrt externalpackages as we currently have.
> >> >> 
> >> >> There are separate ideas:
> >> >> 
> >> >> * ./configure --download-hypre=spack
> >> >> 
> >> >>   or some similar syntax tells configure to ask Spack how to link to a
> >> >>   suitably-built Hypre and to install it if necessary, resolving any
> >> >>   possible transitive dependencies [1].
> >> >
> >> > I don't think spack is designed to support this model [just install
> >> > one package or a subset of pacakges - per our spec]. For one - it
> >> > doesn't have a configure like interface to pass options from petsc
> >> > configure to spack [for all the checks that petsc configure has
> >> > already done.
> >> >
> >> >> 
> >> >> * spack install petsc+hypre
> >> >> 
> >> >>   as a recommended way for users to install.  An issue with this is that
> >> >>   Spack code runs before anything PETSc works with, and Spack setup
> >> >>   (system compilers, MPI, etc.) can be nontrivial.
> >> >
> >> > This is the recommended mode. And I think its useful for users who don't
> >> > want to deal with petsc directly or petsc interface directly.
> >> >
> >> > [for ex: deal.ii users - who want to install deal.ii - but just want a
> >> > compatible petsc installed automatically].
> >> 
> >> This is *exactly* the same model as you rejected a paragraph above.
> >> There is no difference whether we are talking about installing
> >> dependencies for PETSc or dependencies for Deal.II.
> >
> > Not really. My initial claim was 'spack was not yet a replacement for
> > --download-package' option in PETSc. I don't think deal has this
> > feature.
> 
> Okay, fair enough.  But if it's usable for installing dependencies
> needed by a typical deal.II user, it should also be usable for
> installing PETSc's dependencies.
> 
> >> Also, I think most users don't care whether exactly the same compiler
> >> options are passed to all dependent packages.  They want to link against
> >> a working debug or optimized stack with minimal build time.
> >> 
> >> >> [1] Having configure churn for a while and then say that --download-zlib
> >> >> or --enable-zlib is required is super lame.
> >> >
> >> > spack automatically figures out and installs tonnes of additional packages. The
> >> > above model gives the choice of user deciding what to do. In case of p4est - it could
> >> > be an optionl dependency instead of mandatory dependency.
> >> >
> >> > I guess optional dependency handling is a bit complex.
> >> 
> >> It is, but if we're downloading a bunch of packages and zlib is deemed
> >> required, we shouldn't fail.  It's these minutes of babysitting
> >> configure and needing to start over to add non-obvious dependencies that
> >> is infuriating and drives people away from PETSc and/or blocks them from
> >> running their code at new facilities.  (It's a completely different
> >> calculus if I know I can log in, issue a couple simple commands, and be
> >> running in 5-10 minutes versus if I expect to need to babysit and
> >> troubleshoot configuration idiosyncrasies for hours.)
> >
> > In my case - I have spack running for 4-6h - and then I get an error -
> > and then I have to figureout how to work arround them - and restart
> > builds. Different tools have different error cases..
> 
> I agree it can be irritating, though Spack is reasonably reliable about
> caching previous builds so it usually isn't starting over from scratch
> after fixing any particular issue.

If certain dependencies change [due to my choice of workarrounds] - it  builds another copy of all packages that are affected.

> And I didn't mean that the zlib thing on its own is a reason to use
> Spack, but that PETSc configure should either return immediately (<5
> seconds) if the dependency graph is incomplete and/or try to do what the
> user surely wants and find a zlib.

Sure - perhaps there are improvements possible for both the tools..

Satish