September 2015 - petsc-dev - mailman3.cels.anl.gov

http://m.vtk.org/index.php/Main_Page
by Barry Smith 30 Sep '15

30 Sep '15

Worth adding viewer for it?

1 0

Re: [petsc-dev] Adding support for new sparse BLAS inspector-executor routines in MKL
by Satish Balay 30 Sep '15

30 Sep '15

On Wed, 30 Sep 2015, Jed Brown wrote: > Satish Balay <balay(a)mcs.anl.gov> writes: > > > On Wed, 30 Sep 2015, Richard Mills wrote: > > > >> I need to get an initial implementation in place first, but I'll go ahead > >> and ask about how I'll eventually need to set things up in BuildSystem for > >> this. Perhaps I should follow a similar model to the MKL Pardiso support, > >> i.e., make the user explicitly ask for this? Something like > >> '--with-mkl_spmv2-dir=LOCATION_OF_INTEL_MKL'? > > > > Essentially 'yes'. > > > > Perhaps there is a better way to organize the relations btweeen mkl, > > blaslapack, pardiso, spmv2 etc. > > > > Right now the requirement is: > > > > --with-blas-lapack-dir=LOCATION_OF_INTEL_MKL > > --with-mkl_feature-dir=LOCATION_OF_INTEL_MKL > > Wouldn't --with-mkl_$feature=1 be sufficient? I think the issue was - blaslapack.py [as is currently organized] does not need or care for mkl.h. But mkl_cpardiso.py requires it. For mkl_cpardiso.py to find it - it requires the -dir - or include/lib options. Hence my note: "The additional required features [includes or libraries] can be detected in mkl_feature.py" > Make those scripts depend on blaslapack. Yes - thats how its currently organized. Satish > The repetition is annoying. Maybe at some point the > features should be activated by default when using MKL, but I think > that would be jumping the gun at the moment. >

1 0

Re: [petsc-dev] Adding support for new sparse BLAS inspector-executor routines in MKL
by Jed Brown 30 Sep '15

30 Sep '15

Satish Balay <balay(a)mcs.anl.gov> writes: > On Wed, 30 Sep 2015, Richard Mills wrote: > >> I need to get an initial implementation in place first, but I'll go ahead >> and ask about how I'll eventually need to set things up in BuildSystem for >> this. Perhaps I should follow a similar model to the MKL Pardiso support, >> i.e., make the user explicitly ask for this? Something like >> '--with-mkl_spmv2-dir=LOCATION_OF_INTEL_MKL'? > > Essentially 'yes'. > > Perhaps there is a better way to organize the relations btweeen mkl, > blaslapack, pardiso, spmv2 etc. > > Right now the requirement is: > > --with-blas-lapack-dir=LOCATION_OF_INTEL_MKL > --with-mkl_feature-dir=LOCATION_OF_INTEL_MKL Wouldn't --with-mkl_$feature=1 be sufficient? Make those scripts depend on blaslapack. The repetition is annoying. Maybe at some point the features should be activated by default when using MKL, but I think that would be jumping the gun at the moment.

1 0

Re: [petsc-dev] Adding support for new sparse BLAS inspector-executor routines in MKL
by Satish Balay 30 Sep '15

30 Sep '15

On Wed, 30 Sep 2015, Richard Mills wrote: > I need to get an initial implementation in place first, but I'll go ahead > and ask about how I'll eventually need to set things up in BuildSystem for > this. Perhaps I should follow a similar model to the MKL Pardiso support, > i.e., make the user explicitly ask for this? Something like > '--with-mkl_spmv2-dir=LOCATION_OF_INTEL_MKL'? Essentially 'yes'. Perhaps there is a better way to organize the relations btweeen mkl, blaslapack, pardiso, spmv2 etc. Right now the requirement is: --with-blas-lapack-dir=LOCATION_OF_INTEL_MKL --with-mkl_feature-dir=LOCATION_OF_INTEL_MKL [or its variants with-foobar-include, --with-foobar-lib] The idea is - blas/lapack features [of mkl] will be detected in blaslapack.py. The additional required features [includes or libraries] can be detected in with-mkl_feature.py Satish

