Idea for making unit conversions and efficiencies a little easier to specify

[DillonJ]

Currently, to specify a conversion or an efficiency between two flows corresponding to a unit__to_node and/or unit__from_node we need to create a unit__node__node relationship and a [fix/min/max]_[in/out]_[in/out]_unit_flow parameter. The order of the nodes matters and the name of the [fix/min/max]_[in/out]_[in/out] parameter changes the meaning of the order of the nodes. It is quite taxing getting this right, it's quite prone to error and often takes some trial and error to get right.

So this is the idea:

• We would replace this system by designating a reference flow by specifying is_reference_flow = true and then for any conversion you want to define, you simply specify a reference_flow_coefficient parameter on whatever flows you want to constrain relative to the reference flow. No need to create any new relationships and it's all a lot clearer what is happening, in my opinion.

• In addition we can specify units_on_coefficient on a flow to enforce a flow related to units_on (an idle heat rate for example) and the constraint then becomes flow = reference_flow_coefficient * reference_flow + units_on_coefficient * units_on

• We would have two additional versions of this to allow for the min and max functionalities we already have, so min_reference_flow_coefficient etc.

• We would support piecewise linear when doing this which is currently not supported in the existing system of fix_ratio etc.

• It would be familiar to Times users as that’s how it’s done there

• It supports the vast majority of use cases, but there are some cases that won’t work, but none that we have come across a need for in our models. In these cases, you can always fall back on the user_constraints.

• I think it’s a nice system that is Spine-esque and fits well with the whole flow based, multi-commodity thing.

• We could do the same for connections as part of the work to avoid the 4 variables. The reference flow thing would also be a nice way to specify a reference direction.

[jkiviluo]

It's not clear to me how one would implement piecewise-linear efficiencies here. Would the coefficient be dependent on operating point of the flow?

Also the inertia is not clear. What does fixed capacity mean? One is providing inertia only when online, so shouldn't there be units_on_coefficient on that?

How would one limit the amount of reserve one can get from the unit (e.g. thermal power plant can typically provide only about 5% of its total capacity as primary reserve)? Is it that max_reference_flow_coefficient?

[jkiviluo]

One problem with this approach is that in many cases the coefficients need to be calculated and they won't make direct sense. For example, if trying to model a gas turbine with efficiency of 30% and a 10 MW online_coefficient for gas consumption, then the parameters need to be:

gas_turbine__gas [reference_flow] = true
gas_turbine__gas [units_on_coefficient] = 10
gas_turbine__elec [reference_flow_coefficient] = 0.328125

If the user would set reference_flow_coefficient to 0.3 (thinking that it corresponds to 30% efficiency), then the actual efficiency at full power would be 27.6%.

Furthermore, if the user then wants to shift conversion_method from part_load_efficiency to constant_efficiency (to make the model faster), then the reference_flow_coefficient of 0.328125 would be wrong (it should then be 0.3).

[manuelma]

@jkiviluo couldn't that math be avoided by setting the reference flow on the other side of the unit, so to say?

I believe any approach might require math. I think @tarskul was also making that point. I think if that math is 1/x then it's not a big deal.

[jkiviluo]

@jkiviluo couldn't that math be avoided by setting the reference flow on the other side of the unit, so to say?

No, it can't. I was trying to show that above. Reference flow only works if its a constant efficiency unit (and that's more straightforward to do with efficiency approach, so the reference method doesn't gain anything there).

It's not 1/x math. Even for this simple gas turbine case, you will need to figure out how to set the reference_flow_coefficient when considering the units_on_coefficient to match the efficiency/heat-rate at full load (which is the value you will most likely know). Furthermore, the coefficient then loses the correspondence to understandable reality - the resulting value will not state efficiency nor heat rate. The worst thing is that when you want to switch between different ways to present the unit (part-load efficiency or constant_efficiency), the parameter value will not be correct for both.

[manuelma]

Ah - thank you! How is that solved in the other approach?

[jkiviluo]

How is that solved in the other approach?

Since one is stating the (full load) efficiency directly, then the processing code can make sure you get the right coefficients in the conversion equation independent of the selected conversion method. It also works for different piece-wise linear implementations (which I still don't know how to do with the reference approach).