got it :). Debug running time single-threaded = 13s
tell me when it is my turn to do something again ;)
Hmm, that is a good question actually. I export the model, somewhat often, to make sure that it looks like it supposed to, when cplex does something unexpected. But I think it comes down to personal taste. And regarding the output, it depends on what error you run into. I suppose at least some basic info would be sweet - where does the error occur (in branching, in the subproblem, in solving the master problem, in separating a cut..), if it is in the subproblem, I would want to query the currently generated columns, the values of the variables in the latest solution to the MP, the dual values, and preferably the reduced costs, some rudimentary information about the branching tree, number of open nodes, LB, UB etc.. But in the end, I suppose there are a million things once one gets down in the nitty gritty details. I suppose less would be required in your framework, cause the user wouldn't have to deal with Farkas Certificates etc themselves but that would just work below the surface.
Lambda = columns
I needed to rename the file because of circular dependencies. Added some cross platform paths
right now we are solving model 1 with cont flows. I guess we want to goto model 2. Can you have a look at my modelling of integer flows in model 1. Does it make sense
modelling in 5 lines of code :)
I am battling a little with the mapping of the model into a general MIP. I am thinking that in general you would be able to map a fractional model into a time discretized model so to take care of the transit time constraints and similar path resource? For integer flows probably the same. For binary flows one can use MTZ like constraints on the resources to ensure feasibility on path (not sure about non-disposable resource, ie., hard time windows but I think so). Comments?
I am thinking to do this under the hood and only ever expose the edge variables in the graph as you would expect for the path MIP. It would be quite inefficient for the MIP as-is but it can be improved later one and would serve as a solution checker for small examples
sorry for spamming you :)
@erohe_gitlab ^
@ErikOrm ^
Hey! Ehm, hmm. I should first say that for my purposes, integer demand is not that interesting, it is more for the generality of your framework. We could say that that integrality comes in three tiers. The top tier, which is what generally tak about when I talk about integer flows, is that each commodity has to follow a single path. This is generally modelled using binary flow variables (which means that we have to multiply with the amount everywhere, as cost etc. is in $/unit.) So basically, we would just replace the continuous lambda variables with binary ones, and then we'll have to change our branching strategy a bit as branching only on design variables is no longer sufficient. The second tier, is (I believe) less common, and that is the one you are talking about. Here the flows have take integer values. So if a commodity contains 7 units, we can send 3 along one path and 4 along another, but not 3.5 and 3.5. This is of course intuitively interesting, as containers and such are technically integer, but in most applications, the loss in just treating them as continuous is very small when each commodity contains many units, which is most often the case. This is normally modelled with integer flow variables lambda_kp in {0, Q_k}, where Q_k is the number of units in commodity k. And then, yes, naturally we remove the multiplication by Q_k, as we have now rescaled the variable. Solving the subproblem, for both of those models is the same as when using continuous flow, except that we can preprocess and remove arcs with insufficient capacitiy
... to flow all/a single unit, for the two models respectively. Then we just deal with integrality through branching in the master problem. It is probably not great to branch on the lambda variables immediately, so I suppose one would start with branching on arc commodity pairs, which I think won't affect the subproblem structure. The last tier is just the continuous flow we normally talk about.
I suppose you can model it by adding a binary opening-variable eta, in the master problem, for each commodity, with the constraints "sum(eta) <= k" and "lambda<= eta"
I talked to mette gamst about it https://backend.orbit.dtu.dk/ws/portalfiles/portal/6418543/Mette_Gamst_article.pdf
but it is unclear how it fits my framework when you model in edge variables
and each path can carry some flow
double $
do we have any more elegant approaches? what does Mette do in their paper?
Then she replaces the variables so the constraints above become
:(