Duplicating "the template" Topology and Market Model when creating a LES

[grdw]

What if - when creating a LES - we duplicate the topology and market model. This way the topology and market model will always be unique and belong to one LES. If somebody destroy their LES, they'll destroy the topology and market model (easy as that).

I'd also like to introduce an template (boolean) column to indicate that a topology or market model is a template. This would mean that only those 'template' topologies and 'template' market models can be duplicated. This way we can remove clutter in the topology and market model selection while still keeping a unique topology and market model for every created LES.

---

Related #1414, #839

[ChaelKruip]

What if - when creating a LES - we duplicate the topology and market model. This way the topology and market model will always be unique and belong to one LES. If somebody destroy their LES, they'll destroy the topology and market model (easy as that).

👍

I'd also like to introduce an template (boolean) column to indicate that a topology or market model is a template. This would mean that only those 'template' topologies and 'template' market models can be duplicated.

Does this mean that the user can only choose these templates when starting a new LES?

Also, what happens if you clone a LES? Wouldn't you also need to duplicate non-template market models and topologies?

[grdw]

Does this mean that the user can only choose these templates when starting a new LES?

Yes. And you 'clone' the template (topology or market model) when creating a new LES.

Also, what happens if you clone a LES? Wouldn't you also need to duplicate non-template market models and topologies?

You would duplicate/clone the topologies/market models from the LES in question. Also you can just keep the exact same name, since that doesn't matter that much. As long as you don't use the same names for the templates.

[antw]

Related #1414, #839

This basically is #839 isn't it? Only in this issue "Featured" is now called "Template"? :grinning:

I agree with this idea though.

[grdw]

This basically is #839

Wasn't 839 the idea to sort of combine a Market Model and Topology as one whole unit? I can remember this being said in a meeting with @ChaelKruip once. So it could be that it wasn't really speicified in a Github issue or I misunderstood it; could also be 😅

[ChaelKruip]

Wasn't 839 the idea to sort of combine a Market Model and Topology as one whole unit? I can remember this being said in a meeting with @ChaelKruip once. So it could be that it wasn't really speicified in a Github issue.

I think it is good to become more concrete about what we really want here! 👍

For me the main advantages would be:

• less clutter in the list of topologies and market models
• more transparency in the code, the work-flow and the head of the user
• fewer ugly names including 'Clone #1- Clone #2-like strucutures' 😄

[antw]

Wasn't 839 the idea to sort of combine a Market Model and Topology as one whole unit?

Goodness no. At least I hope not. I appreciate the scribbles in that issue aren't very clear. 😆

The intention was that we'd have "featured" topologies and market models (or "templates" in this issue) which would be created the same as they are today, on topologies/new and market_models/new.

Then when you create a LES you would have the option of cloning one of these templates, or to copy a topology/market model from another LES to which you have access. Your new LES would get a clone of the chosen market model and topology.

  class TestingGround
-   belongs_to :topology
-   belongs_to :market_model
+   has_one :topology
+   has_one :market_model

    # ...

I'd also like to introduce an template (boolean) column to indicate that a topology or market model is a template.

I think it might be nicer to instead add two new models: TopologyTemplate and MarketModelTemplate. Then, Topology and MarketModel will belong_to :testing_ground. I think this because there are attributes which make sense existing on templates, which don't have a purpose on non-templates.

For example:

• user_id - it matters who owns a template, but once it is attached to a LES, the original template owner is no longer relevant. The _non-_template clone is owned by whomever owns the LES.
• public - sets whether a template is visible to people other than the owner. Serves no purpose in non-templates since public visibility should be determined by testing_grounds.public.
• name - The "combined" testing ground, topology, and market model already have a name: testing_ground.name. The individual components no longer need separate names.

It might be worth exploring whether it still makes sense for technology_profile to be a column on testing_grounds. Perhaps this might be better placed in the topology row (since it maps directly to the topologies.graph - the technology_profile doesn't make much sense without the graph...)?

[grdw]

It might be worth exploring whether it still makes sense for technology_profile to be a column on testing_grounds. Perhaps this might be better placed in the topology row (since it maps directly to the topologies.graph - the technology_profile doesn't make much sense without the graph...)?

Hmm.. yes. Interesting thought. I would think it's quiet allright that way. We could also not save the duplicate topology as a new topology in a database table. The things you would edit in the Topology tab would be everyting from the technology_profile column except the children. The thing we would store in the technology_profile would be the (now called) Topology attributes + all the technologies as 'children'.

This way - if time let's us - we could expand the graph editor with the technologies table a bit like I once proposed here.

[grdw]

I'm wondering how we're going to duplicate the topology columns. The first step would be to take a template:

{
  "name": "HV",
  "stakeholder": "aggregator",
  "depth": 0,
  "x": 0,
  "y": 0,
  "id": 1,
  "children": [
    {
      "name": "MV1",
      "stakeholder": "aggregator",
      "depth": 1,
      "x": 0,
      "y": 100,
      "id": 2,
      "investment_cost": "",
      "technical_lifetime": "",
      "capacity": ""
    }
  ]
}

Than duplicate it when importing. So create a Topology with a graph and that's it.

---

The next step would be to look at ways to improve the technologies_profile column implementation. It would be cool if you could rename end-points, and if you could have a technology matrix with more than 100 end-points (for instnace the Lochem topology comes up).