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

included update_warm_start functionality #37

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

raoul-herzog
Copy link

No description provided.

@CLAassistant
Copy link

CLAassistant commented Apr 22, 2021

CLA assistant check
All committers have signed the CLA.

Copy link
Member

@imciner2 imciner2 left a comment

Choose a reason for hiding this comment

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

Sorry for the delay in reviewing this. I just had two comments on the contents of this.

@@ -299,6 +299,34 @@ void mexFunction(int nlhs, mxArray *plhs[], int nrhs, const mxArray *prhs[])
return;
}

// update warm_start
if (!strcmp("update_warm_start", cmd)) {
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
if (!strcmp("update_warm_start", cmd)) {
if (!strcmp("warm_start", cmd)) {

The class wrapper doesn't call update_warm_start actually, it will call warm_start when it wants to update both vectors.

Copy link
Member

Choose a reason for hiding this comment

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

Actually, I may have gotten confused here because I didn't see this was the emosqp file, so this change probably isn't actually needed (although we need to document this now in https://github.com/oxfordcontrol/osqp/blob/master/docs/codegen/matlab.rst as well).

y_vec = copyToCfloatVector(mxGetPr(y), (&workspace)->data->m);
}

if(!mxIsEmpty(y)){
Copy link
Member

@imciner2 imciner2 May 28, 2021

Choose a reason for hiding this comment

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

Is there a reason the call to warm starting is guarded against y being non-empty? As another note, with the update above to make this function callable from the wrapper, it should be guaranteed to get both an x and y to warm start.

@raoul-herzog
Copy link
Author

raoul-herzog commented May 29, 2021 via email

@imciner2
Copy link
Member

imciner2 commented May 30, 2021

Sorry about that confusion. My second comment on the if statement guarding the call to the actual OSQP update function still needs to be addressed though, since only checking for y non-empty seems to be incorrect. That function requires both x and y, so we should be making sure they both are non-empty for the call and throwing an error if either are empty I believe.

@raoul-herzog
Copy link
Author

raoul-herzog commented May 31, 2021 via email

@imciner2
Copy link
Member

in principle a warm start with only x and without y is possible, but indeed the question is whether it makes sense ...

The function to call if you only want to warm start one of them is osqp_warm_start_x or osqp_warm_start_y - the function osqp_warm_start requires that both x and y be provided, so we should be checking that both x and y are non-empty vectors if we use that function.

@gbanjac
Copy link
Collaborator

gbanjac commented May 31, 2021

We plan to remove osqp_warm_start_x, osqp_warm_start_y, as well as the function for updating lower and upper bounds separately. We have already done that in develop-1.0 branch of the main OSQP repository. See the commits below:
osqp/osqp@fab90f8
osqp/osqp@e49cf60

@imciner2
Copy link
Member

imciner2 commented May 31, 2021

Basically what I am saying we should do is have code before the call to osqp_warm_start like:

if ( mxIsEmpty(x) || mxIsEmpty(y) ) {
    mexErrMsgTxt("Both x and y must be given");
}

because otherwise we can get a segfault/random data if one isn't specified.

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.

4 participants