[petsc-dev] Discussion about time-dependent optimization moved from PR

[Stefano Zampini]

>
>
> I don't follow why multi-objective optimization would be any different.
> Are you supposing that the different objective functions would be
> implemented by different software packages?
>
>
It was related on how I was thinking to support multi-objective
optimization (and thus multi-gradient) with the current AdjointTS, since
each adjoint run would definitely have a different adapted time step.


>
> There are a bunch of other places that allow nonlinear dependence on
> parameters yet don't pass that parameter Vec, including
> TSSetRHSFunction.  If it is passed explicitly in one such function, it
> needs to be passed explicitly in all.
>
>
Yes but TSSetRHSFunction is supposed to work for standard ODE solves (not
with the parameter dependent analysis enabled). What if instead we add a
design Vec to TS data?


> > I can add a comment on the man pages that the vectors are guaranteed
> > to be the same one passed in my TSSetUpFromDesign, or remove
> > them. Your call.
>
> It's a recipe for confusion.  Either the parameters are never passed
> explicitly or they are always passed explicitly and should not be stored
> redundantly in the context, thus perhaps enabling some sort of higher
> level analysis that dynamically changes parameter values.  I would go
> with the former for now.
>
> > Users can do anything they want with the forward model context, but they
> > are not free to change the application context of the adjoints TS. Maybe
> > this should be improved by adding and extra slot to AdjointTSCtx to carry
> > over the  user context (for the adjoint I mean)?
>
> Why do you need to own the application context for the adjoint TS,
> versus using the context parameters to TSSetRHSJacobian, etc.
>
>
You're right, I could have used the contexts. This can be fixed.


>
> Comments that some lines of code can be deleted is a good sign that they
> should be deleted.
>
>
Will do

>
> I was responding to your statement that "Initial condition dependence on
> the parameters is limited to linear dependence on all the variables" in
> his approach.  General dependence is supported, the user is just
> expected to call it themselves rather than registering a callback that
> TS calls.
>
>
This implies some knowledge from the users about how to take this gradient,
which you cannot assume in general.
If you can automatize it, why not?



>
>
> I see reasons for the adjoint TS to hold a reference to the forward TS,
> but not vice-versa.  What is the use case for your proposal below?
>
> > TSGetAdjointTS(TS f,TS* a) {
> > if (!f->adjtts) TSCreateAdjointsTS(f,&f->adjts);
> > *a = f->adjts:
> > }
> >
> > and the corresponding Setter to allow users to do
> >
> > TSCreateAdjointTS(ts,&atts)
> > TSSetRHSJacobian(ats,...)
> > TSSetAdjointTS(ts,ats)
> >
> > or
> >
> > TSGetAdjointTS(ts,&atts)
> > TSSetRHSJacobian(ats,...)
>

Just automating TSComputeObjectiveAndGradient() for PDAEs with user defined
adjoints,




-- 
Stefano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20171017/053ae917/attachment.html>