<div dir="ltr"><div>Just to provide an update here, the conclusion of our internal discussion was to backlog this on our end for now, in favor of more urgent tasks. Perhaps we can open an issue for this on the PETSc issue tracker (or comment on an existing issue for BDF, if it exists), and I can check in there if/when we come back to it. <br></div><div><br></div><div>Thanks, David<br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Jan 2, 2025 at 7:02 PM Barry Smith <<a href="mailto:bsmith@petsc.dev">bsmith@petsc.dev</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><br></div> Sure, I was suggesting you might implement it for your one-needed TSView_*/TSLoad_*. With a single template done we can easily add the rest.<div><br></div><div> I agree having an API to start with multiple solutions is a good idea and would be needed for any TSView_*/TSLoad_*. so that may be the simplest</div><div>way for you to get started. Or we can look at providing the new API if it is out of scope for you.</div><div><br></div><div> Barry<br><div><br><blockquote type="cite"><div>On Jan 2, 2025, at 5:47 PM, David Kamensky <<a href="mailto:david@coreform.com" target="_blank">david@coreform.com</a>> wrote:</div><br><div><div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Are you up to trying this by adding this functionality to
TSView_*/TSLoad_*, or should we try to fit in time to add this (needed)
support?</blockquote><div><br></div><div>I'll have to consult with the team to decide what direction we want to go. We may want to keep our restart data in a neutral format to support other uses of it (e.g., solution postprocessing), or to maintain consistency and interoperability with some of our non-PETSc time steppers (so that we can, e.g., restart from an intermediate step of a PETSc `TS` using a non-PETSc integrator). If we do stick with our more manual re-initialization of the `TS`, it might be preferable for us to implement an initialization option that allows us to provide an acceleration. (This would be useful even for purposes other than restarting, if a user has a cheaper problem-specific method for computing the initial acceleration, e.g., inverting a mass matrix against the initial configuration's force vector.)<br></div><div><br></div><div>In any case, getting consistent view/load behavior across all time integrators and testing it thoroughly would be significantly larger in scope than what we need.</div><div><br></div><div>Best, David<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 2, 2025 at 2:16 PM Barry Smith <<a href="mailto:bsmith@petsc.dev" target="_blank">bsmith@petsc.dev</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><br></div> David,<div><br></div><div> I think Stefano was saying the TSView/Load approach should be improved to save the additional vector(s) and use them in the restart. </div><div><br></div><div> Are you up to trying this by adding this functionality to TSView_*/TSLoad_*, or should we try to fit in time to add this (needed) support?</div><div><br></div><div> Barry</div><div><br></div><div><div><br><blockquote type="cite"><div>On Jan 2, 2025, at 2:34 PM, David Kamensky via petsc-users <<a href="mailto:petsc-users@mcs.anl.gov" target="_blank">petsc-users@mcs.anl.gov</a>> wrote:</div><br><div><div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">How are you currently restarting the simulation?</blockquote><div><br></div><div>I just reviewed the code, and we're not currently using the `TSView/Load` functions. We're just manually (de)serializing displacement, velocity, and acceleration data using a neutral format, populating PETSc `Vec`s with this data, and associating them with a new `TS` object via `TS2SetSolution` (and setting other relevant data, like time, time step size, etc.). However, `TS2SetSolution` only accepts displacement and velocity.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I think the correct way to handle this is to support storing/loading these extra vectors via TSView()/TSLoad().</blockquote><div><br></div><div>I took a quick look at the implementations of `TSView/Load`, and it looks like the "base class" (to borrow some OOP terminology) implementation in `ts/interface/ts.c` only saves/loads the solution vector, while the subclass-specific logic from `TSView_Alpha` in `ts/impls/implicit/alpha/alpha2.c` only adds some additional output writing the generalized-alpha parameters to ASCII viewers (and similar for BDF). So, following the `TSView/Load` path, I don't see where it would even save/load the velocity vector for 2nd-order-in-time integrators. Is it the case that this functionality is known to be incomplete, and you're suggesting that the best path forward would be to update it?</div><div><br></div><div>Thanks, David<br></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 2, 2025 at 10:41 AM Stefano Zampini <<a href="mailto:stefano.zampini@gmail.com" target="_blank">stefano.zampini@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Note that BDF has the same issue. I think the correct way to handle this is to support storing/loading these extra vectors via TSView()/TSLoad().<div>How are you currently restarting the simulation?</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il giorno gio 2 gen 2025 alle ore 19:25 David Kamensky via petsc-users <<a href="mailto:petsc-users@mcs.anl.gov" target="_blank">petsc-users@mcs.anl.gov</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi,<br></div><div><br></div><div>I've recently been helping some co-workers with restarting PETSc time integrators from saved solution data.</div><br>It looks like the only supported path for restarting the generalized-alpha integrator for 2nd-order-in-time systems (`TSALPHA2`) is to follow the same procedure as initialization, in which two first-order-accurate half-steps are used to estimate an acceleration from the given displacement and velocity. However, the resulting acceleration is not exactly equivalent to the intermediate one that would have been used by the integrator if the integration simply proceeded without restarting. This prevents exact reproducibility of computations from saved intermediate results. (An analogous issue would also affect `TSALPHA` for first-order-in-time
problems, where velocity is estimated on initialization/restart.)<br><br>Am I misunderstanding this, or missing a better method of restarting the 2nd-order generalized-alpha integrator? If not, would there be interest in adding an alternate initialization/restart option to the `TSALPHA2` integrator that takes a user-provided `Vec` for the initial/intermediate acceleration, and skips over the half-step estimation procedure?<br><br>Thanks, David</div>
</blockquote></div><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Stefano</div>
</blockquote></div>
</div></blockquote></div><br></div></div></blockquote></div>
</div></blockquote></div><br></div></div></blockquote></div></div>