Documentation on model debugging

[willu47]

I have been unable to find documentation specific to diagnosing issues with models.

I have found a few useful helper functions, such as model.variables.get_name_by_label() which returns the mapping from the numeric variable number found in the LP file to the variable name of the Python object.

Are there any other useful functions I should know about to help diagnose problems with an LP formulated in linopy (collating ideas here for a section in the documentation)?

Some ideas:

• Force writing out full variable names to LP generation to aid debugging
• Tutorial to demonstrate visualisation of the constraints, matrix, coefficient ranges etc.

[FabianHofmann]

Good point! This is one of the most important things on the list of missing features. In meanwhile, if you use gurobi, you can use the function

m.compute_set_of_infeasible_constraints()

in case you ran into non-feasibility with the gurobi solver. But the inspection of a subset of constraints still remains mediocre. I put that on my list. Ideally, I would like people to not have to look into the LP file in case of infeasibilities, as they can be very long. So in the first step, I would focus on the data inspection of the linopy model.

[willu47]

One incredibly hacky solution is to post-process the LP file with the constraint and variable names. I'm not proud of this, but it got the job done so I can compare the LP file of a test model from the original GNU MathProg implementation and the linopy. Perhaps this is a special case - porting a file, but inspection of a (small) LP file is very useful because it's one common file format almost all algebraic modelling languages can produce.

import re

<build your linopy.Model ``m``>

variable = re.compile('x[0-9]+')
constraint = re.compile('c[0-9]+')

with open('annotated_file.lp', 'w') as annotated:
 with open('original.lp', 'r') as raw_lp_file:
 for line in raw_lp_file:
 vars = variable.findall(line)
 cons = constraint.findall(line)
 for con in cons:
 label = int(con[1:])
 name = m.constraints.get_name_by_label(label)
 line = f"{name}:\n"
 for var in vars:
 label = int(var[1:])
 name = m.variables.get_name_by_label(label)
 line = line.replace(var, name)
 annotated.write(line)

[FabianHofmann]

Interesting workaround :) However that would not work for indexed variables / constraints, as far as I can see. It would only insert the name. But given your thoughts, we can definitely think about introducing (optional) annotations to the LP file.

[FabianHofmann]

Note

The following content was generated by AI (Claude Code) and checked against master (a731680). Posted as evidence only.

Partial progress: a model-debugging surface now exists — Model.compute_infeasibilities / print_infeasibilities / compute_set_of_infeasible_constraints, plus the infeasible-model tutorial. Still unaddressed from the original ask: LP-annotation / constraint-matrix visualization. Keeping open, narrowed to those.

[FabianHofmann]

Note

The following content was generated by AI (Claude Code) and checked against master (a731680). Posted as evidence only. Correcting my earlier comment, which undercounted what has landed.

The LP-annotation ask discussed in this thread is now available: passing explicit_coordinate_names=True to Model.solve(...) / Model.to_file(...) writes the LP/MPS file with human-readable names such as Capacity[gen1,2020]#123 instead of x123 (linopy/io.py, get_printers_scalar/get_printers). Unlike the regex workaround above, this handles indexed variables and constraints correctly.

In addition, Model.dualize() (module linopy/dualization.py, PR #626) now builds the LP dual as a standalone model with dual variables named after the primal constraints — useful for sensitivity/debugging inspection.

So the debugging surface for this issue is now: infeasibility inspection (compute/print_infeasibilities, compute_set_of_infeasible_constraints) ✓, annotated LP/MPS output ✓, and dualization ✓. The only original item without a direct equivalent is constraint-matrix visualization, which is arguably a separate, minor feature. This looks closable — possibly splitting off a dedicated matrix-visualization issue if still wanted.

[FabianHofmann]

sorry for the noise, closing this issue as mostly covered