Removing _plus technologies

[brynpickering]

We currently have two technology base classes which super-charge other baes classes: supply_plus and conversion_plus. With the introduction of custom math and the new data structures in v0.7, I propose removing these.

Below I've described the existing functionality of these base classes and how I would expect them to work in v0.7.

NOTE: I'm using the new variable names (see #451) as much as possible here.

supply_plus

Existing functionality

Resource can be consumed and stored prior to flowing into the technology to be converted to a system carrier. A limit on the rate of resource transfer to the storage device becomes an additional decision variable, so you have source_flow -> storage -> flow_in -> flow_out.

Proposal

With the new custom math, it's feasible to apply storage-related constraints and decision variables to any technology base class. This enables any technology to store flows into the technology for release at a later timestep. For supply technologies, this would relate to the flow of the resource into the tech, which could be tracked with its own decision variable (source_use?) or by using a protected carrier name source in flow_in.

I think flow_in and flow_out should have their own efficiency and potential for flow-limiting variables anyway, which would deal with the issue of needing to replace resource_cap (-> flow_in_cap), although resource_cap could simply move to being linked to supply rather than supply_plus (triggered into existence by setting a source_cap_max/minparameter).

conversion_plus

Existing functionality

N carriers can be consumed and M carriers can be produced from a conversion_plus technology, in two different ways:

1. if carriers are on the same level/"tier" they can be included in a list (e.g., carrier_in: [gas, coal]) and then the amount of each carrier that is consumed/produced is a decision between those two carriers (flow_in = flow_in[gas] + flow_in[coal]).
2. if carriers are placed on a different tier (e.g., carrier_in_2: electricity), they are produced whenever the technology is in use (flow_in[electricity] = flow_in * electricity_to_fuel_ratio.

These two options represent different technology types, the first could represent a dual-fuel power plant (e.g., with the choice to consume biofuel or fossil fuel, with different efficiencies) or a twin-flow heat pump (able to produce heating and/or cooling). The second could represent a combined heat and power plant (whenever electricity is produced, heat is produced as a secondary flow) or to track waste flows (e.g., nuclear waste which you could track in the system as its own carrier). They can even be combined (a CHP with dual-fuel inputs and fixed secondary heat production).

Proposal

We go back to having only one carrier "tier" but continue to allow lists of carriers. How these carriers relate to each other is then set by technology-specific constraints. E.g., if you have carrier_in: [biofuel, coal] you could set the constraint flow_in[biofuel] * biofuel_eff + flow_in[coal] * coal_eff = flow_out[electricity], which would need to override the standard technology balance constraint (default would be (flow_in[biofuel] + flow_in[coal]) * flow_eff = flow_out[electricity]). You could also force flow of one whenever the other flows (flow_in[biofuel] = flow_in[coal] * flow_ratio). With two constraints, you could even set a combination of the two: that there is some forced co-flow but that it's also possible to trade off flow of the "main" carrier for flow of the "secondary" one on top of that.

This removes the need for the carrier_tier dimension and potentially acts as a solution to issues arising in #362. It also circumvents issues that exist when defining custom constraints for mutliple carrier flows that act weirdly when standard conversion_plus constraints are then applied on top of them.

This could then be applied to any technology for which carriers can be defined in / out. It comes with the problem that you then have these different flows that one needs to decide how to control in the context of flow_cap and costs. This is currently handled with primary_carrier_in/out, which would e.g., link variable costs to flow_in[coal] or flow_out[electricity]. With further generalisation of the yaml syntax, carrier-specific parameters could instead be defined at the technology level, e.g.:

techs:
  dual_fuel_in:
    parent: conversion
    carrier_in: [biofuel, coal]
    carrier_out: electricity
    biofuel_eff: 0.6  # new param linked to new constraint
    coal_eff: 0.5  # new param linked to new constraint
    primary_carrier_in: coal
    cost_flow_in: 2  # biofuel cost would need to be handled some other way, e.g., using an intermediate tech?
    ...

could become:

techs:
  dual_fuel_in:
    parent: conversion
    carrier_in: [biofuel, coal]
    carrier_out: electricity
    flow_in_eff: 
      biofuel: 0.6  # would be implicitly assumed that this level refers to the `carriers` dimension
      coal: 0.5
    cost_flow_in:
      monetary:
        biofuel: 1
        coal: 2
    ...

or (in line with current discussion in #452):

techs:
  dual_fuel_in:
    parent: conversion
    carrier_in: [biofuel, coal]
    carrier_out: electricity
    flow_in_eff: 
      data: [0.6, 0.5]
      index: [biofuel, coal]
      dims: carriers
    cost_flow_in:
      data: [1, 2]
      index: [(monetary, biofuel), (monetary, coal)]
      dims: [costs, carriers]
    ...

Summary thoughts

supply_plus seems more readily replaceable. In the context of new YAML config (#362), conversion_plus config does need a solution, and perhaps this could be the starting point for defining that.