MILP feature

[flomnes]

PR #670

[flomnes]

According to MD, there is no need to tell the solver that NbUnitsUp & NbUnitsDown are integer.

It's only needed for the number of ON units.

@AlexFauduet indicates that this may not be exact for the "cluster" model, since it's possible for exemple that NbUnitsUp=0.5 and NbUnitsDown=-0.5.

[flomnes]

This idea may still be interesting, to provide a "degraded, slightly faster MILP" by reducing the number of integer variables.

[flomnes]

@tbittar @AlexFauduet promised a formal proof on that !

[tbittar]

After a discussion with @AlexFauduet , MD is right, NbUnitsUp and NbUnitsDown do not need to be specified as integer, as the constraints imply that the solution will be integer. We can provide a formal proof

[flomnes]

According to MD, existing UC software offer either a "full MILP" mode or "full relaxation + heuristic". There is no hybrid mode: MILP for some units only, relaxation+heuristic for the rest.

For that reason, the "full relaxation + heuristic" is always used because "full MILP" takes too long. In Antares, the "fast" mode is used most of the time because it is faster than the "accurate" and offers a good compromise.

In order for the MILP feature to be widely used, MD suggests

• Local parameter (for each cluster)
  • FAST
  • ACCURATE
  • MILP
• Global parameter
  • LOCAL VALUES
  • FAST
  • ACCURATE
  • MILP

[JMJ-rte]

For FCR and aFFR (primary and secondary reserve) reservation capacity could be modeled either as a boolean function with 2 options (0 or capa1/capa2) or through a linear continue function that can take any value between 0 and capa1/capa2. The 2nd solution may reduce the needs for MILP resolution

[flomnes]

Thanks for the remark. It indicates that that reserve modelling is not strictly dependent on MILP resolution for a given cluster. So these two concepts can somehow be decoupled.

Still, we would need to adapt the thermal heuristic since it probably won't give good results for reserves.

[flomnes]

In file src/solver/utils/mps_utils.cpp

mVariableType.resize(src->NombreDeVariables);
// TODO[FOM] use actual variable types when MIP resolution is integrated
std::fill(mVariableType.begin(), mVariableType.end(), SRS_CONTINUOUS_VAR);
dest->TypeDeVariable = mVariableType.data();

Apply this TODO so that variable types are correct.

[flomnes]

There are 2 parameters for each thermal cluster : min up time and min down time. However, these 2 parameters are aggregated into minUpDownTime before the optimization according to the formula

cluster.minUpDownTime = Math::Max(cluster.minUpTime, cluster.minDownTime);

This is probably related to the way fast and accurate thermal heuristics. However, for an exact resolution, it may be necessary to take into account the real min up times & min down times.

[flomnes]

Strategy for dual variables & reduced costs

In MILP resolution, dual variables & reduced costs don't really make sense. But we can still get an approximation using a well-known trick

1. MILP resolution. Keep the values of all primal variables (continuous & integer)
2. LP resolution with fixed values from the previous resolution for integer variables. Only keep the values of dual variables & reduced costs, discard primal variables.

[flomnes]

In case of MILP resolution, use the "real" NODU, ie the number of "ON" units in the cluster at hour h.