Skip to content
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

New design time freezing #106

Merged
merged 52 commits into from
Aug 9, 2024
Merged

New design time freezing #106

merged 52 commits into from
Aug 9, 2024

Conversation

apozharski
Copy link
Member

@apozharski apozharski commented Jun 19, 2024

Resolves #71. Resolves #85.

@apozharski apozharski changed the title [WIP] New design time freezing New design time freezing Aug 1, 2024
@nurkanovic
Copy link
Member

In simulation problems, we have always one stage, and
problem_options.impose_terminal_phyisical_time = 1;
problem_options.stagewise_clock_constraint = 1;
lead to the very same result, but we may have the same terminal constraint twice (also one relaxed, other as hard, depending on the relaxation settings, hence once we run the integrator, problem_options.stagewise_clock_constraint should always be false.

+nosnoc/+dcs/Heaviside.m Outdated Show resolved Hide resolved
% -- Constraint for the terminal numerical and physical time (if no equidistant grids are required) --
% If the control grid is not equidistant, the constraint on sum of h happen only at the end.
% The constraints are split to those which are related to numerical and physical time, to make it easier to read.
if opts.time_freezing
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the code here is identical to the one in Heaviside.. not sure does it make sense to extract it into a function (or at least copy all the explanation comments (cf. comment in Heaviside on explaining every branching)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps it may make sense to extract this though I am unsure. I think we can leave it as is for now and if having two copies is inconvenient we can extract then.

+nosnoc/+model/Base.m Outdated Show resolved Hide resolved
+nosnoc/+model/Base.m Outdated Show resolved Hide resolved
+nosnoc/+model/Cls.m Outdated Show resolved Hide resolved
+nosnoc/+ocp/Solver.m Outdated Show resolved Hide resolved
+nosnoc/+ocp/Solver.m Outdated Show resolved Hide resolved
+nosnoc/Options.m Outdated Show resolved Hide resolved
@apozharski
Copy link
Member Author

Looks fine except the few minor aestetics comments. As mentioned earlier, having a minimal two contacts example (like the OCP with two discs, described in some of the examples) would be helpful to verify correctness.

I added the three cart problem as a test of the multicontact implementation. It seems to work.

@apozharski
Copy link
Member Author

In simulation problems, we have always one stage, and problem_options.impose_terminal_phyisical_time = 1; problem_options.stagewise_clock_constraint = 1; lead to the very same result, but we may have the same terminal constraint twice (also one relaxed, other as hard, depending on the relaxation settings, hence once we run the integrator, problem_options.stagewise_clock_constraint should always be false.

Yep this is now checked in Options.preprocess

@nurkanovic
Copy link
Member

Thanks for addressing all my comments. We are almost ready to merge.

I have a few final comments:

  • simulation: Gauss Legendre leads to infeasible problems both with Stewart and Heaviside and both elastic and inelastic impacts, with GL size of algebraic e.g. theta and t_grid not consistent.
  • on discs example Heaviside not-lifted much slower than lifted (are the initializations consistent - if yes, then just the nonlinearity makes the difference)
  • disc example Heaviside with n_s = 1 breaks the plotting for some reason.
  • tf_simulation example and inelastic impacts, the plots of the the algebraic variables is quite strange (I tried Radau, as it converges)

@apozharski
Copy link
Member Author

  • simulation: Gauss Legendre leads to infeasible problems both with Stewart and Heaviside and both elastic and inelastic impacts, with GL size of algebraic e.g. theta and t_grid not consistent.

The bug that was causing infeasibility is fixed however size mismatch is expected as we do not include the rhs theta/alpha as a variable in the mpcc.

  • on discs example Heaviside not-lifted much slower than lifted (are the initializations consistent - if yes, then just the nonlinearity makes the difference)

Initialization for $\alpha$ is consistent between both.

  • disc example Heaviside with n_s = 1 breaks the plotting for some reason.

With heuristic step equilibration the solver finds a solution where each other h is zero. This breaks our plotting code.

  • tf_simulation example and inelastic impacts, the plots of the the algebraic variables is quite strange (I tried Radau, as it converges)

Does not seem strange to me. the theta multipliers and beta seem to be correct.

@nurkanovic nurkanovic merged commit c616b50 into main Aug 9, 2024
1 check passed
@nurkanovic nurkanovic deleted the new-design-time-freezing branch August 9, 2024 07:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add option relax_terminal_physical_time for time_freezing problems Stewart reformulation for time-freezing
2 participants