<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">I think we are that stage that Sam finished with: We are currently interested/concerned about round-off and imprecise floating-point and the final accuracy.  </div><div class=""><br class=""></div><div class="">I suspect that Jed is right and that mixed precision will have a hard time achieving proper truncation order, but I’m interested to see someone try.  We just need to be prepared for such submissions.    </div><div class=""><br class=""></div><div class="">As Sam says, odd sized problems might fit the platform better and give the best ranking output but will not have a single cell bottom solver, so you can get dot product variations.  </div><div class=""><br class=""></div><div class="">Some finite volume implementations (like Chombo) compute face flux values just once and re-use them, but FV schemes are typically defined in terms of exact arithmetic and most codes rely on recomputing.  I suspect future code transformations (scalarization, fusion, etc.) will increasing rely on commutative and associative transformations for performance.   Someone might want to try a segmental refinement technique at large levels of concurrency in the face of more pessimistic networks.</div><div class=""><br class=""></div><div class="">It might be a good idea to present a few slides at the SC15 BOF.  I won’t be there though (I did not have anything submitted to SC15 and so the deadline to request to attend has passed for LBL).</div><div class=""><br class=""></div><div class="">Brian</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 3, 2015, at 9:58 AM, Sam Williams <<a href="mailto:swwilliams@lbl.gov" class="">swwilliams@lbl.gov</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">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.  I think we only specify the restrictions on the dimensions of the bottom solve.  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 class=""><br class="">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 class=""><br class="">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 class=""><br class=""><br class=""><br class=""><br class="">On Aug 3, 2015, at 9:20 AM, Jed Brown <<a href="mailto:jed@jedbrown.org" class="">jed@jedbrown.org</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">Brian Van Straalen <<a href="mailto:bvstraalen@lbl.gov" class="">bvstraalen@lbl.gov</a>> writes:<br class=""><br class=""><blockquote type="cite" class="">Once you reach the bottom solver for full multigrid you should not be<br class="">in the network at all anymore.  You would be computing a dot product<br class="">over a few hundred doubles in L1 memory.  <br class=""></blockquote><br class="">And the order of those doubles doesn't depend on the<br class="">network/fine-grid/number of processors (at least not in FE), so it's<br class="">reproducible in any precision and thus I don't know why we're having<br class="">this particular discussion about dot products that occur only on the<br class="">coarsest (serial) grid.<br class=""><br class="">The summation order during restriction might not be reproducible<br class="">(depends on implementation details including whether you use<br class="">MPI_Waitsome versus MPI_Waitall), but can be made reproducible and<br class="">parallel-invariant if desired.<br class="">_______________________________________________<br class="">HPGMG-Forum mailing list<br class=""><a href="mailto:HPGMG-Forum@hpgmg.org" class="">HPGMG-Forum@hpgmg.org</a><br class="">https://hpgmg.org/lists/listinfo/hpgmg-forum<br class=""></blockquote><br class=""></div></blockquote></div><br class=""><div apple-content-edited="true" class="">
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;  "><div class=""><div class=""><font class="Apple-style-span" face="'Courier New'">Brian Van Straalen         Lawrence Berkeley Lab</font></div><div class=""><font class="Apple-style-span" face="'Courier New'"><a href="mailto:BVStraalen@lbl.gov" class="">BVStraalen@lbl.gov</a>         Computational Research</font></div><div class=""><font class="Apple-style-span" face="'Courier New'">(510) 486-4976             Division (<a href="http://crd.lbl.gov" class="">crd.lbl.gov</a>)</font></div></div><div class=""><br class=""></div><div class=""><br class=""></div></span><br class="Apple-interchange-newline">
</div>
<br class=""></body></html>