[docs] update should_i_use.md to remove optimal control

[odow]

Thoughts? Especially @pulsipher.

With tracing, we have a nice interface now. I don't see any reason to recommend people go elsewhere.

Here's an example of a model that is now much nicer to write #3622

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (9e2e263) 98.21% compared to head (597c21c) 98.14%.
Report is 2 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3623      +/-   ##
==========================================
- Coverage   98.21%   98.14%   -0.08%     
==========================================
  Files          43       43              
  Lines        5653     5651       -2     
==========================================
- Hits         5552     5546       -6     
- Misses        101      105       +4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[joaquimg]

Maybe instead of removing the section completely, keep it, remove the references to other tools and add a link to a tutorial.

[odow]

I don't know about keeping the links here. We don't provide links to alternatives for other problem types that JuMP supports. This section is in the "Why shouldn't I use JuMP" bit. And solving an optimal control problem is not a reason not to use JuMP.

I have a TODO to add a MPC tutorial: #2348 (comment)

People seem to be using (and enjoying) JuMP for optimal control problems:
https://discourse.julialang.org/t/setting-up-free-final-time-in-jump-optimization/107302/3

[pulsipher]

Naturally, I like having the reference, but I understand the argument to remove it from the why not to use JuMP section.

Perhaps an alternative suggestion would be to add some references in the tutorials to relevant JuMP extensions (e.g., InfiniteOpt, SDDP, BilevelJuMP). For instance, it is straightforward to implement an optimal control problem that is discretized with a fixed time step that uses explicit/implicit Euler as demonstrated by existing/future JuMP tutorials; however, using a more complex discretization scheme (e.g., orthogonal collocation over finite elements) is nontrivial to implement. Thus, referring the user to InfiniteOpt to handle these more difficult cases would make sense and highlight that JuMP ecosystem has several useful extensions.

[odow]

Added some suggestions #3625.

I think they are a much better way of suggesting relevant extensions. I doubt many people actually read the "when should I not use JuMP" and then followed the link to an extension.

[odow]

Updated to refer to InfiniteOpt and BilevelJuMP in the tutorials.

[odow]

See

https://jump.dev/JuMP.jl/previews/PR3623/tutorials/nonlinear/rocket_control/
https://jump.dev/JuMP.jl/previews/PR3623/tutorials/nonlinear/nested_problems/

[pulsipher]

I approve of the changes and support this PR. I will also note that InfiniteOpt supports 2-stage stochastic programs like https://jump.dev/JuMP.jl/stable/tutorials/applications/two_stage_stochastic/.