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 non-ideal 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 non-zero 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 clean-up 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 predictor-corrector 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 ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
