Roy Stogner wrote: > > 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. > John pointed this out too, all I can say is "oops," what meant to do was take the error from the last iteration of nonlinear solver which I think makes sense as an estimate of the LTE. I'll go back to the drawing board for this taking into account your following suggestions (I am currently using an enum and default to the original AdaptiveTimeSolver method). > 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 would this be as simple as just adding an additional UnsteadySolver member to AdaptiveTimeSolver, so for example core_time_solver could be EulerSolver with theta=1 and (let's call it) aux_time_solver would then be another EulerSolver with theta=0. We then just march them in parallel:
1) run the explicit scheme using aux_time_solver 2) use the solution from aux_time_solver to seed the implicit scheme (core_time_solver) and then solve 3) estimate the LTE from the difference of the two solutions and calculate the new timestep 4) synchronize the current solution of the explicit solver (to that of the implicit solution) -- Nasser Mohieddin Abukhdeir Graduate Student (A.D. Rey Research Group) McGill University - Department of Chemical Engineering http://webpages.mcgill.ca/students/nabukh/web/ http://people.mcgill.ca/alejandro.rey/ ------------------------------------------------------------------------- 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
