Giters

calliope-project / calliope

A multi-scale energy systems modelling framework

Home Page:https://www.callio.pe

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Rename confusing/misleading variables and parameters

brynpickering opened this issue · comments

commented

There are a few variables/parameters that are confusing on a first pass, and sometimes a bit misleading. The main culprit is energy_cap, but there are a few others. Here are some ideas (and why they might need changing in brackets) from offline discussions and my own head:

variables

  • energy_cap -> flow_cap/carrier_cap (this is e.g. in units of flow_per_hour so, if anything, is a power_cap rather than an energy_cap, but power has an energy system focus and is perhaps confusing when one has e.g. water or distance travelled as the carrier)
  • carrier_con -> flow_in/carrier_in (con makes sense once you're a calliope convert, but in is instantly understandable)
  • carrier_prod -> flow_out/carrier_out (prod makes sense once you're a calliope convert, but out is instantly understandable)
  • resource_area -> resource_footprint/footprint/area_use (footprint perhaps better covers the fact that it can be indirect (e.g., biofuel crops) or direct (e.g., PV panels) area use)
  • resource_con -> resource_in/source_use (con makes sense once you're a calliope convert, but in is instantly understandable)
  • purchased -> purchased_units/binary_investment (maybe this is rolled in with units and differentiated by setting the maximum to 1 and then having some other parameter set that allows it to have the same constraints applied to it as purchased currently does)
  • units -> purchased_units/integer_investment (maybe this is rolled in with purchased and differentiated by having some other parameter set that allows it to have the same constraints applied to it as units currently does)
  • prod_con_switch -> in_out_switch/flow_switch (see above)

parameters

All the above are ported across where relevant and...

  • energy_cap_min_use -> flow_out_min_relative/flow_out_min/carrier_out_min
  • resource -> source and sink, i.e. we separate positive and negative resources into their own parameters. sink becomes a positive number now.
  • force_resource -> (source_min, source_max, and source_equals) and (sink_min, sink_max, and sink_equals). _equals has to be there as these parameters tend to be the largest in the model (due to the time dimension).

Calliope version

v0.7.0-dev

commented

I'm starting to think that source and sink should be source_use and sink_use (like with area_use). source_use_max, sink_use_equals, etc. sounds better to me than source_max, sink_equals, etc. Thoughts @sjpfenninger , @FLomb , @jnnr , @FraSanvit ...?