<div dir="ltr"><div>Hi Jed,</div><div><br></div><div>  Good to hear from you!     For the first cases where the geometry is not moving the matrix stays fixed for many many solves and shipping it once to the GPU makes perfect sense.</div><div><br></div><div>Mark has been helping us with our AMG parameter space.  plain GAMG aggregation has worked well for us (hence why my toying with writing it for ourselves).  Our own coarsening in Chombo has some bugs in it somewhere that make our homegrown GMG unreliable for complex embedded geometry.  GAMG done properly works.  You have to set some parameters correctly, but it works.</div><div><br></div><div>  So far OpenMP offload has serialization effects for kernel launch that we are digging through.   Since we have not been knighted with Summit access we are working on summitdev and the other GPU clusters we have laying around.  On Cori KNL we run with 200-800k unknowns per node.</div><div><br></div><div>Brian</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 19, 2018 at 1:16 PM, Jed Brown <span dir="ltr"><<a href="mailto:jed@jedbrown.org" target="_blank">jed@jedbrown.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Brian, how frequently do you need to update the matrix (thus rebuild the<br>
preconditioner)?<br>
<br>
If it is infrequent, we could (in the near term) provide AMG setup on<br>
CPU with solves on GPU.<br>
<br>
What is your typical problem size per node to be run on Summit?  What is<br>
your MPI/OpenMP(?) decomposition?<br>
<br>
Are these heterogeneous Poisson solves or are the equations to be solved<br>
implicitly more complicated?  Do you have experimental information about<br>
relative convergence rates/grid complexity/strong scalability for your<br>
operator solved using classical AMG (e.g., Hypre) versus smoothed (or<br>
plain) aggregation (ML, GAMG default)?<br>
<div class="HOEnZb"><div class="h5"><br>
Brian Van Straalen <<a href="mailto:bvstraalen@lbl.gov">bvstraalen@lbl.gov</a>> writes:<br>
<br>
> So Baky and I have been at the Brookhaven GPU Hackathon now for three days,<br>
> talking to everyone.  We have also been emailing with people who will<br>
> respond to us from the hypre team and the PETSc team, as well as reading<br>
> every blog post and mail archive and message board and from what we can<br>
> tell, a distributed AMG preconditioner will not be available for us on a<br>
> Summit platform for the foreseeable future.<br>
><br>
> There is a hypre build for CUDA, but it has a problem with it's use of<br>
> CUSP, and nobody seems to be working on it.<br>
><br>
> PETSc has some .cu cuda files for the SpMV and Vector operations but the<br>
> preconditioners are limited to point Jacobi and similar simple operations<br>
> and a version of ILU.  Neither works for our stiff projection in the<br>
> embedded boundary algorithms.   We built it and ran it and PETSc takes<br>
> several hundred iterations to get the residual down by a factor of 6.  We<br>
> need to get down to more like 10e-11 for this solve.<br>
><br>
> The AMG being worked on by the NVIDIA team is not targeted for multi-node<br>
> solving, and I haven't heard back from them in months.<br>
><br>
>   We are left with two options as I see it to meet our ECP Milestones:<br>
><br>
> 1. Build yet another interface, this time to see if there is a distributed<br>
> GPU AMG preconditioner in Trilinos<br>
><br>
>  2. Implement our own special-purpose EB-GMG solver written in Chombo.<br>
><br>
> I would love to be wrong about all this.<br>
><br>
> Brian<br>
><br>
> -- <br>
> Brian Van Straalen         Lawrence Berkeley Lab<br>
> <a href="mailto:BVStraalen@lbl.gov">BVStraalen@lbl.gov</a>        Computational Research<br>
> (510) 486-4976            Division (<a href="http://crd.lbl.gov" rel="noreferrer" target="_blank">crd.lbl.gov</a>)<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><span style="font-family:monospace,monospace">Brian Van Straalen         Lawrence Berkeley Lab<br><a href="mailto:BVStraalen@lbl.gov" target="_blank">BVStraalen@lbl.gov</a>        Computational Research<br>(510) 486-4976            Division (<a href="http://crd.lbl.gov" target="_blank">crd.lbl.gov</a>)</span><br></div></div>
</div>