Feature request: Expose additional HiPO timing fields via HighsInfo

[MaykThewessen]

Summary

HiPO's internal hipo::Info struct contains detailed timing data that is valuable for profiling and optimization, but only 4 of 9+ timing fields are currently exposed via HighsInfo.

Currently Exposed (via IpxWrapper.cpp)

These 4 fields are forwarded in solveHipo():

• ipm_analyse_time — symbolic analysis (ordering + elimination tree)
• ipm_factor_time — numerical factorisation
• ipm_solve_time — triangular solves
• ipm_matrix_time — matrix assembly

Proposed Additions

The following fields exist in hipo::Info but are not forwarded to HighsInfo:

hipo::Info field	Proposed HighsInfo field	Description
residual_time	ipm_residual_time	Residual computation (primal/dual infeasibility)
omega_time	ipm_omega_time	Omega (scaling weight) computation
AS_structure_time + NE_structure_time	ipm_structure_time	Sparsity structure detection
factor_number	ipm_factor_count	Number of factorisations (integer)
solve_number	ipm_solve_count	Number of triangular solves (integer)

Use Case

We're benchmarking HiPO on PyPSA DC-OPF problems (168-672h chunks, ~600k constraints). Having detailed timing breakdowns helps us:

1. Identify which IPM phases dominate solve time
2. Guide optimisation efforts (e.g., symbolic reuse, parallel factorisation)
3. Compare HiPO vs IPX phase-by-phase rather than just total time

Implementation

The changes are straightforward:

1. Add 5 fields to HighsInfoStruct in HighsInfo.h
2. Register them as InfoRecord entries in initRecords()
3. Forward from hipo_info in IpxWrapper.cpp::solveHipo()

We have a working implementation on our fork — happy to submit a PR.

[jajhall]

Interesting request. HighsInfo is not the place for such "niche" developer information relating to timing. In the MIP solver we currently compute the time required for execution of sub-solvers - which are of comparable interest to developers and expert users. Perhaps a HighsTime struct can be created to communicate back all such times.

That does nothing for your desire to have factor_number and solve_number. We can consider adding these to HighsInfo. I'll talk to @filikat

[filikat]

It's totally fine to expose these for me. We just need to decide where the best place is.
Just to clarify, residual_time is the time needed to compute the residuals of the 6x6 linear system, not the primal/dual infeasibilities, and omega_time has nothing to do with scaling weights, but it's the time needed to assess the quality of iterative refinement. The way in which I do this may change in the future, so these two times may become obsolete.
I'm not sure what you mean saying that those four fields are exposed via the wrapper. None of these times is currently retrievable outside of HiPO.

[MaykThewessen]

Thanks @filikat for the corrections — we had the meanings of residual_time and omega_time wrong, and incorrectly implied some fields were already exposed via HighsInfo. Appreciate setting the record straight.

@jajhall, a dedicated HighsTime struct for solver sub-timings sounds like a much cleaner approach than adding niche fields to HighsInfo. Having a unified place for sub-timings across IPM, simplex, and MIP would be broadly useful.

For our use case (profiling IPM bottlenecks across hundreds of chunked LP solves), even just factor_time and solve_time would give us what we need to identify whether factorization or back-solves dominate. Happy to help with implementation or testing if that would be useful.