1 0

Re: [petsc-dev] SNESComputeJacobian_DMDA()?
by Barry Smith 30 Sep '15

30 Sep '15

> On Sep 30, 2015, at 10:44 AM, Matthew Knepley <knepley(a)gmail.com> wrote: > > Why does the local version not call MatAssemblyBegin/End() automatically? This would > mirror the Function usage. We make the user call the assembly for matrices, which seems > wrong. I don't see any reason not to change it. But I don't see any particular reason to change it either, so I guess I don't care. Barry > > Matt > > -- > 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

1 0

Re: [petsc-dev] Adding support for new sparse BLAS inspector-executor routines in MKL
by Barry Smith 30 Sep '15

30 Sep '15

> On Sep 30, 2015, at 1:25 PM, Richard Mills <richardtmills(a)gmail.com> wrote: > > Ha! Thanks, Barry -- your way with words is always appreciated. =) > > Matt, the inheritance model *is* kinda sucky and broken but at least you guys didn't use C++, so I'll take it. I will take a look at the different subclasses (including the one that I wrote =) ) to refresh my memory about how to do this correctly. > > I need to get an initial implementation in place first, but I'll go ahead and ask about how I'll eventually need to set things up in BuildSystem for this. Perhaps I should follow a similar model to the MKL Pardiso support, i.e., make the user explicitly ask for this? Something like '--with-mkl_spmv2-dir=LOCATION_OF_INTEL_MKL'? > > What is the workflow for making changes to BuildSystem these days? BuildSystem is just in the PETSc repository so you just make changes there with a branch, test etc in the same way. > Do we have this documented somewhere? I ask because I'll need to add something for configuring the MKL inspector-executor stuff, and also because, in a separate issue, I need to add support for the memkind library (https://github.com/memkind/memkind) (Yes, Jed, I know you don't like it but it's what we've got for now for using KNL MCDRAM. I hope someone comes up with an intelligent middleware approach to dealing with this at some point.) > > --Richard > > On Wed, Sep 30, 2015 at 8:06 AM, Jed Brown <jed(a)jedbrown.org> wrote: > Barry Smith <bsmith(a)mcs.anl.gov> writes: > > >> On Sep 30, 2015, at 9:48 AM, Jed Brown <jed(a)jedbrown.org> wrote: > >> > >> Matthew Knepley <knepley(a)gmail.com> writes: > >>> Richard, this is somewhat subtle since PETSc's inheritance model is sucky > >>> and somewhat broken. Look at > >>> the factorization classes, AIJMUMPS etc., before coding anything. > >> > >> Richard wants to use the MKL implementations of stuff like MatMult and > >> MatAXPY, not just factorization. So it doesn't look like AIJMUMPS. > > > > Jed and Matt, > > > > Remember Richard actually wrote the subclasses of AIJ for the Cray vector machine so you guys are teaching your grandmother to suck eggs. > > Where is @shitbsmithsays when you need it? > > > Barry

1 0

Re: [petsc-dev] Adding support for new sparse BLAS inspector-executor routines in MKL
by Richard Mills 30 Sep '15

30 Sep '15

