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 <[email protected]> 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
<[email protected]> 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
>
