<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5"><div><br></div></div></div><div>I want to say again how much I dislike ad hoc memory layouts through contexts</div><div>and the like. We have a perfectly good layout descriptor (DM) that should be used</div><div>to describe data layout.</div><div><br></div></div></div></div></blockquote><div><br></div><div>Why do you say ad-hoc memory layout? the design vector is an input, and users can decide to layout memory as they want. What do you propose?</div><div>DMGetDesignVec()?</div><div>DMGetDesignDM()?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>  Matt</div><div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
> Users can do anything they want with the forward model context, but they<br>
> are not free to change the application context of the adjoints TS. Maybe<br>
> this should be improved by adding and extra slot to AdjointTSCtx to carry<br>
> over the  user context (for the adjoint I mean)?<br>
<br>
</span>Why do you need to own the application context for the adjoint TS,<br>
versus using the context parameters to TSSetRHSJacobian, etc.<br>
<br>
>> > <a href="https://bitbucket.org/petsc/petsc/src/c2e9112e7fdfd89985f9ffc4d68b0d" rel="noreferrer" target="_blank">https://bitbucket.org/petsc/pe<wbr>tsc/src/c2e9112e7fdfd89985f9ff<wbr>c4d68b0d</a><br>
>> 46cf7cad52/src/ts/interface/ts<wbr>pdeconstrainedutils.c?at=<br>
>> stefano_zampini%2Ffeature-cont<wbr>inuousadjoint&fileviewer=file-<wbr>view-default#<br>
<span>>> tspdeconstrainedutils.c-579<br>
>> ><br>
>> > Here is how ex23.c uses it<br>
>> ><br>
>> > <a href="https://bitbucket.org/petsc/petsc/src/c2e9112e7fdfd89985f9ffc4d68b0d" rel="noreferrer" target="_blank">https://bitbucket.org/petsc/pe<wbr>tsc/src/c2e9112e7fdfd89985f9ff<wbr>c4d68b0d</a><br>
>> 46cf7cad52/src/ts/examples/tut<wbr>orials/ex23.c?at=stefano_zampi<wbr>ni%2Ffeature-<br>
>> continuousadjoint&fileviewer=f<wbr>ile-view-default#ex23.c-677<br>
>><br>
>> And yet you redo the scatter here instead of using what you stuffed into<br>
>> the context.  If you needed to redo it for correctness, you'd also need<br>
>> to in every other function that accesses design parameters.<br>
>><br>
> <a href="https://bitbucket.org/petsc/petsc/src/c2e9112e7fdfd89985f9ffc4d68b0d" rel="noreferrer" target="_blank">https://bitbucket.org/petsc/pe<wbr>tsc/src/c2e9112e7fdfd89985f9ff<wbr>c4d68b0d</a><br>
>> 46cf7cad52/src/ts/examples/tut<wbr>orials/ex23.c?at=stefano_zampi<wbr>ni%2Ffeature-<br>
>> continuousadjoint&fileviewer=f<wbr>ile-view-default#ex23.c-274<br>
>><br>
>><br>
> This is a leftover from a previous version of the code (there's also a<br>
> comment) that was not using TSSetSetUpFromDesign and it's definitely not<br>
> needed.<br>
<br>
</span>Comments that some lines of code can be deleted is a good sign that they<br>
should be deleted.<br>
<span><br>
>> >> > Both methods need the Jacobian of the DAE wrt the parameters: H<br>
>> >> > TSAdjointSetRHSJacobian(), S TSSetGradientDAE()<br>
>> >> ><br>
>> >> > Initial condition dependence on the parameters is implicitly computed<br>
>> in<br>
>> >> > Hong's code (limited to linear dependence on all the variables);<br>
>> >><br>
>> >> How so?  Once the user gets \lambda(time=0), they can apply the chain<br>
>> >> rule to produce any dependency on the parameter vector?<br>
>> >><br>
>> >>  Yes, the chain rule is implemented here<br>
>> ><br>
>> > <a href="https://bitbucket.org/petsc/petsc/src/c2e9112e7fdfd89985f9ffc4d68b0d" rel="noreferrer" target="_blank">https://bitbucket.org/petsc/pe<wbr>tsc/src/c2e9112e7fdfd89985f9ff<wbr>c4d68b0d</a><br>
>> 46cf7cad52/src/ts/interface/ts<wbr>pdeconstrainedutils.c?at=<br>
>> stefano_zampini%2Ffeature-cont<wbr>inuousadjoint&fileviewer=file-<wbr>view-default#<br>
>> tspdeconstrainedutils.c-254<br>
>><br>
>> I know you have a callback for it, but Hong's interface is plenty<br>
>> functional for such systems, they just call that derivative instead of<br>
>> writing and registering a function to do that.<br>
>><br>
><br>
> I'm not saying HOng's interface is not functional.<br>
<br>
</span>I was responding to your statement that "Initial condition dependence on<br>
the parameters is limited to linear dependence on all the variables" in<br>
his approach.  General dependence is supported, the user is just<br>
expected to call it themselves rather than registering a callback that<br>
TS calls.<br>
<span><br>
> The initial condition gradients allow to automatize the process in<br>
> TSComputeObjectiveAndGradient(<wbr>), TSComputeHessian(), and<br>
> MatMult_Propagator(). Anyway, the lambda variables are not modified by<br>
> AdjointTSComputeFinalGradient(<wbr>) (that adds the IC dependency) and<br>
> users can do whatever they want with them.<br>
><br>
> I know you don't like TSComputeObjectiveAndGradient(<wbr>),<br>
<br>
</span>I don't have a problem with the concept but don't want to rely on it.<br>
I'd rather discuss how to unify interfaces for discrete and continuous<br>
adjoints and get a PR for it merged before adding higher level<br>
interfaces.<br>
<span><br>
> but it's a code that anyway users have to write to compute a gradient<br>
> of the DAE not arising from a PDAE. How can this be automatized for<br>
> PDAEs? Should we store the AdjointTS inside the model TS and use<br>
> TSGetAdjointTS(ts,&ts->adjts) with<br>
<br>
</span>I see reasons for the adjoint TS to hold a reference to the forward TS,<br>
but not vice-versa.  What is the use case for your proposal below?<br>
<div class="m_234230227685428616HOEnZb"><div class="m_234230227685428616h5"><br>
> TSGetAdjointTS(TS f,TS* a) {<br>
> if (!f->adjtts) TSCreateAdjointsTS(f,&f->adjts<wbr>);<br>
> *a = f->adjts:<br>
> }<br>
><br>
> and the corresponding Setter to allow users to do<br>
><br>
> TSCreateAdjointTS(ts,&atts)<br>
> TSSetRHSJacobian(ats,...)<br>
> TSSetAdjointTS(ts,ats)<br>
><br>
> or<br>
><br>
> TSGetAdjointTS(ts,&atts)<br>
> TSSetRHSJacobian(ats,...)<br>
><br>
><br>
> --<br>
> Stefano<br>
</div></div></blockquote></div></div></div><br><br clear="all"><span class=""><div><br></div>-- <br><div class="m_234230227685428616gmail_signature" data-smartmail="gmail_signature"><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.caam.rice.edu/~mk51/" target="_blank">https://www.cse.buffalo.edu/~<wbr>knepley/</a><br></div></div></div></div></div>
</span></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Stefano</div>
</div></div>