Do we want hierarchical classes (subclasses)?

[spine-o-bot]

In GitLab by @poncelet on Dec 4, 2018, 11:07

Our current data structure does not support the use of subclasses (related to inheritance). This issue aims to open the discussion regarding whether Spine toolbox should support subclasses.

The idea of subclasses has been put forward in the context of the archetype discussion (see https://gitlab.vtt.fi/spine/model/issues/62#note_2963). In that context, the discussion concluded that subclasses are not sufficient to provide all the functionality we desire for archetypes.

However, this discussion does not relate to archetypes (and even to a certain degree to Spine model), but more general whether the subclasses could be a valuable feature for Spine toolbox (thus in the end, could supporting subclasses be valuable to potential users of the toolbox)?

The advantages for subclasses are:

• Makes it easier to use the toolbox for other models (e.g., the NREL models use subclasses)
• Allows to use same variable names for different subclasses (e.g., if units, storage_units and connections would all be part of the subclass "device", they could all have the same variable "flow" if this is desired (this is a prerequisite for the point below)
• Allows to re-use pieces of the model code in cases there is shared functionality between two object classes (e.g., certain constraints might be similar for units and connections, this code has to be copied since they both belong to different object classes)
• Allows to increase the user-friendliness. For instance, if desired, a user could create a subclass of unit and call it "heating device", or "power plant" instead of the more abstract "Unit". Additionally, this allows to restrict the available parameters for these object classes (certain parameters for power plants might not be relevant for heating devices).

[spine-o-bot]

In GitLab by @manuelma on Dec 4, 2018, 13:04

I like this for future versions. It probably impacts the generic data structure as well, since we would need something like a super_object_class table, or at least a super_class_id field somewhere.

[spine-o-bot]

In GitLab by @poncelet on Dec 4, 2018, 13:20

It probably impacts the generic data structure as well, since we would need something like a super_object_class table, or at least a super_class_id field somewhere.

I believe so too. Do you have an idea how much effort it would require to adapt the data structure/tree view etc. to accommodate subclasses?

I like this for future versions.

I fully understand that from toolbox perspective, this can be something to explore/develop in a later stage. However, if we in the end want to support it in the toolbox, there might be missed opportunities for Spine model to make advantage of this functionality. So in that sense, it is a strategic decision to be made, and I would like to consider it as early as possible.

[spine-o-bot]

In GitLab by @manuelma on Dec 4, 2018, 13:29

Do you have an idea how much effort it would require to adapt the data structure/tree view etc. to accommodate subclasses?

It's though to say, since we don't have a clear requirement yet. I can say that adding a few fields and using those in the treeview, for example, is never too much effort, just something that needs to be done carefully.

But I'm with you, we can take this decision now (or soon) and plan to have it working for version 0.3 or 0.4, something like that. Remember our priority now is to consolidate and document the current version.

[spine-o-bot]

In GitLab by @DillonJ on Dec 4, 2018, 17:17

As we discussed in the storage issue https://gitlab.vtt.fi/spine/model/issues/6, this will impact on archetypes and we should discuss this idea as part of the archetype discussion (the post features/methods implementation).

My feeling is that it would be either archetypes or subclasses and not both... maybe we could implement archetypes using sublcasses or at least on top of subclasses.

It doesn't only impact the generic data structure, it IS the generic data structure :-)

,

[spine-o-bot]

In GitLab by @DillonJ on Dec 4, 2018, 17:19

I was also making the point that using features/methods we can essentially implement the idea of a subclass already. We create a feature parameter and then use the value in conditionals in the model... this is the essential functionality in my view

[spine-o-bot]

In GitLab by @poncelet on Dec 4, 2018, 17:49

this will impact on archetypes and we should discuss this idea as part of the archetype discussion (the post features/methods implementation).

I disagree because (i) subclasses are more likely to be used in other models (see e.g., NREL) which to me is a main reason for the toolbox to support it, and (ii) subclasses cannot provide the functionality we want for archetypes, and should in my view not be seen as a replacement for archetypes (see my comments in issue spine-tools/SpineOpt.jl#62).

My feeling is that it would be either archetypes or subclasses and not both... maybe we could implement archetypes using sublcasses or at least on top of subclasses.

Regarding this, this should be discussed I guess over in Issue spine-tools/SpineOpt.jl#62. As made clear in my comment above, I don't think subclasses can be a replacement of archetypes. I do however believe that archetypes can build on subclasses (so definitively not an either-or for me).

[spine-o-bot]

In GitLab by @jkiviluo on Dec 5, 2018, 15:30

Currently (subject to change as argument evolves), I think we should support sub-classes in Spine Toolbox (e.g. so that NREL can directly implement their data structure), but we wouldn't use it in Spine Model where archetype/feature/method should be sufficient. If at some point it is not sufficient, we could start using sub-classes also in Spine Model, but I would first try to manage without them - this helps to keep things easier to understand.

This approach can help other tool makers to experiment what is the best approach for their purpose. Actually, it can help us too.

[spine-o-bot]

In GitLab by @DillonJ on Dec 5, 2018, 15:46

Let's be mindful of project resources and where we are right now. Our current focus is to try and stabilize the toolbox and complete milestone 2 so we can implement the case studies - and we're quite behind where we should be on those.

Sub classes and archetypes together would create a lot of complexity and in my opinion, create too many ways to do similar things and this could cause problems. I think we need to decide how we do archetypes first and consider the question of subclasses in this context. If we're going to make big changes that impact right across the project from the data structure, toolbox, JuMPAllOut and SpineModel, then we should consider them carefully and try and find the optimal balance between function, impact and effort. We should also try and do it as a single piece of work to minimize the impact.

I think cooperation with NREL is good, but I don't feel that this should dictate changes that have a big impact on the project. Currently, I don't see a reciprocal impact where Spine is impacting NREL development.

Also, in my view, it is fairly straightforward to implement subclasses using features/methods. You define a feature parameter for each object called subclass and then the enumerated values (methods) are the different available sub classes.

[spine-o-bot]

In GitLab by @poncelet on Apr 30, 2019, 10:21

In SpineModel Issue#106, we have been discussing possibly changing the database design. After some discussions, there seems to be multiple motivations for making changes to our current generic data structure.

The ideas that have been discussed are:

• having an entity superclass with subclasses object class and relationship class. The reason for doing this is that we would have only one parameter definition table required.
• having a group object class with the final goal that we can have certain parameters defined for single units only (or relationships between a single unit and some other objects), parameters defined over groups of units only (or relationships between a unit group and some other objects) and parameters which are defined over either a single unit or a unit group (again, or with relationships) without having to define the parameter multiple times (see more detail on that in SpineModel Issue#106. This will likely require having a unit superclass with subclasses single_unit and unit_group.
• general support for superclasses and subclasses (also needed to link better to TIMES and NREL's models)

Next steps are that @juha_k does a proposal and we have a next call to discuss it next Monday 1pm CET.

[spine-o-bot]

In GitLab by @manuelma on Apr 30, 2019, 13:10

having an entity superclass with subclasses object class and relationship class. The reason for doing this is that we would have only one parameter definition table required

We do have only one parameter definition table currently. The 'problem' is that table has two fields, one called object_class_id and another called relationship_class_id, and only one can be NON NULL at the same time. To be honest I prefer it that way, the way it currently is. The alternative is to replace those two fields by other two fields, entity_type and entity_id (ok, those two fields will be in another table, but it's essentially that). So we are not winning anything. The current way of doing it has the additional advantage that one can effectively write a foreign key constraint.