search

Rapid-Design-of-Systems-Laboratory / beluga

General purpose indirect trajectory optimization
Other
25 stars 6 forks source link

Make optimlib's workflow composable #201

Closed msparapa closed 4 years ago

msparapa commented 5 years ago

Thomas had sort of started this work with his simplepipe package. We had to remove it because of other issues, but I've had the overall goal of what he did in the back of my mind. I think we might be able to implement it cleanly now.

msparapa commented 4 years ago

I'm noticing some random bugs popping up here and there because of some of our data handling within optimlib. Truly chaining together operations as opposed to just following the mathematical idea would solve these bugs.

msparapa commented 4 years ago

@SeanMatthewNolan I need some insight on two things:

  1. Can you look through indirect.py on this branch (I201) and see if you like how I have everything set up? Only a handful of problems work, but I don't want to sink too much effort into this if it's bad. I've only run the Goddard rocket, BFR, and Rayleigh oscillator problems so far.

  2. Can you run the Goddard rocket on the master branch, and then run it on I201? My runs on I201 are twice as fast, but they should be identical problems so that doesn't make sense to me.

SeanMatthewNolan commented 4 years ago

It looks better to me. I don't have much to add, honestly. The only thing is thinking about relying more on Sympy symbols than strings, but that probably doesn't fit into this change.

The Goddard rocket problem runs twice as fast for me too. Did you change the way quantities are done? My guess is that the new way generates mathematically equivalent but computationally superior expressions.

msparapa commented 4 years ago

So I'm going to have the OCP and BVP classes automatically convert string inputs to sympy objects, but the output from optimlib is going to be identical to before since I know you're currently working on codegen.

A bit... but everything should be compiled by numba prior to going into the bvp solvers. Maybe I fixed a bug we never knew about.

msparapa commented 4 years ago

I think this is finally done. There's some things here and there that still don't make a lot of sense, like adjoining time prior to dualization but scaling the differential equations after dualization, but this is how everything was done prior to #201. I tried to keep everything modeled the same as before, but the process itself is different. The random bugs I was seeing dealing with indices and dictionaries not in the right order seem to be completely gone.

I changed a small bit in the OCP definition. Path constraints are defined with a different command. This might be a good time to write the OCP definition how we want and move to version 0.4.0