I am currently using MUIO 5.5 to model a power system with high VRE penetration targets. To align with IEA integration phases, I need to enforce a mandatory ratio between Solar PV installation and BESS deployment starting from a specific year (e.g., 2029).
Specifically, I want to ensure that for every 100 MW of PV installed, the model is forced to install at least 25 MW / 100 MWh of BESS (4-hour duration) to guarantee grid flexibility.
However, I have identified what seems to be a structural limitation in the model’s standard formulation regarding User-Defined Constraints (UDCs):
Technology vs. Storage: In MUIO 5.5, UDCs can easily link two technologies (e.g., TotalCapacityAnnual of PV vs. TotalCapacityAnnual of an Inverter). But UDCs do not seem to support a direct link between a Technology and a Storage entity (the energy reservoir).
Power vs. Energy Decoupling: Even if I use a “Proxy Technology” to represent the BESS inverter (MW) and link it to the PV via a UDC, there is no native parameter in the core OSeMOSYS formulation (within MUIO) to strictly lock the NewStorageCapacity (MWh) to that Technology’s capacity.
Optimization Loophole: Without a formal link, the solver could theoretically fulfill the PV/Inverter capacity ratio (MW) while investing in a near-zero storage volume (MWh) to minimize costs, thus bypassing the stability requirement.
My questions to the community:
Am I correct in concluding that MUIO 5.5 (standard core) cannot natively enforce a ratio between a Technology Capacity (MW) and a Storage Volume (MWh) via UDCs?
Aside from merging costs into a “dummy” technology (which loses the inter-temporal dispatch / SOC tracking benefits of the Storage object), is there a known way to bind these two variables?
You are correct, that that specific constraint isn’t possible with the UDCs available in MUIO. However, I think that this isn’t necessary for including storage in OSeMOSYS.
I see two options/use cases for what you are asking:
You are adding a storage cost to PV and not using the model to optimize the storage size/operation. If you do this the PV/Storage ratio is exogenous to the model and you can simply add the full cost of the storage system to the cost of PV and the optimization works as intended. Since the storage is not optimized in the model there is no need to track the storage in the model and simply adding it externally is good enough.
You are trying to optimize the size/operation of the storage system in connection to the PV system. In this case you want the model to choose the size of storage and linking it directly to the installed PV defeats the purpose of modeling storage. Since we want to optimize storage size and operation one should NOT implement this constraint to allow the model to make the choice of how much storage to include.
In both cases above one does not need to link these parameters for the model to work as intended. Modelling storage is challenging and shouldn’t be taken lightly (see http://dx.doi.org/10.2139/ssrn.5584535 for some of the complexity of modelling storage in OSeMOSYS).
Yes, you’re correct about the limitation. In standard OSeMOSYS:
- Technology (MW) and storage (MWh) are separate decision spaces
-UDC (User-defined constraints) typically operate on TotalCapacityAnnual(technologies) and Activity variables.
-But storage capacity variables for instance, storageCapacity, NewStorageCapacity are not always exposed in UDC structures in tools like MUIO and are not directly linkable to technology capacity via standard parameters.
This means your conclusion is correct: there is no native way to enforce a strict linkage between MW and MWh ratio via UDC in the standard core.
This limitation exists and provides important insight. This is not just a user-interface (UI) issue; its structural:
-Storage in OSeMOSYS is modelled as an energy reservoir (MWh) with charging/discharging flows (MW) coming from technology. But the power component is implicit (via technologies), and the energy component (MW) is explicit (storage object).
There is no built-in coupling constraints, like storageCapacity proportional to technology capacity. This decoupling is intentional for flexibility, but it creates exactly your loophole.
(Explanation for loophole
This loophole means that the model has a structural gap that allows the optimisation to avoid the intended constraint. For instance, in OSeMOSYS modelling, you want PV capacity (MW) to be linked to storage capacity (MWh), but because the model doesn’t enforce that link, it creates a loophole. This means that the solver can install the required PV (MW) to satisfy your UDC constraint (MW-based) but install very little or zero storage (MWh); this is technically valid but physically unrealistic. For simplicity, consider a rule stating that “every car must have an engine”, but without specifying the engine size or fuel; this allows a manufacturer to install a tiny, useless engine just to comply with the rule. This is what a loophole is.
Therefore, your optimisation loophole concern is absolutely right. The server can satisfy MW constraints while minimising MWh. This behaviour is observed when installing a PV+minimal inverter proxy, keeping storage volume approximately zero but still satisfying UDC. This is a well-known modelling pitfall in high-VRE studies.
Practical ways to enforce PV-BESS Coupling
Option 1
Extend the core model (best technical solution)
-You could modify the the model equations
Introduce a custom constraint like NewStorageCapacity (y) greater than or equal or proportional to NewCapacity PV (y).
Where the proportionality is equal to 1 (for MW proportional to MWh), or adjust to 0.25 x 4 h equal to 1. This applies for greater than or equal to 2029. This is the cleanest and most correct solution, but it requires editing the OSeMOSYS code, e.g., in GNU MathProg/Pyomo.
Option B
Proxy coupling via linked technologies
What you described is close but incomplete, but you can improve it:
First, create two technologies: BESS-power (MW) and BESS-Energy-proxy (fake tech representing MWh).
Secondly, enforce ratios via UDCs by making sure that PV is proportional to BESS power (MW ratio) and BESS power is proportional to BESS energy proxy (fixed duration, e.g., 4 hours). Use the energy proxy capacity that is a product of capacity, power and 4.
Thirdly, it is to tie a proxy to storage (indirectly) by assigning a very high penalty cost if storage capacity is less great than the proxy or force storage to be the feasible sink/source. This is still indirect but can be gamed unless tightly constrained.
Option C
Consider minimum storage constraints. This is simpler but less precise. Instead of strict coupling, make the storage capacity by year greater or equal to the product of beta and total PV by year. This is easier to implement if the storage variables are accessible, though it’s not tied to a new build and is less accurate for phased policies.
What is usually done by experts in real-world practice
In studies aligned with international energy agency integration phases, you require modifying the core model, which is preferred, or using soft constraints like penalties instead of hard ratios is preferred. There is also running iterative scenarios by adjusting storage until adequacy is met.
the recommended approach for your case.
Given your goal, strict policy enforcement is recommended.
The best roadmap is:
1. Add a custom constraint in the core model
couple the NewCapacity (PV) and NewStorageCapacity (BESS)
activate from 2029 onwards.
If you can’t modify the core, then use a dual UDC chain by linking PV-BESS power-proxy energy. Then add penalty costs to prevent underinvestment in storage.
Conclusion
Your diagnosis is technically correct
The limitation is structural, not just UI-based
There is no clean solution that exists without either model modification or carefully engineered proxy constraints.