Split between individual and aggregated load profiles is not always practical

[DorinevanderVlies]

Current situation:

Currently for <31 units an individual load profile for electricity has to be selected.
For >30 households an aggregated profile has to be selected.

Problem:

There are cases when I want to assign an aggregated profile to <31 households.
For example when I have different end nodes to represent different stakeholders. But, on the network these nodes are connected to one transformer. In this case the individual profiles are way too spiky.

Possible solutions:

• Add a button which can be selected if a user wants to use an aggregated profile on <31 households.
• Keep the current interface, but make it possible to assign an aggregated profiles on <31 households when a CSV file is used to define the technologies.

[ChaelKruip]

Keep the current interface, but make it possible to assign an aggregated profiles on <31 households when a CSV file is used to define the technologies.

I prefer this option.

@antw @grdw what do you think?

[ChaelKruip]

@grdw can you pick this up?

[DorinevanderVlies]

An other option is that the difference between individual and aggregated profiles is just defined in the name of the profile. So, not all profiles can be used for all numbers of households. Like it is for water heating.

I prefer this option.

[grdw]

We could make this way more easy. The easiest way would be getting rid of the < 31 threshold and make it possible to create a separate base_load_edsn and base_load technology. I think it's a bit 'unfair' to only make this possible with a CSV input (in fact I'm not a big fan of the CSV input) and not in the profile matrix editor.

[antw]

I think it's a bit 'unfair' to only make this possible with a CSV input (in fact I'm not a big fan of the CSV input) and not in the profile matrix editor.

I'm not sure of the best solution, but I absolutely agree with this. We can't apply one set of rules to the normal interface and another to CSVs, otherwise things will break in unpredictable ways when you try to edit these LESes.

I, too, wish we could get rid of the CSV import (export is fine). It might be useful to know in which ways editing a CSV is easier than the normal technology editor, and try to improve it until the CSV import feature is no longer needed. That's a bit off-topic though...

[antw]

There are cases when I want to assign an aggregated profile to <31 households. For example when I have different end nodes to represent different stakeholders. But, on the network these nodes are connected to one transformer. In this case the individual profiles are way too spiky.

It's worth noting that there is a difference between the individual and aggregated household technologies other than the profiles that may be chosen. Individual households (<31 units) permit use of the "postponing" strategy, while aggregated households use "saving".

An individual household technology (<31 units) with an "aggregated" profile will still use the "postponing" strategy.

The easiest way would be getting rid of the < 31 threshold and make it possible to create a separate base_load_edsn and base_load technology.

I think this may be the right way to go.

When importing a new scenario from ETE we could apply the same approach as we do today: <31 units = individual, ≥31 = aggregated. If the user wants to override that by manually adding an aggregated household with only 20 units, or an individual household with 40, why not let them?

[DorinevanderVlies]

When importing a new scenario from ETE we could apply the same approach as we do today: <31 units = individual, ≥31 = aggregated. If the user wants to override that by manually adding an aggregated household with only 20 units, or an individual household with 40, why not let them?

Sounds good to me

[ChaelKruip]

Good ideas everybody!

When importing a new scenario from ETE we could apply the same approach as we do today: <31 units = individual, ≥31 = aggregated. If the user wants to override that by manually adding an aggregated household with only 20 units, or an individual household with 40, why not let them?

Let's do it! 👍

[grdw]

I am currently exploring this issue and @ChaelKruip came with a really great suggestion. He suggested to determine the behavior based on the chosen load_profile. I think this might be a way to approach it.

So that way I assume there will only be a single base_load technology with both aggregrated and non aggregated profiles. Their curve_type will determine if this profile will either be put in the aggregated or non aggregated basket and this will determine the behavior of the technology. I think this is currently possible... (I am looking at @antw )

[antw]

I think this is currently possible... (I am looking at @antw )

The exact technology behavior is determined by InstalledTechnology#behavior_with_curve:

base_load = InstalledTechnology.new(type: 'base_load')

base_load.behavior_with_curve(:inflex)
# => "generic"

base_load.behavior_with_curve(:flex)
# => "deferrable" (aka postponing)

# ---------------

base_load_edsn = InstalledTechnology.new(type: 'base_load_edsn')

base_load_edsn.behavior_with_curve(:inflex)
# => "generic"

base_load_edsn.behavior_with_curve(:flex)
# => "optional" (aka saving)

I'm a bit on the fence about this. It would definitely be a easier from the user's perspective to not have to choose between "individual" and "aggregated", but changing the technology behavior by selecting a different profile does feel a bit "magic" and not obvious.

We'd have to add a table/columns so that you could select which strategy applies when uploading base load profiles, and add a special case inside InstalledTechnology to trigger the correct behavior in the network calculation.

At the moment the technology behavior is defined in the YAML file, but now we have to special-case some technologies and profiles? Its easy for a user, but is it simple?

[grdw]

[..] a different profile does feel a bit "magic" and not obvious.

I also agree with this. ⚖

[ChaelKruip]

I also agree with this. ⚖

I'm also not convinced about this solution to be honest.

[grdw]

Allright I think we should keep the distinction between a base_load technology and a base_load_edsn technology. A user can add one or both. We should let the user have the maximum amount of freedom. The first time a user imports their technologies the base_load should 'switch' to base_load_edsn when the threshold is reached. After that automatic edit the user is free to change whatever he or she wants.

[ChaelKruip]

After that automatic edit the user is free to change whatever he or she wants.

So, what would happen if someone chooses an individual (base_load) profile for a base_load_edsn technology and uses the save aggregated base load strategy? Will that strategy try to save the 'flexible part' of the individual (base_load) profile?

Or the other way around: would the postpone strategy applied to aggregated (edsn) profiles try to postpone the flexible part of the aggregated profile?

Both wouldn't work as the flexible parts of the two types of profiles are very different.

What I think would be perhaps more robust is that we allow the user to adjust the number of units of either the base_load or base_load_edsn technology importing without applying the threshold automatically. Still keeping the profiles exclusive for each technology.

[grdw]

So, what would happen if someone chooses an individual (base_load) profile for a base_load_edsn technology and uses the save aggregated base load strategy? Will that strategy try to save the 'flexible part' of the individual (base_load) profile?

You can't pick an individual profile for a base_load_edsn technology. You can add a base_load_edsn technology (for which you can pick base_load_edsn profiles) and a base_load technology (for which you can choose base_load profiles). The units however don't matter anymore. The user is free to add - for example - a base_load_edsn technology, with units = 1. This doesn't make much sense but it is possible.