[petsc-dev] MatDiagonalScale default implementation

[Hapla Vaclav]

Yes, this would a good option as well.

Also nice it would be easy to distinguish "implicit" matrices, where people shouldn't expect e.g. MatGetRow() to work, as subtypes of shell...

Vaclav

On 7 Dec 2018, at 11:28, Stefano Zampini <stefano.zampini at gmail.com<mailto:stefano.zampini at gmail.com>> wrote:

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<mailto: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<mailto: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<mailto: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<mailto: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/5ec515fa/attachment.html>