migrate snapshot clustering to eTraGo repos

[ulfmueller]

@simnh We created the new repos for the optimization of transmission grids concerning storage expansion https://github.com/openego/eTraGo

Can you migrate your snapshot clustering to that new repository and do the further work there?

[simnh]

yes I can. just two questions:

• What about the pyPSA fork? Where will this be?
• What about the module/package structure ?

Maybe you, @s3pp, can provide a proposal?

I actually think it can be an good idea to have optimization code and apps in different repositories. But if they are in the same, they should at least be inside different packages...

But I will follow your proposal.. :)

[eosram]

PyPSA was forked by openego. It's in the organization repos.

I would propose the following structure.

README.rst,
LICENSE
requirements.txt
setup.py
...etc.etc.
doc/
test/
examples/
...
etrago/
etrago/appl.py
etrago/nextappl.py --> these should be moved to top lvl examples if still exemplary in future
etrago/cluster/
etrago/cluster/snapshot.py
etrago/cluster/tools.py
etrago/api/ or db/ or io/
etrago/api/interfaceto.py
...

[simnh]

ok, sounds good to me

[simnh]

Ok now there is also a PyPSA fork...can anybody set it up for eGo-Usage. i.e. select the correct version and set up our dev branches etc.? Then I would add a features/snapshot-clustering branch. But I do not know on which version you want to base our development on...

Ah and the same for the eTraGo repo, by setting up the structure proposed above (inlcuding your eGo Templates for setup/requirements etc?)

[ulfmueller]

Thanks for reminding and pointing out the todos. I will structure and get to them!

[eosram]

wrt the PyPSA fork is there any naming etiquette to consider or a best practice @simnh ? From my point of view it would suffice if a dev branch maybe named openego/dev is checked out on the version aimed on, in our case its version v0.8.0.. Every feature could also reside in the openego/ namespace. Or is it considered best practice to delete all existing branches except master and start from there?

[eosram]

Giving it a second thought I now removed all feature branches from our fork, created a dev branch based on the current master branch (latest commit). The PyPSA master branch is a few commits ahead of tag v0.8.0. I guess those commits are important enough to be included right away, but not important enough to bump up the version tag for. In case we aim on tracking pypsa / syncing the repositories, we would merge the upstream master (original PyPSA) with the fork master.

[eosram]

btw ego.io and ego.powerflow on refactor/upgrade-to-pypsa-0.8 rely on a different database structure. Some columns had to be renamed in order to work with pypsa v0.8. On the oedb these changes have not been made yet. For a local copy executing this script could be sufficient. But I'm still not sure if everything works as expected : ).

[mariusves]

@s3pp @ulfmueller What about this issue? Is this still relevant?

[ulfmueller]

I think it can be closed.