Add example for a multiphase problem.

[moorepants]

I realized that we can probably do multiphase problems with something like this. But I am currently limited to the duration of each phase having to be equal. @Peter230655 any ideas on how to let this block collide with the wall at any time? My intuition is that I need to move the collision equation from the instance constraints into the DAE somehow.

[Peter230655]

I realized that we can probably do multiphase problems with something like this. But I am currently limited to the duration of each phase having to be equal. @Peter230655 any ideas on how to let this block collide with the wall at any time? My intuition is that I need to move the collision equation from the instance constraints into the DAE somehow.

Let me think about it. :-)
(As I understand, you want it with Newtonian collission, so we have different eoms before and after the impact?)

[moorepants]

There is essentially just 1 eom in this case because the block is always sliding:

$$ m\dot{v} = -\textrm{sgn}({v})\mu m g + F $$

but at $x=1$ the impact occurs and you apply a mometum balance for before and after impact:

$$ v_\textrm{after} = e v_\textrm{before} $$

If you break the EoM into the moving right and moving left portions, then you can remove the dicontinuity in the EoM. So then you do have 2 EoMs, one for before and one after.

[Peter230655]

There is essentially just 1 eom in this case because the block is always sliding:

m v ˙ = − s g n ( v ) μ m g + F

As I understood the equations in your code, F = 0 after the impact, the equation above seems to imply F is present always?

but at x = 1 the impact occurs and you apply a mometum balance for before and after impact:

v a f t e r = e v b e f o r e

If you break the EoM into the moving right and moving left portions, then you can remove the dicontinuity in the EoM. So then you do have 2 EoMs, one for before and one after.

I guess with Newtonian impact, by definition the speed will change discontinuously - something opty does not like.
So, two eoms are likely necessary.
Is Newtonian collision important, or would Hunt-Crossley also be o.k.?

I am asking, so I know in which direction to think.

[moorepants]

As I understood the equations in your code, F = 0 after the impact, the equation above seems to imply F is present always?

I wrote one equation in this comment, but I split it into two in the opty formulation.

[moorepants]

Is Newtonian collision important, or would Hunt-Crossley also be o.k.?

The point of this example is to avoid discontinuities when transitioning between phases of a problem. I can solve this with an impact force, but that's not the purpose. Sometimes you want to model transitions from one eom to another, e.g. standing on the ground, jumping off, and landing but not have to model the contact forces with things such as Hunt-Crossely. Newton's momentum exchange is a perfectly good model for impact also.

[Peter230655]

Is Newtonian collision important, or would Hunt-Crossley also be o.k.?

The point of this example is to avoid discontinuities when transitioning between phases of a problem. I can solve this with an impact force, but that's not the purpose. Sometimes you want to model transitions from one eom to another, e.g. standing on the ground, jumping off, and landing but not have to model the contact forces with things such as Hunt-Crossely. Newton's momentum exchange is a perfectly good model for impact also.

All clear now to me, I think.

[Peter230655]

Could this be done as a two stage problem, similar to PR #262 ?

In your example, splitting it up will simply result in using maximum force until impact, and in the second phase there is no control left for opty to do anything with. It will just slide.

In PR #262 the second phase is depending on the first one, through the amount of fuel left. (the third phase is like your second phase: nothing left to be controlled)
When I did it, I had to optimize the the first and second phases separately - and surely this must be worse (maximally equal) to optimizing them combined. I do not know, how Betts optimized them, but the results of PR #262 and of Betts are quite close.

So, I guess the goal must be to do it in one stage (splitting it up is 'primitive') - let me think along these lines.

[moorepants]

When I did it, I had to optimize the the first and second phases separately - and surely this must be worse (maximally equal) to optimizing them combined.

Yes, I want to solve these kinds of problems where all phases are solve simultaneously. My example here may be able to be solved by separating into multiple optimal control problems but, in general, we'd like to solve problems this way that cannot be solved separately. That's what I'm trying to do, but there may not be a "hack" to get opty to do this. It may be something we have to build into opty more carefully.

[Peter230655]

When I did it, I had to optimize the the first and second phases separately - and surely this must be worse (maximally equal) to optimizing them combined.

