Unsmooth points at the beginning and end of control function

[Song921012]

Hello, Pulsipher, appreciate your work on InfiniteOpt. While solving the following optimal control problem

The optimal control function should be smooth. But the numerical optimal results has unsmooth points at the beginning and end.

I test many examples, it happened in most examples. Why it happens and how to deal with it?

using InfiniteOpt, Ipopt, Plots
using KNITRO
# Parmeters
# Time span
t0 = 0
tf = 1
# Initial values
x1 = 1
# Model
model = InfiniteModel(KNITRO.Optimizer)
# infinite_parameter
@infinite_parameter(model, t ∈ [t0, tf], num_supports = 101)
# variable
@variable(model, x ≥ 0, Infinite(t))
@variable(model, u, Infinite(t), start = 0)
# objective
@objective(model, Min, x(1)^2+∫(u^2, t))
# constraint
@constraint(model, x(0) == x1)
@constraint(model, x_constr, ∂(x, t) == x + u)
# Optimization
print(model)
optimize!(model)
# Visulization
ts = value(t)
u = value(u)
x = value(x)

@show plot(ts, u)
@show plot(ts, x)

[pulsipher]

Hi @Song921012, welcome to the InfiniteOpt discussion forum! (I moved this to the forum since it constitutes a modeling question)

To answer your question, we first need to think of how this problem is solved. By default, InfiniteOpt will project the formulation onto discrete support points (i.e., employ direct transcription) and approximate the derivatives using backward finite difference (note other derivative approximations are available as explained here). With direct transcription approaches, the control trajectory is generally taken to be piece-wise continuous (not necessarily smooth e.g., bang-bang control). However, state variables are generally taken to be continuous and smooth (like x in this case as shown in the plot below).

Now for optimal control problems u(0) pertains to an extra degree of freedom that has no effect on the optimization problem (for this reason finite optimal control problems exclude u(0) from the formulation).

In this example, the terminal state objective drives the final control action that you see. To some extent this is an artifact of using the direct transcription approach with the solver can exploit a little on the last time step. Again, to this affect most finite-time approaches truncate the final control point.

Hence, with optimal control problems like this one that use direct transcription approaches, people will commonly truncate the first and/or last control variables points. InfiniteOpt doesn't do this automatically since it is intended for general infinite-dimensional problems . However, we do have plans in the works to enable to control specific features (e.g., #216 and #199). We also plan to add an FAQ section (#217) to address common questions/considerations for specific problem domains like optimal control).

[pulsipher]

I should also mention that the exact behavior of u(t) at the domain boundaries is determined by the choice of derivative approximation method using the derivative_method keyword argument.

[Song921012]

@pulsipher Really appreciate your time and response! By the way,

(1) could you please show me a link to the api for all the choices of derivative_method?
I didn't find the api for choices of derivative_method. I know OrthogonalCollocation().

(2) Are choices of derivative_method associated with the kind of direct methods to solve optimal control problem, such as direct collection, orthogonal collection? Is multiple shooting method supported?

[pulsipher]

1.) Toward the end of the derivative basic usage section there is a table of the various choices with hyperlinks to the API of each. Similarly, you can directly look at the derivative API manual here.

2.) In this context, the derivative_method indicates what technique will be used to approximate the derivatives in the direct transcription approach. Currently, FiniteDifference and OrthogonalCollocation approaches are supported for this. This is specific for the TranscriptionOpt backend. I am currently working on a fundamental rewrite of our transformation backend API (#248) that will enable us to create a wide variety of transformation techniques to solve the problem (e.g., multiple shooting). The new API will also make the use of transformations more transparent to the user and will make them more flexible.

[Song921012]

Got it! Really help me a lot. Thank you for your efforts.

[DarioSlaifsteinSk]

Re-opening this discussion with some small details.
if I change the derivative_method to

@infinite_parameter(model, t ∈ [t0, tf], num_supports = 101, derivative_method=FiniteDifference(Forward(), true))

The results are

But if you change to false

@infinite_parameter(model, t ∈ [t0, tf], num_supports = 101, derivative_method=FiniteDifference(Forward(), false))

they change to:

how should I modify the rest of the code for the second option to work?
The guide says:
"Note that in this case, the boundary relation corresponds to $n=0$ and would be included if we set FiniteDifference(Forward(), true) or would be excluded if we let the second argument be false. We recommend, selecting false when an initial condition is provided. Also, note that a terminal condition should be provided when using this method since an auxiliary equation for the derivative at the terminal point cannot be made. Thus, if a terminal condition is not given terminal point derivative will be a free variable."

but I'm not so sure how to implement it.

[pulsipher]

You'll need to add a terminal condition such as

@constraint(model, x(tf) == 0.5) # TODO replace `0.5` with the actual terminal value

Otherwise, you introduce additional degrees of freedom that invalidate the assumptions for the derivative approximation scheme.

[DarioSlaifsteinSk]

But what happens if I need the optimizer to actually find out the terminal value? Under which case would FiniteDifference(Forward(), false)) fail?

[pulsipher]

If you don't have a terminal condition, then use true instead of false such that the discretization is well posed.