> On Mar 10, 2022, at 2:51 PM, Jed Brown <[email protected]> wrote: > > Would the order be inferred by the number of vectors in TSBDFSetStepVecs(TS > ts, PetscInt num_steps, const PetscReal *times, const Vec *vecs)?
Ah! Yes. num_steps could be used to set bdf->k which is the current order of BDF. Hong (Mr.) > "Zhang, Hong" <[email protected]> writes: > >> It is clear to me now. You need TSBDFGetStepVecs(TS ts, PetscInt *num_steps, >> const PetscReal **times, const Vec *vecs) as Jed suggested so that you can >> access the work vectors for TSBDF. In addition, you need to save the step >> size and the current order to jumpstart BDF (without starting from BDF-1). >> Setting the step size is straightforward with TSSetTimeStep(). To >> access/recover the order, you need something like >> TSBDF{Set|Get}CurrentOrder(TS ts, PetscInt **order). >> >> Thanks, >> Hong (Mr.) >> >> On Mar 10, 2022, at 11:35 AM, Alfredo J Duarte Gomez >> <[email protected]<mailto:[email protected]>> wrote: >> >> Hello, >> >> The solutions y_n and y_n-1 are the same ones as those saved internally for >> the BDF-2. >> >> The practical problem is for example: run a simulation with a BDF-2 for 10 >> hrs, see that everything looks good and decide that this simulation is worth >> continuing for another 10 hrs. Except now when I start from that last >> solution, the TSBDF starts from a single solution and steps its way up to >> the BDF-2 (numerical noise appears), instead of simply being able to load >> the last two solutions from my HDF5 output file and continue as if it had >> not stopped. >> >> Maybe I confused you by referencing the TSBDF_Restart, instead of the >> "starting" procedure for higher order BDFs, I thought they were the same but >> maybe not. >> >> Thank you, >> >> -Alfredo >> >> >> >> On Thu, Mar 10, 2022 at 11:04 AM Zhang, Hong >> <[email protected]<mailto:[email protected]>> wrote: >> >> >> On Mar 10, 2022, at 10:05 AM, Alfredo J Duarte Gomez >> <[email protected]<mailto:[email protected]>> wrote: >> >> Hello Zhang and Hong, >> >> Thank you for your reply. >> >> As I described, I simply wanted to be able to restart a higher order BDF >> from a previous solution. >> >> For example, if I want to restart a BDF-2 solution I can simply load times >> (n is current time step ) t_n-1, t_n, load solutions y_n, and yn-1 from a >> restart file and continue integration with a BDF-2 formula as if it never >> stopped. >> >> Are y_n and yn-1 from the restart file different from the states saved >> internally for BDF-2? Are you trying to modify these states yourself? A >> restart is needed typically when you have discontinuities in the system, so >> the solutions before the discontinuity point have to be discarded. If you >> simply want to modify the states, there should be better ways than using >> checkpoint-restart. >> >> Hong (Mr.) >> >> >> >> This would replace the current default approach, which starts from a single >> time tn, solution yn and uses lower order BDF steps as you build up to the >> selected order. >> >> I am not sure why, but an abrupt change in integration order or time step >> leads to unwanted numerical noise in my solution, which I blame on the high >> nonlinearity of the system (I have tested extensively to rule out bugs). >> >> Thank you and let me know if you have any questions, >> >> -Alfredo >> >> On Wed, Mar 9, 2022 at 4:49 PM Zhang, Hong >> <[email protected]<mailto:[email protected]>> wrote: >> TSTrajectory supports checkpointing for multistage methods and can certainly >> be extended to multistep methods. But I doubt it is the best solution to >> Alfredo’s problem. Alfredo, can you elaborate a bit on what you would like >> to do? TSBDF_Restart is already using the previous solution to restart the >> integration with first-order BDF. >> >> Hong(Mr.) >> >>> On Mar 9, 2022, at 4:24 PM, Jed Brown >>> <[email protected]<mailto:[email protected]>> wrote: >>> >>> Can you restart using small low-order steps? >>> >>> Hong, does (or should) your trajectory stuff support an exact checkpointing >>> scheme for BDF? >>> >>> I think we could add an interface to access the stored steps, but there are >>> few things other than checkpointing that would make sense mathematically. >>> Would you be up for making a merge request to add TSBDFGetStepVecs(TS ts, >>> PetscInt *num_steps, const PetscReal **times, const Vec *vecs) and the >>> respective setter? >>> >>> Alfredo J Duarte Gomez <[email protected]<mailto:[email protected]>> >>> writes: >>> >>>> Good morning PETSC team, >>>> >>>> I am currently using a TSBDF object, which is working very well. >>>> >>>> However, I am running into trouble restarting higher order BDF methods. >>>> >>>> My problem is highly nonlinear, and when restarted for higher order BDF >>>> methods (using the TSBDF_Restart function), wiggles appear in a specific >>>> region of the solution. >>>> >>>> Is there any way I can initialize the higher order BDF restart loading >>>> previous solutions from a data file? I took a look at the code, but there >>>> is no obvious way to do this. >>>> >>>> Thanks, >>>> >>>> -Alfredo >>>> >>>> -- >>>> Alfredo Duarte >>>> Graduate Research Assistant >>>> The University of Texas at Austin >> >> >> >> -- >> Alfredo Duarte >> Graduate Research Assistant >> The University of Texas at Austin >> >> >> >> -- >> Alfredo Duarte >> Graduate Research Assistant >> The University of Texas at Austin
