<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">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">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>