[petsc-users] Reproducibility when restarting generalized-alpha

[David Kamensky]

>
> 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?


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

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.

Best, David

On Thu, Jan 2, 2025 at 2:16 PM Barry Smith <bsmith at petsc.dev> wrote:

>
>   David,
>
>     I think Stefano was saying the TSView/Load approach should be improved
> to save the additional vector(s) and use them in the restart.
>
>     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?
>
>     Barry
>
>
> On Jan 2, 2025, at 2:34 PM, David Kamensky via petsc-users <
> petsc-users at mcs.anl.gov> wrote:
>
> How are you currently restarting the simulation?
>
>
> 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.
>
> I think the correct way to handle this is to support storing/loading these
>> extra vectors via TSView()/TSLoad().
>
>
> 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?
>
> Thanks, David
>
>
> On Thu, Jan 2, 2025 at 10:41 AM Stefano Zampini <stefano.zampini at gmail.com>
> wrote:
>
>> 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().
>> How are you currently restarting the simulation?
>>
>> Il giorno gio 2 gen 2025 alle ore 19:25 David Kamensky via petsc-users <
>> petsc-users at mcs.anl.gov> ha scritto:
>>
>>> Hi,
>>>
>>> I've recently been helping some co-workers with restarting PETSc time
>>> integrators from saved solution data.
>>>
>>> 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.)
>>>
>>> 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?
>>>
>>> Thanks, David
>>>
>>
>>
>> --
>> Stefano
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20250102/ef70c77c/attachment-0001.html>