feat: extend IIS calculation to support Xpress solver

[FabianHofmann]

Summary

This PR extends the IIS (Irreducible Infeasible Set) calculation functionality in linopy to support the Xpress solver, in addition to the existing Gurobi support.

Changes

• Extended compute_infeasibilities() method: Now auto-detects solver type and routes to appropriate IIS implementation
• Added _compute_infeasibilities_xpress() method: Implements Xpress-specific IIS computation using xpress.iisall() API
• Updated print_infeasibilities() method: Now works with both Gurobi and Xpress solvers
• Comprehensive test coverage: Extended existing tests and added new test suite test_infeasibility.py
• Updated documentation: All docstrings now reflect dual solver support
• Maintained backward compatibility: Existing Gurobi-only code continues to work unchanged

Technical Implementation

• Uses Xpress's iisall() method to compute all IIS in the model
• Leverages getiisdata() API to extract constraint information from each IIS
• Maps Xpress constraint objects back to linopy constraint indices
• Handles multiple IIS scenarios (common with element-wise constraints)
• Provides clear error messages for unsupported solvers

Test Plan

• Simple infeasible model detection (both solvers)
• Complex infeasible model detection (both solvers)
• Multi-dimensional infeasible model detection (both solvers)
• Error handling for unsupported solvers
• Error handling for missing solver models
• Feasible model IIS computation
• Deprecated method compatibility
• Integration with existing test suite (32 tests passed)

🤖 Generated with Claude Code

[claude]

Claude finished @FabianHofmann's task —— View job

---

PR Review Complete

Review Todo List:

• Read and analyze the main changes in linopy/model.py
• Review the new test file test/test_infeasibility.py
• Check the minor change in test/test_optimization.py
• Evaluate Python best practices and type safety
• Assess xarray integration patterns
• Review performance implications for large-scale problems
• Check mathematical correctness of solver interfaces
• Evaluate memory efficiency considerations
• Assess test coverage and edge cases
• Check consistency with existing codebase patterns
• Provide comprehensive review feedback

---

Code Review

This PR successfully extends IIS (Irreducible Infeasible Set) calculation to support Xpress solver alongside Gurobi. The implementation is well-structured and maintains backward compatibility.

✅ Strengths

1. Type Safety and Python Best Practices:

• Good use of type hints (e.g., list[int] return type in compute_infeasibilities())
• Proper error handling with descriptive messages
• Clean separation of concerns between solver-specific implementations
• Consistent docstring format following the established pattern

2. Mathematical Correctness:

• Xpress implementation correctly uses iisall() and getiisdata() API
• Proper handling of multiple IIS scenarios (common with element-wise constraints)
• Correct mapping from Xpress constraint objects back to linopy constraint indices
• Maintains consistency with Gurobi implementation approach

3. Performance Considerations:

• Uses set() to efficiently collect unique constraint labels across multiple IIS
• Avoids redundant computations by collecting all IIS in one pass
• Minimal memory overhead for constraint object mapping

4. Test Coverage:

• Comprehensive test suite covering multiple scenarios (simple, complex, multi-dimensional)
• Tests for both supported solvers with parametrized tests
• Edge case testing (feasible models, unsupported solvers, missing solver models)
• Backward compatibility testing for deprecated methods

⚠️ Areas for Improvement

1. Type Safety Issues:

• linopy/model.py:1345-1395: The _compute_infeasibilities_xpress method uses Any type annotations for several parameters in the getiisdata() call. Consider using more specific types if available from the Xpress API, or at least document expected types in comments.

2. Error Handling:

• linopy/model.py:1389-1393: The try-except ValueError block silently skips constraints that can't be found. Consider logging this occurrence or adding a debug message to help with troubleshooting.

3. Memory Efficiency:

• linopy/model.py:1358: Creating list(solver_model.getConstraint()) loads all constraints into memory. For very large models, this could be inefficient. Consider using a generator or mapping approach if the Xpress API supports it.

4. Code Style:

• linopy/model.py:1363-1370: Consider extracting the type annotation list initialization into a more readable format, possibly using a dataclass or named tuple for better maintainability.

📝 Minor Issues

1. Documentation:

• linopy/model.py:1284-1288: The docstring mentions "This function requires that the model was solved with gurobi or xpress" but doesn't specify which termination conditions are expected. Consider adding this clarification.

2. Code Organization:

• linopy/model.py:1345-1395: The method is quite long. Consider extracting the IIS data retrieval logic into a separate helper method for better readability.

🔧 Suggestions

1. Type Safety Enhancement:

# Instead of:
miisrow: list[Any] = []

# Consider:
miisrow: list[Any] = []  # xpress.constraint objects

2. Error Handling Enhancement:

# Around line 1389:
try:
    idx = all_constraints.index(constraint_obj)
    labels.add(idx)
except ValueError:
    # Log or handle the case where constraint is not found
    logger.debug(f"Constraint {constraint_obj} not found in model constraints")

3. Memory Optimization:

# Consider creating a constraint index mapping once:
constraint_to_index = {constraint: idx for idx, constraint in enumerate(solver_model.getConstraint())}

📊 Overall Assessment

This is a solid implementation that successfully extends IIS functionality to Xpress solver. The code follows established patterns in the codebase, maintains backward compatibility, and includes comprehensive testing. The mathematical approach is sound and the performance impact is minimal.

Score: 8.5/10

The implementation is production-ready with the current code. The suggested improvements would enhance maintainability and type safety but are not blocking issues.

---