Ha! Thanks, Barry -- your way with words is always appreciated. =) Matt, the inheritance model *is* kinda sucky and broken but at least you guys didn't use C++, so I'll take it. I will take a look at the different subclasses (including the one that I wrote =) ) to refresh my memory about how to do this correctly. I need to get an initial implementation in place first, but I'll go ahead and ask about how I'll eventually need to set things up in BuildSystem for this. Perhaps I should follow a similar model to the MKL Pardiso support, i.e., make the user explicitly ask for this? Something like '--with-mkl_spmv2-dir=LOCATION_OF_INTEL_MKL'? What is the workflow for making changes to BuildSystem these days? Do we have this documented somewhere? I ask because I'll need to add something for configuring the MKL inspector-executor stuff, and also because, in a separate issue, I need to add support for the memkind library ( https://github.com/memkind/memkind) (Yes, Jed, I know you don't like it but it's what we've got for now for using KNL MCDRAM. I hope someone comes up with an intelligent middleware approach to dealing with this at some point.) --Richard On Wed, Sep 30, 2015 at 8:06 AM, Jed Brown <jed(a)jedbrown.org> wrote: > Barry Smith <bsmith(a)mcs.anl.gov> writes: > > >> On Sep 30, 2015, at 9:48 AM, Jed Brown <jed(a)jedbrown.org> wrote: > >> > >> Matthew Knepley <knepley(a)gmail.com> writes: > >>> Richard, this is somewhat subtle since PETSc's inheritance model is > sucky > >>> and somewhat broken. Look at > >>> the factorization classes, AIJMUMPS etc., before coding anything. > >> > >> Richard wants to use the MKL implementations of stuff like MatMult and > >> MatAXPY, not just factorization. So it doesn't look like AIJMUMPS. > > > > Jed and Matt, > > > > Remember Richard actually wrote the subclasses of AIJ for the Cray > vector machine so you guys are teaching your grandmother to suck eggs. > > Where is @shitbsmithsays when you need it? > > > Barry >

1 0

Initial public release of Haskell bindings for SLEPc
by Marco Zocca 30 Sep '15

30 Sep '15

Dear all, I have published the first version of my Haskell bindings for the SLEPc parallel eigenproblem library; it's available at https://github.com/ocramz/slepc-hs So far, only the most basic functionality is wrapped, and there is no exception control or high-level types and combinators, but it showcases a number of aspects of Haskell foreign-function interface design (using `inline-c`). I am also developing Haskell bindings for PETSc, thanks to the similar design of the two libraries, and I hope to release it before the end of the year. My biggest hope however is to contribute to the conversation between the functional programming and high-performance computing communities, as I feel the expressiveness and correctness guarantees provided by the former can be of great advantage to the latter. I look forward to your feedback; Kind regards, Marco Zocca

1 0

Re: [petsc-dev] Adding support for new sparse BLAS inspector-executor routines in MKL
by Barry Smith 30 Sep '15

30 Sep '15

> On Sep 30, 2015, at 10:39 AM, Matthew Knepley <knepley(a)gmail.com> wrote: > > On Wed, Sep 30, 2015 at 10:29 AM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > On Sep 30, 2015, at 9:58 AM, Matthew Knepley <knepley(a)gmail.com> wrote: > > > > On Wed, Sep 30, 2015 at 9:48 AM, Jed Brown <jed(a)jedbrown.org> wrote: > > Matthew Knepley <knepley(a)gmail.com> writes: > > > Richard, this is somewhat subtle since PETSc's inheritance model is sucky > > > and somewhat broken. Look at > > > the factorization classes, AIJMUMPS etc., before coding anything. > > > > Richard wants to use the MKL implementations of stuff like MatMult and > > MatAXPY, not just factorization. So it doesn't look like AIJMUMPS. > > > > It will look like that in the sense that he wants to keep some data structures and > > not others, and override some functions and not others. AIJMUMPS shows you > > how to keep things in sync since there are too many places where they can go > > wrong. Factorization is beside the point. > > No it isn't. We have a special infrastructure for factorizations that is distinct from making subclasses of mat subclasses. > > What matrix subclasses do we have that are not factorizations? MatCreate_MPIAIJCR MatCreate_MPIAIJPERM MatCreate_MPIAIJCUSP MatCreate_MPIAIJCUSPARSE MatCreate_MPIAIJViennaCL > > Matt > > Barry > > > > > Matt > > > > -- > > 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 > > > > > -- > 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

1 0

SNESComputeJacobian_DMDA()?
by Matthew Knepley 30 Sep '15

30 Sep '15

Why does the local version not call MatAssemblyBegin/End() automatically? This would mirror the Function usage. We make the user call the assembly for matrices, which seems wrong. Matt -- 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

1 0