<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <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 class="moz-txt-link-freetext" href="https://github.com/SciML/DifferentialEquations.jl">https://github.com/SciML/DifferentialEquations.jl</a>). The system
      jacobian matrix is a Julia SparseMatrix
      (<a class="moz-txt-link-freetext" 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 class="moz-txt-link-freetext" 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 class="moz-cite-prefix">On 26/04/2023 23:26, Junchao Zhang
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CA+MQGp-rNVVoa1mkQrxHT=sT0z-zCucVLdOQbrL8=_o7FVgL+g@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <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" class="gmail_signature"
              data-smartmail="gmail_signature">
              <div dir="ltr">--Junchao Zhang</div>
            </div>
          </div>
          <br>
        </div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Wed, Apr 26, 2023 at
          3:59 PM Barry Smith <<a href="mailto:bsmith@petsc.dev"
            moz-do-not-send="true" class="moz-txt-link-freetext">bsmith@petsc.dev</a>>
          wrote:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0px 0px 0px
          0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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" target="_blank"
            moz-do-not-send="true" class="moz-txt-link-freetext">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>
  </body>
</html>