<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, May 26, 2014 at 12:20 PM, Michele Rosso <span dir="ltr"><<a href="mailto:mrosso@uci.edu" target="_blank">mrosso@uci.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Mark,<br>
<br>
thank you for your input and sorry my late reply: I saw your email
only now.<br>
By setting up the solver each time step you mean re-defining the KSP
context every time? </div></blockquote><div><br></div><div>THe simplest thing is to just delete the object and create it again. THere are "reset" methods that do the same thing semantically but it is probably just easier to destroy the KSP object and recreate it and redo your setup code.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">Why should this help?<br></div></blockquote><div><br></div><div>AMG methods optimized for a particular operator but "stale" setup data often work well on problems that evolve, at least for a while, and it saves a lot of time to not redo the "setup" every time. How often you should "refresh" the setup data is problem dependant and the application needs to control that. There are some hooks to fine tune how much setup data is recomputed each solve, but we are just trying to see if redoing the setup every time helps. If this fixes the problem then we can think about cost. If it does not fix the problem then it is more serious.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
I will definitely try that as well as the hypre solution and report
back.<br>
Again, thank you.<span class="HOEnZb"><font color="#888888"><br>
<br>
Michele</font></span><div><div class="h5"><br>
<br>
<div>On 05/22/2014 09:34 AM, Mark Adams
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">If the solver is degrading as the coefficients
change, and I would assume get more nasty, you can try deleting
the solver at each time step. This will be about 2x more
expensive, because it does the setup each solve, but it might
fix your problem.
<div>
<br>
</div>
<div>You also might try:</div>
<div><br>
</div>
<div>
<div>-pc_type hypre</div>
<div>-pc_hypre_type boomeramg</div>
<div><br>
</div>
<div><br>
</div>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Mon, May 19, 2014 at 6:49 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">
<div>Michele Rosso <<a href="mailto:mrosso@uci.edu" target="_blank">mrosso@uci.edu</a>>
writes:<br>
<br>
> Jed,<br>
><br>
</div>
> thank you very much!<br>
> I will try with ///-mg_levels_ksp_type chebyshev
-mg_levels_pc_type<br>
> sor/ and report back.<br>
<div>> Yes, I removed the nullspace from both
the system matrix and the rhs.<br>
> Is there a way to have something similar to Dendy's
multigrid or the<br>
> deflated conjugate gradient method with PETSc?<br>
<br>
</div>
Dendy's MG needs geometry. The algorithm to produce the
interpolation<br>
operators is not terribly complicated so it could be done,
though DMDA<br>
support for cell-centered is a somewhat awkward. "Deflated
CG" can mean<br>
lots of things so you'll have to be more precise. (Most
everything in<br>
the "deflation" world has a clear analogue in the MG world,
but the<br>
deflation community doesn't have a precise language to talk
about their<br>
methods so you always have to read the paper carefully to
find out if<br>
it's completely standard or if there is something new.)<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div></div>