Preconditioning

[alphaville]

(Implemented preconditioning in Python)

Implement scaling of the cost function and the constraints...

where, for example,

and

[which is not very straightforward as we don't compute the Jacobian of F1 directly]

The weights can be easily computed in Rust.

[alphaville]

@korken89 This is why this is not so straightforward: we need to compute scaling parameters w_f, w_1 and w_2 such that the FBE becomes

Recall that in Rust, we only have access to F1, F2 and psi, but not f and that psi as well as its gradient auto-generated.

The problem is not how we can compute the scaling parameters w_f, w_1 and w_2, but how to actually scale psi and its gradient.

However, here is a possible easy and, in my opinion, clean solution: Casadi will generate code for the function

the argument p is already there: it is the user-defined parameter; the additional argument w will be the vector of scaling parameters. In fact this may or may not be part of p.

In other words:

My proposal would be to use the existing vector p to pass w because it will be less disruptive.

[korken89]

Makes sense, I don't remember the interface we use right now, but I understand there is a limit on the interface and we cannot add more parameters? Or is it just simply a simple way to include the new scanning parameters?

[alphaville]

That's an overview of the various interfaces:

The question is whether to:

• make w part of the ALM vector xi or
• make xi part of the parameter vector p or
• create a new argument for the scaling parameters

Moreover, we currently do not compute the Jacobian of F_1 or F_2 (well, in a way we do, but only implicitly), but we'll have to in order to determine w_1 and w_2. We'll have to split F_1 and F_2 into multiple functions F_{1, j} and F_{2, j}.

[korken89]

Ah okey, it's an issue for the augmented Lagrangian. Does the penalty method have the same issue?

[alphaville]

@Arun-R-M @smokinmirror To push this forward, let us break it down into small tasks. Every task should correspond to a PR.

Regarding DevOps:

• create a branch called dev out of master
• for every PR, create a branch out of dev and after review, merge it into dev (not master)
• include unit tests where possible in every PR

Here is a list of tasks:

• [x] In Python, generate a C file (via CasADi) with the preconditioning parameters (the w's and ρ). Do not change the number of parameters of the solver at this stage [see #286]
• [x] For each generated function (e.g., w_cost, wf_1, wf_2, init_penalty) we need to update casadi_memory.h with the casadi-specific constants that will be needed to call the functions from C [see #287]
• [x] In templates/icasadi/, in interface.c, implement a wrapper in C around the auto-generated files. The file icasadi/build.rs has to be modified to include the auto-generated C file with the preconditioning parameters. There are several examples in the same file. You must test this implementation. [see #288]
• [x] Move on to templates/icasadi/icasadi_lib.rs. This generates the file icasadi/lib.rs. There you need to make an interface to allow you to call the C code from Rust.
• [x] Modify templates/optimizer.rs. This generates the main file src/lib.rs in the auto-generated solver. Focus on function solve

[korken89]

🚀

Happy to see this getting some focus :D

[korken89]

Also, ping me if you want some feedback :)

[alphaville]

Also, ping me if you want some feedback :)

Thank you, Emil. This is almost done now (we're testing it). I'll send you a review request soon.