<div dir="ltr"><br><div class="gmail_quote"><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"><div>If PETSc was an application, it could do whatever it wanted, but it's not.  If PETSc is a library that intends to meet the needs of HPC applications, it needs to support the programming models the applications are using.  </div></div></div></div></blockquote><div><br></div><div>To repeat, PETSc supports threads, currently with MKL kernels and third party solvers (hypre), and GPUs with native solvers and again through hypre. I'm sure we will add more mechanism in the future. (I really don't know how to say this any more clearly.)</div><div> </div><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"><div>Or I suppose you will continue to disparage everyone who doesn't bow down and worship flat MPI on homogeneous big-core machines as a divine execution model until your users abandon you for otherwise inferior software that is willing to embrace user requirements.</div></div></div></div></blockquote><div><br></div><div>I agree, and I suspect we have a consensus that we should not disparage threads publicly as much (or at all) in the future as we have. It just does not do any good. Those that get it get it and those that don't don't.</div><div> </div></div></div>