[petsc-users] MatSetValuesCOO after MatDuplicate

[Junchao Zhang]

It sounds like we should do reference counting on the internal data
structures used by COO>.
--Junchao Zhang


On Wed, Apr 26, 2023 at 3:59 PM Barry Smith <bsmith at petsc.dev> wrote:

>
>    Yes, it looks like a bug since no one tested this situation.
>
>    MatSetPreallocationCOO() is pretty heavy memory-wise. It essentially
> keeps a copy of all the coo_i, coo_j indices within the Mat as well as the
> usual matrix information. So in your scenario, you will have two copies of
> all this stuff; lots of memory. Is this really what you need?
>
>
>
> > On Apr 26, 2023, at 4:07 PM, Maxime Bouyges <maxime.bouyges at gmail.com>
> wrote:
> >
> > Dear PETSc developers,
> >
> > I am trying to use the MatSetValuesCOO function (very appropriate and
> performant for my case) but I am encountering a problem when I use it on a
> Mat obtained with MatDuplicate. It seems that the non-zero pattern is
> preserved by MatDuplicate, but not the "COO information". Here are the few
> steps to reproduce the problem:
> > MatCreate(comm, A)
> > MatSetUp(A)
> > MatSetPreallocationCOO(A, ncoo, coo_i, coo_j)
> > MatSetValuesCOO(A, coo_v, INSERT_VALUES) # -> works ok
> > MatDuplicate(A, MAT_DO_NOT_COPY_VALUES, B)
> > MatSetValuesCOO(B, coo_v, INSERT_VALUES) # -> seg-fault
> >
> > Is this an expected behaviour? Of course if I call again
> MatSetPreallocationCOO on the duplicated matrix it's ok but the performance
> is lost in my case. Is there a way to fix it? Thank you in advance.
> >
> > Best regards,
> >
> > Maxime Bouyges
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20230426/6d5b3b23/attachment-0001.html>