<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 style="word-wrap:break-word;line-break:after-white-space"><div><div><br></div><div>Everything is fine with GAMG I think, please find the (trimmed) -eps_view attached. </div></div></div></blockquote><div><br></div><div>This looks fine. The eigen estimates are pretty low, but I don't know what they really are.</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>The problem is that, correct me if I’m wrong, there is no easy way to redistribute data efficiently from within PETSc when using fieldsplit with unbalanced number of unknowns per field. </div></div></div></blockquote><div><br></div><div>Note, as you scale up the coarse grids become more important re complexity. So the process reduction and potential repartitioning will become more noticable. At extreme scale you can spend a majority of the time in the coarse grids.</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>For the other three fields, the solvers are still behaving somehow properly. Now if I’d like to optimize this some more, I’d probably need to switch from a fieldsplit to a MatNest, with submatrices from different communicators, so that I don’t have all processes handling the pressure space. But this is apparently not allowed.</div><div><br></div><div>Thanks,</div><div>Pierre</div><div><br></div><div></div></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><div></div><div><br></div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_quote"><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_9210919351242793226m_-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>
</div></blockquote></div><br></div></blockquote></div></div>