<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><blockquote type="cite"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div class="gmail_quote"><div><br></div><div>Do you mean the coarse grids? GAMG reduces active processors (and repartitions the coarse grids if you ask it to) like telescope.</div></div></div></div></blockquote><div><br></div><div>No I was talking about the fine grid. If I do this (telescope then GAMG), </div></div></div></blockquote><div><br></div><div>What does Telescope do on the fine grids? Is this a structured grid and Telescope does geometric MG?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><div>MatMultTranspose and MatMultAdd perform OK, but the smoother (MatSOR) takes more and more time as one would have guessed… it seems that there is no easy way to make this strong scale.</div><br></div></div></blockquote><div><br></div><div>Strong scaling will always stop at some point. The question is where. I'm not seeing any data on where it is stopping (I have not dug into the data files).</div><div><br></div><div>My first suspicion here was that GAMG stops coarsening and there are many coarse grids (ie, crazy behavior). I have seen this occasionally.</div><div><br></div><div>Also, did you check the iteration count in GAMG. I'm not sure if this is a convergence problem or a complexity problem.</div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><blockquote type="cite"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div class="gmail_quote"><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">>> 2) have the sub_0_ and the sub_1_ work on two different nonoverlapping communicators of size PETSC_COMM_WORLD/2, do the solve concurrently, and then sum the solutions (only worth doing because of -pc_composite_type additive). I have no idea if this easily doable with PETSc command line arguments<br>><span class="m_-5551793458628865409Apple-converted-space"> </span><br>> 1) is the more flexible approach, as you have better control over the system sizes after 'telescoping’.<br><br>Right, but the advantage of 2) is that I wouldn't have one half or more of processes idling and I could overlap the solves of both subpc in the PCCOMPOSITE.<br><br>I’m attaching the -log_view for both runs (I trimmed some options).<br><br>Thanks for your help,<br>Pierre<br><br><br>> Best regards,<br>> Karli</blockquote></div></div></div></blockquote></div><br></div></blockquote></div></div>