Open rbolgaryn opened 7 months ago
Hello,
Yes of course I can remove them. I added them mainly for my personal convenience (basically to remember to install grid2op in all my venv) but I totally understand that it's a problem for you so i'll remove them in next release (hopefully next week)
we are adding lightsim2grid as a required dependency of pandapower in all future versions
Great :-) I am really honoured.
Also, be aware that if you do that for all systems, then some people might not be able to use pandapower on some machine.
For example I think people on recent MacOS (using M1 or M2 chips) encounter some issues with lightsim2grid (see eg #59 or #55 I think I solve this issue but I cannot test it without a macos machine with one of these chips - which i don't have)
Less critically maybe, lightsim2grid (for now) is released only for 64bits system for both linux and windows. It would require a bit of work in the CI to make the release for 32bits linux or arm64 (linux) but for x86 windows and / or arm64 windows (not even sure if that's a thing) it might require a bit more work.
TL;DR: lightsim2grid wheels are provided for python >= 3.7 for windows x64, linux 64 bits and macos 64 bits. Everything "arm64" (linux, macos or windows) or 32 bits (eg x86 on windows) will require an installation of lightsim2grid from source (I don't see why it would not work but that requires a working c++ compiler for exampler).
Benjamin
Also if you want to include some tests for some versions of pandapower in lightsim2grid (for example checking that some function of lightsim2grid you rely on works properly on a given pandapower version) feel free to let me know.
Absolutely no problem for me to include this kind of "non regression testing" (and honestly the more the better)
Thank you @BDonnot!
I have access to an M1 machine so I could try and see what happens.
Also, we have started looking into all the warnings that are triggered in the test pipeline, and found one in lightsime2grid that would be an easy fix (and I think a reasonable change):
Basically, replacing the ~ by not.
edit (BDonnot): done in version 0.8.2
OK so we will include lightsim2grid as an optional dependency in the list "performance" and it will be installed when one installs pandapower with pip install -e .[all] or pip install pandapower[all]
I will update the documentation ti recommend to install pandapower[all]
Hi
I have access to an M1 machine so I could try and see what happens.
If you have access to a M1 machine, maybe you can try to run the following commands (inside a virtual environment for example):
pip install ligthsim2grid
python -c "import lightsim2grid"
python -c "from lightsim2grid import *"
python -c "from lightsim2grid.newtonpf import newtonpf"
Then inside the same venv (or another, does not really change anything:
pip install grid2op
python -c "from lightsim2grid import LightSimBackend"
python -c "from lightsim2grid import LightSimBackend; import grid2op; env = grid2op.make('l2rpn_case14_sandbox', test=True, backend=LightSimBackend())"
And let me know if you encounter some issues with it please :)
Basically, replacing the ~ by not.
Will do it ASAP :-)
I should have done it a long time ago but I don't really look at the warnings, thanks for spotting it.
OK so we will include lightsim2grid as an optional dependency in the list "performance" and it will be installed when one installs pandapower with pip install -e .[all] or pip install pandapower[all]
I will update the documentation ti recommend to install pandapower[all]
I think it's better this way. It would be weird that you have to deal with people wanting to use pandapower on eg windows arm but cannot because of lightsim2grid.
Also, I think you wrote some issues quite some time ago like #49 for example. Would you want that lightsim2grid offers some more flexibility directly on the solver side (so you can call for example TimeSeries
or ContingencyAnalysis
directly on the solver and skipping the GridModel
interface. I'm asking this because I think you said that you prefer to deal with the construction of the Ybus and Sbus in pandapower rather than in lightsim2grid (which is fair considering that pandapower is much more flexible and models more elements)
Hi @BDonnot ,
I would like to be able to use functions from lightsim2grid directly, maybe even including the possibility to construct Ybus, Yf, Yt with functions from lightsim2grid.
Right now we are using also functions from contingency analysis module in pandapower.contingency:
def run_contingency_ls2g(net, nminus1_cases, contingency_evaluation_function=pp.runpp, **kwargs):
...
lightsim_grid_model = init_ls2g(net)
solver_type = SolverType.KLU if KLU_solver_available else SolverType.SparseLU
...
s = ContingencyAnalysisCPP(lightsim_grid_model)
s.change_solver(solver_type)
...
v_init = net._ppc["internal"]["V"]
s.compute(v_init, net._options["max_iteration"], net._options["tolerance_mva"])
v_res = s.get_voltages()
s.compute_flows()
kamps_all = s.get_flows()
...
This is a very fast way for contingency analysis with pandapower, much much faster than with the other (Python-only) function
We use this function in a timeseries simulation to obtain max/min voltage per bus and max. loading per line for every time step - we substitute the contringency function for the pp.runpp function with the "run" parameter in pp.timeseries.run_timeseries
The snippet above will be perfectly correct as long as the call to
lightsim_grid_model = init_ls2g(net)
is valid, which is equivalent to say that every element in pandapower should be modeled in lightsim2grid (it will not work for example if there are 3w trafos)
What I had in mind (that might interest you) is a call like this:
def run_contingency_ls2g_fromybus(ybus, sbus, slacks_id, slack_weights, pv, pq, delta_ybus, contingency_evaluation_function=pp.runpp, **kwargs):
...
solver_type = SolverType.KLU if KLU_solver_available else SolverType.SparseLU
...
s = SomethingThatDoesNotCurrentlyExistsInLightsim()
s.change_solver(solver_type)
# ybus is computed from lightsim2grid
# delta_ybus is the ybus modification after some contingencies.
# We want for example ybus_post_contingency_k = ybus + delta_ybus[k]
v_init = net._ppc["internal"]["V"]
max_iteration = int(net._options["max_iteration"])
tolerance_mva = float(net._options["tolerance_mva"])
# init the solver
v_ref = s.solve(Ybus, 1. * v_init, Sbus, slacks_ids, slack_weights, pv, pq, max_iteration, tolerance_mva)
# v_ref should match v_init hopefully
# run the contingencies
res_v = np.zeros((len(delta_ybus), v_ref.shape[0]))
for cont_id, delta in enumerate(delta_ybus):
res_v[cont_id, :] = s.solve(Ybus + delta, 1. * v_init, Sbus, slacks_ids, slack_weights, pv, pq, max_iteration, tolerance_mva)
# convert back the resulting (complex) voltages to whatever you want
back to pandapower to process the voltages
This way (but i'm not sure if this is a real need for you or not) you skip the "transformation" to lightsim2grid GridModel which models only a small part of pandapower (no switches, no 3w trafos, etc.)
I could also do the loop for cont_id, delta in ....
in cpp directly and also include some modification of Sbus too (for time series with contingency analysis)
right now we need to make sure that the grid model is "lightsim2grid-ready" but using the Ybus directly would enable using any pandapower grid.
At the moment I think it is less attractive than e.g. running timeseries analysis in lightsim2grid (with/without contingency).
It would be interesting to also have a possibility to change transformer taps like in pandapower with the "recycle" configuration.
Also, a different topic, it would be interesting to have temperature model for power lines and the implementation of a hybrid AC/DC power flow with multi-terminal HVDC and VSC converters (finalizing this for pandapower at the moment).
At the moment I think it is less attractive than e.g. running timeseries analysis in lightsim2grid (with/without contingency).
Ok no problem, let me know if it's an important needs :)
It would be interesting to also have a possibility to change transformer taps like in pandapower with the "recycle" configuration.
Sounds doable already (cpp side) but i'm not sure python side. I'll try to make these available python side too. Can you write a github issue for that specifically, with the desired interface python side ?
Also, a different topic, it would be interesting to have temperature model for power lines and the implementation of a hybrid AC/DC power flow with multi-terminal HVDC and VSC converters (finalizing this for pandapower at the moment).
As long as I can have a clear view of:
This should be doable :-) But probably not in next release unfortunately.
For now in lightsim2grid I model HVDC by "linking together" two generators, which is not perfect so any better model would be good.
I remove the "bug" label because the original issue has been fixed (you should be able to install lightsim2grid without grid2op and without warning)
I keep this one open because we also talked about other ligthsim2grid features
LightSimBackend import error: No module named 'grid2op' PhysicalLawChecker import error: No module named 'grid2op' TimeSerie import error: cannot import name 'TimeSerie' from 'lightsim2grid.timeSerie' (C:\Users\xxxxxx\Documents\repositories\pandapower\venv-tutorial-test\Lib\site-packages\lightsim2grid\timeSerie.py) ContingencyAnalysis import error: cannot import name 'ContingencyAnalysis' from 'lightsim2grid.contingencyAnalysis' (C:\Users\xxxxxx\Documents\repositories\pandapower\venv-tutorial-test\Lib\site-packages\lightsim2grid\contingencyAnalysis.py) rewards import error: No module named 'grid2op'
Dear @BDonnot ,
We are encountering warnings at import of pandapower when lightsim2grid is installed (we are adding lightsim2grid as a required dependency of pandapower in all future versions).
As grid2op is optional and lightsim2grid can be used as a standalone library for the power flow and contingency analysis backend of pandapower, these warnings are superfluous.
Can you please remove these warnings?
edit (BDonnot) : this has been done in version 0.8.2. I keep this post open because it speaks about other things now.