[petsc-users] MatSetValuesCOO after MatDuplicate

[Maxime Bouyges]

Thanks for the prompt confirmation! I have to admit that I hadn't tested 
yet the memory performance of using COO instead of the classical 
MatSetValues. I will keep both approach in my code and do more 
performance checks (CPU and memory) before I take a decision. In any 
case, calling "again" MatSetPreallocationCOO after MatDuplicate is 
working so I can live with that. I just wanted to be sure that it was a 
"bug" (or a missing feature I would say) and not a misuse from me.

If you are curious, here is the context. I am using the Julia langage to 
solve an ODE using the DifferentialEquations.jl package 
(https://github.com/SciML/DifferentialEquations.jl). The system jacobian 
matrix is a Julia SparseMatrix 
(https://docs.julialang.org/en/v1/stdlib/SparseArrays/) with CSC format. 
I am using PETSc as a backend for the linear algebra (with 
https://github.com/bmxam/PetscWrap.jl). So at some point I have to fill 
a PETSc matrix with the values of a Julia CSC sparse matrix. Recovering 
the COO information from the Julia matrix is trivial, and using 
MatSetValuesCOO with this information seems very efficient. However, the 
ODE solver does several matrix duplication (wrapped as MatDuplicate in 
my case) and that's why I stumbled accross this bug. But as explained 
above 1) I can call MatSetPreallocationCOO each time MatDuplicate is 
called and 2) I can keep the classical MatSetValues and use an other way 
to fill the PETSc matrix.

Thanks again for your quick answer (and for the great library ;)) !

Best regards,

Maxime Bouyges

On 26/04/2023 23:26, Junchao Zhang wrote:
> 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/20230427/01a92930/attachment.html>