MATSHELL a bit broken...

Matthew Knepley knepley at
Thu Oct 25 16:50:54 CDT 2007

It sounds fine. I just wonder what it is about methods like this, and whether
we are missing some structure.


On 10/25/07, Barry Smith <bsmith at> wrote:
>   Yes.
>   It should be handled more systematically, inside Mat_Shell
> have an entire _MatOps table, also have a PetscBT() with one bit for
> each operation. For methods that cannot be overloaded directly turn
> that bit on. Now MatShellSetOperation() will check the corresponding bit
> if it is set then put the provided function into the _MatOps table that
> is inside the Mat_Shell. If the bit is not set then put the provided
> function into the regular _MatOps
>   Make sense? (I don't know that is why I am asking everyone).
>    Barry
> Overtime we will likely find that more methods must have the bit set.
> On Thu, 25 Oct 2007, Lisandro Dalcin wrote:
> > It seems MATSHELL implementation is a bit broken. If I'm not wrong, if
> > a user set the operations MOP_ASSEMBLY_END, then the use of the
> > automatic MatScale/MatShift would lead to unexpected result...
> >
> > Should this operation be managed the same way as
> > mult/multtranspose/get diagonal currently is, that is, by backupping
> > the user provided function pointer?
> >
> > BTW, sorry if I disturb you asking for making changes that seems
> > trivial, but I really do not like to change any line of code after
> > knowing your opinion.
> >
> >

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

More information about the petsc-dev mailing list