SpineOpt.jl
SpineOpt.jl copied to clipboard
spine-tools
Variable scaling
I just scaled FlexTool variables to be of similar size, since there were some models that took very long time to solve using HiGHS. To my surprise, this improved LP solution time for FlexTool by orders of magnitude when using HiGHS. I did limited testing with CPLEX as well and there was no clear impact for CPLEX - presumably CPLEX knows how to scale itself. So, I suggest making sure SpineOpt models are scaled well.
Since integer variables are typically 0 or 1 and even in case of multiple units typically not too far from 1, all variables should be scaled to that range [0-1....] (e.g. including a multiplication of the flow variable by the unit capacity in the constraints and then translating that to right number in the results). It can be difficult with investment variables since the maximum is not known (or it can be set very high by the user to avoid hitting any limits). So, I decided to scale based on 'virtual_unitsize' that I have used for integer startups. If it's not set, then FlexTool used existing capacity and if there was not existing capacity, then just 1000 MW as a default assumption for the 'virtual_unitsize'.
I also scaled the objective function - it seems to be not an issue unless there is a difference of many orders of magnitude between the other variables and the objective value. And this can be so, if not scaled at all.
Very interesting @jkiviluo
I would let the folks over at https://github.com/ERGO-Code/HiGHS know about this. They are very receptive to input and feedback.
Scaling a model according to the goal of all variables being of order 1, and scaling constraints so that the RHS is of order 1, is better than automatic scaling by the solver.
Perhaps we could make use of the RHS in deciding how to scale.
Thanks for the information! In the case of these energy system models, it can be sometimes difficult to predetermine the scaling factors, since in investment problems the investment variables are can be open ended (although user can choose to limit those). Our models are actually just model generators, so all parameters are up to the user. Users could even end up using different units of measurement and then default scaling would be off.
Still, in most intended use cases, default scaling factors can be fine and they should definitely be implemented in SpineOpt based on that FlexTool experience.
It's possible that if commercial solvers detect a badly-scaled model, they will only solve a scaled model to the desired tolerances. An "orders-of-magnitude" improvement with HiGHS is remarkable.
