Feature method to convert network to subsystem

[HaSchneider]

As described in #1020 this implements a method for the Network class which returns a subsystem class implementation of the corresponding network.

A new subsystem is created and all sinks and sources are transformed in subsystem interfaces. All connections and the corresponding components are converted, only those to/from sink/sources are reconnected to subsystem interfaces.

This doesnt have to be a method of Network class, it could also be implemented as normal function in subsystem.py for example.

To do:

• Add PowerSources and PowerSinks
• Refactor code
• Implement unit tests for the changes
• Update the documentation
• Implement an example and a system test
• Update the changelog at docs/whats_new/*

[fwitte]

Thank you for the contribution @HaSchneider, will look into this and give you feedback soon!

[fwitte]

As it could be possible to have subsystem-internal sources/sinks, I would like to suggest the following change:

• expose all sources and sinks by default
• allow user to specify a list of sources and sinks to be exposed

I would also add/transfer the properties of the original connections to the interface connections so starting values can be preserved, if the original Network was solved already.

Other than that, I am thinking if the Subsystem/Network architecture needs to be implemented in a different way, there are a couple of thoughts that come to my mind:

• What about a Subsystem in a Subsystem in a Subsystem ...
• Serialization/Deserialization of Subsystem instances (right now the components and connections are flattened by prefixing their labels with the subsystem label) and then serialized/deserialized through Network
• Allow to solve Subsystem independently of Network or other way round by fixing what ever the specifications/boundary conditions are at the interfacing connections.

Any thoughts about it, since you are working with Subsystems frequently? This does not need to be included in this PR but it let to me thinking about it :D

[HaSchneider]

That are good suggestions. I adjusted the method, so that all connections are copied instead of creating new conenctions. All connection properties should be kept now. Only the source/targets are now adjusted accordingly to the subsysteminterface.
I also added an argument to exclude sinks/sources from conversing them to subsystem interfaces.

Regarding your other suggestions:

• "nested subsystems" are already possible, arent they?
• right now subsystems are "only" grouping network parts, but without much functionalitites, right? So nice features I could imagine are (just a brainstorming):
  • Solving subsystem independly as you already mentioned. I think that would make large networks easier to maintain and debug. And would probably allow an implementation of an hybrid of sequential modular and simultaneous solving.
  • import/export of subsystems: for that a dedicated serialization/deserialisation of subsystems might be nice. So that only the subsystem can be exported and imported without the need of import/export the whole network.
  • combine modeltamplate and subsystems:
    • allow subsystem specification in modeltemplate classes with corresponding method to converse/export the modeltemplate to a subsystem with defined interface exceptions and starting values etc.
    • plotting subsystems in a model template seperatly or in seperat colors

[fwitte]

That are good suggestions. I adjusted the method, so that all connections are copied instead of creating new conenctions. All connection properties should be kept now. Only the source/targets are now adjusted accordingly to the subsysteminterface. I also added an argument to exclude sinks/sources from conversing them to subsystem interfaces.

Nice, thank you! I will have a look at the changes. All the other topics can go to a different issue/pr.

* "nested subsystems" are already possible, arent they?

It is, but the inherit logic of which subsystem belongs to where goes missing due to the flattening of the labels. So a structured registry in the Network could be helpful.

  * Solving subsystem independly as you already mentioned. I think that would make large networks easier to maintain and debug. And would probably allow an implementation of an hybrid of sequential modular and simultaneous solving.

Yes, that is exactly what I am thinking about as well. Also being able to put parts of Network in "shutdown" mode.

  * import/export of subsystems: for that a dedicated serialization/deserialisation of subsystems might be nice. So that only the subsystem can be exported and imported without the need of import/export the whole network.

also agree

    * allow subsystem specification in modeltemplate classes with corresponding method to converse/export the modeltemplate to a subsystem with defined interface exceptions and starting values etc.
    * plotting subsystems in a model template seperatly or in seperat colors

also agree

[fwitte]

I think the copying/plain reusing of connections could break things if a model is exported more than once. There will be still some objects in the copied Connection instances which point to the original objects, e.g. fluidwrappers etc. So maybe it is actually better to serialize and de-serialize instead.

[HaSchneider]

Yes, that is correct. I tried also deepcopy but that results in the follwoing error:

TESPyComponentError: Component name in subsystem is not unique

[fwitte]

Maybe this could live in the Subsystem class instead. So we could have something like this:

• Subsystem.from_network()
  • calls Network.export(), your logic to transform the ports and then Subsystem._deserialize() to deserialize the Network.export()
• Subsystem.to_network()
  • calls Subsystem._serialize(), logic to transform SubsystemInterface to Source/Sink etc., Network.from_dict()
• Subsystem._deserialize()
• Subsystem._serialize()

[HaSchneider]

Yes, this might be a better location. Currently the type of the returned Subsystem is:

tespy.networks.network.Network.convert_to_subsystem.<locals>.sub_network

😆

[fwitte]

Let's maybe have a call to discuss this topic in detail @HaSchneider, do you have time Monday next week?

[HaSchneider]

The subsystem has now a clasmethod from_network(label, nw) which returns a subsystem created from the label.

There is one issue that might come up here: When a proper configured network is converted to a subsystem, using that subsystem in another network will most likely lead to an overdetermined system.

[fwitte]

Thank you for the update, we could change it so the subsystem can optionally be created "clean" = without any specifications.