Add example of parameter estimation from multiple measurement trials #230
Conversation
| u1.subs({t: t0}) - x0[4], | ||
| u2.subs({t: t0}) - x0[5], | ||
| u3.subs({t: t0}) - x0[6], | ||
| u4.subs({t: t0}) - x0[7], |
There was a problem hiding this comment.
You generally don't want instance constraints in parameter estimation problems. This overly constrains the solution.
There was a problem hiding this comment.
You generally don't want instance constraints in parameter estimation problems. This overly constrains the solution.
Sorry, I missed this in the PR I just started. Will correct it.
Question: Would you not know the initial conditionsd of the experiment, like im my case you would know how much you extended the mas, and at what initial speed it started?
There was a problem hiding this comment.
My bet is that if you remove these, you'll get better parameter estimates.
There was a problem hiding this comment.
Question: Would you not know the initial conditionsd of the experiment, like im my case you would know how much you extended the mas, and at what initial speed it started?
You know the initial conditions only as good as your error filled measurement might say. If you force the initial condition to the value of a measurement that has error, then you are not allowing for solutions that minimize the overall error.
There was a problem hiding this comment.
Makes sense!
When I give reasonable bounds it finds good values.
I will try to incorporate all you suggested tomorrow.
There was a problem hiding this comment.
Question: does it make sense to estimate continuous parameters this way? What I mean: say, I apply a time varying force to this sytem and try to estimate what it looks like?
There was a problem hiding this comment.
If I understand you, I think you can.
|
This is the right idea and very cool to see that it works! |
Removing the instance control did two things:
|
| are to be estimated. | ||
|
|
||
| The idea is to set up four sets of eoms, one for each of the measurements, with | ||
| identical parameters, and let opty estimate the parameters. |
There was a problem hiding this comment.
Maybe we should add an explanation of why we have to do such a thing. Something like:
For parameter identification, it is common to collect measurements of a system's trajectories from distinct expeirments. For example, if you are identifying the parameters of a mass-spring-damper system you will excite the system with different initial conditions multiple times. The data cannot simply be stacked and the identification run because the measurement data would be discontinuous between trials. A work around in opty is to create a set of differential equations with unique state variables for each measurement trial that all share the same constant parameters. You can then identify the parameters from all measurement trials simultaneously by passing the uncoupled differential equations to opty.
| # %% | ||
| # Initial guess. | ||
| # | ||
| initial_guess = np.array(list(np.random.randn(8*num_nodes + 2))) |
There was a problem hiding this comment.
In parameter identification problems you have the measured state values, so there is really no reason to not use the measurements as the initial guess for the state trajectories.
There was a problem hiding this comment.
You also typically have some reasonable guess for the parameters and the parameters needs to be bounded.
| # Solve the Optimization Problem. | ||
| # | ||
| solution, info = problem.solve(initial_guess) | ||
| print(info['status_msg']) |
There was a problem hiding this comment.
new cell before the plot command, basically a new cell should be after anything you print or plot
moorepants
changed the title
| x0 = np.array([3, 3, 3, 3, 0, 0, 0, 0]) | ||
| pL_vals = [1.0, 0.25, 1.0, 1.0] | ||
|
|
||
| resultat1 = solve_ivp(gradient, t_span, x0, t_eval = times, args=(pL_vals,)) |
There was a problem hiding this comment.
A more realistic measurement data set would be collected from trials that have different initial conditions. You often don't have control of the initial conditions in the experiments, you simply measure whatever the state happens to be.
|
I removed instance constraints, added bounds to the unknown parameters, set the initial guess of x to the measured states and set the initial guess for u's to zeros, and gave reasonable guesses for the unknown parameters and I get a consistent optimal solution. I think making those updates would make this more realistic and solve well. Additionally, we should use different initial conditions for each of the four measurement trials. |
I will do this. But could you plot the constraint violations? |
|
It would be helpful to make the final plot be a comparison of the optimal trajectories vs the measured trajectories (like done in the other parameter id examples). You can do this by first plotting the measurements on the same number of axes that the |
No there is a bug. |
|
There should be a |
| # %% | ||
| """ | ||
|
|
||
| Parameter Estimation |
There was a problem hiding this comment.
The title and filename are too generic.
- We use the terms "parameter identification" in opty not "parameter estimation", we should be consistent.
- This is a special parameter id example, in that it is showing how to use multiple measurement trials that constitute a set of discontinuous data. So the title should reflect this uniqueness (relative to the other simpler parameter id examples)
|
I just pushed this to let you know where I am. Not yet been able to incorporate all your suggestions. |
I will try to fix the bug in the next few days. I might have caused it when I changed this method a bit. |
|
Already fixed: #232 |
Equations are here: https://en.wikipedia.org/wiki/Mass-spring-damper_model |
Thanks! |
Unbelievable! I would have taken me 2 days!! :-( |
| """ | ||
|
|
||
| Parameter Identification of a Mass-Spring-Damper System. | ||
| ======================================================== |
There was a problem hiding this comment.
I'd prefer "Parameter Identification from Non-Continuous Measurements" or something similar. The unique aspect of this example relative to what we already have is that we have these independent measurements of the system's motion.
There was a problem hiding this comment.
Maybe "non-contiguous" is the right word.
There was a problem hiding this comment.
Parameter Identification from Non-Contiguous Measurements
There was a problem hiding this comment.
I'd prefer "Parameter Identification from Non-Continuous Measurements" of something similar. The unique aspect of this example relative to what we already have is that we have these independent measurements of the system's motion.
Will do so and push
There was a problem hiding this comment.
Also change the filename to plot_non_contiguous_parameter_estimation.py
| # %% | ||
| """ | ||
|
|
||
| Parameter Identification from Non-Continuous Measurements. |
There was a problem hiding this comment.
You didn't agree that "contiguous" was the correct word?
contiguous /kən-tĭg′yoo͞-əs/
adjective
Sharing an edge or boundary; touching.
Neighboring; adjacent.
Connecting without a break.
There was a problem hiding this comment.
I guess it can be either, but we have continuous measurements, they are just not contiguous in time.
There was a problem hiding this comment.
You didn't agree that "contiguous" was the correct word?
contiguous /kən-tĭg′yoo͞-əs/ adjective
Sharing an edge or boundary; touching. Neighboring; adjacent. Connecting without a break.
:-) :-)
I thought is was a typo. Knowing you I should have known better! Will change and push.
There was a problem hiding this comment.
It doesn't' really matter, I just get nit picky on wording. I'm working an journal article this morning doing the final editing and my mind is in the mode of being extremely precise with wording.
There was a problem hiding this comment.
It doesn't' really matter, I just get nit picky on wording. I'm working an journal article this morning doing the final editing and my mind is in the mode of being extremely precise with wording.
Can I get a copy when you are done with it?
|
I modified this example a bit: I added a force = F1 * sin(omega * t) and also estimate F1 and omega. |
I'd prefer if we didn't add this to this example and simply demonstrate how to do parameter identification from multiple non-contiguous measurements. If you want it to be something different I can make an example that focuses on the parameter id approach. |
NO, not at all, I'd like for the one already pushed to be added! |
You have to read the error message. |
What is title underline too short? |
| @@ -0,0 +1,209 @@ | |||
| # %% | |||
| """ | |||
|
|
|||
There was a problem hiding this comment.
/home/runner/work/opty/opty/docs/examples/plot_non_contiguous_parameter_estimation.rst:206:Title underline too short.
I guess that it is complaining about this empty line, as the underline ==== seems to be the right length.
My strategy in these cases is to look toward what part the error messages points me and in this case compare the code to similar examples. Those don't have this empty line ;)
|
|
||
| # %% | ||
| # Set up the Identification Problem. | ||
| # -------------------------------- |
There was a problem hiding this comment.
The error is here and it is exactly what it says in the error message.
There was a problem hiding this comment.
The error is here and it is exactly what it says in the error message.
Fair enough! I only looked at the 'big' title. I will correct and push
|
I close this PR and start a new one, as here are wrong files included |
In a simple spring / damper model the spring constant and the dampening coefficient are to be estimated using noisy measurements.
The model is set up four times corresponding to four noisy measurements.
I create these noisy measurements by integrating the four systems and adding random numbers to each point of the solutions and a random shift.
As the method plot_trajectories does not work if no input trajectories are given, I plot them 'manually'.
(I hope I understood the idea correctly)