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

Smith, Barry F. bsmith at mcs.anl.gov
Wed Apr 17 00:39:54 CDT 2019


  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.

   Thanks

    Barry

Perhaps if spack had an easier mechanism to allow the user to "point to" local git clones it could get closer to the best of both worlds. Maybe spack could support a list of local repositories and branches in the yaml file. But yes the issue of rerunning the "./configure" stage still comes up.






> On Apr 17, 2019, at 12:00 AM, Balay, Satish via petsc-users <petsc-users at mcs.anl.gov> wrote:
> 
> On Tue, 16 Apr 2019, Sajid Ali via petsc-users wrote:
> 
>>> develop > 3.11.99 > 3.10.xx > maint (or other strings)
>> Just discovered this issue when trying to build with my fork of spack at [1
>> <https://github.com/s-sajid-ali/spack/commit/05e499571b428f37b8cd1c7d39013e3dec08e5c8>].
>> 
>> 
>> So, ideally each developer has to have their develop point to the branch
>> they want to build ? That would make communication a little confusing since
>> spack's develop version is some package's master and now everyone wants a
>> different develop so as to not let spack apply any patches for string
>> version sorted lower than lowest numeric version.
> 
> There is some issue filed [with PR?] regarding this with sorting order
> of string versions and numerical versions. This might improve in the
> future. But for now 'bugfix-vecduplicate-fftw-vec' will be lower than
> version 0.1
> 
> Also 'develop' might not be appropriate for all branches.
> 
> For ex: - petsc has maint, maint-3.10 etc branches. - so if one is
> creating a bugfix for maint - (i.e start a branch off maint) it would
> be inappropriate to call it 'develop' - as it will be marked > version
> 3.11.99 and break some of the version comparisons.
> 
>> 
>>> Even if you change commit from 'abc' to 'def'spack won't recognize this
>> change and use the cached tarball.
>> True, but since checksum changes and the user has to constantly zip and
>> unzip, I personally find git cloning easier to deal with so it's just a
>> matter of preference.
>> 
> 
> Here you are referring to tarballs - where the sha256sum is listed.
> 
>     url      = "http://ftp.mcs.anl.gov/pub/petsc/release-snapshots/petsc-3.5.3.tar.gz"
>     version('3.11.1', 'cb627f99f7ce1540ebbbf338189f89a5f1ecf3ab3b5b0e357f9e46c209f1fb23')
> 
> However - one can also say:
> 
>     git      = "https://bitbucket.org/sajid__ali/petsc.git"
>     version('3.11.1', commit='f3d32574624d5351549675da8733a2646265404f')
> 
> Here - spack downloads the git snapshot as tarball (saves in tarball
> cache as petsc-3.11.1.tar.gz - and reuses it) - and there is no
> sha256sum listed here to check. If you change this to some-other
> commit (perhaps to test a fix) - spack will use the cached tarball -
> and not downloaded the snapshot corresponding to the changed commit.
> 
> Satish



More information about the petsc-users mailing list