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

[Smith, Barry F.]

> On Apr 17, 2019, at 12:56 AM, Jed Brown <jed at jedbrown.org> wrote:
> 
> "Smith, Barry F. via petsc-users" <petsc-users at 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.