<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 3, 2015 at 9:58 AM, Sam Williams <span dir="ltr"><<a href="mailto:swwilliams@lbl.gov" target="_blank">swwilliams@lbl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think scalable implementations *should* reduce the bottom problem size to a single process.  Nevertheless, I don't think we specify that the bottom solve *must* be run on a single process.  </blockquote><div><br></div><div>This does violate one of our two (or is it just one) rules: HPGMG must be scale and architecture free.  No processes, no caches, no main memory, etc.</div><div><br></div><div>I just realized that since we do not specify the coarse grid solver nor its size, someone could just call the whole solve the coarse grid and do whatever they like ...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think we only specify the restrictions on the dimensions of the bottom solve.  </blockquote><div><br></div><div>How so?  Your implementation has some restrictions, but it's not in the specification.</div><div><br></div><div>If we specify restriction and prolongation, as we do now (I think), then I guess we can only refine by powers of 2, but we could define it more generally (eg, P_0 & P_1) and that would allow for odd coarsening to use MG all the way to one cell.  One could, at a coarse grid, put a nice grid over the ugly (eg, (2*13)^3) grid, and use more general interpolation, to get to a nice grid.  We do not have to worry about it this round, but something to think about.</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This flexibility could be beneficial for odd problem sizes like (11*2^k)^3 whose bottom solve may be 11^3.  Even if running on a single process, there can still be multiple threads, cores, or processors (e.g. single process spans a multisocket node) performing the bottom solve.  How one chooses to thread such an operations is an implementation choice.<br>
<br>
For the FV method, you are also required to sum the flux surfaces for each cell.  Obviously this is 6 terms that must be summed and not 1000, but I don't think we should mandate the order of that summation.  There is a deeper question as to whether adjacent cells must calculate common flux surfaces with the same order of operations.<br>
<br>
At this point, I'm not inclined to mandate reproducibility, but am curious to see quantitative/numerical data where it made a difference in HPGMG-FV.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
On Aug 3, 2015, at 9:20 AM, Jed Brown <<a href="mailto:jed@jedbrown.org">jed@jedbrown.org</a>> wrote:<br>
<br>
> Brian Van Straalen <<a href="mailto:bvstraalen@lbl.gov">bvstraalen@lbl.gov</a>> writes:<br>
><br>
>> Once you reach the bottom solver for full multigrid you should not be<br>
>> in the network at all anymore.  You would be computing a dot product<br>
>> over a few hundred doubles in L1 memory.<br>
><br>
> And the order of those doubles doesn't depend on the<br>
> network/fine-grid/number of processors (at least not in FE), so it's<br>
> reproducible in any precision and thus I don't know why we're having<br>
> this particular discussion about dot products that occur only on the<br>
> coarsest (serial) grid.<br>
><br>
> The summation order during restriction might not be reproducible<br>
> (depends on implementation details including whether you use<br>
> MPI_Waitsome versus MPI_Waitall), but can be made reproducible and<br>
> parallel-invariant if desired.<br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> HPGMG-Forum mailing list<br>
> <a href="mailto:HPGMG-Forum@hpgmg.org">HPGMG-Forum@hpgmg.org</a><br>
> <a href="https://hpgmg.org/lists/listinfo/hpgmg-forum" rel="noreferrer" target="_blank">https://hpgmg.org/lists/listinfo/hpgmg-forum</a><br>
<br>
_______________________________________________<br>
HPGMG-Forum mailing list<br>
<a href="mailto:HPGMG-Forum@hpgmg.org">HPGMG-Forum@hpgmg.org</a><br>
<a href="https://hpgmg.org/lists/listinfo/hpgmg-forum" rel="noreferrer" target="_blank">https://hpgmg.org/lists/listinfo/hpgmg-forum</a><br>
</div></div></blockquote></div><br></div></div>