[petsc-dev] Suggestions for MatProductCreate()

[hzhang at mcs.anl.gov]

Matt and Lisandro,
Let me explain a little more about new API for mat-mat operations, which
include MatMaMult (AB), MatPtAP (PtAP), MatMatMatMult (ABC), with a total 6
matproduct types.

1) MatProduct is logically similar to MatFactor, not a single Mat. Calling
MatProductCreate(A,B,NULL,&D);
MatProductSetType(D, MATPRODUCT_AB);
MatDestory(&A); // A is gone
MatDestory(&B); // B is gone
MatProductSymbolic(D);
 is equivalent to calling MatMatMult(null, null, ..., &D)
or MatGetFactor(null, ...,&F).
If you do this, you'll get segfault (I'll add additional error message for
this use case).

2) New API is an incremental improvement over the old API, e.g.,
MatMatMultSymbolic(A,B, fill,&C); MatMatMultNumeric(A,B,C)
are replaced by
MatProductCreate(A,B,NULL,&D);
MatProductSetType(D, MATPRODUCT_AB);
 MatProductSetFill(D,fill);
 MatProductSetFromOptions(D);
MatProductSymbolic(D):
MatProductNumeric(D);

There are at least two reasons we decided to introduce new API.
a) there are multiple implementations (algorithms) for some product types
and matrix types, e.g., A*B  and PtAP for mpiaij_mpiaij matrices.
Developers are adding more and more special implementations, e.g, for gpu
etc. Previously, the options of algorithms are selected in
MatMatMultSymbolic_xxx(...,&D) with random option names. However, some
options need to be selected before D is setup, and attached to D. For this
reason, we introduced new API, and add MatProductSetFromOptions(D) to
handle all the options. Note: the options can only be determined at the
level of producttype and mattype are known, thus the options are enabled in
MatProductSetFromOptions_mattype_producttype().

b) Reuse of MatProduct D = A*B means same A and B with updated values.
However, some users change A or B, some use different  D without knowing
original D might contain internal data structure that is associated with A
and B. The new API forces reuse same A, B, unless user
calls MatProductReplaceMats(A,B,C,D).

3) For MatProduct, I consider
MatProductSetFromOptions() is logically equivalent to MatSetFromOptions(),
MatProductSymbolic() is logically equivalent to MatSetUp(),
and
MatProductNumeric() assembles the matproduct  D repeatedly when A or B are
updated.

I'm willing to incorporate your thoughts and comments into this new API.
Hong

On Mon, Mar 23, 2020 at 4:29 PM Matthew Knepley <knepley at gmail.com> wrote:

> On Mon, Mar 23, 2020 at 5:12 PM Lisandro Dalcin <dalcinl at gmail.com> wrote:
>
>>
>>
>> On Mon, 23 Mar 2020 at 17:57, hzhang at mcs.anl.gov <hzhang at mcs.anl.gov>
>> wrote:
>>
>>> Lisandro:
>>>
>>>> MatProductSetFromOptions() is not really setting any options. It looks
>>>> like the correct name for this API is MatProductSetUp(). In any case, it
>>>> looks like both SetFromOptions() and SetUp() should be provided.
>>>>
>>>
>>> Not all product and matrix types enable algorithmic options. For those
>>> who do have options,
>>> MatProductSetFromOptions_mattype_producttype() enables it.
>>> See MatProductSetFromOptions_MPIAIJ_AB().
>>>
>>
>> I have to insist, you should separate SetFromOptions() from SetUp(). For
>> many types, SetFromOptions may be empty (you can even use a NULL pointer to
>> handle these cases), but the rest of the code that does setup stuff (that
>> is, preparing the data structures) should go SetUp() routines.
>> This design pattern is used everywhere in PETSc. That's the proper way to
>> do it, IMHO. This way is the one that gives maximum flexibility to power
>> users/developers, because some times developers may want to configure
>> objects with some parameters, and do a SetUp() without calling
>> SetFromOptions() to prevent users to mess up with the parameters the
>> developer carefully chose.
>>
>
> I agree here. We should not be using options in SetUp or setting up in
> SetFromOptions() since it might not be called. I am tying to fix all this
> in DM.
>
>    Matt
>
>
>> --
>> Lisandro Dalcin
>> ============
>> Research Scientist
>> Extreme Computing Research Center (ECRC)
>> King Abdullah University of Science and Technology (KAUST)
>> http://ecrc.kaust.edu.sa/
>>
>
>
> --
> What most experimenters take for granted before they begin their
> experiments is infinitely more interesting than any results to which their
> experiments lead.
> -- Norbert Wiener
>
> https://www.cse.buffalo.edu/~knepley/
> <http://www.cse.buffalo.edu/~knepley/>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20200323/5844b5cf/attachment.html>