MATSHELL a bit broken...

[Barry Smith]

  Matt,

   Because of the MatShell shift and scale being handled automatically 
this affects many of the methods.

   Barry


On Thu, 25 Oct 2007, Matthew Knepley wrote:

> It sounds fine. I just wonder what it is about methods like this, and whether
> we are missing some structure.
> 
>   Matt
> 
> On 10/25/07, Barry Smith <bsmith at mcs.anl.gov> 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.
> > >
> > >
> >
> >
> 
> 
>