AUTOopt : an Auto driver for boundary-value optimization problems

(1)

POLITECNICO DI MILANO

Scuola di Ingegneria industriale e dell’Informazione Course of Automation and Control Engineering

AUTOopt: an AUTO driver for

boundary-value optimization problems

Supervisor:

Prof.

FABIO DERCOLE

Candidate:

MATTEO ZAPPALAGLIO

personal code: 878376

Academic year 2018-2019

(2)

Introduction

More then 25 years ago, it has been presented in [Doedel et al., 1991b] a method for the optimization of boundary-value problems with AUTO, a software package based on the pseudo-arclength continuation. The proposed method optimizes the solutions of this types of systems with respect to a vector of control parameters. The method proceeds through a series fo successive continuations, each aimed to find a local extrema of the user-defined objective functional with respect to one or more control parameters. To perform this type of optimizations with AUTO, the user has to write the equations for the adjoint variables and the code scripts which allow the software to perform the sequence of continuations correctly. These steps can be really expensive in therms of time and energy for the user. In this script, it will be showed the functionalities of AUTOopt, a Python script which automatically generates the equations and command files to optimize boundary-value problems with AUTO. Not even the first-derivatives of the user problem, involved in the equations for the adjoint variables, are required. The user has the possibility to provide them or not and in this case, they will be approximated with the finite differences. Further, to allow the user to exploit all the AUTO potentialities, there’s also the possibility to provide the second-derivatives, that will be used to pass to AUTO the first-derivatives of the optimization problem. Starting from the optimization method presentation, will be showed the functionalities of AUTOopt, its input files, how they are used to generate the output ones and how these files adds the new equations and perform the sequence of continuations. Then, it will be showed how to use AUTOopt in order to optimize control input signals. This is made possible by discretizing the signal in a finite number of points on the time grid. In the end, it will be showed the resolution of two well-known examples on the optimal control and variational calculus, the controllability Gramian and the brachistochrone curve. For the last one, will be described the procedure used to reformulate the variational problem as an optimal control one, using the curvature of the profile along the system’s trajectory as control signal.

(5)

Chapter 1 Optimization of boundary-value

problems

This chapter has been written with the intent to be a sort of ”state of the art” on the op-timization of boundary-value problem with AUTO. The reader will be introduced to such kind of problems starting from the notions and the method in introduced more then 25 years ago in the articles [Doedel et al., 1991a] and especially [Doedel et al., 1991b]. After a generic definition of boundary-value problem and the system of equations composing it, will be illustrated, with the adjoint of an objective functional, how to rewrite it in a sort of optimization form through the Lagrange multipliers method. Then will be showed how to solve the obtained boundary-value optimization problem by executing a series of continuations, which takes the name continuation strategy, with AUTO. After this, there will be a first introduction to the use of AUTO, giving to the reader some basic notions on its utilization and on Fortran language, which is the programming language used to create input files for AUTO. Such basis concepts will be useful to the reader in the next chapters. At the end of the chapter, it will be showed the optimization of obv, the example of boundary-value optimization problem included in the AUTO demos. Such example will be used again at the end of the second chapter to show the results of the driver AUTOopt in solving it.

1.1 The problem definition

Using the notation introduced in [Doedel et al., 1991b], consider a generic boundary-value problem (BVP), in which the dynamical system

˙u(t) − f (u(t), µ, λ) = 0, t ∈ [0, 1], f : Rn× Rnµ× Rnλ _{→ R}n_, _(1.1) composed by n first order differential equations, it’s subject to, possibly nonlinear or non-separated, nb boundary conditions

(6)

1.2 Optimality equations 1. Optimization of boundary-value problems

and to ni linear or nonlinear integrals constraints Z 1

0

q(u(t), µ, λ)dt = 0, q : Rn× Rnµ_{× R}nλ _{→ R}nq_. _(1.3) In the equations above, u(t) ∈ Rn _{is the state vector of the system, u(0) and u(1) are} respectively the system’s initial and final state, µ ∈ Rnµ is the free model parameters vector, while λ ∈ Rnλ _{is the vector of the control parameters. Now, add to such BVP} another constraint, a generic objective functional of the kind

ω = Z 1

0

g(u(t), µ, λ)dt, g : Rn× Rnµ_{× R}nλ _{→ R,} _(1.4) that has to be minimized or maximized in the same time interval t ∈ [0, 1]. The result is an optimization problem in which the control vector (or signal) λ has to be optimized in order to find the extrema of the objective functional ω. In the definition of problem (1.1) - (1.4), has to be notice that the formulation in time interval [0,1] is general for any finite final time. The only remark is to scale function f by an appropriate parameter T, which has to be inserted between the components of vector µ in case it will be able to vary. In addition, to let the BVP be well posed, it’s required that the dimension nµ of vector µ has to satisfy relation

nµ = nb+ ni− n ≥ 0 (1.5)

in order to define an isolated and unique solution u(t), t ∈ [0, 1], of BVP (1.1) - (1.3). Therefor, from now long, it will be assumed to have a number nµ of model parameters free to change in all the continuations in according to equation (1.5).

1.2 Optimality equations

In Sect. 4.3 of [Doedel et al., 1991b], it’s showed how to solve the optimization problem defined in the previous paragraph. Starting from the equations of the BVP and the objective functional (eq. (1.1) - (1.4)), it’s possible to derive the optimality equations which allow to define a boundary-value optimization problem (BVOP), that if solved with an appropriate continuation strategy, allows to find the optimal control vector λ. Such vector will able to optimizes the objective functional. Here after is reported a different approach, but equivalent, to derive the optimality equations. These last can be computed with the Lagrange multipliers method, by searching a stationary point for the system’s Lagrangian, called L, which is generically defined as the sum between a generic objective function g(x, y), that has to be minimizes (or maximized), and the summation of all the nc system’s constraints of equations f (x, y) ∈ Rnc, each one multiplied by a Lagrange multiplayer l L(x, y) = g(x, y) + nc X i=1 lifi(x, y). (1.6)

(7)

In our optimization problem, the objective functional is (1.4), while the constraints are those imposed by the boundary conditions (1.2), the integral constraints (1.3) and the first order differential equations of the BVP system (1.1). Consequently, the Lagrangian can be written as sum of two therms:

L(u(t), µ, λ, γ, w(t), β, κ) = L1(u(t), µ, λ, γ, w(t), κ) + L2(u(0), u(1), µ, λ, β) (1.7) where the L1 represents the sum of those therms that can be grouped in the integral along time interval [0,1]:

L1 = Z 1

0

(γg(u(t), µ, λ) + w(t)0( ˙u(t) − f (u(t), µ, λ)) + κ0q(u(t), µ, λ))dt (1.8) while L2 is the sum of the remaining therms:

L2 = β0b(u(0), u(1), µ, λ) (1.9)

with w(t) ∈ Rn×1,κ ∈ Rni×1,β ∈ Rnb×1 _{and γ is a scalar.} _{In the equations above,} apex 0 indicates transposition and therms β, κ and w(t) are the Lagrange multipliers related respectively to the boundary conditions, integral constraints and to the first order differential equations, while γ is a scaling factor for such multipliers. The use of this last parameter will need the addition of a new constraint, related to the Lagrange multipliers norm. Notice that parameters w(t) are function of time. This is due to the fact that the associated constraints ˙u − f (u(t), µ, λ) = 0 have to be satisfied in all the time instants of interval [0,1]. Thus, the summation of the related therms can be transformed in a time integral, and then grouped with the other integral constraints. At this point we have to search a stationary point for L, so we have to set zero all its first order derivatives with respect to u(t), µ, λ, γ, w(t), β and κ. In the next computations, with the notation ∂/∂u(t) will refer to the derivative with respect to all the components of u(t), in all the instants t except for the initial and final one (t equal 0 or 1). The initial and final state will be treated separately, and the corresponding notation will be ∂/∂u(0) for the initial, and ∂/∂u(1) for the final one. Starting from the Lagrangian partial derivative with respect u(t), this first one can be computed as

∂L(·) ∂u(t) = ∂L1(u(t), µ, λ, γ, w(t), κ) ∂u(t) + ∂L2(u(0), u(1), µ, λ, β) ∂u(t) (1.10)

