Multicore Programming / increase efficiency

[Jonas]

Hello everyone,

I am looking for a way to speed up the OCP solver.

The cost function is partly given by a Gaussian Process Regressor offline calculated by GPFlow earlier. Each GPR call takes ~5 sec. Therefore, it takes a looong time to calculate a solution for the OCP problem. I am working on increassing GPFlows performance, not sure if it is possible at all though.

Nevertheless, you might have an idea of how to increase Casadis performance. I am particularly thinking about using my universities HPC cluster. It seems like MUMPS supports shared memory, multithreaded parallelism and it looks like HSL_MA97 does as well (would prefer mumps only for convenient reasons though).

Do I have to/ Is it possible to control the use of multicores within Casadi, like

opt ={"parallel_computing": True},

or do you have any other option to determine this? Or is it default enabled that the solver looks for the fastest possible way?

I am totally new to this stuff, so apologies if I ask obvious things.

Also, I am happy about any other idea on how to increase performance.

Thanks in advance!

Jonas

[Joris Gillis]

Dear Jonas,

First you need to find out whether the bottleneck is in function evaluations or in solver time.

The solver printout should help with that assessment.

Also, can you provide more details on your problem setup?

Where does the GPFlow call occur? Only in the objective? Or also in constraints? Does is depend on a lot of variables?

How do you get sensitivity information from GPFlow? Are you looking for a method with an exact Hessian or limited memory approximation?

Best regards,

  Joris

[Jonas]

Dear Joris,

the solver did not finish so I don't have the full printout.

The GPFlow only occurs in the cost function, not in the constrains. It depends on 4 controls (which are all I have) and 1 state (I have 3 states in total).

Within GPFlow, it needs to calculate a 1 x n  vector, each entry needs to be calculated (exp(x_i * x_new) ) and then multiplied with nx1 constant vector. Since n = 700.000 I totally understand it takes its time. All this happens within the GPFlow function, so is kind of blackbox and I cannot actively manipulate there. GPFlow is designed for high data dimensions though. I know that reducing n would be the first idea but due to the modeling approach I have had earlier I'd prefer not to do so and pay this by having longer calculation times. 

If I solve the OCP having a cost function without GP it works perfectly fine and doesn't take more than a few seconds. So I don't think the botteleneck comes from the ODE System but from calling GP.

Using another cost function given by an API function with a counter showed that during the optimization process it called the function 200.000 times, so everytime evaluating GP sums up I guess.

I dont really understand "a method with an exact Hessian or limited memory approximation". I am using multiple shooting which seems to be the most robust method but I am open to other methods. I don't need the Hessian I basically just care about the optimal state and control trajectory.

Thank you very much,

Jonas

[Joris Gillis]

Dear Jonas,

"cost function without GP it works perfectly fine and doesn't take

more than a few seconds" -> right, so looking into solver
parallelization (MUMPS/HSL) does not make sense.
Only objective -> look for a way to get reverse/adjoint sensitivities
out of your blackbox GPFlow. You are using finite-differences now to
get sensitivities?

Multiple shooting is a method to transcribe OCP to NLP. Exact
Hessian/limited memory relates to the NLP solver. I'd advise to try:
opts.ipopt.hessian_approximation = limited_memory;

Best,
Joris

> --
> Sent from CasADi's user forum at http://forum.casadi.org.
> ---
> You received this message because you are subscribed to the Google Groups
> "CasADi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to casadi-users...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/casadi-users/d9c2c4cc-385c-4de3-af0c-a9c813436138%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

[Joris Gillis]

Note that a reverse/adjoint sensitivity may also be referred to as 'gradient'. cfr https://github.com/GPflow/GPflow/issues/643

> email to casadi-users+unsubscribe@googlegroups.com.

[Jonas]

Dear Joris,

thanks I will give it a try. In Python

opts = {}
opts['ipopt.hessian_approximation'] = "limited_memory"    

doesn't work, what is the right syntax?

Thanks,

Jonas

[Jonas]

PS

Thanks as well for the info about parallelization.

Yes, finite differences it is.

Am Mittwoch, 25. Juli 2018 14:54:20 UTC+2 schrieb Joris Gillis:

[Jonas]

My bad,

"limited-memory" it is.

Thanks so much so far!
I will try your suggestions :)