[petsc-dev] MatDiagonalScale default implementation

[Hapla Vaclav]

Yes, that means that a significant part of MatShell logic would become default implementations. But I would now do that only with MatDiagonalScale as a proof-of-concept - then we can progressively do the same with the others. At some point it could happen even with axpy - I think it would be cool although more a complex task as you say.

Vaclav

> 1. 12. 2018 v 21:31, Smith, Barry F. <bsmith at mcs.anl.gov>:
> 
> 
>   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.hapla at 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
>