[petsc-users] MatSetValuesCOO after MatDuplicate

[Junchao Zhang]

Hi, Maxime,
  Thanks for the introduction. It sounds to me it makes sense to share the
COO information in MatDuplicate.  The data structure consumes a lot of
memory, making it more justified.  I will add it.

--Junchao Zhang


On Thu, Apr 27, 2023 at 2:15 PM Maxime Bouyges <maxime.bouyges at gmail.com>
wrote:

> 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/20230428/7e1cd601/attachment.html>