<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 20, 2013 at 6:04 PM, Karl Rupp <span dir="ltr"><<a href="mailto:rupp@mcs.anl.gov" target="_blank">rupp@mcs.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
As the comment noted, this is quite a hack and actually breaks the current implementation for GPU matrices. I think that the problem can be completely resolved by not checking for PETSC_DEFAULT and PETSC_DECIDE in the MPI preallocation above, but just forward d_nz and o_nz to the sequential preallocation routine. This way, the logic remains in MatSeqAIJSetPreallocation(), where MAT_NEW_NONZERO_ALLOCATION_ERR is only set if the user provided an explicit preallocation scheme.</blockquote>
</div><div class="gmail_extra"><br></div><div class="gmail_extra" style>Hmm, the 'nonew' member is accessed in the MATMPIAIJ so we have to either change the code to avoid ever using it from the top level or we need to propagate the setting back to the parent. See also this discussion:</div>
<br><a href="http://lists.mcs.anl.gov/pipermail/petsc-dev/2012-January/007121.html">http://lists.mcs.anl.gov/pipermail/petsc-dev/2012-January/007121.html</a><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">
<a href="https://bitbucket.org/petsc/petsc/commits/7827cd58">https://bitbucket.org/petsc/petsc/commits/7827cd58</a><br></div></div>