Thank you so much, This is exactly what I need. Just to clarify, these functions that you are mentioning already exist?
Or you are simply sketching out what is going to be needed? Thank you, -Alfredo On Thu, Mar 10, 2022 at 3:40 PM Zhang, Hong <[email protected]> wrote: > > > 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 > > -- Alfredo Duarte Graduate Research Assistant The University of Texas at Austin
