[petsc-dev] MatDiagonalScale default implementation

[Stefano Zampini]

I think the best solution is to have mattranspose, matnormal and similar to
be subclasses of matshell

Il giorno Dom 2 Dic 2018, 02:23 Smith, Barry F. via petsc-dev <
petsc-dev at mcs.anl.gov> ha scritto:

>
>    I am fine with you giving this a try. I fear it mostly just moves the
> complications from one (several :-)) places to a different place but.
>
>     Barry
>
>
> > On Dec 1, 2018, at 2:47 PM, Hapla Vaclav <vaclav.hapla at erdw.ethz.ch>
> wrote:
> >
> > 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
> >>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20181207/bac1b082/attachment.html>