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. > > > > > > > > > > > > >
