Always attach efficiencies to inflows and outflows

[gnawin]

What and Why

As a result of discussion #432, we want to keep efficiency terms both for inflows and outflows where lowest resolution is used (e.g., conversion balance).

In create_model.jl, currently we differentiate

• incoming_flow_lowest_resolution
• outgoing_flow_lowest_resolution
• incoming_flow_lowest_resolution_w_efficiency
• outgoing_flow_lowest_resolution_w_efficiency

We only want to keep

• incoming_flow_lowest_resolution_w_efficiency
• outgoing_flow_lowest_resolution_w_efficiency

By default, the efficiencies should be 1 so they can also replace the current cases for

• incoming_flow_lowest_resolution
• outgoing_flow_lowest_resolution

Possible Drawbacks

No response

Related Issues

#437

[gnawin]

A flag add_efficiency is used to generate the different expressions, which is needed because sometimes we want to consider efficiencies, and sometimes not. So simply removing that does not work.

I wanted to set the efficiency to 1 when we don't need it. But I have not thought of a general way to do that. I'm thinking of refactoring the input data somehow because I remember some data is redundant, maybe some of the efficiencies?
An example would be in the hub balance, since we do not need efficiencies, the efficiency for the flows should be 1. But in flow_data.csv, there are efficiencies for the flows related to hubs.

Any thoughts @datejada ?

[datejada]

I see; it is clearer now, and I'm starting to recall the case. So, the difficulty arises when a flow from a storage or conversion asset is also used in a balanced hub. For example, in the flow ccgt -> hub, you need the efficiency if you are constructing the conversion balance equation, but you don't need it if you create the hub balance one. Is that the case? @gnawin

I'm open to hearing options to handle these cases better and avoid confusion in the future. However, the first step is cleaning the Norse case data files. Some columns are unnecessary and confusing. I've created issue #440 to keep the changes in a more atomic-commit manner.

Then, you can refactor the data in this issue if needed. Is that ok?

[gnawin]

@datejada I'm already doing something in the data. What I see is that for hub balance and for consumer balance, no efficiencies are needed, meaning the efficiencies of inflows and outflows for hubs and consumers have to be set to 1 (but if the same data is also used in conversion balance, then maybe better not touch that data). If I recall correctly, the efficiency for conversion comes from assets? We'll have to check storage as well.

Maybe I can start #440 as well, otherwise I'll just put my comments there. Do you want to do #440, maybe you (or someone else) know more what is currently used and what not, which may be faster?

[datejada]

@gnawin I updated the files in here #441 you are a reviewer

Regarding your proposal, remember that we have the efficiency in the flows because an asset can have several inputs and outputs. So, there might be not only one efficiency associated with the asset but multiple ones, so having them in the flow file was easier to handle.