<div dir="ltr">Ok, will do. It may take me a few days to get a minimal reproducible example though since the rest of the program has gotten quite large.<div><br></div><div>Thanks,</div><div>Sreeram</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 16, 2023 at 8:27 PM Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</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"><div dir="ltr"><div dir="ltr">On Thu, Nov 16, 2023 at 6:19 PM Sreeram R Venkat <<a href="mailto:srvenkat@utexas.edu" target="_blank">srvenkat@utexas.edu</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"><div dir="ltr"><div dir="ltr" class="gmail_signature"><div dir="ltr"><div style="color:rgb(34,34,34)">I have a program which reads a vector from file into an array, and then uses that array to create a PETSc Vec object. The Vec is defined on the global communicator, but not all processes actually contain entries of it. For example, suppose we have 4 processors, and the vector is of size 10. Rank 0 will contain entries 0-4 and Rank 1 will contain entries 5-9. Ranks 2 and 3 will not have any entries of the Vec.</div><div style="color:rgb(34,34,34)"><br></div><div style="color:rgb(34,34,34)">This Vec is then used as an input to other parts of the code, and those work fine. However, if I try to take the norm of the Vec with VecNorm(), I get the error</div><div style="color:rgb(34,34,34)"><br></div><div style="color:rgb(34,34,34)">`MPI_Allreduce() called in different locations (code lines) on different processors`<br></div><div style="color:rgb(34,34,34)"><br></div><div style="color:rgb(34,34,34)">The stack trace shows that ranks 0 and 1 (from the above example) are still in the VecNorm() function while ranks 2 and 3 have moved on to a later part of the code. If I add a PetscBarrier() after the VecNorm(), I find that the program hangs. </div><div style="color:rgb(34,34,34)"><br></div><div style="color:rgb(34,34,34)">The funny thing is that part of the code duplicates the Vec with VecDuplicate() and assigns to the duplicated vector the result of some computations. The duplicated Vec has the same layout as the original Vec, but taking VecNorm() on the duplicated Vec works fine. If I use VecCopy(), however, the copied Vec also causes VecNorm() to hang. I've printed out the original Vec, and there are no corrupted/NaN entries.</div><div style="color:rgb(34,34,34)"><br></div><div style="color:rgb(34,34,34)">I have a temporary workaround where I perturb the original Vec slightly before copying it to another Vec. This causes the program to successfully terminate.</div><div style="color:rgb(34,34,34)"><br></div><div style="color:rgb(34,34,34)">Any advice on how to get VecNorm() working with the original Vec?</div></div></div></div></blockquote><div><br></div><div>Vecs with empty layouts work fine, so it must be something else about how it is created.</div><div><br></div><div>In order to track it down, I would first make a short program that just creates the Vec as you say and see if it hangs. If so, just send it and we will debug it. If not, I would systematically cut down your program until you get something that hangs that you can send to us.</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"><div dir="ltr"><div dir="ltr" class="gmail_signature"><div dir="ltr"><div style="color:rgb(34,34,34)">Thanks,</div><div style="color:rgb(34,34,34)">Sreeram</div></div></div></div>
</blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><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>
</blockquote></div>