On Sun, Jun 1, 2014 at 10:46 PM, Michele Rosso <[email protected]> wrote:
> Mark, > > I tried to reset every-time: the number of iterations is now constant > during the whole simulation! > 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. > 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. > I need to optimize the solve now, maybe by resetting only when needed. > Could you help me with that please? > This logic that you put in your code. You can setup a variable for a frequency of resetting, if (mod(++count,reset_factor)==0) solver. KSPReset(ksp); // or whatever. You could check the iteration count after a solve and if it is too high. > > Thanks, > Michele > > > On 05/28/2014 07:54 PM, Mark Adams wrote: > > > > > On Mon, May 26, 2014 at 12:20 PM, Michele Rosso <[email protected]> wrote: > >> Mark, >> >> thank you for your input and sorry my late reply: I saw your email only >> now. >> By setting up the solver each time step you mean re-defining the KSP >> context every time? >> > > 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. > > >> Why should this help? >> > > 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. > > >> I will definitely try that as well as the hypre solution and report back. >> Again, thank you. >> >> Michele >> >> >> On 05/22/2014 09:34 AM, Mark Adams wrote: >> >> 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. >> >> You also might try: >> >> -pc_type hypre >> -pc_hypre_type boomeramg >> >> >> >> >> On Mon, May 19, 2014 at 6:49 PM, Jed Brown <[email protected]> wrote: >> >>> Michele Rosso <[email protected]> writes: >>> >>> > Jed, >>> > >>> > thank you very much! >>> > I will try with ///-mg_levels_ksp_type chebyshev -mg_levels_pc_type >>> > sor/ and report back. >>> > Yes, I removed the nullspace from both the system matrix and the rhs. >>> > Is there a way to have something similar to Dendy's multigrid or the >>> > deflated conjugate gradient method with PETSc? >>> >>> Dendy's MG needs geometry. The algorithm to produce the interpolation >>> operators is not terribly complicated so it could be done, though DMDA >>> support for cell-centered is a somewhat awkward. "Deflated CG" can mean >>> lots of things so you'll have to be more precise. (Most everything in >>> the "deflation" world has a clear analogue in the MG world, but the >>> deflation community doesn't have a precise language to talk about their >>> methods so you always have to read the paper carefully to find out if >>> it's completely standard or if there is something new.) >>> >> >> >> > >