in which symbol (·) stands for omitted dependencies. The second therm related to L2, that doesn’t depend on u(t), is zero, while the other one is equal to:

∂L1(·) ∂u(t) = Z 1 0 (γgu(u(t), µ, λ))dt + ∂ ∂u(t) Z 1 0 w(t)0˙u(t)dt − Z 1 0 w(t)0fu(u(t), µ, λ)dt+ + Z 1 0 (κ0qu(u(t), µ, λ))dt (1.11)

(8)

1.2 Optimality equations 1. Optimization of boundary-value problems with: gu(u(t), µ, λ) = ∂g(u(t), µ, λ) ∂u(t) fu(u(t), µ, λ) = ∂f (u(t), µ, λ) ∂u(t) qu(u(t), µ, λ) = ∂q(u(t), µ, λ) ∂u(t) .

The second therm on the right side of (1.11) can be computed through the integration by parts ∂ ∂u(t) Z 1 0 w(t)0˙u(t)dt = ∂ ∂u(t)(w(t) 0 u(t) 1 0− Z 1 0 ˙ w0(t)u(t)dt) (1.12) where the first therm on the right side is equal zero. It’s a function of u(0) and u(1), and not of u(t). Thus, (1.12) results

∂ ∂u(t) Z 1 0 w(t)0˙u(t)dt = − Z 1 0 ˙ w0(t)dt (1.13)

Substituting (1.13) in (1.11) and by setting it to zero we obtain Z 1

0

(γgu(u(t), µ, λ) − ˙w(t)0 − w(t)0fu(u(t), µ, λ) + κ0qu(u(t), µ, λ))dt = 0. (1.14) Moving ˙w(t) on the other side and making the transpose, the first optimality equation is

˙

w(t) = −fu(u(t), µ, λ)0w(t) + qu(u(t), µ, λ)0κ + γgu(u(t), µ, λ) (1.15) with w(t) ∈ Rn×1,κ ∈ Rni×1, fu(·) ∈ Rn×n,qu(·) ∈ Rn×ni,gu(·) ∈ Rn×1 and γ is a scalar, which represents a new group of ODEs describing the dynamic of new state variables w(t). Such new variables will be called from here after co-states. Similarly to (1.10), the partial derivative of L with respect of u(0) is given by the two partial derivatives sum of L1 and L2 that are:

∂L1(·) ∂u(0) = ∂ ∂u(0) Z 1 0 w(t)0˙u(t)dt (1.16a) ∂L2(·) ∂u(0) = β 0 b0(u(0), u(1), µ, λ) (1.16b) with b0(u(0), u(1), µ, λ) = ∂b(u(0), u(1), µ, λ) ∂u(0) . (1.17)

and equation (1.16a) can be computed by parts as the (1.12), and it results ∂ ∂u(0) Z 1 0 w(t)0˙u(t)dt = ∂ ∂u(0)(w(t) 0 u(t) 1 0− Z 1 0 ˙ w0(t)u(t)dt) = −w(0)0. (1.18)

(9)

This time is the integrative therm to be equal 0. It depends on all u(t) except u(0) and u(1), while the minus of w(0) is due to the fact that u(0) is the lower extreme. Summing the equation (1.16a) with (1.16b) we obtain

∂L(·)

∂u(0) = −w(0) 0

+ β0b0(u(0), u(1), µ, λ) (1.19) that setted equal zero, and by making the transpose, it gives a new optimality equation, which expresses n new boundary conditions:

w(0) − b0(u(0), u(1), µ, λ)0β = 0 (1.20) where w(0) ∈ Rn_{,β ∈ R}nb×1 _{and b}

0(·) ∈ Rn×nb. The derivative with respect u(1) can be computed in a similar way to the u(0) one and the result is

w(1) + b1(u(0), u(1), µ, λ)0β = 0 (1.21) which gives other n new boundary conditions, with w(1) ∈ Rn,β ∈ Rnb×1 _{and b}

0(·) ∈ Rn×nb_{. Now it’s necessary to make the derivative with respect the system’s parameters} µ,λ, the Lagrange multipliers w(t), β, κ and the scaling factor γ. With respect to µ, the resultant derivatives of L1(·) and L2(·) are

∂L1(·) ∂µ = Z 1 0 (γgµ(u(t), µ, λ))dt − Z 1 0 w(t)0fµ(u(t), µ, λ)dt + Z 1 0 (κ0qµ(u(t), µ, λ))dt (1.22a) ∂L2(·) ∂µ = β 0 bµ(u(0), u(1), µ, λ) (1.22b) with gµ(u(t), µ, λ) = ∂g(u(t), µ, λ) ∂µ fµ(u(t), µ, λ) = ∂f (u(t), µ, λ) ∂µ qµ(u(t), µ, λ) = ∂q(u(t), µ, λ) ∂µ qµ(u(t), µ, λ) = ∂q(u(t), µ, λ) ∂µ .

Summing together the two equation of (1.22), making the transpose and setting them to zero we obtain

Z 1

0

(−fµ(u(t), µ, λ)0w(t) + bµ(u(0), u(1), µ, λ)0β + qµ(u(t), µ, λ)0κ + γgµ(u(t), µ, λ)0)dt = 0 (1.23)

(10)

1.3 Continuation strategy 1. Optimization of boundary-value problems

which is an equation that describes nµnew integral constraints and where w(t) ∈ Rn×1,κ ∈ Rni×1_{, f}

µ(·) ∈ Rnµ×n,qµ(·) ∈ Rnµ×ni,gµ(·) ∈ R1×nµ and γ is a scalar. The same procedure can be done for the derivative with respect λ. It results in

Z 1

0

(−fλ(u(t), µ, λ)0w(t) + bλ(u(0), u(1), µ, λ)0β + qλ(u(t), µ, λ)0κ + γgλ(u(t), µ, λ)0)dt = 0 (1.24) which generates nλ integral constraints. In equation (1.24), w(t) ∈ Rn×1,κ ∈ Rni×1, fλ(·) ∈ Rnλ×n,qλ(·) ∈ Rnλ×ni,gλ(·) ∈ R1×nλ and γ is a scalar. The derivatives with respect the Lagrange multipliers w(t),β,κ and γ generates respectively (1.1), (1.2), (1.3) and (1.4) of the starting system. In the end, the optimality equations are those of the starting original BVP plus some new equations derived by the Lagrange multipliers method, which are

˙

w(t) = −fu(u(t), µ, λ)0w(t) + qu(u(t), µ, λ)0κ + γgu(u(t), µ, λ), (1.25a)

w(0) − b0(u(0), u(1), µ, λ)0β = 0, (1.25b)

w(1) + b1(u(0), u(1), µ, λ)0β = 0, (1.25c)

Z 1

0

(−fµ(u(t), µ, λ)0w(t) + bµ(u(0), u(1), µ, λ)0β + qµ(u(t), µ, λ)0κ + γgµ(u(t), µ, λ)0)dt = 0, (1.25d) Z 1

0

(−fλ(u(t), µ, λ)0w(t) + bλ(u(0), u(1), µ, λ)0β + qλ(u(t), µ, λ)0κ + γgλ(u(t), µ, λ)0)dt = 0. (1.25e) Note that the new system’s dimensions are bigger then those of the original BVP. The number of differential equations is now 2n, it has been doubled. The total number bound-ary conditions is nb+ 2n. The number of integral constraints is grown too. In addition to those specified by (1.3) and (1.4), that in total are ni+ 1, the BVOP has in more nµ+ nλ integral constraints, due to the free model and control parameters of the starting BVP. Now, as mentioned in paragraph 1.1, due to the introduction of scaling factor γ for the multipliers w(t), β and κ, we should add a constraint to the norm α0 of such multipliers, that can be expressed in the following way as an integral condition

Z 1

0

(w(t)0w(t) + β0β + κ0κ + γ2− α0)dt = 0 (1.26) and the total number of BVOP’s integral constraints is ni+ 2 + nµ+ nλ.

1.3 Continuation strategy

AUTO is a software package aimed to the continuation of solutions of systems composed by ordinary differential equations through the pseudo-arclength continuation method.

(11)

1.3 Continuation strategy 1. Optimization of boundary-value problems

