<div dir="ltr">If you want to make a PR with your hack, we can help build out the infrastructure for what Jed is recommending.<div><br></div><div> Thanks,</div><div><br></div><div> Matt</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 4, 2023 at 2:56 PM Jed Brown <<a href="mailto:jed@jedbrown.org">jed@jedbrown.org</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">Yeah, we'd like the implementation to stay in alpha2.c. There could be a new interface TSAlpha2SetPredictorType (with -ts_alpha2_predictor_type [none,same_velocity,...]) or TSAlpha2SetPredictorFunction.<br>
<br>
David Kamensky <<a href="mailto:david@coreform.com" target="_blank">david@coreform.com</a>> writes:<br>
<br>
> Hi Jed,<br>
><br>
> The current workaround I'm using is very minimal and basically just moves<br>
> the definition of `TS_Alpha` from `alpha2.c` up to `petsc/private/tsimpl.h`<br>
> (and renames it to avoid a conflict with `TS_Alpha` in `alpha1.c`), but I<br>
> gather that we're really still not "supposed to" include that header in<br>
> applications. So, I don't know whether something like that would be<br>
> welcomed upstream. The actual computation of the predictor is done on the<br>
> application side.<br>
><br>
> Having options like `-ts_alpha_same_velocity` and<br>
> `-ts_alpha_same_acceleration` could probably be implemented by analogy to<br>
> `-ts_theta_initial_guess_extrapolate`, although they wouldn't quite cover<br>
> my specific use-case, where I'm only setting the predictor on part of the<br>
> solution vector. So, maybe something more general, like providing a<br>
> generalized-$\alpha$-specific option for a custom predictor callback that<br>
> takes `X0`, `V0`, and `A0` arguments would be the cleanest solution (and<br>
> some convenient shortcuts for full-solution same-velocity and<br>
> same-acceleration predictors could subsequently make use of that<br>
> infrastructure). I've been working quickly over the past week, but I might<br>
> be able to take some time to implement a more sustainable solution soon.<br>
><br>
> Thanks again,<br>
> David<br>
><br>
> On Fri, Aug 4, 2023 at 9:23 AM Jed Brown <<a href="mailto:jed@jedbrown.org" target="_blank">jed@jedbrown.org</a>> wrote:<br>
><br>
>> Some other TS implementations have a concept of extrapolation as an<br>
>> initial guess. Such method-specific initial guesses sound like they fit<br>
>> that pattern and would be welcome to be included in alpha2.c. Would you be<br>
>> willing to make a merge request to bring your work upstream?<br>
>><br>
>> David Kamensky <<a href="mailto:david@coreform.com" target="_blank">david@coreform.com</a>> writes:<br>
>><br>
>> > Hi Jed,<br>
>> ><br>
>> > What I'm trying to compute is basically a standard same-velocity or<br>
>> > same-acceleration predictor (although slightly more complicated, since<br>
>> I'm<br>
>> > restricting it to a sub-system). I hadn't looked into<br>
>> > `SNESSetComputeInitialGuess` yet, although one difficulty is that it<br>
>> would<br>
>> > need access to the `X0`, `V0`, and `A0` members of the `TS_Alpha` struct,<br>
>> > which is only defined in `alpha2.c`, and thus not available through the<br>
>> > API.<br>
>> ><br>
>> > For now, we just worked around this by patching PETSc to move the<br>
>> > definition of `TS_Alpha` up into a header to make it accessible.<br>
>> > (Modifying the library obviously introduces a maintenance headache; I<br>
>> also<br>
>> > considered just casting the `ts->data` pointer to `(char*)`, calculating<br>
>> > memory offsets based on `sizeof` the struct members, and casting back to<br>
>> > `Vec`, but that relies on compiler-specific assumptions, and could also<br>
>> > break if the PETSc source code was updated.) We also shuffled the order<br>
>> of<br>
>> > some calls to `VecCopy` and `TSPreStage` in the routine<br>
>> `TSAlpha_Restart`,<br>
>> > so that `TSPreStage` can set the initial guess, although that sounds like<br>
>> > it would be unnecessary if we instead used a callback in<br>
>> > `SNESSetComputeInitialGuess` that had access to the internals of<br>
>> > `TS_Alpha`.<br>
>> ><br>
>> > Thanks, David<br>
>> ><br>
>> > On Thu, Aug 3, 2023 at 11:28 PM Jed Brown <<a href="mailto:jed@jedbrown.org" target="_blank">jed@jedbrown.org</a>> wrote:<br>
>> ><br>
>> >> I think you can use TSGetSNES() and SNESSetComputeInitialGuess() to<br>
>> modify<br>
>> >> the initial guess for SNES. Would that serve your needs? Is there<br>
>> anything<br>
>> >> else you can say about how you'd like to compute this initial guess? Is<br>
>> >> there a paper or something?<br>
>> >><br>
>> >> David Kamensky <<a href="mailto:david@coreform.com" target="_blank">david@coreform.com</a>> writes:<br>
>> >><br>
>> >> > Hi,<br>
>> >> ><br>
>> >> > My understanding is that the second-order generalized-alpha time<br>
>> stepper<br>
>> >> in<br>
>> >> > PETSc uses a same-displacement predictor as the initial guess for the<br>
>> >> > nonlinear solver that executes in each time step. I'd like to be<br>
>> able to<br>
>> >> > set this to something else, to improve convergence. However, my<br>
>> >> > (possibly-naive) attempts to use `TSSetPreStep` and `TSSetPreStage`<br>
>> >> haven't<br>
>> >> > worked out. Is there any way to set a custom predictor?<br>
>> >> ><br>
>> >> > Thanks,<br>
>> >> > David Kamensky<br>
>> >><br>
>><br>
</blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div><div><br></div><div><a href="http://www.cse.buffalo.edu/~knepley/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div>