multiphase collision.
This is not yet a fully 'beautified' version. I pushed it for you to see, if this is along the lines you thought. In principle, your idea of adding DEAs to the eoms seems to work in this case. The convergence is not trivial: I had ot play around so I could understand how to make it converge.
I scanned through it, but I don't easily understand what you have done.
One comment is that the solution I'm (likely) interested in would not involve any approximations of non-continuous functions. The reason to break the simulation into the leftward and rightward motion is to avoid such functions because the motion is continuous in each of those periods.
Right now, I am working on a better explanation, will push it when finished. Essentially what I did was this:
- run your program, except that instead of having the collision right at the midpoint of the journey I moved it to around 2/3 of the journey., but still a predetermined point in time. This is only to create a good initial guess.
- Run the 'main program' with this initial guess. Here I add two additional eoms which enforce that x_l = x_r when x_l reaches the wall and v_l = e*v_r when x_l reaches the wall. But when x_L will hit the wall is determined by opty.
I kept your set-up completely, except I let opty decide the time of the collision. I have to use differentiable hump functions for this, opty will not accept ``Heavyside` type functions to the best of my knowledge.
In the version I am working on right now, this is explained better.
I added explanations and 'beautified' it. As I now understand, it does not solve 333 as you wanted it solved. If it does not add anything to examples-gallery, I will close it and push it to pst-notebooks. ( I feel it does show something new: how to solve a problem like the one in #333 by running it partially outside the physical meaning and then using hump functions to let opty determine the time of impact - but of course only you are the best judge what is viable for examples gallery. It does not take much time: less than 2 sec on my PC)
We have enough examples where you have shown how to make a smooth step or hump function. I'm not sure what this adds to the examples.
Reopen if you think this bring something new.
Better delete. The idea was to 'switch' eoms along the path. It worked for this simple example, but totally failed on a more difficult one.
Reopening, maybe we will add this as it has an interesting method.
Just brought the branch up to date.