Starting from a user-provided system solution (a BVP initial solution), AUTO can follow the parametric solution family, in finite and infinite dimensions, and analyze possible bifurcations. The continuation approach allows to find extrema of an objective function, or a functional of the solution of boundary-value problem. In these cases, the optimization is performed with respect to a finite number of control parameters λ. These continuations are performed in order to find, at first, an extremum of the objective function with respect to one of the λ parameters. Then, the other control parameters are added one-by-one to the continuation problem, each time to find a new fold point imposing all the previous extremal conditions. Thus allows to solve BVOP, by finding optimal values for the control parameters. Here after is reported divided in steps the continuation strategy (the sequence of continuations), presented in Sect. 4.3 [Doedel et al., 1991b], that should be performed in order to solve a BVOP.

(0) After having defined a BVP and an objective functional, a solution u(0)_{(t) ∈ R}n_{, t ∈} [0, 1], µ = µ(0)_{, λ = λ}(0) _{with ω = ω}(0) _{to such BVP as to be computed by the user.} Then, the user has to choose the control parameters λ and transform the BVP in a BVOP by adding the new equations specified by (1.25). After this, the user has to choose one of the control parameters, for example λ1, with respect to witch perform the search for a local extrema of the objective functional (1.4) and, for each of the other λ parameters, with the exception of the first, it has to introduce a new parameter αi, that will be used for the evaluation of the integral conditions of eq. (1.25e). This means transform those equations in

Z 1

0

(f_λ10 w(t) + b0_λ1β + q_λ10 κ + γg_λ10 )dt = 0, (1.27a) Z 1

0

(f_λi0 w(t) + b0_λiβ + q_λi0 κ + γg_λi0 − αi)dt = 0, (1.27b) with i = 2, . . . , nλ, in which dependencies are omitted. Now, the user has to update the previous BVP solution by adding the trivial one for the co-states w(0)_{(t) = 0,} and setting to zero all the other parameters added by eq. (1.25), i.e. α0 = α2:nλ = β = κ = γ = 0.

(1) At this point, starting from the initial solution defined in step (0), the user as to make a first continuation run, specifying as free parameters ω, λ1,α0,α2:nλ,β,κ,γ and µ. These last parameters must be chosen according to eq. (1.5), in which should be used the dimensions referred to the starting BVP system. During this continuation, all the parameters are kept zero, with the exception of λ1, which is free to change along with the state vector (solution) u(t), parameters µ and the objective functional ω. When AUTO detects a branch point (BP ) [Dercole, 2008], that corresponds to a fold of ω with respect to λ1, the first continuation run can be stopped, because to such point (λ1 = λ

(BP )

1 , u(t) = u(BP )(t),µ = µ(BP ) and ω = ω(BP )) corresponds a nontrivial solution for the adjoint variables w(t),β,κ and γ.

(12)

1.4 A first introduction to AUTO 1. Optimization of boundary-value problems

(2) By keeping the same free parameters of step (1), with the use of the AUTO branch switch feature, another continuation run is made in order to grow the nontrivial solution for the adjoint variables. The norm α0, defined in (1.26), will grow, and the continuation will be stopped in a point where α0 is equal to an arbitrary value specified by the user. The point can be detected by the AUTO user function. In this continuation, all the free adjoint variables, that were equal zero in step (1), will reach a value different to zero (such point will be indicated with (1)-super-script), and the obtained solution u(t) = u(BP )(t), w(t) = w(1)(t),µ = µ(BP ),λ1 = λ(BP )₁ ,ω = ω(BP ),γ = γ(1),β = β(1),κ = κ(1),α0 = α

(1)

0 ,α2:nλ = α (1)

2:nλ, for t ∈ [0, 1] is extremal with respect to λ1. Because isn’t jointly extremal with respect to other λi, all the α(1)_2:nλ will be nonzero.

(i) Once in point (1) defined in step (2), the norm α0 is fixed and removed from the free parameters. It will replaced by another control parameter, λ2 for example, and an other continuation is made, looking for a possible point in which the value α2 is equal zero (denoted with (2)). In that point the solution will be jointly extremal with respect to (λ1, λ2). Then for i = 3, . . . , nλ, this procedure is repeated. Once an αi−1 is nullified, it has to bee removed from the free continuation parameters and replaced with another control parameter, say λi and a continuation is made looking for points in which αi = 0. When all the αi are vanished, in the last point i = λ, solution is jointly extremal to all the λi, and it will be the BVOP solution.

1.4 A first introduction to AUTO

The aim of this paragraph is to give to the reader some notions on how a user can interact with AUTO. It will be explained with the description of those input files needed by AUTO in order to set up a continuation problem, and by giving also few practical notions on the Fortran language, used to create such inputs. For more material on the AUTO software and on Fortran the reader can consult the AUTO manual [Doedel et al., 2007] and a book on Fortran language, like [Chapman, 1998]. AUTO can interact with the user indirectly, through three input files, <pgm>.f90, c.<pgm> and <pgm>.auto (where <pgm> identifies a generic filename) and directly, from its terminal, with the use of Python commands. The file with extension .f90 is written in Fortran language and gives to AUTO those information regarding the system’s ODEs, its (boundary and/or integral) constraints and the user-supplied solution. In the file c., the user has to specify the continuation and system’s parameters, while in the file .auto there should be written, in Python language, the commands used from AUTO to perform all the continuations needed. This last file isn’t strictly necessary, because the same commands can be give from the terminal. In the following subparagraphs we will enter in the details of such files.

(13)

1.4.1 The <pgm>.f90 file

In this file there is the declaration of six subroutines, which are procedure that the main program of AUTO invokes by using a CALL command. These procedures are able to receive inputs and send back outputs. An example of a standard subroutine declaration is reported in figure 1.1, which will be taken as reference in the following explanation. Note that in this figure all the lines starting with a ! are comments. Those lines will be ignored by Fortran compilers. The subroutine definition is delimited by two commands, SUBROUTINE and END SUBROUTINE (lines 1 and 16), which both need the specifi-cation of the subroutine name (subroutine name). The first needs also the specifispecifi-cation

Figure 1.1: The structure of a standard Fortran subroutine. It can be separated in a declaration section, where are specified the attributes of the arguments list and an execution section, in which are specified the computations that the subroutine has to perform before sending back the outputs.

of all the subroutine inputs and outputs in a list of arguments reported between brackets. It’s also necessary to include a part in which declare the nature of those variables com-posing that list. In the figure, this part is called declaration section, and it’s the place in which the user has to declare attributes of all the elements composing the arguments list through the use of statements. The main attributes are:

• type : if the variable is or it’s composed by all integer numbers, it’s type will be INTEGER as for input1 and constant (lines 5 and 9). While for variables that are composed by double-precision numbers, the type is obviously DOUBLE PRECISION, as for input2, output1, output2 and inout1 (lines 6-8).

• dimension : if an element of the argument list is an array or a matrix (so is a variable with more then one element), it’s dimension should be specified with the use of statement DIMENSION as for the square matrix inout1 (line 8), or by specifying it between brackets as for vectors output1 and output2 (line 7). The

(14)

dimensions values can be written explicitly by inserting a number or a variable as for output1,output2 and inout1. In this last case, it is important to declare the statement of the variable used before the others statements that will use it.

• intent : this attribute declares if an element of the argument list can be used as: - only an input with INTENT(IN) as for input1 and input2 (lines 5 and 6), - only an out with INTENT(OUT) as for output1 and output2 (line 7),

- both, input and output, to pass and return data from the subroutine with INTENT(INOUT) as for inout1 (line 8) .

