Re: [petsc-users] VecView to hdf5 broken for large (complex) vectors

[Smith, Barry F. via petsc-users]

> On Apr 17, 2019, at 12:56 AM, Jed Brown <j...@jedbrown.org> wrote:
> 
> "Smith, Barry F. via petsc-users" <petsc-users@mcs.anl.gov> writes:
> 
>>  So it sounds like spack is still mostly a "package manager" where people 
>> use "static" packages and don't hack the package's code. This is not 
>> unreasonable, no other package manager supports hacking a package's code 
>> easily, presumably. The problem is that in the HPC world a "packaged"
>> code is always incomplete and may need hacking or application of newly 
>> generated patches and this is painful with static package managers so people 
>> want to use the git repository directly and mange the build themselves which 
>> negates the advantages of using a package manager.
> 
> I don't think people "want" to hack the packages that they don't
> contribute to.

   Ok, "want" is not the right word, "need" is perhaps more correct.

>  Spack provides pretty rapid distribution of patches.
> 
> What if PETSc had
> 
>  ./configure --with-mumps=spack
> 
> or some alternative that would check with spack to find a suitable
> MUMPS, installing it (with Spack's dependency resolution) if not
> available?  Then you could hack on PETSc with multiple PETSC_ARCH,
> branches, incremental rebuilds, and testing, but not need to deal with
> PETSc's crude package installation and upgrade mechanism.

  This is fine for "hacking" on PETSc but worthless for any other package. Here 
is my concern, when someone 
realizes there is a problem with a package they are using through a package 
manager they think, crud I have to

1) find the git repository for this package
2) git clone the package 
3) figure out how to build the package from source, is it ./configure, cmake, 
what are the needed arguments,... 
4) wait for the entire thing to build 

then I can go in and investigate the problem and provide and test the fix via a 
pull request. Heck I'm not going to bother.

Thus a lot of potential contributions of small fixes that everyone in the 
community would benefit from are lost. This is why, for 
me, an ideal HPC package manager provides a trivial process for providing 
fixes/improvements to other packages.

For example Sajid could have easily figured out the VecView_MPI_HDF5() bug and 
provided a fix but just the hassle of 
logistics (not ability to solve the problem) prevented him from providing the 
bug fix to everyone rapidly. 


Barry



> 
> Upon completion, the build could offer a yaml snippet for packages.yaml
> in case the user wanted other Spack packages to use that PETSc.