Restructure components

[p-snft]

The name "custom components" implies that also third party custom components should go there. However, it is perfectly possible to define custom components outside the oemof directory in the project using oemof.

Now, I think of, "custom components" somewhat as of the "staging" part of the Linux kernel. The code is already part of it, but it is not fully tested or documented. At some point in time, it will eventually be become core functionality. What do you think?

Update: Also, as the number of components grows, it might be useful to have some more structure, eventually even a document comparing different models for one (real world) component.

[jakob-wo]

I quote myself from another Issue because it belongs here:

I see solph.custon as a place not only for "not-100%-tested-and-documented-Components" but also for highly specified Components that have no generic formulation or application.

That means, I do not see solph.custom as something like "staging" even though in some cases it can be used for staging. I prefere to stay with "solph.custom".

[p-snft]

I see. Probably this is just one aspect of a broader topic. I will tag it for the v0.4 release and bring it to the agenda at the 2019 spring dev meeting.

[jakob-wo]

@uvchik suggested a web-conference in Issue #603 that is related to this topic:

Shall we make a web-conference about "Where to place advanced components?

Would you like to join us?

[uvchik]

I agree in both. Changing the name and dividing the modules. But we will not be able to discuss it before the v0.4.0 release. But we could change it with v0.4.1 and add a deprecate warning. We could remove the old name with v0.5.0.

[p-snft]

As a follow up: I am currently reworking the Link, which I see as a simple component in staging. Could we sort the others? (Probably, ElectricalLine is more of a complex component rather than staging. Have we a name for this kind?)

[p-snft]

Taking a broader view (chatting with @uvchik), I was convinced that this structure is caused by the fact that oemof.solph is historically grown. Not knowing the exact background, it can be confusing. Thus, I propose the following:

1. There should be a submodule (directory) components containing all components.
2. Inside that directory, all components are placed in individual modules (python files). E.g., there will be generic_storage.py, but also transformer.py. (The latter is a component but currently placed in solph.network).
3. These modules contain both, the solph class and the Pyomo block class. (This, i.a. means that the TransformerBlock will move from solph.blocks to solph.components.transformer.)
4. Instead of moving a "staging" component to another directory when it matures, we issue a warning if experimental modules are loaded. So, solph.custom will be dissolved and integrated into solph.components.

As a side effect, this will split the big chunk of code, components.py has become.

[uvchik]

Additionally I would move the Flow-related classes from network.py and blocks.py to flow.py and the bus to a bus.py.

I am not sure if it makes sense to create a sink.py and a source.py in components.`

If we do so in network.py there is nothing more left than the EnergySystem class. Shall we rename network?

[p-snft]

Additionally I would move the Flow-related classes from network.py and blocks.py to flow.py and the bus to a bus.py.

This is a reasonable addition to make everything consistent.

I am not sure if it makes sense to create a sink.py and a source.py in components.`

As these components do nothing related to model-generation but only check network-related connections, we could also just import them from oemof.network and move the check there.

If we do so in network.py there is nothing more left than the EnergySystem class. Shall we rename network?

Yes, would be more consistent.

[uvchik]

As these components do nothing related to model-generation but only check network-related connections, we could also just import them from oemof.network and move the check there.

If I get you right you want to remove the Sink from solph and change the oemof.solph.init.py:

- from .network import Sink
+ from oemof.network.network import Sink

So that it is still possible to use :

from oemof.solph import Sink

Or do you want to import Sink and Source classes directly from oemof.network?

from oemof.network.network import Sink

[p-snft]

- from .network import Sink
+ from oemof.network.network import Sink

This. Especially, as solph related functionality might be added in the future.

[uvchik]

@oemof-developer : Feedback wanted!

[p-snft]

Results from the 2020 December meeting:

• The solph network should be subdivided into components, busses, and flows.
• All components (also Sink/Source/Transformer) including the corresponding Blocks go to the "components" submodule.
• Experimental components will be located in solph.components but can be imported from solph.experimental.
• We will try to derive classes InvestmentFlow and NonConvexFlow from the Flow class, in the process "solph.options" will be removed.
• There will be basically three folders:
  • _components -> contains all components and blocks
  • _flows -> will contain Flow, NonConvexFlow and InvestmentFlow
  • _buses
  • Should these be "private" to show users tey should import from solph?
• custom will become solph-experimental
• solph.Sink (and others) might be just in solph/init.py

[p-snft]

I think, this is done.