<div class="gmail_quote">On Wed, Apr 20, 2011 at 00:35, Ethan Coon <span dir="ltr"><<a href="mailto:ecoon@lanl.gov">ecoon@lanl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div id=":6z">Ok, here's a patch that does the very very special case of:<br>
<br>
p=P=1, s > p, DMDA_BOUNDARY_PERIODIC in the z-direction.<br>
<br>
Note this is really only possible in the z-direction...</div></blockquote><div><br></div><div>That is the case that you usually want, otherwise DMDAVecGetArray has rather inefficient indexing.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div id=":6z"> when in the<br>
z-direction, we can just check if the global index < 0 or > x*y*z and<br>
adjust appropriately.  So this can't generalize to x- or y- directions<br>
(though it could do the y-direction in the 2D case, allowing one to do<br>
1D problems in a 2D algorithm?)<br>
<br>
Compared to the rest of the cruft in da3.c and how non-general the<br>
global index generation is overall, it's not actually that ugly...<br></div></blockquote><div><br></div><div>We should all go unstructured for everything. Then we would have already paid the storage cost of heavier data structures so many of the special cases go away. :-)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div id=":6z">
<br>
I've tested with s=2 and 3, BOX and STAR, and the indices look right<br>
(i.e. they are identical in the z-dimension).  But it's ugly, so please<br>
test with your stuff too Jed.</div></blockquote></div><div><br></div><div>It seems to be working with Andrew's MHD code so I've pushed your patch. Thank you Ethan.</div><div><br></div><div>Andrew, your code is running now with NZ=1. Your function evaluation still evaluates to zero so SNESSolve is not doing any iterations. I assume there is some other step to turn on your source terms.</div>