I would turn on the ERR_ON_ALLOCATION option and then do your<div>MatSetValues(). That way the exact location of the allocation is clear.</div><div>MAybe this will expose the bug.</div><div><br></div><div> Matt<br><br><div class="gmail_quote">
On Sun, Feb 21, 2010 at 1:25 PM, Dave May <span dir="ltr"><<a href="mailto:dave.mayhem23@gmail.com">dave.mayhem23@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hello,<br>
I have a question about the usage of DAGetMatrix().<br>
Is there any possibility that the matrix preallocation and the indices<br>
returned from DAGetGlobalIndices() are incompatible with each other?<br>
<br>
To clarify my question, I use DAGetMatrix() with a DA created with the<br>
lx,ly,lz (local nodes sizes) specified. The resulting DA is used to<br>
represent a Q1 finite element mesh. I then use values return from<br>
DAGetGlobalIndices() to define the equation number for each dof<br>
associated with each element. In the past I've used this approach in<br>
parallel without any problems matrix preallocation issues, but I've<br>
never specified lx,ly,lz before.<br>
<br>
What I see now is that for certain grid resolutions and element<br>
combinations, -info reports that additional non-zeros are having to be<br>
allocated.<br>
<br>
Is my function to compute the element node relationship screwed, or is<br>
there an assumption about when and where DAGetMatrix() is valid. I<br>
suspect the former, but looking through the numbers I cannot see any<br>
problems.<br>
<br>
<br>
Cheers,<br>
<font color="#888888"> Dave<br>
</font></blockquote></div><br><br clear="all"><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>
</div>