Idea for strict enforcement of units

[tsmbland]

I made a start at trying to calculate LCOE (and its component parts such as capital cost), and found it an unnerving process dealing with a series of floats with no context about what these represent. For example, we have the capital_cost parameter in ProcessParameter, but what does this actually represent? A one-off cost, cost per year, per unit of capacity? Same with fixed_operating_cost, is this a cost per year, per timeslice, per unit of capacity, per unit of activity...? Dealing with these kinds of quantities you want to be sure you get this right, otherwise you could into a real mess (e.g. adding a yearly quantity with a lifetime quantity). Trust me, I've seen this done in MUSE1.

Instead of having all model quantities as f64, maybe we could create distinct structs for quantities with different units, with a series of restrictions and rules about combining quantities with different units.

I found this which I thought was neat, and wondered if we could do something similar (there's also the uom crate but I think this is overkill). Although my idea is slightly different and simpler as I'm not proposing using actual units (e.g. kg) with conversion between units (e.g. kg to tonne). We don't ask users for units anyway, just that the quantities they provide are consistent, and I think this is fine. But we do at least know the type of quantity that each value represents, and we could use this knowledge to restrict the operations that are permitted.

I've created a draft PR (#481) which gives this a go, including some cost calculations. Take a look, but the general idea is as follows:

---

I think we could have the following base quantities:

• Energy (e.g. PJ)
• Money (e.g. $)
• Time (or Year, since one unit of time always represents a year)
  as well as Activity and Capacity, which are both Energy/Year but differ by a constant factor (cap2act)

We could then have composite types such as MoneyPerYear, EnergyPerYearPerCapacity, and a series of rules about converting between quantities (e.g. Money divided by Year gives MoneyPerYear), and restrictions (e.g. can only add quantities of the same type, so you can't add a Money quantity with a MoneyPerYear quantity, for example).

In the PR I've also created IYear, as numbers of years can also be integers, and it's probably good to distinguish this, but it's all still a bit rough at this stage.

I think the parameters provided in the input data would be the following types (although this could definitely be wrong):

Agent

• annual_cost_limit: MoneyPerYear
• capex_limit: MoneyPerYear or Money (not actually sure, good to clarify)

Asset

• capacity: Capacity

Commodity:

• costs: MoneyPerEnergy
• demands (over the year): EnergyPerYear
• fractions: Year (or Dimensionless?)
• timeslice demands (= demand * fraction): Energy

Process:

• flows: EnergyPerYearPerCapacity
• flow costs: MoneyPerEnergyPerYearPerCapacity (???)
• capital cost: MoneyPerCapacity
• fixed operating cost: MoneyPerYearPerCapacity
• variable cost: MoneyPerActivity
• lifetime: Year
• discount rate: Dimensionless (or possibly PerYear?)
• cap2act: ActivityPerCapacity

Timeslices:

• fractions: Year

I'm hoping that most of the calculations would then go ahead pretty seamlessly, as we shouldn't ever do anything that would violate the unit rules, but if we did this would be flagged at compile time. This would certainly prevent a lot of potential bugs, and the kind of bug that would be almost impossible to spot (again, trust me, I've been through this with MUSE1!).

---

Something to bear in mind: I've created Energy as a single quantity, but actually the units will depend on the commodity, so 1 unit of Energy is not necessarily a consistent quantity. For example, the user may wish to represent oil in litres and electricity in petajoules, so we shouldn't add these together even if the compiler might allow it. If the user is careful with how they define their model (and we're also careful) then this should be fine, and in line with MUSE's "unit-agnostic" approach. However, there's a lot of responsibility on the user to get this right, e.g.

• Any commodities that are PACs of the same process must have equal units, as we add their flows together
• The cap2act parameter must be appropriate for the commodities that are PACs for that process
• It's up to the user to use appropriate capacity units based on cap2act and the units of the PAC commodities

Since we're not asking users to provide units, it's not possible for us to check and enforce this. I would consider adding a units column to commodities.csv so we can at least check and enforce this first point.

[tsmbland]

@alexdewar Something else to discuss

[alexdewar]

I've had a look at your PR and it seems like this could be feasible. Maybe let's try doing it as an experiment and see how we get on. The most complicated bit of maths that will go into MUSE in the short term will be your LCOX work, which will be a nice test case. If it works for you there, then that's probably a good sign that it won't cause too much pain elsewhere.

I think the idea of making users supply unit types in the input files is a really good one -- how about opening an issue for it? It's definitely a much more long-term thing, but anything we can do to help users not shoot themselves in the foot seems like a good idea.

[alexdewar]

This is done; closing