Variables can be also declared in order to be used only in the subroutine (are not in-put or outin-put), like constant in line 9, and the dimension of the inin-puts (IN and INOUT e`oements) can be left undefined by specifying it with a *. In this case the subroutine will accept that input whatever its dimension will be. Then, after having declared what are the elements of the arguments list, all the commands and computations that the subrou-tine have to perform before sending back the desired outputs can be written (execution section, lines 11-14). If a call to another subroutine is inserted (like in line 13), the com-putation of the calling subroutine are paused until the called subroutine will send back its outputs. In the following are reported the six subroutines that AUTO expect to find in file <pgm>.f90, focusing their functions and on their principal inputs and outputs (for more information [Doedel et al., 2007]). Such subroutines will be called from here after main subroutines. They are:

• FUNC: is used to evaluate the problem ODEs. It takes as inputs the constant NDIM and the variable U, which are the system’s dimension (i.e. number of ODEs and state variables) and the state vector, and as output vector F. This is of dimension NDIM (as U) and its elements are equal to the value of the ODEs for the state defined by the input U. As INOUT it takes the matrices DFDU and DFDP, which specify, respectively, the derivatives of the ODEs with respect the state vector U and those with respect all the system’s parameters. Their dimensions are defined as: DFDU(NDIM,NDIM) and DFDP(NDIM,*);

• STPNT : is the subroutine in which the user has to define the initial solution. It takes as INOUT the vector U and as only input T, that’s the time. It’s called several time before the first continuation in order to construct the starting solution; • BCND : is used to evaluate the boundary conditions. It takes as input NDIM,

NBC (number of boundary conditions), U0 and U1 which are the vectors of the initial and final states. As output vector FB of dimension NBC, whose elements are equal to the value of the boundary conditions for the initial and final state vectors U0 and U1. The matrix DBC of dimensions (NBC,*) is an INOUT argument. Its elements are the value of the boundary conditions derivatives made with respect the initial state U0, final state U1 and system’s parameters;

(15)

• ICND : is used to evaluate the integral constraints. It takes as input NDIM, NINT (number of integral conditions) and the state vector U. FI is the output vector of dimensions NINT, whose elements are equal to the value of the integral conditions for the given state vector U. As INOUT element it has matrix DINT, dimensions (NINT,*). Its elements are the values of the inegral constraints’ derivatives made with respect the state U and system’s parameters;

• FOPT : is used to evaluate possible objective functional. It’s inputs are the state vector U and NDIM. The output is the value of the objective functional saved in FS, as INOUT it has vectors DFDU(NDIM) and DFDP(*), which contain respectively the derivatives of the objective functional with respect the state vector U and the system’s parameters;

• PVLS : it is used for get outputs elements of measure. In this subroutine it is possible to specify function whose aim is to send back particular outputs to the user.

All the subroutines above take as input vectors PAR and ICP. The first is a vector containing the value of all the system’s parameters. The second one contains all the indices of the free continuation parameters. Each parameter is identified as PAR(index ), where index is user-defined integer number. So if one of them is a free continuation parameter, its index will be present in ICP.

1.4.2 The c.<pgm> file

The c.<pgm> is the file in witch the user has to set all the continuation parameters (such as tolerances, system’s dimensions and so on) that AUTO should use to perform the continuation of the system defined in file <pgm>.f90. An example of such type of file is showed in fig. 1.2. Here after, it is reported a list of those parameters needed to the reader to better understand the function of the driver AUTOopt explained in the next chapter. Some of them were already introduced in paragraph 1.4.1, but here are reported with a further explanation to give the reader a faster and easy way to recover them. For more notions on the other parameters it’s suggested to consult [Doedel et al., 2007]. The fundamental parameters are:

• NDIM: is the system’s dimension, i.e. the number of ODEs and the dimension of the state vector. It’a equal to n for the BVP system and 2n for the BVOP one. • NBC: is the number of boundary conditions to which the system is subject. It is

also the dimension of vectors U0 and U1. For the starting BVP it’s equal to nb, while for the corresponding BVOP is nb+ 2n.

• NINT: is the number of integral constraints to which the system is subject. For the starting BVP it’s equal to ni, while for the corresponding BVOP is ni+ nλ+ nµ+ 2.

(16)

• NPAR: is the total number of system’s parameters, i.e. the total number of all parameters in file <pgm>.f90 referred with the expression PAR(index ), in witch index is an integer number. NPAR corresponds to the biggest of such indices, in all the cases. This mean that, for example, if the system has three parameter but one of them is referred with PAR(5), NPAR will be equal 5.

• JAC: is the parameter used by AUTO to understand if it has to take in consideration the matrices of the derivatives specified by the user in the main subroutines of file <pgm>.f90 (i.e. DFDU e DFDP for subroutine FUNC, DBC for BCND and so on). By setting JAC=0, the user is telling AUTO to don’t use such matrices, also if they are specified. In this situation, AUTO will approximate those derivatives with the finite differences. Instead, if JAC=1, the user is asking AUTO to use the specified derivatives. This means that AUTO will not do the finite differences, and will use the values stored in the matrices DFDU,DFDP,DBC and DINT given as output by the subroutines.

• ICP: is a vector that the user can use to indicate to AUTO which are the free continuation parameters, by listing their indices.

• ISW: this is a parameter used to indicate to AUTO if it has to do a branch switch when it encounter a fold.

• NMX: is the maximum number of points that AUTO should use in a continuation to computes a solution family.

• UZR: is a vector, defined with graph brackets, that the user can use to specify new type of points which AUTO should detect, label and return as output. For example, consider parameter PAR(15) and PAR(34). If we want AUTO to detect all those solutions, along a continuation branch, that have PAR(15)=0.0 or PAR(34)=1.0, we can specify in c.<pgm> vector UZR={15:0.0,34:1.0}, and so AUTO will detect and label such type of solutions if it finds them.

• DS: is the continuation step used by AUTO to compute the parametric solution families. It’s not constant and its sign determines the direction in which AUTO performs the continuation.

1.4.3 The <pgm>.auto file

This is the file in which the user can give, through Python commands, instructions to AUTO on how make one or more continuations. An example of such commands is showed in fig. 1.3, which is taken as reference figure in this paragraph. The main command is run, that allows the user to specify which problem AUTO has to continue, the starting continuation solution and parameters by inserting different options between brackets (as in lines 9,13,17,21 of the figure). Each result of a run command can be stored in a variable

(17)

Figure 1.2: The layout of a generic c.<pgm> file. This is also an example on how to write file c.obv, which defines the continuation parameters too solve the obv optimization problem of paragraph 1.5.

and will be saved in it until the close of the AUTO-terminal, or until an overwrite of the variable. Examples are in lines 17 and 21, in which the results of run are stored in variables r3 and r4. The first run needs the loading of an equation file <pgm>.f90 and a constant file c.<pgm>, in order to let AUTO know which problem files it has to consider. This can be done with the first run command, as in line 9 of the figure, in which the values of e and c are setted equal to a string (in this case pgm=’obv’ ) that allows AUTO to load the equations from <pgm>.f90 and the constants from c.<pgm> files. The strings that identify those two files can be different, but is suggested to keep them equal. For

Figure 1.3: An example of a standard <pgm>.auto file.

(18)

1.5 OBV: an AUTO demo 1. Optimization of boundary-value problems

(for the first run, it has been identified through subroutine STPNT with the load of file <pgm>.f90). Usually this solution is one of those found in a previous continuation and it’s possible to select it by specifying the variable in which it’s stored. If only the variable name is specified (as in line 17), the solution selected is the last computed in the corresponding continuation. Instead, if the desired solution is another one, and it has been labelled by AUTO, it can be selected by specifying the corresponding label. For example, in line 13, the continuation whose results are stored in r2 will take as starting solution the one found in continuation named r1 and labelled with the string ”BP1”. Note that the software labels automatically solutions for which it detects special points (like the one used in the previous example). For other kind of solutions, it is the user to tell AUTO which ones it has to detect (for example through the use of UZR). In the end, command run allows to modify the continuation parameters by inserting them as option (ex. lines 13,14 and 17). If with a run command

- no continuation parameters are changed, for that run and for all the next ones, the parameters used are those of the file c.<pgm> (loaded with the first run);

- new continuation parameters values are specified, AUTO will use for such parame-ters the modified values, while for the others will keep the same values loaded from file c.<pgm> or defined with a previous run command. For all the next continua-tions, it will keep these parameters values, until a new modification of file c.<pgm> or by new run commands.

Of course, it’s possible to save the continuation results in output files. This can be done through the use of command save, which takes as input the variable in which are stored the continuation results and a string that defines the name used for the output files extension. These output files are three. File b.name contains the data related to the bifurcation diagram (name is the extension). The states solutions are stored in file s.name, while file d.name is the diagnostic file. For example, the save command in line 18 saves the results stored in variable r3 and the output files will be saved with extension ’2’, i.e. b.2,s.2 and d.2.

1.5 OBV: an AUTO demo

In this paragraph, will be showed the AUTO demo of optimization problem, also presented in [Doedel et al., 1991b], called obv. The aim is to show to the reader an application of what has been explained in the previous paragraphs, and to introduce an example of the procedure that has to be followed in order to solve an optimization of a BVP with AUTO, starting from the problem definition and arriving to a solution computed with the software. The first steps concern the problem definition and the optimality equations derivation, so consider a system composed by the following differential equations

˙

u1(t) = u2(t) (1.28a)

˙

(19)

with ∆ = u1(t) + p2u2₁(t) + p3u4₁(t), subject to the two boundary conditions

u1(0) = 0 (1.29a)

u1(1) = 0, (1.29b)

and the objective functional ω = Z 1 0 (u1(t) − 1)2dt + 0.1 3 X k=1 p2_k. (1.30)

According to equation (1.5), being n = 2,nb = 2 and ni = 0, due to the absence of integral constraints, the problem is well posed and doesn’t need the specification of additional free model parameters µ (nµ = 0). Defined vectors f (u(t), λ) ∈ R2×1, b(u(0), u(1)) ∈ R2×1 and g(u(t), λ) as f (u(t), λ) = u2(t) −λ1exp(∆) (1.31a) b(u(0), u(1)) =u1(0) u1(1) (1.31b) g(u(t), λ) = Z 1 0 (u1(t) − 1)2dt + 0.1 3 X k=1 λ2_k (1.31c)

where λ are the parameters to be optimized (in this case all the three system’s parameters: λ1 = p1, λ2 = p2, λ3 = p3, with λ ∈ R3×1= |λ1 λ2 λ3|0), the derivatives needed to build the new optimality equations are

fu(u(t), λ) = " _{∂f [1]} ∂u1(t) ∂f [1] ∂u2(t) ∂f [2] ∂u1(t) ∂f [2] ∂u2(t) # = 0 1 −λ1exp(∆)∆1 0 (1.32a) gu(u(t), λ) = h ∂g ∂u1(t) ∂g ∂u2(t) i =2(u1(t) − 1) 0 (1.32b) b0(u(0), u(1)) = " _∂b[1] ∂u1(0) ∂b[1] ∂u2(0) ∂b[2] ∂u1(0) ∂b[2] ∂u2(0) # =1 0 0 0 (1.32c) b1(u(0), u(1)) = " _∂b[1] ∂u1(1) ∂b[1] ∂u2(1) ∂b[2] ∂u1(1) ∂b[2] ∂u2(1) # =0 0 1 0 (1.32d) fλ(u(t), λ) = "_{∂f [1]} ∂λ1 ∂f [1] ∂λ2 ∂f [1] ∂λ3 ∂f [2] ∂λ1 ∂f [2] ∂λ2 ∂f [2] ∂λ3 # = 0 0 0

−exp(∆) −λ1exp(∆)u21(t) −λ1exp(∆)u41(t) (1.32e) gλ(u(t), λ) = h ∂g ∂λ1 ∂g ∂λ2 ∂g ∂λ3 i =0.2λ1 0.2λ2 0.2λ3 (1.32f) where ∆1 = ∂∆/∂u1 = 1 + 2 ∗ λ2u1 + 4λ3u31, while all the others partial derivatives (bλ, qu, . . . ) are null. According to eq. (1.25), the new optimality equations that has to be adjoined to those of the starting BVP are:

(20)

- new ODEs from (1.25a) ˙

w1(t) = λ1exp(∆)∆w2(t) + 2γ(u1(t) − 1) (1.33a) ˙

w2(t) = −w1(t) (1.33b)

- new boundary conditions from (1.25b) and (1.25c)

w1(0) − β1 = 0 (1.34a)

w2(0) = 0 (1.34b)

w1(1) + β2 = 0 (1.34c)

w2(1) = 0 (1.34d)

- new integral conditions from (1.25e) Z 1 0 (−exp(∆)w2(t) − 0.2λ1γ)dt = 0 (1.35a) Z 1 0 (−λ1exp(∆)u21w2(t) − 0.2λ2γ)dt = 0 (1.35b) Z 1 0 (−λ1exp(∆)u41w2(t) − 0.2λ3γ)dt = 0 (1.35c) In addition, to prepare the system in order to be continued with AUTO, there must be included also eq. (1.26), the integral constraint regarding the norm α0 of the multipliers, and, according to eq. (1.27), the integral constraint specified in eq. (1.35a) should be rewrite as Z 1 0 (−exp(∆)w2(t) − 0.2λ1γ)dt = 0 (1.36a) Z 1 0 (−λ1exp(∆)u21w2(t) − 0.2λ2γ − α2)dt = 0 (1.36b) Z 1 0 (−λ1exp(∆)u41w2(t) − 0.2λ3γ − α3)dt = 0. (1.36c) The next step is the preparation of files obv.f90, c.obv and obv.auto. In the appendix at page 97 is reported an example of how should be written file obv.f90, in order to define correctly the obv system. Notice the initial solution defined in subroutine STPNT, in which both, the states and the co-states are setted equal zero, as for all the system’s parameters. The only parameter to be non-null is ω because for such solution its value is one. Examples of the c. and .auto files are reported in the appendix at page 99. In the following, will be present the main results of the continuations performed with the obv.auto file. In tab. 1.1 it’s possible to see the evolution of parameters values run by run, starting from their initial values. Following the strategy explained in paragraph 1.3, pag. 9, the continuation steps results are:

(21)

(1) : starting from a trivial solution defined in the subroutine STPNT of file <obv>.f90, a first run (called r1 in file obv.auto) is performed, in order to find an fold be-tween parameters ω and λ1. AUTO detects three fold as branch point (as shown in fig. 1.4a) but it could be stopped also at the first. If we look to the solution in this branch point, we will see that the states values are now different from those of the trivial solution, while the ones of the co-states are still null.

(2) : the second run (r2 ) starts taking into account the solution of labeled with ”BP1” and by keeping the same free parameter of run r1. The continuation r2 is stopped once the norm α0 is equal 1. By looking the solution of in this point, it’s possible to see that the co-states are now grown and different from zero (fig. 1.4b). The states values are the same of the previous step.

(3) : starting from the last computed solution in (2), the free parameters of run r3 are changed. The norm has been removed, while λ2 is inserted. Then another continuation is performed and a new solution is detected when the value of α2 is null (black point in fig. 1.4c). This solution point will be set as the starting one for the next continuation.

(4) : for the last run r4, α2 is removed from the free parameters and replaced with λ3 and the final solution is found when α3 is nullified (black point of fig. 1.4e).

(22)

1.5 OBV: an AUTO demo 1. Optimization of boundary-value problems 0.8 1 1.2 1.4 1.6 1.8 2 2.2 2.4 2.6 0 0.5 1 1.5 2 2.5 3 3.5 4 1 BP1 BP2 BP3 (a) 0 0.2 0.4 0.6 0.8 1 t -1 -0.5 0 0.5 1 u1(t) u2(t) 0 0.2 0.4 0.6 0.8 1 t -1 -0.5 0 0.5 1 w1(t) w2(t) (b) (c) 0 0.2 0.4 0.6 0.8 1 t -5 0 5 0 0.2 0.4 0.6 0.8 1 t -0.2 -0.1 0 0.1 0.2 (d) (e) 0 0.2 0.4 0.6 0.8 1 t -5 0 5 0 0.2 0.4 0.6 0.8 1 t -0.2 -0.1 0 0.1 0.2 (f )

Figure 1.4: In figure (a) is represented the continuation branch generated starting from the initial solution and the three fold detected, while in figure (b) are rep-resented the values of states and co-states after the grow of the norm α0, i.e. they refers to the solution obtained with the second run. In figure (c) is represented the continuation branch generated starting from the point BP1 of fig. 1.4a after the grow of the norm α0. In figure (d) are represented the values of states and co-states in the special point found with the third run, in which α2 is null. In figure (e) is represented the continuation branch generated starting from the point marked in fig. 1.4c and in figure (f) are represented the values of states and co-states for the solution with α3 is null, which is the optimal one. It is showed also the value of the objective functional ω.

(23)

1.5 OBV: an AUTO demo 1. Optimization of boundary-value problems Run ω λ1 λ2 λ3 α2 α3 β1 β2 γ – 1.00000E-01 0 0 0 0 0 0 0 0 1 9.23445E-01 9.24364E-01 0 0 0 0 0 0 0 2 9.23445E-01 9.24364E-01 0 0 -1.06361E-03 -1.42566E-05 -5.44963E-01 -5.44963E-01 -5.44930E-01 3 3.60824E-01 6.86096E-01 8.51277E-01 0 4.44579E-06 -3.28896E-0 1 -2.21476E-01 -2.21476E-01 -9.47023E-01 4 2.84593E-01 3.77216E-01 2.37845E-01 4.67597E-01 – 7.32288E-07 -2.13827E-01 -2.13827E-01 -9.50475E-01 T able 1.1: Results of demo OBV. Here are rep orted the v alues of the parameters at the end of eac h run. The first ro w iden tifies the parameters v alues at the in itial user -pro vided solution. Runs n um b er 1 and 2 sho ws the v alues of the parameters at the branc h p oin t and for the increased norm. The last tw o are related to the p oin ts α2 = 0 and α3 = 0. The v a lues of the λ parameters of run 4 ar e the optimal ones. P arameter α 0 isn’t rep orted for its trivial v alu es. F or the initial solution and run 1 its v alues is 0. When the norm has b een increased (sp ecial p oin t of run 2) it’s equal 1, then this parameter is remo v ed from the free con tin uation parameters.

(24)

Chapter 2 AUTOopt: a driver for the

optimization of BVP

AUTOopt is a driver written in Python language, which is born with the intent to be a powerful supporting tool for the optimization of boundary-value problems with the use of AUTO software. Consider a generic BVP that can be defined as in paragraph 1.1. The passages that should be done before running AUTO and solve the corresponding BVOP are:

- derivation of the optimality equations, - definition of the continuation strategy,

- writing the files <pgm>.f90, c.<pgm> and <pgm>.auto according to the BVOP. These steps can be really expensive in therms of time and computation, depending on the system’s dimensions n,nb,ni,nµ and nλ. Indeed, the user must compute manually all the first order derivatives necessary to find the BVOP equations and then, write the AUTO input files in order to perform the continuation strategy of paragraph 1.3, which solves the optimization problem. Instead, adopting AUTOopt will allow to optimize the system with this steps:

- writing <pgm>.f90 and c.<pgm> defining the original BVP and its first derivatives (these are not necessaries, it’s a choice left to the user to define them or not), - load and execute the AUTOopt driver from AUTO or Python-terminal, - run the output files generated by the driver with AUTO.

At first, this new steps can seem hard as the previous ones, but the user doesn’t have to - compute the optimality equations,

(25)

2.1 The input files 2. AUTOopt: a driver for the optimization of BVP

- write a <pgm>.auto file able to perform the continuation strategy,

strongly reducing the time to solve and analyse the BVOP. In the following paragraphs, will be showed the functioning of driver AUTOopt, focusing on it’s interaction with the user. Starting from the inputs file defining the starting BVP system, it will be described the main functions and tasks of the output files generated by AUTOopt. At the end will be explained the principal function that composed the AUTOopt driver, which is called opt, and will be showed the results obtained by solving the AUTO demo obv with the driver.

2.1 The input files

The driver AUTOopt takes as inputs a Fortran file and a constants file, called respec-tively <pgm>.f90 and c.<pgm>. In the first one, the user has to define the starting BVP equations, by writing them in the corresponding subroutine, which as to be defined with its standard statement (see paragraph 1.4). Consequently, it’s structure is equal to the one of a generic AUTO Fortran file. In the subroutine FUNC there should be defined the differential equations composing the BVP system of ODEs, in subroutine BCND the equations defining the BVP boundary conditions and the integral constraints in ICND. In STPNT there’s should be defined a BVP initial solution and the objective functional must be specified in the subroutine FOPT, and setted equal to its output. The user can also include in the .f90 file new functions and/or subroutines that will be copied and reported as they are by the driver in its Fortran output file. The driver suppose that such input file is free by coding errors and that can be used for continuation purpose with the add of appropriated c. and .auto file. This means that there should be defined all the main subroutines, but in some cases, one or more them could be useless. For example, if the BVP doesn’t have any integral constraint (NINT=0 ), the subroutine ICND is useless because there are not equations to be specified in it. The same example can be done for subroutine BCND (when NBC=0 ) or for PVLS, when the user doesn’t need any out-put. However, to be executable, a standard AUTO .f90 file should contain the definition of every main subroutine, so the user has to define also the useless ones anyway. Can leave it empty, but there should be commands SUBROUTINE and END SUBROUTINE defining it. For example, suppose that our starting BVP doesn’t need the specification of any integral condition. As consequence, we will have no equations or data to insert in subroutine ICND. We have always to define it, but we can do it in this way:

SUBROUTINE ICND(NDIM,PAR,ICP,NINT,U,UOLD,UDOT,UPOLD,FI,IJAC,DINT) END SUBROUTINE ICND

with no instruction between the initial and final statement. Further, we can also omit the subroutine arguments and/or leave blank spaces between the two statements. As will be explained in paragraph 2.2, the AUTO main subroutines of file <pgm>.f90 are utilized by the driver to create the so called USER- subroutines or user subroutines, which will

(26)

2.1 The input files 2. AUTOopt: a driver for the optimization of BVP

be used to evaluate the initial BVP equations. This means that if a subroutine is useless for <pgm>.f90, it will be useless also for <pgm> opt.f90. The driver is design to search such useless subroutine (if present) and to don’t report them in the output Fortran file. If for example, ICND in <pgm>.f90 is empty and so there’s no reason for the driver to copy it, AUTOopt will always search it in order to delete its text from the <pgm> opt.f90 file text. For subroutines BCND and ICND the driver makes decide if they should be copied or not according to the values of NBC and NINT inserted in file c.<pgm>. If those values are zero, there could be defined (also completely) subroutines BCND and ICND in <pgm>.f90, but they will be not reported in the <pgm> opt.f90. However, for subroutine PVLS doesn’t exist a parameter that can used to understand if there are defined some output functions in it, so the driver has to decide if copy or not this subroutine through its definition statements. If in the definition are specified the subroutine arguments (i.e. SUBROUTINE PVLS(...)) the driver will suppose that the user has specified output functions and so it will copy subroutine PVLS. Instead, if no arguments are present (i.e. SUBROUTINE PVLS ), the driver will discard such subroutine. As previously mentioned, the main scope of file <pgm>.f90 is to define the starting BVP system. Instead, the file c.<pgm> function is to define the system’s parameters, the continuation parameters and the BVP free model and control parameters (µ and λ). The values of these constants influence the generation of the output files. Those that have a major impact are the system’s parameters NDIM,NBC,NINT,NPAR and constant JAC, that are used by the driver to :

- check if the user has specified an appropriate number of free model parameters µ, according to eq. (1.5),

- create and index the right number of parameters to be added (ω,β,κ,α,γ and other supporting parameters),

- select which computation should be performed to generate the optimality equations (see paragraph 2.2),

- define the system’s parameters values for the BVOP.

The free model and control parameters are selected by the user with the use of vector ICP. This last one is used for this task because is an useless variable for the driver output files. Indeed, the driver will automatically generate the continuation path in file <pgm> opt.auto, so there’s no need of a free continuation parameters specification by the user. Vector ICP must be composed by integer numbers, whose values represent the indices of those parameters selected as µ or λ. The free model parameters must be inserted before the control ones. Knowing the system’s dimensions n (NDIM ), nb (NBC ) and ni (NINT ), the driver can compute through eq. (1.5) the value of nµ, and so it will consider the first nµ indices as those of the free model parameters. It’s important to remark again that all the input files must be free by coding errors. AUTOopt doesn’t make any control on that. For example, if in the user makes a coding mistake in the file<pgm>.f90, such

(27)

2.2 The <pgm> opt.f90 file 2. AUTOopt: a driver for the optimization of BVP

as forget to associate to a do loop an enddo command, the error can be reported by the driver in the output file <pgm> opt.f90. The user can get a notice on this error when AUTO will compile <pgm> opt.f90 before execute the instructions of <pgm> opt.auto, so in anyway the user has the possibility to correct it, but it’s always suggested to compile file <pgm>.f90 and look for errors before using AUTOopt in order to safe time.

2.2 The <pgm> opt.f90 file

In this paragraph we will enter in the details of the output file <pgm> opt.f90. Before doing this, it’s important to make some remarks on the terminology that will be used in the following. When it’s talk about those equation that are not generated by driver, so those that define the BVP of paragraph 1.1 and that are defined by the user in the input file <pgm>.f90, it will make reference to them with therms like the old integral constraints or the BVP ODEs. Instead, when it’s talk about the equations (1.25), it will make reference to them with therms like the new equations or the BVOP new boundary conditions. In particular, the (1.25a) are the co-states equations, the (1.25b) and (1.25c) are the co-states boundary conditions, while the (1.25d) and (1.25e) are the co-states integral constraints. For BVOP equations or BVOP system it will intend all it’s equation, so those of the BVP plus the new equations. Also for the subroutines a distinction is made. Those that are named in file <pgm> opt.f90 as the AUTO standard subroutines will be called main subroutines, while those that were named as the AUTO standard subroutines in file <pgm>.f90 and that are reported in the output Fortran file with the suffix USER, will be called USER- subroutines or user subroutines. The text of file <pgm> opt.f90 can be divided in three parts:

• module text: always inserted at the top of the Fortran output files, it contains the definitions of module cons and of all the variables that has to be shared between the main subroutines. The module is a Fortran construction which allows to share variables (and/or subroutines and functions) between different subroutines. In this file, the module called cons (constants) is used to store and share those variables in which are saved the new parameters indices. Such data will be used by the main subroutines to create the new equation of the BVOP system. The stored variables are:

– NBCOLD: is the number of boundary conditions of the starting BVP. It’s the value of NBC inserted by the user in file c.<pgm>;

– NINTOLD: is the number of integral constraints of the starting BVP. It’s the value of NINT inserted by the user in file c.<pgm>;

– NPAROLD: is the total number of BVP parameters. It’s the value of NPAR inserted by user in file c.<pgm>;

(28)

– NLAMBDA: is the total number of λ parameters defined by the user in file c.<pgm> with vector ICP. It’s computed with the difference between the length of ICP and NMU ;

– OMEGA: is the index of the parameter assigned to ω; – GAMMA: is the index of the parameter assigned to γ;

– KAPPA: is a vector of length NINTOLD containing the indices of those pa-rameters assigned to store the κ papa-rameters. If NINTOLD=0, and so the BVP doesn’t have any integral constraint, this list will be not inserted in the module because it’s useless and no parameters will be defined to store the unnecessary κ parameters;

– BETA: is a vector of length NBCOLD containing the indices of those pa-rameters assigned to store the β papa-rameters. If NBCOLD=0, and so the BVP doesn’t have any boundary condition, this list will be not inserted in the module because it’s useless and no parameters will be defined to store the unnecessary β parameters;

– ALPHA: is a vector of length NLAMBDA containing the indices of those parameters related to the α parameters. The first one refers to the norm α0 while the others to α2:nλ

– ICPU: is the copy of vector ICP inserted by the user in file c.<pgm>. It’s length is NMU+NLAMBDA and contains the user specified indices of the BVP parameters related to the µ and λ ones. The first NMU elements are the indices referred to the µ parameters, while the others to the λ ones.

The user should not change any value inside the module, in order to guarantee the file functionalities.

• core text: contains the definition of all the main subroutines plus the so called D- subroutines. These ones are used to evaluate the co-states ODEs, boundary conditions and integral constraints, which can be derived by the first derivatives of the BVP equations.

• user text: is the copy of <pgm>.f90 file text, in which at the AUTO standard subroutines names has been added suffix USER-, i.e. FUNC became USERFUNC, BCND became USERBCND and so on. So it’s the text in which are contained the user subroutines, which will be used to evaluate the BVP equations.

The name used for the parts are equal to those of the variables in which the Python code of AUTOopt saves that corresponding parts, in order to build the final text of <pgm> opt.f90. This is done to keep the same names along this script.

(29)

Figure 2.1: An example of module text

2.2.1 The JAC cases

The text of the main subroutines depends on the JAC case selected by the user. With JAC case it will make reference to the value of constant JAC specified by the user in the input file c.<pgm>. For example with JAC case equal 1, it will be referred to all that cases in which the user has setted JAC=1 in file c.<pgm>. As you know, to compute the new equations are necessaries the first derivatives of:

- the BVP ODEs with respect the BVP states and parameters µ and λ;

- the BVP boundary conditions with respect the BVP initial state, the final state and parameters µ and λ;

- the BVP integral constraints with respect the BVP states and parameters µ and λ; - the objective functional with respect the BVP states and parameters µ and λ. File <pgm> opt.f90 can compute such derivatives in two different ways:

- with the finite differences

- with their expression specified by the user in file <pgm>.f90, which can be recovered by calling the user subroutines;

The method used depends on the JAC case selected by the user. Indeed, AUTOopt has been designed in order to let the user decide if compute manually the expressions of the first derivatives of the system, and then give them as additional data to the driver, or give as input only the BVP equations and let the driver approximate them with the finite differences. AUTOopt knows if this derivatives are been specified in file <pgm>.f90 through the value of constant JAC inside file c.<pgm>. If it’s value is 0, the driver will generate in file <pgm> opt.f90 a core text in which the main subroutines will perform the finite differences, and will construct the new equations with approximated derivatives.

(30)

Instead, if the value of JAC is 1, the main subroutines will compute the first derivatives by evaluating their expression given by the user. If it’s decide to give the first derivatives as input, all of them must be specified. It’s not possible to specify only a part of them. Further, the user is allowed also to give the second derivatives of the BVP equations with the first ones. As seen in paragraph 1.4.2, AUTO can use the first derivatives of all the equations of the system specified in file .f90 (derivatives of the constraints included) to perform a more precisely continuation. To let the user utilize this option by setting JAC=1 in c.<pgm> opt, the main subroutines can compute the derivatives required by AUTO starting from those given by the user. As will be showed in the following paragraphs, if the user gives the first derivatives of the starting BVP system, a lot of the BVOP ones can be trivially computed. Only a few part of them need additional computations, which depends on the specifications of the BVP second derivatives. If those aren’t present, the missing derivatives will be computed again with the finite differences, otherwise will be computed by evaluating them through their expressions. To let AUTO know that both, the first and second derivatives, are been inserted in the <pgm>.f90 file, the user has to set JAC equal to 2 in c.<pgm>. Summing up, the JAC cases are three and they depends on the value of JAC in c.<pgm>. If in the c. input file:

- JAC=0 : the driver will suppose that the user hasn’t specified the BVP derivatives. This means that AUTOopt will generate file <pgm> opt.f90 in order to let it com-pute the derivatives necessaries to evaluate the new equations with finite differences. The user can solve the BVOP only with JAC=0 in file c.<pgm> opt;

- JAC=1 : the driver will suppose that the user has specified all the first derivatives of the starting BVP. If the user specifies JAC=0 in file c.<pgm> opt, those derivatives will be used only to construct and compute the new equations. In this case AUTO will evaluate all the first derivatives of the BVOP with finite differences for contin-uation purposes. Instead, if JAC is equal 1 in c.<pgm> opt, the first derivatives will be used to construct and evaluate the new equations, to give AUTO all the BVOP system’s derivatives that can be trivially computed from those of the BVP, while all the remaining ones will be approximated in the main subroutines with the finite differences, and then passed to AUTO. In this case AUTO doesn’t perform any finite difference, because it knows all the BVOP first derivatives;

- JAC=2 : the driver will suppose that the user has specified in file <pgm>.f90 the BVP first and second derivatives. If the user wants to continue the system with JAC=0 in c.<pgm> opt, the derivatives will be used to compute the new equations and AUTO will evaluate the BVOP system’s first derivatives with the finite dif-ferences to make the continuations. With JAC=1, the derivatives will be used to compute the new equations and to evaluate all the BVOP derivatives to be passed to AUTO. In this case, neither AUTO or the main subroutines of file <pgm> opt.f90 uses the finite differences.

Final remark, when the driver generates c.<pgm> opt it will assign to JAC the value of 0 if the JAC case specified by the user is 0, while for the other two it will assign to variable

(31)

JAC the value of 1, so in this cases if the user performs the continuation strategy without change something in the output files, AUTO will use the derivatives given by the user.

2.2.2 The user subroutines

When the JAC case is equal 1 or 2, the main subroutines of file <pgm> opt.f90 use the expressions of the first and/or second order BVP derivatives. This expressions must be specified by the user in main subroutines of file <pgm>.f90. But, how can be practically done this? To give an answer to this question we should explain the task of the user subroutines and how they are created and used in file <pgm> opt.f90. For example, sup-pose that we have defined our starting BVP model in a file <pgm>.f90. In the subroutine FUNC we have inserted the ODEs, in BCND and so on. We have written such file ac-cording to the AUTOopt requirements, free by coding errors and like a normal AUTO Fortran file, i.e. like it’s the file representing the system that we will continue. This means that we have specified an initial solution in STPNT, we have setted the ODEs equal to the elements of the vector F (that’s the output of FUNC ), the boundary conditions to the elements of FB (output of BCND ) and so on. We execute the driver and we generate file <pgm> opt.f90. In this file, the driver has written the user text by copying the text of <pgm>.f90 and by changing the names of its main functions, by adding to them prefix USER. Subroutine FUNC became USERFUNC, STPNT became USERSTPNT and so on. This subroutines rename is done for two reasons:

1- remove the interference that will be created with the main subroutines definition in the core text. Indeed, there should not be defined two subroutine with the same name in file <pgm> opt.f90. Further, the main subroutines should return to AUTO the values of all the BVOP equations, not only of the BVP ones. AUTOopt copies without adding nothing to the text of file <pgm>.f90 created by the user, that doesn’t have to insert nothing for evaluate the BVOP equations, so this subroutines cannot be used as main subroutines in the output .f90 file. They cant evaluate the complete BVOP system.

2- make those subroutines callable from the main subroutines inside the core text, in order to let them evaluate the BVP equations.

Now, consider the obtained subroutine USERFUNC. It is completely equal to subroutine FUNC of file <pgm>.f90. Nothing as been changed. Also it’s arguments are equals, in names,types and intent attributes. Until now we have said that the main subroutines of <pgm> opt.f90 calls the user subroutines to evaluate the BVP equations. But they can also allowed the driver to evaluate the first derivatives of the system. Indeed, by adopting the same definition of the old main subroutines and by changing just their name, the user subroutines have all the necessary elements to evaluate and transmit the first derivatives values. As input they takes the states vectors U,U0,U1 and the parameters vector PAR, which can be used to evaluate the equations stored in their output vectors (F for FUNC, FB for BCND and so on) and they have also some matrices that can be used to define the

(32)

derivatives. Going back to the example of USERFUNC, the user could define the BVP ODEs derivatives in the old subroutine FUNC by assign their values to the elements of matrix DFDU, which will be sent to the new subroutine FUNC any time it makes a call to know the values of the BVP ODEs. The same procedure can be done for the derivatives of the boundary conditions, integral constraints and objective functional. Summing up, to define the first derivatives when JAC case is equal 1 or 2 the user as to assign their values to the standard matrices that AUTO uses to store them. More precisely, in file <pgm>.f90, the user has to define:

- the first derivatives of the BVP ODEs in subroutine FUNC by assigning their val-ues to the elements of matrices DFDU end DFDP. In DFDU should be stored the derivatives with respect the BVP states, while in DFDP those with respect the system’s parameters. According to the numeration of AUTO, the generic element DFDU(a,b) is the derivatives the a-th ODEs with respect the b-th state. For ex-ample, in DFDU(3,4) should be stored the derivatives of the third ODE (i.e. the third element of the output vector F ) with respect the fourth BVP state (i.e. the fourth element of the input vector U, which is the state). Almost the same for matrix DFDP, in which the generic element DFDP(a,b) stores the derivative of the a-th ODEs with respect to the b-th BVP parameter (i.e. the b-th element of vector PAR, which is PAR(b)). For example the element DFDP(2,3) is the derivative of the second BVP ODE (i.e. the second element of vector F ) with respect the third BVP parameter (i.e. the third element of vector PAR,PAR(3)). The dimensions of the matrices are DFDU(n,n) and DFDP(n,np) where n is the number of BVP states and np is the total number of BVP parameters (i.e. it’s equal to the value of variable NPAR inserted in file c.<pgm>);

- the first derivatives of the boundary conditions in subroutine BCND by assigning their values to the elements of matrix DBC. In this matrix should be stored all the derivatives, those respect the initial and final states plus those made with respect to the BVP parameters. They are stored in the following way:

- in the first n columns should be stored the derivatives with respect the initial states (i.e. with respect the elements of vector U0 );

- from column n+1 to column 2*n there should be stored the derivatives with respect the final states (i.e. with respect the elements of vector U1 );

- from column 2*n+1 up to the last one there should be stored the derivatives with respect the BVP parameters;

Remember that matrix DBC has dimensions (nb,2 ∗ n + np) where nb is the number of BVP boundary conditions, n is the number of BVP states and np is the number of BVP parameters. For example, suppose that nb = 4, n=3 and np = 3. The elements DBC(2,1:3) are the derivatives of the second boundary condition equation (i.e. second element of FB ) with respect the initial BVP states (U0(1),U0(2) and

(33)

U0(3)). The elements DBC(3,4:6) are the derivatives of the third boundary con-dition equation with respect the final BVP states, i.e. DBC(3,4) is the derivative with respect the first final state, which is the first element of U1 and so on. While DBC(1,7:9) are the derivatives of the first boundary condition with respect the three BVP parameters. DBC(1,8) is the derivatives with respect PAR(2);

- the first derivatives of the integral constraint in subroutine ICND by assigning their values to the elements of matrix DINT. Like matrix BCND, in DINT should be inserted all the derivatives of the integral constraints with respect the BVP states and parameters. Its dimension are (ni,n + np) where ni is the number of BVP integral constraints, n is the number of BVP states and np is the number of BVP parameters. The derivatives are stored in the following way:

- in the first n columns should be stored the derivatives with respect the states (i.e. with respect the elements of vector U );

- from column n+1 up to the last one there should be stored the derivatives with respect the BVP parameters;

For example, if ni = 3, n=5 and np = 4, element DINT(3,5) is the derivative of the third BVP integral constraint (i.e. the third element of vector FI ) with respect the fifth state (i.e. the fifth element of vector U ). Instead, DINT(5,8) is the derivative of the fifth integral constraint with respect the the third BVP parameter (i.e. the third element of vector PAR, PAR(3));

- the first derivatives of the objective functional in subroutine FOPT by assigning their values to the elements of vectors DFDU end DFDP. This two have the same name and functions of the matrices used in FUNC to store the ODEs derivatives. The difference is that the objective functional is just one equation, so they are row vectors and not matrices. For example, DFDU(3) is the derivatives of the objective functional with respect the third BVP state, while DFDP(4) is the derivative of the objective functional with respect PAR(4). DFDU has dimension n (total number of the BVP states) and DFDP has dimension np(total number of the BVP parameters). To define the second derivatives it is asked one more step. Indeed, the problem is that the user subroutines, as we have considered defined them until now, don’t have any additional output that we can use to transmit the second derivatives to the new main subroutines. This means that we have to change their definition by adding them additional output arguments. This is made by the driver when the selected JAC case is equal 2. As will be showed in paragraph 2.4, in this case, AUTOopt modifies not only the name of the old main subroutines, but also their arguments by adding elements that allows the new main subroutines to receive the second derivatives from the user subroutines. Those arguments are three dimensional matrices that can be used by the user to store the second derivatives in the main subroutines of file <pgm>.f90. Referring to that file, keeping the same definitions of n,nb,ni and np used previously, the matrices are:

AUTOopt : an Auto driver for boundary-value optimization problems

POLITECNICO DI MILANO