Structure reformation of namespace for expressions, variables and constraints

[Betristor]

Adopted from GenX repo, basic name space for expression, variables and constraints has some patterns like starting with e for expressions, with v for variables and with c for constraints. Balance constraints will have balance in name space and common constraints will have con basically. But now we need more energy sectors being modeled and this name space is expanding fast out of easy-going understanding area.
A more detailed name space should be designed and applied to take future and current developing energy sectors into consideration.

Generally we need to design name space for different energy sectors, energy flow nodes/joints inside each energy sector and different technical levels. This is hierarchical structure extraction from physical modeling. Besides this in code level, different macros in JuMP should firstly be distinguished for referencing them. And at the same time model name space should be combined.
In this structure, typically the name space will be like

• vPPower for power output (Power) in electricity sector (P), note that it involves multi energy nodes (generation and storage) so this level is missing.
• ePPowerBalance for generic power balance (PowerBalance) in electricity sector (P) of different zones at any time. Still, it involves multi energy nodes (generation and storage) so this level is missing. Since we know it's for electricity, we may use Balance instead of PowerBalance.
• cPPowerBalance for generic power balance (PowerBalance) in electricity sector (P) of different zones at any time given demand. Still, it involves multi energy nodes (generation and storage) so this level is missing.

And some examples using full name space will be like

• vPGenThemalCommit (maybe vPGenThemalOnline) for thermal unit commit. P for sector, Gen for energy flow nodes, Commit for technical level.
• ePPowerBalanceGenThermalCommit and ePPowerBalanceGenThermalNoCommit for balance sub terms and ePPowerBalanceGenThermalAll for adding them. The name space is long while readable and easy to understand.
• though we have many anonymous constraints, this name space is useful when constructing them. Like cPGenThermalRampingUp and cPGenThermalRampingDn for ramping constraints. Also, for unit commitment constraints, cPGenThermalUCStart and cPGenThermalUCInter.

But practice is more complicated, I think more familiar abbreviation could help reduce the length and construct them. Another problem to consider is the usage of capital form or lower form. It's not a big deal but affects reading experience.

[Betristor]

For different sectors including power, hydrogen, carbon and synthesis fuels, single character like P, H, C, F could be used as sector identifier. With more energy sectors involved, more characters could be used.
In power sector, main nodes involing energy flow are categorized into four containing many energy components, including GEN for generation, NET for network transportation, STO for storage and D for demand.
In hydrogen sector, this is very similar to power. Four nodes are distinguished which are GEN for generation, TRA for transmission, STO for storage and D for demand.
Carbon sector is nearly identical to hydrogen sector with tiny difference in using CAP instead of GEN for carbon capture.
Synthesis fuels sector is also categorized into four nodes including GEN for generation, TRA for transmission, STO for storage and D for demand.

[Betristor]

Specifically, in power sector, four nodes are GEN for generation, NET for network transportation, STO for storage and D for demand.
In generation node, different resources could be applied (excluding storage in name space). Generic generation could be described with vPPower and power balance which is the core we need to consider could be described with ePBalance. Deep into sub terms, power balance from thermal and renewables could be described with ePBalanceThermal and ePBalanceRenewable or using short format with ePBalanceTHE and ePBalanceVRE. Thermal generation could further be divided into ePBalanceThermalCommit and ePBalanceThermalNoCommit. Commitment variables in thermal generation could be expanded into vPGenThermalOnline, vPGenThermalStart and vPGenThermalShut. This should could cover most of the cases we will encounter.
In regard of constraints, their name space is more complicated especially grouped and anonymous constraints are common. For these constraints, most aggressive way is to name each constraint. But the fact is we don't need them named. Mostly we could use comments to help distinguish their physical meaning which could offer a more comprehensive understanding for users. Only those important constraints like balance equals demand and some other constraints that we need to reference should be named.
Storage is separated from generation not only in physical nodes but also in name space design cause it has more levels in technical details. Typically energy and power capacity should be designed separately for storage system and charging and discharging action should also be distinguished. Besides a soc variable and constraint should be introduced. Seems like vPStoDis, vPStoCha and vPStoSoc.

Capacity variables for each technology with distinguishment of newly built, retirement, existing and total should be also taken into the structure. vPGenCapNew, vPGenCapRet, ePGenCapExt, vPGenCapTotal. It's trivial for storage capacity cause it involves energy capacity (necessary), discharge capacity (necessary) and charge capacity (unnecessary). Maybe vPStoCapDisNew (this is defined since generation and storage are processed together), vPStoCapChaNew and vPStoCapEneNew. Confusing parts lie in the technical level, which depedns on which node we're talking about.

Leaving physical modeling aside, it's time to discuss something about costs. Capital expenditure (CAPEX), operational expenditure (OPEX) and potential replacement expenditure (REPEX) are the sub-first terms. Under this level, OPEX could be divided into FOM and VOM. This part is mainly expressions attached to costs. Maybe ePCostFix, ePCostVar, ePCostVarNsd, ePCostFixExp (for network expansion), ePCostFixCha, ePCostFixEne, ePCostVarStart. According to code, different adding combination could occur depending on how we compose them.

[Betristor]

Nearly finishing modeling, some hidden things should be revealed that inputs and sets for indexing could also be named with this name space cause they also suffers from expansiong of energy sectors.

Sets could all be capital which is easy to recognize. But Z, T, G, H which are single character should be used carefully. To distinguish a concept of global and local, we could use Z and T across the whole model but it will cause zonal asymmetricity for different energy sectors. Temporarily we assume that a zone is an energy hub, but this also could be expanded by using multi zonal index and sets. It's ok to do so with T. But other sets like generators set, line set, carbon cap set and load curtailment segment should be specified. We could add energy sector identifier and then saperate key words with underscore.

Inputs are more complicated since we throw nearly everything into inputs to be passed into the model. Inner containment is almost unknown. Hierarchical inputs data structure is unacceptable since we will not know through how many levels could we have access to the data we need. So one layer of data packing through dictionary is perfectly designed and name space should be carefully used. Energy sector identifier is still a good way to distinguish the difference.

[Betristor]

This issue will be reopened if next version is on schedule. For the current version this may have large impact on existing code and users.