# Assessment of e_max for units with variable profiles, through an "extremist" pre-approach

Currently, all instantiations set a default value for e_max. This approach has 2 shortcomings :

- If the default value is below the actual e_tot needed to solve the optimization, the problem is rendered infeasible.
- If the default value is way above the actual e_tot, the calculation routine may be far less efficient than if e_max was an educated guess.

Users can manually enter values of e_max themselves, but this does not guarantee efficient calculations if the user gives a wrong estimate of e_max. Besides, it makes the definition of the problem a bit less user-friendly.

To solve all these issues, OMEGAlpes could have an internal routine to get an educated guess of e_max for each and every unit with variable profile. The idea is similar to the (already existing) calculation of e_max for Fixed units, but a bit trickier.

Before the actual optimisation, this routine would assume that each variable unit has to take care of the fixed profiles of ALL its counterparts, through ALL possible ways.

In an example with these units:

- TVPU = VariableProductionUnit [Thermal]
- TFCU = FixedConsumptionUnit [Thermal]
- EVPU = VariableProductionUnit [Electrical]
- EFCU = FixedConsumptionUnit [Electrical]
- ETTCU = ElectricalToThermalConversionUnit
- NT = EnergyNode [Thermal]
- NE = EnergyNode [Electrical]

and these connections between units:

- TVPU -> NT -> TFCU
- EVPU -> ETTCU -> NT -> TFCU
- EVPU -> NE -> EFCU

the educated guess for e_max of each variable unit would be:

- e_max_TVPU = e_tot_TVPU_extremist = e_tot_TFCU
- e_max_EVPU = e_tot_EVPU_extremist = e_tot_TFCU / elec_to_therm_ratio_ETTCU + e_tot_EFCU

Of course, the routine can get a lot trickier depending on the case. But it seems worth investigating whether the calculation time for this routine is compensated afterwards thanks to avoiding infeasibility issues and loss of performance due to sub-optimal guesses of e_max.

It can be coded to trigger only if the user does not set an e_max for the unit. That way, users still have the freedom to limit the maximum production/consumption of a unit themselves.