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@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.zamp...@gmail.com
> <mailto:stefano.zamp...@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@mcs.anl.gov <mailto:petsc-users@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
