estimate time shift

[Peter230655]

I wanted to play around with #294
Unfortunately, I misunderstood the issue, so this does not solve #294

What it does is this:
It estimates $\delta$ (and on the way also F and $\omega$) if the driving force is e.g. $F\sin(\omega(t - \delta))$
(of course sin could be replace by another given function)

[moorepants]

This is equivalent to a phase shift in the sin(): sin(w*t + phi).

opty does not yet support having time explicit in the equations of motion and we have shown how to make time explicit by introducing a variable T(t) in another example. So I'm not sure this adds any new tricks for a reader of the documentation. Let me know otherwise.

[Peter230655]

I agree, nothing new here.
I will think of an example with explicit time, maybe Betts has one. My rolling ball on a spinning disc had explicit time, but I used your trick there with a known trajectory, as it made more sense.

[Peter230655]

Now I ran into something odd:

I wrote $torque = F \cdot T(t)^2 \cdot sin(\omega(t - \delta) \cdot stepdiff(t, \delta, steep)$
that is I added explicit time, and replaced T(t) in the functions with the time symbol t

Backend='numpy' accepted this without any issues, but backend='cython' raised a long error.
If T(t) was inside the functions, 'cython' had no problems.

'numpy' seems raise the same error, just took it much longer to get there. T(t) inside the functions seems acceptable to both.

[Peter230655]

I used $torque = F \cdot T(t)^2 \cdot \sin(\omega(t - \delta)) \cdot stepdiff(t, \delta, steep)$
I played around some more and I found this:

• if I fix $\delta$ and leave t in the functions, 'numpy' will set up Problem, an error comes with solve. In this situation 'cython' already raises an error in Problem
• if I leave $\delta$ an unknown parameter, both backends raise an error in Problem already.
• if I replace t with T(t) both backends get the result.

I will push this new version, with additional comments in the docstrings again. If what I found is correct, this may be an interesting example?

[moorepants]

Are you saying that omega(T(t) - delta) works if omega is a state (or input)?

[Peter230655]

Are you saying that omega(T(t) - delta) works if omega is a state (or input)?

It worked for me, if this is the argument of a known function, like sm.sin(omega(T(t) - delta)).
It did not work for me with T(t) replaced by t
I only tried with omega, delta = unknown parameters, not with unknown_input_trajectories.

[moorepants]

The thing we are trying to solve with Christoph's PR is that an unknown state or input variable is a delayed function of time. It still is not clear if you are addressing the same issue or something else.

[Peter230655]

No, this is not the same issue I am addressing.
I re-opended my PR because opty did not accept something like sin(omega(t - delta), with omega and delta unknown parameters, but it does accept sin(omega(T(t) - delta)) without any problems. I thought, this may be of independent interest.

I have not tried anything like state_variable(omeaga(t - delta)).
I cannot think of a simple example where this would be needed. If you or Chris can give me an idea, I could play around with it, likely unsuccessfully, but I have time. :-)

[moorepants]

If omega is an unknown parameter, that is a constant. I don't even know what it means to do something like omega(...). I didn't think that was defined on a symbol.

[Peter230655]

Fair enough! An unknown parameter of course is an unknown constant.
I should have written: sin(omega*(t - delta)), this was what I meant.

[Peter230655]

I pushed again for two reasons;

• I added explicit time dependence in the eoms. We have this in other examples, but there it was solved using a known_trajectory (Betts&Huffman 2003, ball_rolling_on_spinning_disc), here a state variable is used to mimick the time.
• An expression like sin(omega*(t - delta)), with delta and omega unknown parameters, does not seem to work with opty, but sin(omega*(T(t) - delta)) does work fine, with T(t) being the state variable to mimick time. I believe, this is new in our examples - at least new for me.

[moorepants]

This example shows how to use T(t) for explicit time: https://opty.readthedocs.io/stable/examples/beginner/plot_betts2003.html

[Peter230655]

I mentioned this in my comment. This where I got the idea to use it in my spinning disc.
But is using a state variable and setting T(t).diff(t) = 1.0 in the eoms not still simpler? I do not recall, whether the known_input_trajectory way would accept a variable time interval. The state_variable way does work in any case.

However I feel my second observation, if correct (all my tests confirmed it) is more interesting, and does seem to show something new.
NB: Both 'numpy' and 'cython' fail if t instead of T(t) is used in the sin function or the step function, but the error messages are a bit different,

[moorepants]

If you have a workaround to get expclit time working with variable time step, then we should show that. Maybe even in place of the idea shown in https://opty.readthedocs.io/stable/examples/beginner/plot_betts2003.html

However I feel my second observation, if correct (all my tests confirmed it) is more interesting, and does seem to show something new.

I still don't understand what you are showing.

NB: Both 'numpy' and 'cython' fail if t instead of T(t) is used in the sin function or the step function, but the error messages are a bit different,

Testing whether these backends fail is not that pertinent. I know they will fail because they were not designed to do what you want them to do. The failure is very likely the same reason even if the raised error occurs at a different line in the code.

[Peter230655]

If you have a workaround to get expclit time working with variable time step, then we should show that. Maybe even in place of the idea shown in https://opty.readthedocs.io/stable/examples/beginner/plot_betts2003.html

Making T(t) a state variable, setting T(t).diff(t) = 1.0 in the oems works for variable time. I will write a simulation and push it.

However I feel my second observation, if correct (all my tests confirmed it) is more interesting, and does seem to show something new.

I still don't understand what you are showing.

What I want to show is this (based on my misunderstanding of Chris' needs):
You have a mechanicval system, which is driven by a known function(t, parameters), but you do not know the parameters. You want to get them by measuring some state variables of the system, and get opty to get estimates of the parameters.

Say the known function of the driving force is sin(omega*(t - shift))
If you set driving_force = sin(omega*(t - shift)) so opty can get estimates of omega and of shift this will not work.
If instead you set driving_force = sin(omega*(T(t) - shift)), where T(t) is the state variable from above, this will work without problems. It may not be obvious, that the first attempt, witht does not work, but the second one, with T(t) will.

This is want I want to show.
(The explicit time, without using a known_input_trajectory is not the key feature in this simulation.)

NB: Both 'numpy' and 'cython' fail if t instead of T(t) is used in the sin function or the step function, but the error messages are a bit different,

Testing whether these backends fail is not that pertinent. I know they will fail because they were not designed to do what you want them to do. The failure is very likely the same reason even if the raised error occurs at a different line in the code.

As you say, opty was not designed to do what I wanted it to do - but with the workaround using T(t) it will do it.
This is the key point of my simulation: How to work around something, opty presently cannot do.

[Peter230655]

I looked at
https://opty.readthedocs.io/stable/examples/beginner/plot_betts2003.html#sphx-glr-examples-beginner-plot-betts2003-py
more closely.
What I want to show here is already there, except that T(t) is realized as a known_input_trajectory rather than as a state_variable.
So, really nothing new here, just expanded a little bit.
I will push this to pst-notebooks and close it.
It is getting harder to find really new stuff for examples-gallery! :-)