Add active attribute to components

[FabianHofmann]

This PR introduces a new component active which, as discussed, allow to enable/disable assets from pypsa core functionalities. These are

• optimization
• power flow
• statistics

When set to inactive, the optimization masks the corresponding asset out. The asset then still appears in the index but does not contain any value. To save memory (in particular for the myopic optimization), we might change this to a harder filter such that inactive assets do not even appear in the variable blocks in the first place. My preference would be to tackle that after #848.

The PR further introduces as Component class. Note that this is purely non-breaking and non-intrusive. We had a Component object before, which was a namedtuple. With the new class we gain more control when iterating over components. It might as well pave the way to a more formal Component behaviour as discussed on #936.

(Do not merge yet, I would like to see some more tests on the optimization and power flow.)

Checklist

• Code changes are sufficiently documented; i.e. new functions contain docstrings and further explanations may be given in doc.
• Unit tests for new features were added (if applicable).
• Newly introduced dependencies are added to environment.yaml, environment_docs.yaml and setup.py (if applicable).
• A note for the release notes doc/release_notes.rst of the upcoming release is included.
• I consent to the release of this PR's code under the MIT license.

[fneum]

Ups :)

[lkstrp]

Can we drop dict?

[FabianHofmann]

sure

[lkstrp]

Looks good to me. But one bigger concern:
We are mixing n.active, n.active_in_investment_period and n.get_active_assets and neither the naming is clear nor is it apparent what the difference is. I would merge them all into one n.active_assets and handle if build year/lifetime should be taken into account in there.
Even cleaner would be to write the build year and lifetime into the active column. Then nothing would get mixed up. But that is probably not reasonable within the current structure, which makes a clean API important.

Otherwise, thanks for the great cleanup. I am not a big fan of the dataclass though. It starts to implement something without changing all the underlying structural issues and nested initialization. But I guess that's okay since it doesn't touch the API.

[lkstrp]

Maybe merge that as an optional argument into active_assets?

Also active_asserts_in_investment_period instead, but I think a combined method is cleaner

[lkstrp]

Needs update, specially since we mix active and the build_year/ life_time now and not write back to one

[FabianHofmann]

thanks for the comments @lkstrp! As for the active assets function, what is needed quite regularly is the index of active assets. With the current get_active_assets that would be

c.df.index[c.get_active_assets()]

which I shortcut to

c.active_assets

but I agree this is confusing. I will revert that and only define get_active_assets() for the Component class. At some point, we should think about a better naming. As I see, the name get_active_assets suggest that you get a listlike object with all active assets, but instead you get a boolean series indicating whether it is active or not. With that proposal, I wanted to introduce a better naming, but let's go step by step.

[FabianHofmann]

For more background: The general issue here is that the activity of an asset has two sources of information

a) the global (new) attribute active which defines activity for all pypsa functionality. This should be independent of any build_year or investment year and enable to fully control whether an assets is there or not.

b) the investment year dependent activity which adds on top and is only considered when doing and multi investment optimization. This is dependent on build_year (input), life_time (input) and investment_year (function argument).

When thinking about different approaches, my feeling is that the rule that static active columns should remain an input only thus not be touched/altered by the code.

[FabianHofmann]

and about the comment about the dataclass, I am happy to remove the dataclass decorator if this is what you meant

[lkstrp]

and about the comment about the dataclass, I am happy to remove the dataclass decorator if this is what you meant

Na, keep it is a it is. It is also so much cleaner than before

[lkstrp]

This check can be ignored now

[lkstrp]

As discussed:

• Completely moves active_asset logic to Component class
• Removes Component reference to Network
• Moves it to own module (definitions). That's how we named it in pypsa-eur. Not sure if it's the best name. But a composition is needed, otherwise we get circular import errors.

[FabianHofmann]

looks great, thanks lukas!