From: Roy Stogner <roy@st...>  20080519 19:10:43

On Mon, 19 May 2008, Nasser Mohieddin Abukhdeir wrote: > A while ago I mentioned something about the time stepping algorithm > employed by AdaptiveTimeSolver as being nonideal for my PDE system. I > think I have implemented a very simple adaptive time solver based on the > local truncation error: > > core_time_solver>du() / calculate_norm(_system, *_system.solution) This isn't the local truncation error; it will be nonzero even if your solver and system are chosen in such a way that the time integration error is zero. > where it simply increases the time step up to a default of 2 > (max_growth=2). The only advantage of this approach for me application > is that the default algorithm is expensive (three nonlinear steps for > one effective time step) That's three nonlinear steps for two effective time steps, but yes, that's a reasonable complaint. > and, while locally it gives a good estimate of the error, is too > optimistic with its adaptive time stepping (my PDEs are highly > nonlinear). Also a reasonable complaint; I occasionally see the time stepper having to backtrack on an extremely nonlinear system. > If this makes any sense for inclusion into LibMesh's > AdaptiveTimeSolver I can cleanup and provide the code for review. That would be great, thanks! We've currently got the global_tolerance flag for use in choosing between a couple different refinement heuristics; another boolean would probably be the only interface change we'd need to add for your method, right? We might want to refactor that into an enum, a strategy pattern, subclasses, or something like that eventually, but that's what the untested() macro is for... If you've got time to play around with time solver adaptivity, one thing on our todo list is predictorcorrector schemes. Pick an explicit and an implicit scheme of the same order, use the difference between them to estimate your truncation error, then use the implicit scheme for your solution at the next time step to keep stability. That can actually end up being faster than just the implicit scheme alone, since the explicit result should give a better initial guess for your solver.  Roy 