On Mon, 19 May 2008, Nasser Mohieddin Abukhdeir wrote: > 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'm not sure of that, either. The error on your last algebraic nonlinear solver iteration should depend on those solver tolerances, which don't necessarily have anything to do with your time discretization error. > 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. At this point we've differed enough from the original AdaptiveTimeSolver design that I'd refactor the class tree. Maybe make AdaptiveTimeSolver a branch class, with one leaf for the current behavior (with what name?) and another for the new PredictorCorrectorTimeSolver. Then you could rename core_time_solver as corrector_time_solver and call aux_time_solver predictor_time_solver, too. > We then just march them in parallel: > > 1) run the explicit scheme using aux_time_solver Right. I'd want the default diff_solver settings for that to be appropriate for linear problems, too; for forward Euler we're just solving a mass matrix. > 2) use the solution from aux_time_solver to seed the implicit scheme > (core_time_solver) and then solve Right. And since the solution is stored with the system, reusing it should be as simple as "doing nothing". ;-) > 3) estimate the LTE from the difference of the two solutions and calculate > the new timestep Right. > 4) synchronize the current solution of the explicit solver (to that of the > implicit solution) Again, "doing nothing" (other than the advance_timestep() you'd do anyway). ;-) The only catch that comes to mind is that the time solvers are also responsible for initializing old DiffSystem solution vectors. That's no trouble for forward vs backward Euler, but if you wanted to write an Adams-Bashforth predictor for Crank-Nicholson, you'd have to be careful that the former gets used in initialization since it needs to save more old vectors. That's probably a safe rule of thumb: "use the predictor for initialization"; unless someone tries something weird, the corrector solver is always going to need the same or less old information. --- 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
