-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Release 1.0.0 #251
Comments
@ocots hadn't you written a global list of todo's for 1.0.0? can't find nothing more than scattered issues (which is fine, but would like some prioritisation) |
@jbcaillau I can't find any list. Maybe we can do one. I watch Léon Marchand at 11:40 and then, I will start a list. |
Things we can do before the new release See some info here about Reference. Documentation.
Performance.
Enhancement.
Unit tests.
Bug. |
manu thanks @ocots I've added 🚀 on the must-be-done-before-1.0.0 according to me. @PierreMartinon @gergaud feel free to update! ps. hey, #194 was the list I had in mind 👍🏽 |
For what I will do I have put a ⚽️ |
I have added |
We should also add a tutorial about how to improve performance installing |
@ocots nice. if not already done, I guess we can remove the dependency towards NonlinearSolve 💩 |
No there will be both. |
where do we (still) need NonlinearSolvePoo? |
Tutorials:
|
OK: thought you had gone back to MINPACK for these. |
I think we should add:
Actually the two first points are indicated in the list above. I should add something about the |
we are far from optimal right now, but that's a dev (not user) issue, including (but not limited to):
|
To me only two things left to go 1.0.0:
Gents... 🙂 |
Yes, we could do something like: https://docs.sciml.ai/NonlinearSolve/stable/tutorials/code_optimization/ Just simple things like you said: changing the linear solver, using MKL. Saying that it is possible to change the AD backend without any comparison. It is maybe more tuning than optimising that we should say. But I think we can profit from what @0Yassine0 did to explain some possibilities. It shows the versatility of our package.
I was not thinking of this.
I was simply thinking about the fact that the user can choose the method to solve its problem. For the moment, there is only one case: see OptimalControl.jl/src/solve.jl Line 9 in 2ae8993
But, later there will be more. I thought about a simple tutorial explaining how to choose the method with its description. We could profit to redirect to the documentation of the packages we use, like
|
@ocots @PierreMartinon we should immediately add MadNLP: #259 Works out of the box (check #260) and @frapac can help in case of need 🙂 |
Regarding MadNLP, I have one question: I don't know how to have the CTSolveExt extension loaded if either We could try to have one extension per solver, but this is not how we currently work: we have a single function with a Symbol argument for the solver, not several methods with multiple dispatch... |
For the sparsity pattern, the current trapeze method makes it a bit more involved: we typically store the dynamics at the end of a time step before moving on to the next step, so that we don't compute it twice. This complicates the decomposition of the constraints as a simple loop over the time steps, and the resulting sparsity pattern.
Ideally we would only have |
@PierreMartinon Est-ce clair ?
La première fonction Bon je me suis planté pour l'appel avec |
@PierreMartinon that is what I would favor, again to avoid load time issues (= just load the relevant extension when triggered by the chosen solver). |
@PierreMartinon oh, right. spares half the computation. nice. |
@PierreMartinon bien sûr le Voui. La je coince sur ces ù*^$ de descriptions: je voudrais rajouter et tester le cas :madnlp au lieu de :ipopt, mais je ne trouve pas la bonne syntaxe -_-
Pas sur non plus de comprendre comment fonctionne getFullDescription avec ses priorites. Finalement est-ce qu'on ne ferait pas mieux de revenir a de bons vieux kwargs avec des valeurs par defaut ? Edit: bon j'ai juste enleve le type de available_methods() et ca semble marcher |
First madnlp tests control-toolbox/CTDirect.jl#191 |
@PierreMartinon one step away from 1.0.0 🤞🏽 |
Désolé le bon type était : |
@ocots @PierreMartinon thanks for the active cleaning / upgrading ( |
The parsing for the constraints multipliers should be up in the next release. Untested though. Before 1.0 I'd like to
|
Not a priority, I think. I am not expecting big changes from midpoint (dual to trapezoidal scheme with more or less the same properties). Having a higher order would be nice (see control-toolbox/CTDirect.jl#101 (comment)) but not top priority for most i use case.
But even more important (see this other exchange with @amontoison, control-toolbox/CTDirect.jl#188 (comment)) Check control-toolbox/CTBase.jl#232 |
I know, but I can't really pass the sparse structure with the trapeze method (more blocks than a true single step method due to each dynamics acting on two steps and not just one, and also the saving of this dynamics for the next step complicates things). |
@PierreMartinon ah ok. but I think you can. independently on how you (efficiently) you compute the constraint, its value is sth like for which the derivative wrt. |
@PierreMartinon available for a quick call to decide on publishing 1.0? |
Eh, more likely next week. Do we have a deadline for 1.0, conf or something ? |
@PierreMartinon no deadline, just not bad to proceed according to what was planned above. next Monday? 15:00? |
@jbcaillau Bump |
@PierreMartinon meeting scheduled tonight 21:00 To discuss: |
|
Breakage seems to work: control-toolbox/CTDirect.jl#209 (comment) |
Constraints / multipliers parsing seems to work: control-toolbox/CTDirect.jl#210 |
See control-toolbox/CTDirect.jl#115 (comment)
The text was updated successfully, but these errors were encountered: