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