Originally posted by: SystemAdmin
You will most probably get the -1 basis status only if there is no basis at all (in which case all variables would have basis status -1). This is the case if you did not solve the problem, or if you have solved it with barrier but without crossover.
If you start from an optimal basis and then add new columns, you would typically reoptimize using the
primal simplex algorithm. This is because the old basis is still primal feasible when you add new columns, but no longer dual feasible. The dual simplex algorithm would need to go into phase 1 again in this situation, which potentially could lead you pretty far away from primal feasibility, which then has to be recovered again in phase 2. But of course, this is just a general comment and it could be that for your particular problem instance dual simplex is the better choice. Note also that for a number of column generation problems it is the best choice to use barrier (without crossover!) for all LP solves, even though barrier cannot benefit from warm starts. This is because barrier produces a central solution on the optimal face and thus tends to not jump around in the (dual) solution space with consecutive solutions. This often helps to mitigate the tailing-off effect that you often see with column generation.
After solving your LP, it should be possible to remove all variables with basis status 0 (provided that the lower bound is zero for all of them) and all rows with basis status 1, and then solve the model again to get the same optimal objective value (maybe a different solution vector, if you start from scratch).
Are you saying that the full problem has 55k variables, and because the solve times are too large you are trying to use a column generation approach? I do not think that this is useful. Basically, what your pricing algorithm has to do is exactly the same calculation that CPLEX would internally do for the existing columns. So, using a column generation approach here just means to reduce the options that CPLEX has for pivoting. The run-time fo the linear system solves depend more on the number of rows than the number of columns. So, maybe it would be better to use a row generation approach? But even this, I doubt that it will help much. Of course, if you can (because of your knowledge about the problem) identify in advance a large set of rows that is very unlikely to be active in an optimal solution, then row generation (i.e., cutting plane separation) would be a viable option.
Tobias
#CPLEXOptimizers#DecisionOptimization