<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 7, 2016 at 1:04 PM, Matthew Knepley <span dir="ltr"><<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Fri, Jul 1, 2016 at 4:32 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br>
   The DOE SciDAC institutes have supported PETSc linear solver research/code development for the past fifteen years.<br>
<br>
    This email is to solicit ideas for linear solver research/code development work for the next round of SciDAC institutes (which will be a 4 year period) in PETSc. Please send me any ideas, no matter how crazy, on things you feel are missing, broken, or incomplete in PETSc with regard to linear solvers that we should propose to work on. In particular, issues coming from particular classes of applications would be good. Generic "multi physics" coupling types of things are too general (and old :-)) while  work for extreme large scale is also out since that is covered under another call (ECP). But particular types of optimizations etc for existing or new codes could be in, just not for the very large scale.<br>
<br>
    Rough ideas and pointers to publications are all useful. There is an extremely short fuse so the sooner the better,<br></blockquote><div><br></div></span><div>I think the suggestions so far are fine, however they all seem to start at the "how", whereas I would prefer we start at the "why". Maybe something like</div><div><br></div><div>1) How do we run at bandwidth peak on new architectures like Cori or Aurora?</div><div><br></div><div>Patrick and Rich have good suggestions here. Karl and Rich showed some promising numbers for KNL at the PETSc meeting.</div><div><br></div></div></div></div></blockquote><div><br></div><div>Future systems from multiple vendors basically move from 2-tier memory hierarchy of shared LLC and DRAM to a 3-tier hierarchy of fast memory (e.g. HBM), regular memory (e.g. DRAM), and slow (likely nonvolatile) memory  on a node.  Xeon Phi and some GPUs have caches, but it is unclear to me if it actually benefits software like PETSc to consider them.  Figuring out how to run PETSc effectively on KNL should be generally useful...</div><div><br></div><div>Jeff</div><div><br></div></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Jeff Hammond<br><a href="mailto:jeff.science@gmail.com" target="_blank">jeff.science@gmail.com</a><br><a href="http://jeffhammond.github.io/" target="_blank">http://jeffhammond.github.io/</a></div>
</div></div>