Generalise how generator, store and storage unit are added to the workflow

[pz-max]

Problem:
Adding a new technology can be cumbersome. For instance, adding a new storage requires to change the following (example in beyond cost study repo):

1. add_electricity.py
2. add_extra_components.py
3. config.yaml (add
4. costs.csv (add cost, efficiency data)

Aim: Just have two interfaces to add or customize technologies. Improve user experience and scalability.

• Interface to technology-data without technology constraint/model information. This is already done by the package technology-data which creates the cost.csv for any year of interest. If people want to add custom data they can do this by adding new technologies to the cost.csv -> maybe we should create a new file called cost-custom.csv that updates the cost.csv from technology-data (benefit of transparency of what values change to the PyPSA default data).
• Interface to config option relevant "technology model" details. This is currently placed in config.yaml only for the renewables generator model design. We should add here model relevant information for any technology. The list of options can grow by contributions from users with components such as generator, storage, dynamic load response, dynamic line rating, grid. This overtime growing interface should be a single monolithic e.g. technology-model.yaml and should not be in the config.yaml. The config.yaml could be updated with the technology-model.yaml by setting provided in the config.yaml (e.g. like with carriers, however, one should also specify which technology one wants for each carrier e.g. in list format onwind: [VESTAS1MW, ENERCON5MW. Example of options that are required for the energy storage in the technology-model.yaml include specific charging to discharging ratio, SOC_cycle_level -> state_of_charge cycle: False/ any percentage between 0-100%.

Ressource requirement:

• Time: The above-suggested changes require a considerable amount of time and a lot of testing (expected time 2-4weeks for everything).
• Experience: Advanced understanding of the repository is required to implement these changes into PyPSA-Earth.

Further implications beyond technology model design:

• Maybe an option interface that can grow by user contributions could be created in a similar way. So users/devs can contribute their new custom constraints and anyone can select in the config.yaml which constrain should be added.

[pz-max]

@davide-f the point we discussed in the meeting however in extended format. Couldn't stop thinking about it

[davide-f]

Very nice description!
To me, point 2 seems more interesting, because the point 1, which means changing cost parameters, may be done manually by newcomers, even without running technology-data (I understand, it is sub-optimal, but it is possible).
Whereas, implementing different technologies of the "same type" is nearly impossible for a newbie and it is time consuming also for us.
I'd prioritize 2

[pz-max]

True. Point 2 is the new interesting stuff. Point 1 only a minor improvement & transparency provider in terms of what values really changed (imagine you checkout another's cost.csv).

I think prio is point 2 but actually another person could work simultaneously on 1 (relativ easy to implement)