<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Apr 2, 2017 at 2:13 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Apr 2, 2017, at 9:25 AM, Justin Chang <<a href="mailto:jychang48@gmail.com">jychang48@gmail.com</a>> wrote:<br>
><br>
> Thanks guys,<br>
><br>
> So I want to run SNES ex48 across 1032 processes on Edison, but I keep getting segmentation violations. These are the parameters I am trying:<br>
><br>
> srun -n 1032 -c 2 ./ex48 -M 80 -N 80 -P 9 -da_refine 1 -pc_type mg -thi_mat_type baij -mg_coarse_pc_type gamg<br>
><br>
> The above works perfectly fine if I used 96 processes. I also tried to use a finer coarse mesh on 1032 but the error persists.<br>
><br>
> Any ideas why this is happening? What are the ideal parameters to use if I want to use 1k+ cores?<br>
><br>
<br>
</span>   Hmm, one should never get segmentation violations. You should only get not completely useful error messages about incompatible sizes etc. Send an example of the segmentation violations. (I sure hope you are checking the error return codes for all functions?).</blockquote><div><br></div><div>He is just running SNES ex48.</div><div><br></div><div>  Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888"><br>
  Barry<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> Thanks,<br>
> Justin<br>
><br>
> On Fri, Mar 31, 2017 at 12:47 PM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
><br>
> > On Mar 31, 2017, at 10:00 AM, Jed Brown <<a href="mailto:jed@jedbrown.org">jed@jedbrown.org</a>> wrote:<br>
> ><br>
> > Justin Chang <<a href="mailto:jychang48@gmail.com">jychang48@gmail.com</a>> writes:<br>
> ><br>
> >> Yeah based on my experiments it seems setting pc_mg_levels to $DAREFINE + 1<br>
> >> has decent performance.<br>
> >><br>
> >> 1) is there ever a case where you'd want $MGLEVELS <= $DAREFINE? In some of<br>
> >> the PETSc tutorial slides (e.g., <a href="http://www.mcs.anl.gov/" rel="noreferrer" target="_blank">http://www.mcs.anl.gov/</a><br>
> >> petsc/documentation/tutorials/<wbr>TutorialCEMRACS2016.pdf on slide 203/227)<br>
> >> they say to use $MGLEVELS = 4 and $DAREFINE = 5, but when I ran this, it<br>
> >> was almost twice as slow as if $MGLEVELS >= $DAREFINE<br>
> ><br>
> > Smaller coarse grids are generally more scalable -- when the problem<br>
> > data is distributed, multigrid is a good solution algorithm.  But if<br>
> > multigrid stops being effective because it is not preserving sufficient<br>
> > coarse grid accuracy (e.g., for transport-dominated problems in<br>
> > complicated domains) then you might want to stop early and use a more<br>
> > robust method (like direct solves).<br>
><br>
> Basically for symmetric positive definite operators you can make the coarse problem as small as you like (even 1 point) in theory. For indefinite and non-symmetric problems the theory says the "coarse grid must be sufficiently fine" (loosely speaking the coarse grid has to resolve the eigenmodes for the eigenvalues to the left of the x = 0).<br>
><br>
> <a href="https://www.jstor.org/stable/2158375?seq=1#page_scan_tab_contents" rel="noreferrer" target="_blank">https://www.jstor.org/stable/<wbr>2158375?seq=1#page_scan_tab_<wbr>contents</a><br>
><br>
><br>
><br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div>
</div></div>