FYI -- the solutions for one of our underactuated homeworks on trajopt fail reliably on the focal image on deepnote since RobotLocomotion/drake#18401 landed. (just did a very fun deepnote/docker bisection!). This is a nonlinear nonconvex optimization, so it's hard to say it's a regression. But maybe it's worth another careful look at that PR just to make sure we're happy with it.
deepnote.comDeepnoteManaged notebooks for data scientists and researchers.deepnote.com10
russtedrake [7:28 AM]
frustratingly, it passes on mac, and on my local ubuntu (jammy) machines, which is the only place I typically run the "solutions get full points" tests.
[7:30 AM]previously, the solver was able to find a good trajectory from a reasonable initial guess; we get result.is_success() == False unless we loosen some of the constraints (and get a much worse trajectory out).
russtedrake [7:38 AM]
interestingly, that notebook uses almost entirely symbolic Expression constraints, so i wouldn't have thought we would have any duplicate variables in there which would have been impacted by that change.
russtedrake [7:44 AM]
Specifically, it has one quadratic cost (via an expression), many many Expression constraints, and a bunch of LinearConstraints (also added via expressions). That's it. So I would have thought that from the perspective of snopt, the problem should be invariant to the changes in 18401?
[7:45 AM]by visual inspection of the (massive) console output printing the prog, I don't see any duplicate variables.
russtedrake [7:57 AM]
But adding a log output in PruneGradientDuplication of snopt_solver.cc suggests that I do have duplicates in this program:
if (it == gradient_index_to_G.end()) {
log()->info("found duplicate");
duplicate_to_G_index_map->push_back(iGfun->size());
gradient_index_to_G.emplace_hint(it, index, iGfun->size());
iGfun->push_back(iGfun_w_duplicate[i]);
jGvar->push_back(jGvar_w_duplicate[i]);
} else {
duplicate_to_G_index_map->push_back(it->second);
}Maybe the ExpressionConstraint is giving duplicates?
[7:59 AM]something is happening that I don't understand...
Terry Suh [9:26 AM]
FYI my year when I took underactuated with @Tobia Marcucci, we could reproduce occasions for this problem where the SNOPT's solution would change quite drastically depending on the order we put the constraints in, even though it was the exact same problem. IPOPT seemed more robust to these issues. (edited)
Hongkai Dai [2:59 PM]
I will look into why there is duplicated variables in the ExpressionConstraint.
russtedrake [6:41 PM]
I’m not sure there is. I think my log output might have been in the wrong place.
FYI -- the solutions for one of our underactuated homeworks on trajopt fail reliably on the focal image on deepnote since RobotLocomotion/drake#18401 landed. (just did a very fun deepnote/docker bisection!). This is a nonlinear nonconvex optimization, so it's hard to say it's a regression. But maybe it's worth another careful look at that PR just to make sure we're happy with it.
deepnote.comDeepnoteManaged notebooks for data scientists and researchers.deepnote.com10
russtedrake [7:28 AM]
frustratingly, it passes on mac, and on my local ubuntu (jammy) machines, which is the only place I typically run the "solutions get full points" tests.
[7:30 AM]previously, the solver was able to find a good trajectory from a reasonable initial guess; we get result.is_success() == False unless we loosen some of the constraints (and get a much worse trajectory out).
russtedrake [7:38 AM]
interestingly, that notebook uses almost entirely symbolic Expression constraints, so i wouldn't have thought we would have any duplicate variables in there which would have been impacted by that change.
russtedrake [7:44 AM]
Specifically, it has one quadratic cost (via an expression), many many Expression constraints, and a bunch of LinearConstraints (also added via expressions). That's it. So I would have thought that from the perspective of snopt, the problem should be invariant to the changes in 18401?
[7:45 AM]by visual inspection of the (massive) console output printing the prog, I don't see any duplicate variables.
russtedrake [7:57 AM]
But adding a log output in PruneGradientDuplication of snopt_solver.cc suggests that I do have duplicates in this program:
if (it == gradient_index_to_G.end()) {
log()->info("found duplicate");
duplicate_to_G_index_map->push_back(iGfun->size());
gradient_index_to_G.emplace_hint(it, index, iGfun->size());
iGfun->push_back(iGfun_w_duplicate[i]);
jGvar->push_back(jGvar_w_duplicate[i]);
} else {
duplicate_to_G_index_map->push_back(it->second);
}Maybe the ExpressionConstraint is giving duplicates?
[7:59 AM]something is happening that I don't understand...
Terry Suh [9:26 AM]
FYI my year when I took underactuated with @Tobia Marcucci, we could reproduce occasions for this problem where the SNOPT's solution would change quite drastically depending on the order we put the constraints in, even though it was the exact same problem. IPOPT seemed more robust to these issues. (edited)
Hongkai Dai [2:59 PM]
I will look into why there is duplicated variables in the ExpressionConstraint.
russtedrake [6:41 PM]
I’m not sure there is. I think my log output might have been in the wrong place.