So basically hoist most of the data structure 

typedef struct {
  struct _MatShellOps ops[1];

  PetscScalar vscale,vshift;
  Vec         dshift;
  Vec         left,right;
  Vec         left_work,right_work;
  Vec         left_add_work,right_add_work;
  Mat         axpy;
  PetscScalar axpy_vscale;
  PetscBool   managescalingshifts;                   /* The user will manage 
the scaling and shifts for the MATSHELL, not the default */
  void        *ctx;
} Mat_Shell;

  into Mat?    MatShell handles the axpy (which is nasty), would you handle 
that as well, if not then you still have code duplication between the MatShell 
implementations and the Mat___Basic implementations. If it wasn't for the axpy 
I would say it is worth trying but including correctly the axpy (I am not sure 
if it is always handled correctly for MatShell) requires complex code.


    Barry


> On Dec 1, 2018, at 1:49 PM, Hapla Vaclav <vaclav.ha...@erdw.ethz.ch> wrote:
> 
> MatDiagonalScale_Shell, MatDiagonalScale_Normal, 
> MatDiagonalScaleHermitian_Normal and perhaps some others are essentially the 
> same.
> 
> What about converting them into one MatDiagonalScale_Basic which would be the 
> default implementation if no type-specific implementation is provided?
> 
> I'm asking because I wanted to add the same to MATTRANSPOSE. But with my 
> proposal, this redundancy would be removed and additionally 
> MatDiagonalScale() would work for any current or future MatType while it 
> doesn't prevent providing an optimised version for explicit matrix types.
> 
> Note the same could be done for MatScale, MatShift, MatDiagonalSet and maybe 
> some others.
> 
> I also think such approach would promote using such high-level API functions 
> in higher PETSc layers and user codes because one wouldn't have to be afraid 
> those methods might not be implemented in input matrices.
> 
> Thanks for opinions
> 
> Vaclav

Reply via email to