Barry Smith <bsm...@mcs.anl.gov> writes: >> On Oct 17, 2017, at 9:20 AM, Jed Brown <j...@jedbrown.org> wrote: >> >> Barry Smith <bsm...@mcs.anl.gov> writes: >> >>>> On Oct 17, 2017, at 7:43 AM, Stefano Zampini <stefano.zamp...@gmail.com> >>>> wrote: >>>> >>>> >>>> >>>> >>>> What happens if you call TSCreateAdjointsTS() on a TS obtained with >>>> TSCreateAdjointsTS()? Is the resulting TS useful? >>>> >>>> >>>> I don't think so. >>> >>> Hmm, this is rather bothersome. So the new TS that comes out is not >>> really a full-featured TS (using your new extended TS object that >>> knows about adjoints)? >> >> Is it useful to precondition Newton with Newton preconditioned with >> Newton? >> >>> It is like a subclass of TS that can only do timestepping? This >>> goes back to my concern that TS shouldn't be overloaded with all >>> the adjoint sensitivity stuff, there should be a higher level >>> PetscSensi object that does sensitivities and it contains multiple >>> TS for the ODE/DAE integrator and one for "reverse" mode. >> >> Let's not mix together Stefano's TSComputeObjectiveAndGradient (which >> could easily go into a helper PetscSensi) with the control flow needed >> to create/integrate an adjoint system. > > Jed, > > I am not mixing them! I am not even considering the > TSComputeObjectiveAndGradient() at all I am only considering > the "the control flow needed to create/integrate an adjoint system." My > PetscSensi is not for TSComputeObjectiveAndGradient level stuff.
Okay, interesting. > >> In my opinion, it must be >> possible to have a comparable/same interface to create a discrete >> adjoint (which depends on the forward implementation) as to create a >> continuous adjoint (with customizable space and time discretization). > > Absolutely and fundamentally. No argument at all about this. > >> >> I think we should postpone discussion of higher level convenience >> functions like TSComputeObjectiveAndGradient or some new organization >> thereof until we agree about the basic representation of adjoints. > > Totally agree and that is what I have done. > >> My >> preference is for TSCreateAdjointTS() which the user can customize to >> use arbitrary time integration methods (thus becoming a >> "continuous-in-time" adjoint) and to use different spatial >> discretizations (for consistency with the adjoint PDE). > > I understand, I think TSCreateAdjointTS() is not the right model. I think > that the correct model is, for example > > PetscSensiCreate() > PetscSensiSetObjective.... or whatever etc etc > PetscSensiGetIntegrator(,&TS) > PetscSensiGetAdjointIntegrator(,&TS). How would PetscSensiGetAdjointIntegrator be implemented? Since it needs to be able to create a discrete adjoint (which depends on the forward TS implementation), the control flow *must* go through TS. What does that interface look like? > ... > > Note I am not married to the current model of TSSolve/TSAdjointSolve(). > > Barry
