Split function assigns deprecated profile that is no longer be included in concurrency

[jorisberkhout]

We increased the storage volume of electric vehicles in the ETM in https://github.com/quintel/etsource/commit/526e1960f599b5409147be8352b77722b425c5ce. This means that any newly installed electric vehicles in ETMoses will have a storage volume of 100 kWh. Since the electric vehicles availability profiles depend on this storage volume, I generated new profiles and uploaded them to the Beta server. These profiles can be recognised by the 100 kWh in their name. For clarity, I moved the old profiles to the deprecated category and renamed them to include 25 kWh in their name. I also excluded them from the concurrency.

When I create a new LES from a scenario with electric vehicles, these electric vehicles are assigned one of the new profiles (ev_availability_profile_1_100.0_kWh_3.7_kW). However, when I use the split function, the split off part is assigned with one of the old profiles (ev_availability_profile_1_kWh_3.7_kW). I was expecting that this profile cannot be used anymore, because it is not included in the concurrency anymore. Can you shine some light on this, @grdw .

[antw]

It is my understanding that splitting a technology gives you an exact duplicate of the original (including the profile) and halves the number of units for each. It's up to the user if they want to assign a different profile (or change any other attributes) for the new technology.

[ChaelKruip]

It is my understanding that splitting a technology gives you an exact duplicate of the original (including the profile) and halves the number of units for each. It's up to the user if they want to assign a different profile (or change any other attributes) for the new technology.

Is this true @grdw? I suspect that the 'clone' gets a new profile...

[grdw]

These profiles can be recognised by the 100 kWh in their name

So you are assuming that by the 100 kWh in their name the code automatically looks at the volume of the EV and picks the correct profile? Would be a cool feature.

For clarity, I moved the old profiles to the deprecated category and renamed them to include 25 kWh in their name

That's not really how that works.... because they are still in the select box:

The way this works is as follows:

You have a LoadProfile and a Technology. They are connected by a TechnologyProfile connection table as it were. To exclude a certain LoadProfile from a Technology you have to go to the edit form and remove it from the permitted technologies:

The 'deprectated' is just a label used for sorting, it doesn't do anything.

Is this true @grdw? I suspect that the 'clone' gets a new profile...

No

[ChaelKruip]

No

If so, how can it be possible that @jorisberkhout experiences this:

However, when I use the split function, the split off part is assigned with one of the old profiles (ev_availability_profile_1_kWh_3.7_kW).

So, either the clone gets the exact same profile as the original and @jorisberkhout is lying. Or the clone gets assigned another profile and @grdw is lying. 😜

[grdw]

When I create a new LES from a scenario with electric vehicles, these electric vehicles are assigned one of the new profiles (ev_availability_profile_1_100.0_kWh_3.7_kW)

The current profile matrix editor is pretty dumb when splitting and selecting a new profile (just like we told each other to do, magically selecting a new profile was a bit too much hassle (I can remember some discussion about it)). When hitting the split button it selects the first profile from the select box. However, when importing the code automatically selects the first profile where included_in_concurrency (which right now is a pretty useless name, because it should just be called visible or included) is true.

We can't hide the old profiles considering that there are old LES's who still use those profiles. We could however, alter the sorting of the select box options to make the included_in_concurrency options the first options and than show all the old profiles.

[ChaelKruip]

selects the first profile where included_in_concurrency (which right now is a pretty useless name, because it should just be called visible or included) is true.

Wouldn't 'automatically_selectable' be a better term? The application can only choose from those profiles that have that boolean set to True. The user can also select other profiles still.

[antw]

It looks to me like splitting assigns the same profile as the original technology. For me, at least, it doesn't assign a new profile at random, nor does it default back to the first profile in the <select> box (base_load_4 is the fourth option in the list).

Before

After

I think this is the desired behaviour. Splitting is not "concurrency", and if a visitor wants to assign a different profile to their new technology then can choose one by hand; they may see a different profile assigned automatically and think that this is a bug in the "split" feature.

[grdw]

The application can only choose from those profiles that have that boolean set to True. The user can also select other profiles still.

Hmm.. I need to think about that.

It looks to me like splitting assigns the same profile as the original technology. For me, at least

That's only true for base loads. Every non-base load technology fishes out the first profile from the select box. This is because base loads have the EdsnSwitch in between the profile selection.

[grdw]

Turns out it was a bug. The profile_id was correctly set, however cloning a DOM element caused the profile select box to reset to the first option (while still maintaining the profile_id of the original DOM element... ). I fixed that problem 👍