<div dir="ltr"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>The way to reduce the memory is to have the all-at-once algorithm (Mark is an expert on this). But I am not sure how efficient it could be implemented.   </div></div></div></div></div></div></blockquote><div><br></div><div>I have some data  from a 3D elasticity problem with 1.4B equations on:</div><div><br></div><div><div>/home1/04906/bonnheim/olympus-keaveny/Olympus/olympus.petsc-3.9.3.skx-cxx-O on a skx-cxx-O named <a href="http://c478-062.stampede2.tacc.utexas.edu">c478-062.stampede2.tacc.utexas.edu</a> with 4800 processors, by bonnheim Fri Mar 15 04:48:27 2019</div><div>Using Petsc Release Version 3.9.3, unknown </div></div><div><br></div><div>I assume this is on 100 Skylake nodes, but not sure.</div><div><br></div><div>Using the all-at-once algorithm in my old solver Prometheus. There are six levels and thus 5 RAPs. The time for these RAPs is about 150 Mat-vecs on the fine grid.</div><div><br></div><div>The total flop rate for these 5 RAPs was about 4x the flop rate for these Mat-vecs on the fine grid. This to be expected as the all-at-once algorithm is simple and not flop optimal and has high arithmetic intensity.</div><div><br></div><div>There is a fair amount of load imbalance in this RAP, but the three coarsest grids have idle processes. The max/min was 2.6 and about 25% of the time was in the communication layer. (hand written communication layer that I wrote in grad school)</div><div><br></div><div>The fine grid Mat-Vecs had a max/min of 3.1.</div><div><br></div><div>Anyway, I know this is not very precise data, but maybe it would help to (de)motivate its implementation in PETSc.</div><div><br></div><div>Mark</div></div></div></div>