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

Multi-mission sensitive to model size and variable splitting #102

Open
mayork opened this issue Sep 1, 2017 · 10 comments
Open

Multi-mission sensitive to model size and variable splitting #102

mayork opened this issue Sep 1, 2017 · 10 comments

Comments

@mayork
Copy link
Contributor

mayork commented Sep 1, 2017

Issue to discuss growing pains in the multi-mission analysis

@mayork
Copy link
Contributor Author

mayork commented Sep 1, 2017

@1ozturkbe @bqpd I noticed some pretty interesting things.

First off, compare these two commits 3a4ee22 (doesn't work) 51009fd .... (works) @bqpd correct me if I'm wrong but I think this indicates there's a bug in how GPkit is handling these vector variables?

Also, I think we discovered Mosek can't solve the really big problems because this commit works 51009fd while this one doesn't 3f256df. The only difference should be the size of the problem.

@mayork mayork changed the title Multi-mission sensitive to solve time and variable splittiing Multi-mission sensitive to model size and variable splitting Sep 1, 2017
@1ozturkbe
Copy link
Contributor

@mayork I do think that there were some potentially problematic constraints, and I pushed some changes to the branch multiFix in an effort to get multimission working. I would think that these constraints would have definitely caused primal infeasibility.

@mayork
Copy link
Contributor Author

mayork commented Sep 5, 2017

@1ozturkbe multi-mission does work, but not for large Nmission vals

@bqpd
Copy link
Contributor

bqpd commented Sep 5, 2017

@mayork that does look like a bug, I'll take a look. As for the size issue...I sure hope it's not a max-number-of-variables thing. :-/ I feel like MOSEK would exit with a memory error if it were?

@bqpd
Copy link
Contributor

bqpd commented Sep 5, 2017

@mayork does it fail on the first solve with the additional mission? If so, could you upload the working/not-working mskexpopt problem statement files so I could send them to MOSEK?

@mayork
Copy link
Contributor Author

mayork commented Sep 5, 2017

@bqpd doesn't fail on the first solve. remind me again how to generate the mskexpopt?

@bqpd
Copy link
Contributor

bqpd commented Sep 5, 2017

I think it's .localsolve(solver="mosek_cli", path="", clearfiles=False)

@bqpd
Copy link
Contributor

bqpd commented Sep 11, 2017

@mayork, 3a4ee22 works fine when I run tests; what is broken by that commit?

@bqpd
Copy link
Contributor

bqpd commented Sep 11, 2017

3f256df also works for me...on convexengineering/gpkit@585d8bf and presumably the two commits before it, since they just change documentation/tests

@erling-d-andersen
Copy link

There are no size limits in MOSEK and it should never crash. It may not solve your problem due to numerical issues though.

If you think MOSEK has a bug you want us to look at, then please report it to

https://www.mosek.com/support/

Just include information so it easy for us to reproduce the issue.

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

No branches or pull requests

4 participants