user_unpack_cuts

int user_unpack_cuts(void *user, int from, int type, int varnum, var_desc **vars, int cutnum, cut_data **cuts, int *new_row_num, waiting_row ***new_rows)

**Description:**-
If the user has defined application-specific cut classes, these cuts must be interpreted as constraints for the current LP relaxation, i.e., the user must decode the compact representation of the cuts (see the

`cut_data`structure) into rows for the matrix. A pointer to the array of generated rows must be returned in`***new_rows`(the user has to allocate this array) and their number in`*new_row_num`.

Note that SYMPHONY has built-in support for cuts generated explicitly as matrix rows with no user-defined packed form, i.e., cuts whose indices and coefficients are given explicitly (see the function`user_find_cuts()`. These cuts can be constructed and added using the helper function`cg_add_explicit_cut()`and are packed and unpacked automatically, so the user does not need to implement this function. In post processing, SYMPHONY unpacks explicitly defined cuts and internally generated generic cuts. **Arguments:**-
`void *user`IN Pointer to the user-defined LP data structure. `int from`IN See below in ``Notes''. `int type`IN `UNPACK_CUTS_SINGLE`or`UNPACK_CUTS_MULTIPLE`(see notes below).`int varnum`IN The number of variables. `var_desc **vars`IN The variables currently in the problem. `int cutnum`IN The number of cuts to be decoded. `cut_data **cuts`IN Cuts that need to be converted to rows for the current LP. See ``Warning'' below. `int *new_row_num`OUT Pointer to the number of rows in `**new_rows`.`waiting_row ***new_rows`OUT Pointer to the array of pointers to the new rows. **Return values:**-
`USER_ERROR`Error. The cuts are discarded. `USER_SUCCESS`User unpacked the cuts. `USER_DEFAULT`There are no user cut types defined. In this case, SYMPHONY deals with only explicit cuts and internally generated cuts. **Wrapper invoked from:**- Wherever a cut needs to be unpacked
(multiple places).
**Post-processing:**-
Explicit row cuts are processed, as well as SYMPHONY's internally generated cuts. Also, the pointers to each cut are transferred to the

`waiting_rows`data structure (in previous version, this was done by the user). **Notes:**-
- When decoding the cuts, the expanded constraints have to be adjusted to
the current LP, i.e., coefficients corresponding to variables currently not in
the LP have to be left out.
- If the
`one_row_only`flag is set to`UNPACK_CUTS_MULTIPLE`, then the user can generate as many constraints (even zero!) from a cut as she wants (this way she can lift the cuts, thus adjusting them for the current LP). However, if the flag is set to`UNPACK_CUTS_SINGLE`, then for each cut the user must generate a unique row, the same one that had been generated from the cut before. (The flag is set to this value only when regenerating a search tree node.) - The
`from`argument can take on six different values:`CUT_FROM_CG`,`CUT_FROM_CP`,`CUT_FROM_TM`,`CUT_LEFTOVER`(these are cuts from a previous LP relaxation that are still in the local pool),`CUT_NOT_IN_MATRIX_SLACK`and`CUT_VIOLATED_SLACK`indicating where the cut came from. This might be useful in deciding whether to lift the cut or not. - The
`matind`fields of the rows must be filled with indices with respect to the position of the variables in`**vars`. **Warning:**For each row, the user must make sure that the cut the row was generated from (and can be uniquely regenerated from if needed later) is safely stored in the`waiting_row`structure. SYMPHONY will free the entries in`cuts`after this function returns. If a row is generated from a cut in`cuts`(and not from a lifted cut), the user has the option of physically copying the cut into the corresponding part of the`waiting_row`structure, or copying the pointer to the cut into the`waiting_row`structure and erasing the pointer in`cuts`. If a row is generated from a lifted cut, the user should store a copy of the lifted cut in the corresponding part of`waiting_row`.

- When decoding the cuts, the expanded constraints have to be adjusted to
the current LP, i.e., coefficients corresponding to variables currently not in
the LP have to be left out.

2011-05-30