On Wed, Mar 2, 2011 at 11:29 AM, Ethan Coon <span dir="ltr"><<a href="mailto:ecoon@lanl.gov">ecoon@lanl.gov</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Ok, I've gotten frustrated enough to generalize the DMDA Periodicity to<br>
allow for periodic, ghosted, or nonghosted individually in each<br>
dimension.<br>
<br>
The 1D case is done, but one design choice regarding the higher<br>
dimensional cases that I wanted some advice on.  Is there a reason to<br>
not use negative indices in the construction of the index sets that<br>
specify the global-to-local scatter?  In the construction of the<br>
"to" (local) index set, the STAR_STENCIL case specifically enumerates<br>
the pattern in both to and from index sets.  However, it would much<br>
cleaner to:<br></blockquote><div><br></div><div>If its simpler, I say use it. The -1's could be easily compressed out with any pass.</div><div><br></div><div>   Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

1. specify the full local domain in the "to" local IS<br>
2. generate the "from" IS with -1 in the corners (and in the ghost cells<br>
that have no corresponding global entry, as they are off the domain, in<br>
the DMDA_XYZGHOSTED case).<br>
<br>
With -1 in the IS, there would be no communication done, but the IS<br>
would be slightly larger.  Is the overhead associated with negative<br>
indices nontrivial?<br>
<br>
Ethan<br>
<div><div></div><div class="h5"><br>
<br>
<br>
On Tue, 2010-12-07 at 15:41 -0700, Ethan Coon wrote:<br>
> On Tue, 2010-12-07 at 13:45 -0600, Barry Smith wrote:<br>
> > DMDA_XYZGHOSTED does not exist for 2d and 3d it was added, I'm guessing, as an experiment and was never in the initial design of DMDA. To fully support it one needs to go back tot he design of DMDA and see how to have it properly done and not just bolt it on.  Some people like to use these types of ghost nodes so I agree it is a useful thing to have but who is going to properly add it?<br>

> ><br>
><br>
> At some point in the not-too-distant future I'll get frustrated enough<br>
> to look into this, but I don't have the time at the moment.  At first<br>
> glance it looks like:<br>
><br>
> - Ensure DMDA{X,Y,Z}Periodic() macros are used everywhere instead of<br>
> direct comparisons to dd->wrap (they aren't used everywhere currently).<br>
><br>
> - Define macros DMDA{X,Y,Z}Ghosted() to (in some places) replace<br>
> DMDA{X,Y,Z}Periodic() and then choosing the appropriate macro in the<br>
> right places.<br>
><br>
> - This probably doesn't merit a change in the DMDACreate* API (it would<br>
> affect a very large amount of user code).  The most obvious alternative<br>
> to an API change would be a larger, somewhat convoluted enum for the<br>
> PeriodicType (DMDA_XPERIODIC_YGHOSTED, DMDA_XYGHOSTED, etc) which could<br>
> at least be made backward compatible.<br>
><br>
> At least all of the functionality should be there already (since it's<br>
> needed in the periodic case)... it's just higher level code that would<br>
> need to change.<br>
><br>
> Ethan<br>
><br>
> ><br>
> > On Dec 7, 2010, at 1:30 PM, Jed Brown wrote:<br>
> ><br>
> > > On Tue, Dec 7, 2010 at 20:21, Ethan Coon <<a href="mailto:ecoon@lanl.gov">ecoon@lanl.gov</a>> wrote:<br>
> > > 'd like a DA where there are ghost cells on every boundary, and some of<br>
> > > those ghost cells (but not all) are filled in with periodic values.<br>
> > ><br>
> > > It would be useful to people doing explicit stuff if there was a way to get ghost nodes in the local vector without implying periodic communication (and weird coordinate management).<br>
> > ><br>
> > > A related issue for purely explicit is to have a way to VecAXPY without needing to copy to and from a global vector.  (TSSSP has low-memory schemes, paying for an extra vector or two is actually significant in that context, and (less significant) I'm certain I can cook up a realistic benchmark where the memcpy costs more than 10%.)  I think I know how to implement this sharing transparently (more-or-less using VecNest) so we could make it non-default but be able to activate it at runtime.<br>

> ><br>
> >    Why can you not use VecAXPY() on the local Vecs?<br>
> ><br>
> >    Barry<br>
> ><br>
> ><br>
> ><br>
> > ><br>
> > > Jed<br>
> ><br>
><br>
<br>
--<br>
------------------------------------<br>
Ethan Coon<br>
Post-Doctoral Researcher<br>
</div></div>Applied Mathematics - T-5<br>
<div><div></div><div class="h5">Los Alamos National Laboratory<br>
505-665-8289<br>
<br>
<a href="http://www.ldeo.columbia.edu/~ecoon/" target="_blank">http://www.ldeo.columbia.edu/~ecoon/</a><br>
------------------------------------<br>
<br>
</div></div></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>