<div dir="ltr"><div dir="ltr">On Tue, Mar 15, 2022 at 9:58 PM Nicolás Barnafi <<a href="mailto:nabw91@gmail.com">nabw91@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello, sorry to bring back this issue.<br>
<br>
I am observing some behavior that I don't understand to try to debug<br>
our code, so my question is: what happens when to set values to a<br>
matrix from dofs that don't belong to the processor? I.e. if processor<br>
0 has [0 1 2] and proc 1 has dofs [3 4 5], if I set the value in<br>
position (3,3) in proc 0, does this not complain during assemble as<br>
long as I preallocated sufficient rows, even if these do not coincide<br>
with the ones from MatSetSizes?<br></blockquote><div><br></div><div>Here is what happens. When you call MatSetValues(), if the value is for an off-process row, it is</div><div>stored in a MatStash object. When you call MatAssemblyBegin(), those values are sent to the</div><div>correct process, and inserted with the normal call. If there is insufficient allocation, you would get</div><div>an error at that time.</div><div><br></div><div>  THanks,</div><div><br></div><div>    Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Thanks in advance,<br>
Nicolas<br>
<br>
On Thu, Mar 10, 2022 at 2:50 AM Nicolás Barnafi <<a href="mailto:nabw91@gmail.com" target="_blank">nabw91@gmail.com</a>> wrote:<br>
><br>
> Thank you both very much, it is exactly what I needed.<br>
><br>
> Best regards<br>
><br>
> On Wed, Mar 9, 2022, 21:19 Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>> wrote:<br>
>><br>
>> On Wed, Mar 9, 2022 at 5:13 PM Barry Smith <<a href="mailto:bsmith@petsc.dev" target="_blank">bsmith@petsc.dev</a>> wrote:<br>
>>><br>
>>><br>
>>>   You need to do a mapping of your global numbering to the standard PETSc numbering and use the PETSc numbering for all access to vectors and matrices.<br>
>>><br>
>>>    <a href="https://petsc.org/release/docs/manualpages/AO/AOCreate.html" rel="noreferrer" target="_blank">https://petsc.org/release/docs/manualpages/AO/AOCreate.html</a> provides one approach to managing the renumbering.<br>
>><br>
>><br>
>> You can think of this as the mapping to offsets that you would need in any event to store your values (they could not be directly addressed with your random indices).<br>
>><br>
>>   Thanks,<br>
>><br>
>>      Matt<br>
>><br>
>>><br>
>>>   Barry<br>
>>><br>
>>><br>
>>> On Mar 9, 2022, at 3:42 PM, Nicolás Barnafi <<a href="mailto:nabw91@gmail.com" target="_blank">nabw91@gmail.com</a>> wrote:<br>
>>><br>
>>> Hi community,<br>
>>><br>
>>> I have an application with polytopal meshes (elements of arbitrary shape) where the distribution of dofs is not PETSc friendly, meaning that it is not true that cpu0 owns dofs [0,a), then cpu1 owns [a,b) and so on, but instead the distribution is in fact random. Another important detail is that boundary dofs are shared, meaning that if dof 150 is on the boundary, each subdomain vector has dof 150.<br>
>>><br>
>>> Under this considerations:<br>
>>><br>
>>> i) Is it possible to give an arbitrary mapping to the matrix structure or is the blocked distribution hard coded?<br>
>>> ii) Are the repeated boundary dofs an issue when computing a Fieldsplit preconditioner in parallel?<br>
>>><br>
>>> Best regards,<br>
>>> Nicolas<br>
>>><br>
>>><br>
>><br>
>><br>
>> --<br>
>> What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
>> -- Norbert Wiener<br>
>><br>
>> <a href="https://www.cse.buffalo.edu/~knepley/" rel="noreferrer" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br>
<br>
<br>
<br>
-- <br>
Nicolás Alejandro Barnafi Wittwer<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div><div><br></div><div><a href="http://www.cse.buffalo.edu/~knepley/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div></div>