Appearance of objective function in the model.write()
Answered
Hello guys, I used the code to write my model
model.write('my_iis.ilp')
In the file the objective function formula seems to be distorted:
The code that defines the objective function is:
#objective function
obj=gp.quicksum(xa[a1,a2]*ta[a1,a2] for a1,a2 in arcs)
model.setObjective(obj,GRB.MINIMIZE)
Variable ta is connected with other variables in the constraints such as kf_a. Is this how it is supposed to look? Seems like it has some substitutions.
Kind regards
Iason
-
Regarding the \( 0 \) objective coefficients: if a variable does not appear in any of the constraints, Gurobi adds it to the objective function with a coefficient of \( 0 \). Because the objective coefficient is \( 0 \), this does not affect the objective function. One reason for this is simply to ensure that all variables included in the model appear in the model file, regardless of whether they appear in any constraints.
Regarding the form of the quadratic objective terms: by convention, quadratic objective expressions are written in a form such that the quadratic expression is divided by \( 2 \). This is mentioned in the Single-Objective Case section of the LP format documentation. Your screenshot cuts off the end of the objective function, where you would see the closing bracket and division by \( 2 \). In textbooks and papers, it's fairly common to see quadratic objective expressions written in the form \( \frac{1}{2} x^\top Q x \).
1 -
Thanks Eli.
0 -
The variable kfa is defined as:
#kf_a
kfa = model.addVars(arcs, vtype=GRB.CONTINUOUS, ub=kfa_max, name='kf_a')I have the constraint
for i,j in arcs:
model.addGenConstrLog(kfa[i,j], lkfa[i,j], name="log_kfa")But my model is infeasible so far. Does this mean that this constraint could cause a bug? Because it is like the model does not recognize the kfa variable(but not necessarily). When I replace a set of constraints that include kfa the problem becomes feasible. I see that on the same file I posted above the constraints of this variable are included:
Could It be that Gurobi has limited power when handling log function constraints and this makes the model infeasible?0 -
It will be easier to figure out the issue with a reproducible example. Can you please post a minimal, self-contained code example that builds an infeasible model you would expect to be feasible?
0 -
Thanks Eli. My model is
Constraint 4 is named the BPR function. I have 3 alternative ways of modeling it: The first one is to drop the fourth power:
This is not wanted. It is just a test. The code runs in this case. The next alternative is
This alternative is provided in a paper in my dropbox file. This does not work but it is supposed to work. The lines you see are the lines of this alternative in the code.
The third alternative is also included in the paper and the code works.
Put untitled1.py which is the file of my code in a folder with the files Table1, Table2, allpaths, Dijkstra. Replace the path that my code has in the beginning with the path of the file you have all those files and run the file up to line 290 (model.optimise()). If you uncomment and comment those alternatives in the lines I have noted above you will run the 3 alternatives. I have also included the paper with the theory 2 of them(just for your reference, it is not essential). The alternative with the logarithms crashes. The thing is I have to add more constraints that include logarithms in the future and I do not know the reason why my code crashes. The link to those files is:
https://www.dropbox.com/scl/fo/0w8bt6jue8dn5cykewa94/h?dl=0&rlkey=2h1vvq0plpt8b6rl8pepehtosFeel free to ask any questions. The paper has BPR as constraint 7 pg 4/12 Its linearization is provided from equations 19+21, or 21+24, and the 2 equations in yellow above 24. Those are the two alternatives from Riemann. You do not need anything else from the paper.
Kind regards
Iason0 -
If the code runs with alternatives 1,3 then this means that if there is a bug is on the lines of the 2nd alternative or in the lines the variables of the 2nd alternative are defined. But those lines are so few and I do not see a bug there. So I suspect that Gurobi cannot solve this alternative due to the complexity of the logarithmic constraints.
0 -
I can give you a presentation if you want to your time zone to present and explain everything.
0 -
I suspect the issue is related to \(\texttt{kfa_max}\), which you define to be the upper bound of the \(\texttt{kfa}\) variables. \(\texttt{kfa_max}\) has a value of \( 53300^4 = 8.0706559921 \cdot 10^{18} \). This is far too large of a value for multiple reasons:
- Gurobi stores this value as a 64-bit double-precision float. This data type is only accurate up to about 16 base-10 digits of accuracy, so the value of \( \texttt{kfa_max}\) cannot even be accurately stored. Any arithmetic operations performed with this value will likely result in serious roundoff error.
- Gurobi does not directly model function constraints like \(y = \log(x) \). Rather, Gurobi internally builds a piecewise-linear approximation of the underlying function. Thus, when you add a constraint like \(\texttt{lkfa}_{ij} = \log(\texttt{kfa}_{ij})\), you're asking Gurobi to build a piecewise-linear approximation of the logarithm function over the domain \((0, 8 \cdot 10^{18}]\). This will inevitably be a very poor approximation of the \(\log\) function. The value of \(\texttt{lkfa}_{ij}\) can be far from the calculated value of \(\log(\texttt{kfa}_{ij})\), resulting in unexpected infeasibilities or large constraint violations.
I would start by modifying your formulation so the value of \(\texttt{kfa_max}\) is significantly smaller.
0
Please sign in to leave a comment.
Comments
8 comments