<div dir="ltr">On Tue, Mar 26, 2013 at 12:32 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
   Dominik,<br>
<br>
     There is no copy of vector entries on the calls to VecGetArray/RestoreArray() so the overhead is minimal. Likely you would barely be able to measure a difference.<br></blockquote><div><br></div><div style>Calling these inside the loop requires caution, however, in case some process may have zero elements. (This often happens on coarse grids, for example.)</div>
<div style><br></div><div style>The problem is that VecRestoreArray() invalidates any cached norms. So if you run:</div><div style><br></div><div style>VecNorm(X,NORM_2,&xnorm_before);</div><div style>for (each local element) {</div>
<div style>  VecGetArray(X,&x);</div><div style>  VecRestoreArray(X,&x);</div><div style>}</div><div style>VecNorm(X,NORM_2,&xnorm_after);</div><div style><br></div><div style>if some process has no local entries, it will think that X has not been modified and will not enter the MPI_Allreduce() to compute 'xnorm_after', which is deadlock.</div>
<div style><br></div><div style>To avoid stuff like this, we recommend placing the VecGetArray() outside the loop, which is consistent with its designation as "logically collective".</div><div style><br></div><div style>
You can use VecGetArrayRead() without worrying about this problem.</div></div></div></div>