<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jun 1, 2014 at 10:46 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Mark,<br>
<br>
I tried to reset every-time: the number of iterations is now
constant during the whole simulation!<br>
I tried GMG instead of AMG as well: it works in this case too, so
the trick was to reset the ksp object each time.<br>
As you predicted, each solve takes longer since the ksp has to be
setup again. I noticed that the time increase is larger than 2x,
particularly for large grids. <br>
I need to optimize the solve now, maybe by resetting only when
needed.<br>
Could you help me with that please?<br></div></blockquote><div><br></div><div>This logic that you put in your code. You can setup a variable for a frequency of resetting, </div><div><br></div><div>if (mod(++count,reset_factor)==0) solver.<span style="font-family:arial,sans-serif;font-size:13px"> KSPReset(ksp); // or whatever.</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">You could check the iteration count after a solve and if it is too high.</span></div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<br>
Thanks,<br>
Michele<div class=""><br>
<br>
<div>On 05/28/2014 07:54 PM, Mark Adams
wrote:<br>
</div>
</div><div><div class="h5"><blockquote type="cite">
<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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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><font color="#888888"><br>
<br>
Michele</font></span>
<div>
<div><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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div></div>