> On Apr 17, 2019, at 6:49 AM, Matthew Knepley <knep...@gmail.com> wrote: > > On Wed, Apr 17, 2019 at 2:40 AM Smith, Barry F. via petsc-users > <petsc-users@mcs.anl.gov> wrote: > > > > On Apr 17, 2019, at 1:35 AM, Balay, Satish <ba...@mcs.anl.gov> wrote: > > > > On Wed, 17 Apr 2019, Smith, Barry F. via petsc-users wrote: > > > >> 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. > > > > I never said that any current practices are better than using spack! It is > just that perhaps > with a few tweaks spack could provide a way to fundamentally improve our > current practices (which are, as you acknowledge cumbersome). > > This sounds like a hopeless pipedream. But maybe. Most of the infrastructure is there already. > > Matt > > Barry > > > Even without spack and multiple packages - this is not a easy thing to > > do. For ex: most of our users install petsc from tarball. > > > > And if they find a bug - they have to go through similar complicated > > process [create a bitbucket account, get a fork - learn the petsc PR > > process - make a PR etc]. > > > > With spack - I stick to the usual process - and don't get bogged down > > by 'spack' support for this process. > > > > If I see a breakage - I do 'spack build-env package [this has its own > > issues] - attempt a fix - get it first working with a spack build. > > > > [Alternative is to just edit the package file to get my fix - if its a > > patch I can find] > > > > > > Once I have it working [the major issue is taken care off]. Then I > > have a diff/patch and then worry about how to submit this diff/patch > > to upstream. > > > > Sure its a multi step model - and has many trip points. But is not > > that our current petsc only model doesn't have any. > > > > Satish > > > > -- > 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/
Re: [petsc-users] VecView to hdf5 broken for large (complex) vectors
Smith, Barry F. via petsc-users Wed, 17 Apr 2019 09:25:42 -0700
- Re: [petsc-users... Sajid Ali via petsc-users
- Re: [petsc-users... Balay, Satish via petsc-users
- Re: [petsc-users... Smith, Barry F. via petsc-users
- Re: [petsc-users... Sajid Ali via petsc-users
- Re: [petsc-users... Balay, Satish via petsc-users
- Re: [petsc-users... Balay, Satish via petsc-users
- Re: [petsc-users... Jed Brown via petsc-users
- Re: [petsc-users... Smith, Barry F. via petsc-users
- Re: [petsc-users... Balay, Satish via petsc-users
- Re: [petsc-users... Smith, Barry F. via petsc-users
- Re: [petsc-users... Smith, Barry F. via petsc-users
- Re: [petsc-users... Jed Brown via petsc-users
- Re: [petsc-users... Balay, Satish via petsc-users
- Re: [petsc-users] VecView to hdf5 broken f... Smith, Barry F. via petsc-users
- Re: [petsc-users] VecView to hdf5 broken f... Smith, Barry F. via petsc-users