<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"></head><body dir="auto">Hi Junchao,<div dir="auto"><br></div><div dir="auto">I share you pov, but I don't know what PETSc looks like deep down. I was afraid to suggest that because I guess handling the case where A is destroyed but B remains while pointing to the COO information of A... But if you can of course that will be nice (for me at least!). I will watch closely the next PETSc changelog ;).</div><div dir="auto"><br></div><div dir="auto">Maxime</div><div><br></div><div align="left" dir="auto" style="font-size:100%;color:#000000"><div>-------- Message d'origine --------</div><div>De : Junchao Zhang <junchao.zhang@gmail.com> </div><div>Date : 28/04/2023 21:52 (GMT+01:00) </div><div>À : Maxime Bouyges <maxime.bouyges@gmail.com> </div><div>Cc : Barry Smith <bsmith@petsc.dev>, petsc-users@mcs.anl.gov </div><div>Objet : Re: [petsc-users] MatSetValuesCOO after MatDuplicate </div><div><br></div></div><div dir="ltr"><div>Hi, Maxime,</div><div> 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.<br></div><div> <br></div><div><div><div data-smartmail="gmail_signature" class="gmail_signature" dir="ltr"><div dir="ltr">--Junchao Zhang</div></div></div><br></div></div><br><div class="gmail_quote"><div class="gmail_attr" dir="ltr">On Thu, Apr 27, 2023 at 2:15 PM Maxime Bouyges <<a href="mailto:maxime.bouyges@gmail.com">maxime.bouyges@gmail.com</a>> wrote:<br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
<div>
<p>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.</p>
<p>If you are curious, here is the context. I am using the Julia
langage to solve an ODE using the DifferentialEquations.jl package
(<a href="https://github.com/SciML/DifferentialEquations.jl">https://github.com/SciML/DifferentialEquations.jl</a>). The system
jacobian matrix is a Julia SparseMatrix
(<a href="https://docs.julialang.org/en/v1/stdlib/SparseArrays/">https://docs.julialang.org/en/v1/stdlib/SparseArrays/</a>) with CSC
format. I am using PETSc as a backend for the linear algebra (with
<a href="https://github.com/bmxam/PetscWrap.jl">https://github.com/bmxam/PetscWrap.jl</a>). 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.</p>
<p>Thanks again for your quick answer (and for the great library ;))
!</p>
<p>Best regards,</p>
<p>Maxime Bouyges<br>
</p>
<div>On 26/04/2023 23:26, Junchao Zhang
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>It sounds like we should do reference counting on the
internal data structures used by COO>.<br>
</div>
<div>
<div>
<div dir="ltr">
<div dir="ltr">--Junchao Zhang</div>
</div>
</div>
<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div class="gmail_attr" dir="ltr">On Wed, Apr 26, 2023 at
3:59 PM Barry Smith <<a href="mailto:bsmith@petsc.dev">bsmith@petsc.dev</a>>
wrote:<br>
</div>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><br>
Yes, it looks like a bug since no one tested this
situation.<br>
<br>
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?<br>
<br>
<br>
<br>
> On Apr 26, 2023, at 4:07 PM, Maxime Bouyges <<a href="mailto:maxime.bouyges@gmail.com">maxime.bouyges@gmail.com</a>>
wrote:<br>
> <br>
> Dear PETSc developers,<br>
> <br>
> 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:<br>
> MatCreate(comm, A)<br>
> MatSetUp(A)<br>
> MatSetPreallocationCOO(A, ncoo, coo_i, coo_j)<br>
> MatSetValuesCOO(A, coo_v, INSERT_VALUES) # -> works ok<br>
> MatDuplicate(A, MAT_DO_NOT_COPY_VALUES, B)<br>
> MatSetValuesCOO(B, coo_v, INSERT_VALUES) # ->
seg-fault<br>
> <br>
> 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.<br>
> <br>
> Best regards,<br>
> <br>
> Maxime Bouyges<br>
> <br>
<br>
</blockquote>
</div>
</blockquote>
</div>
</blockquote></div>
</body></html>