particle in tube. removed hacks, added inequalities #456
Conversation
|
All tests fail with this message: |
|
Update with master to fix the build issue. |
I am unclear what this means. Could you explain, please. |
|
I have fixed the issue in the master branch and you have to merge the updated master branch into this branch. |
|
Got it, thanks! |
| # %% | ||
| # Create the optimization problem and set any options. | ||
| eom_bounds = { | ||
| 7: (-np.inf, par_map[radius]), |
There was a problem hiding this comment.
Wouldn't it be cleaner to have - radius in the eom?
There was a problem hiding this comment.
Wouldn't it be cleaner to have
- radiusin the eom?
As the distance can never be negative, {7: (0.0, par_map[radius]} would have been good enough.
I saw in the last simulation, that -np.inf worked faster, so I put it here. I did not test it with 0.0, though.
There was a problem hiding this comment.
If you have an equation, e..g a + b/c >= d + c then I think we want to show in examples that you should always do something like: a + b/c - d - c >= 0 and then the bounds would be {0: (0, inf)}. I am not seeing why you'd ever need bounds that aren't zero and +/infinity.
Having to extract values from the par_map and then pass that to problem, which already has par_map passed in, seems like something is wrong.
There was a problem hiding this comment.
If you have an equation, e..g
a + b/c >= d + cthen I think we want to show in examples that you should always do something like:a + b/c - d - c >= 0and then the bounds would be{0: (0, inf)}. I am not seeing why you'd ever need bounds that aren't zero and +/infinity.Having to extract values from the par_map and then pass that to problem, which already has par_map passed in, seems like something is wrong.
I agree:
any inequality a < eom < b can be comverted into two inequalities
- 0 < eom - a < infinity
- -infinity < eom - b < 0
Would this be the preferred way?
This doubles the eoms needed for bounds,
| solution, info = prob.solve(initial_guess) | ||
| initial_guess = solution | ||
| print(info['status_msg']) | ||
| print(info['obj_val']) |
There was a problem hiding this comment.
This isn't good for a example. Examples should have 1 call to Problem and the initial guess should be prepared and stored so that elaborate initial guess coaching isn't needed.
There was a problem hiding this comment.
This isn't good for a example. Examples should have 1 call to Problem and the initial guess should be prepared and stored so that elaborate initial guess coaching isn't needed.
The solution is stored and used. I made this elaborate thing, so a solution will be found, if a user does not want to use the solution stored.
Does it make sense to offer a way to get as solution for first principles, which does not work if tried?
In this example, this approach from easy to difficult was the only way I found to make opty converge.
There was a problem hiding this comment.
Does it make sense to offer a way to get as solution for first principles, which does not work if tried?
No, I don't think we need such things in these examples...unless we are making an example to teach methods of getting convergence or best practices for preparing an initial guess. This example has now become a mini research problem instead of a simple example to learn how to use opty.
There was a problem hiding this comment.
Obviously, I do not totally agree. :-)
A potential user should see examples how to apply opty.
Unless it converges it is of no use.
At least it took me quite a while to come up with this iterative approach. I could not get convergence any other way. (the need to build Problem numerous times got me to post #455 )
Hence I feel, that at least in the advanced section, such an example has its place.
I guess, getting convergence is not particular to opty, but to any nonlinear optimization program.
At least I came to opty without any experience in nonlinear optimization, could it not be the case that other potential users come my route?
Of course, your opinion counts, so I see these options:
- we drop this example (then we should also drop the existing one, it suffers from the same problem)
- we give a simple version, but we know it will not converge if no solution is available.
There was a problem hiding this comment.
I guess, getting convergence is not particular to opty, but to any nonlinear optimization program.
Yes, that is more the point.
There was a problem hiding this comment.
Maybe the key thing is that the documentation for software is to show "how to use the software" not "how to solve any problem you possibly can with the software".
There was a problem hiding this comment.
This is a clear direction.
I admit I like to test out the limits of opty (and of sympy mechanics)
But your examples, like the guy getting up from a chair, are also not exactly basic. :-)
There was a problem hiding this comment.
If we ever add a feature to opty that automates iterating through initial guess designs, the we could have an example that shows how to use that feature. But opty currently has zero features that have anything to do with developing good initial guesses. We do have this open PR #365, which will need an example once merged. But that's it.
The example I am updating to inequalities right now, plot_car_around_pylons would certainly qualify.
There was a problem hiding this comment.
But your examples, like the guy getting up from a chair, are also not exactly basic. :-)
Yes, this one should probably not be an example.
There was a problem hiding this comment.
but it is GREAT!!
Interesting: here As I reported earlier, |
Please move to another PR> |
This is a separate PR #464 As this is an example we already have on examples-gallery, just the hacks replaced with eom inequalities, I feel it should be merged. |
This is the example in examples-gallery/advanced
I also make a small change in plot_constraint_violations:
if subplots=True and there are eom_bounds, the eoms are shown, not supressed.
NB:
As this version is slightly more general than the one it should replace, I cannot compare the execution times.