[Ipopt] IDX_STY and NEW_X in the Fortran sample (fwd)

[Wendel Melo]

>> I could use some more clarity - If NEW_X is 0 then I am safe returning
from the subroutine without doing any calculations, but if it is 1 then I
should do the calculations so that the values returned by the subroutine
are correct for the value of x supplied to it. Is that right?

No. You must provide the calculations in BOTH cases (NEW_X being 1 or 0)!
NEW_X is 1 if the the current point being evaluated is different from the
point evaluated in the last callback calling. NEW_X has the goal of enable
you, in some cases, to speed up some calculations if you need evaluate the
same point in different callbacks.

For example, you can be requested to evaluate the objective function in a
new point X1. After that, Ipopt can require you to evaluate the constraints
also in that same point X1. In this case, the callback evaluating the
objective will receive NEW_X as 1, but the callback evaluating the
constraints will receive NEW_X as 0.

>> Looking at the final result, it does appear to be a valid solution to
the
problem, but I am not using NEW_X to control anything yet.

It is probable you are doing some mistakes in the calculations. I suggest
you use the derivative checker to be sure if you are providing calculations
correctly.

Regards

Wendel Melo

El mié., 14 nov. 2018 a las 17:48, Daniel Feenberg (<feenberg at nber.org>)
escribió:

>
>
> On Wed, 14 Nov 2018, Stefan Vigerske wrote:
>
> > Hi,
> >
> > On 11/14/18 6:56 PM, Daniel Feenberg wrote:
> >>
> >> 2) I am unsure of how to handle NEW_X. Can I just add:
> >>
> >>     IF(NEW_X.EQ.1) return
> >
> > That would usually not give you what you want.
> >
> >> at the start of EV_G,EV_JACG,EV_F and EV_GRAD_F, after the
> >> declarations and before any computations? Is the constant
> >> 1 or 0? When I print NEW_X, it always seems to be zero.
> >
> > Yes, should be 0 or 1.
> >
> > NEW_X gives can additional information about the point to be evaluated:
> It is
> > 0 if any evaluation method was previously called with the same values in
> x,
> > and is 1 otherwise.
> > So ignoring NEW_X would be fine, but it might help you to safe some
> > computations in your implementations of the callbacks, but eventually
> the
> > callbacks should still provide the function values, gradients, or
> Hessian.
> >
>
> I could use some more clarity - If NEW_X is 0 then I am safe returning
> from the subroutine without doing any calculations, but if it is 1 then I
> should do the calculations so that the values returned by the subroutine
> are correct for the value of x supplied to it. Is that right? Maybe I
> don't understand something fundamental since NEW_X is always 0 in my small
> test calculations when passed to all the ev* subroutines except for calls
> to ev_g, where NEW_X is always 1. Even if I have 1 and 0 mixed up,
> shouldn't ev_g need at least 1 actual evaluation?
>
> Looking at the final result, it does appear to be a valid solution to the
> problem, but I am not using NEW_X to control anything yet.
>
> Daniel Feenberg
> NBER_______________________________________________
> Ipopt mailing list
> Ipopt at list.coin-or.org
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__list.coin-2Dor.org_mailman_listinfo_ipopt&d=DwICAg&c=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4&r=AEWIZiNSSlppb_jyQKA8GtHkg2N4WiI7Ya5btonYBgA&m=ZDplrYHbXSCEJAP_SLpFsREGMzeV8hPwky0Ik6pW-p4&s=K3jjuPpQiYFPJQ7DgaEIwN2A5jHKAHZTJTPy8m6COAM&e=
>


-- 
Wendel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/ipopt/attachments/20181114/cdc575af/attachment.html>