Yes, I want to solve these kinds of problems where all phases are solve simultaneously. My example here may be able to be solved by separating into multiple optimal control problems but, in general, we'd like to solve problems this way that cannot be solved separately. That's what I'm trying to do, but there may not be a "hack" to get opty to do this. It may be something we have to build into opty more carefully.

I do not know, but I am getting clearer in the direction of thinking.
Would it be of any help to ask John Betts whether he solved #262 simultaneously or one after another?

[Peter230655]

In your program, the impact is halfway through the duration. This can be changed, and the optimum does not seem to be the middle. But no progress in finding a hack, yet

[moorepants]

There may be no hack. We probably have to make opty handle multiphase problems properly.

[Peter230655]

You are probably right - but I have time to play around. :-)

[Peter230655]

What I did here, just to get a feel was this:
I moved the impact time at various points during the journey.
What I mean: if duration = n * h, then I set the impact time at impact = n/T * h for various T > 1 (200 different T in the picture)
There clearly seems to be a minimum.

(forget the red lines, I drew them by accident, no meaning)

I am trying to replace the impact time with a DAE in the eoms, as you suggested.
Too early to say, whether this is a feasible route.

Similar picture, just max. force changed from 200 to 160

[moorepants]

I could change the requirement that the block simply travels 2 meters total and is stationary at the start and the end. Maybe a solution that had varying periods of no motion at the start and end is possible, where these two stationary periods are not equal in time.

[Peter230655]

In your original set-up the block was not at rest at the end, you left its speed open. So I also did it in my simulation.
My set up mimicks exactly your original set-up, except I let opty decide the point of impact - and it does find a better one! :-)

[Peter230655]

For clarification:
The plots above were created by moving the time of impact around, from early on in the journey to late in the journey.
But every time the time of impact was predetermined! I only wanted to see if the time of impact relative to total journey had an influence on the length of the journey - otherwise there would be nothing to optimize.
It does have an influence of the length of the journey, so there was a chance for opty to find a good time of impact - which it does.

[moorepants]

I don't see how you can move the time of impact in my example that requires the duration before impact to be the same as the duration after impact. That is is hardcoded in my example here.

[Peter230655]

I did it like this:
The time of impact is still predetermined, just does not have to be the middle of the journey.

teiler = 1.667
zs = int((num_nodes - 1)/teiler) * h
dur = (num_nodes - 1) * h

instance_constraints = (
    xr(0*h) - 0.0,
    xr(zs) - 1.0,
    vr(0*h) - 0.0,
    vl(zs) + e*vr(zs),
    xl(zs) - x_impact,
    xl(dur) - 0.0,
)

But this is not the main point of my simulation. The main point is that opty decides the time of impact - which it seems to do.
x_impact is trhe location of the wall, x_impact=1.0 in your original example. Of no importance.

[moorepants]

I think I understand, your problem's duration is much longer. It simulates xr past the impact (> ~ 0.11 seconds). That is nonsense for xr, because it shouldn't continue past 1 meter. If you then look at xl at t=0 it start at 2.5 meter (not 1 meter!). So it seems you are not solving the problem as stated.

[Peter230655]

YES, mine is much longer.
I think, it solves the physical problem, but one after another, not simultaneously so to speak.

Now I understand what you meant by different time intervals: To solve simultaneously with t_impact != (tf - t0)/2 one would need different length time intervals.

What is the advantage of doing it simultaneously? I guess saving CPU time?

[moorepants]

Ok, I now see what you did and that it is likely a valid solution. I would have never thought about simulating the equations of motion outside of the x = 0 to 1 meter range. But if you relax that restriction (a hack), then you can find a solution.

[moorepants]

What is the advantage of doing it simultaneously? I guess saving CPU time?

You are solving the problem outside of the bounds of interest. So you have to also ensure that portion can solve. This will depend on CPU as well as your ability to get a solution. It is trivial for this test example, but would not be for a complex model.

[Peter230655]

Even with this simple example, when I moved t_event too close to t0 or to tf, it would not find a solution easily.
(But I did not pay too much attention to this: for just about any simulation I have played around with, it took some trying different things before it would converge...)

From this step it was only a small step to let opty find t_impact. But again it took trying things before it would converge.
My feel is, it is hard to judge from the equations, whether a problem is hard: The brachistochrone were very simple equations, but hard to get a solution.