From: Nasser Mohieddin Abukhdeir <nasser.abukhdeir@mc...>  20080519 20:59:58

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 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. > 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 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 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/ 