[lightsim2grid] incorrect checks performed when chosing to use lightsim2grid

[BDonnot]

Hello,

TL;DR: each time you use newtonpf you can replace it with newton_ls when it can be imported. Lightsim2grid also supports other algorithms: DC and Gauss Seidel, for now and I plan on introducing the HELM at some point which might be linked to your issue #114 and BDonnot/lightsim2grid#17. The only case when lightsim2grid should not be used is when something "smarter" is happening inside the newtonpf function (such as "iwamoto" or "voltage_dependant_loads"). In all other cases, newton_ls can act as a full replacement of pandapower newton_pf.

I think the checks to use lightsim2grid or not are not correctly implemented in pandapower (I refer to the function _check_lightsim2grid_compatibility in auxilliary.py fine)

Currently it is:

def _check_lightsim2grid_compatibility(net, lightsim2grid, voltage_dependend_loads, algorithm, enforce_q_lims):
    if lightsim2grid:
        if not lightsim2grid_available:  # check 1
            return _deactive("option 'lightsim2grid' is True activates but module cannot be imported. "
                             "I'll deactive lightsim2grid.")
        if algorithm != 'nr':  # check 2
            raise ValueError("option 'lightsim2grid' is True activates but algorithm is not 'nr'.")
        if voltage_dependend_loads:  # check 3
            return _deactive("option 'lightsim2grid' is True but voltage dependend loads are in your grid."
                             "I'll deactive lightsim2grid.")
        if enforce_q_lims:  # check 4
            return _deactive("option 'lightsim2grid' is True and enforce_q_lims is True. This is not supported."
                             "I'll deactive lightsim2grid.")
        if len(net.ext_grid) > 1:  # check 5
            return _deactive("option 'lightsim2grid' is True and multiple ext_grids are in the grid."
                             "I'll deactive lightsim2grid.")
        if np.any(net.gen.bus.isin(net.ext_grid.bus)):  # check 6
            return _deactive("option 'lightsim2grid' is True and gens are at slack buses."
                             "I'll deactive lightsim2grid.")

I think the is a confusion between what lightsim2grid does itself, and what the "newtonpf" function of lightsim2grid does.

The lightsim2grid newtonpf function is an implementation of a NR solver, so basically the netwonpf function of pandapower that does not support voltage dependants loads.

So basically:

• # check 1 valid: You CANNOT use lightsim2grid in such case, of course
• # check 2 => not valid: lightsim2grid can do dc approximation and Gauss Seidel, but the "newtonpf" function of lightsim2grid cannot (let me know if you want equivalent function, it's rather easy to do!). You would just need to use another function of lightsim2grid, for example "from lightsim2grid.solver import dc_pf" and / or "from lightsim2grid.solver import gauss_seidel_pf". You could use lightsim2grid in this case, but not (of course) its newtonpf function.
• #check 3 valid: in pandapower, voltage_dependend_loads are handled inside the newtonpf function, lightsim2grid does not do it, so indeed, lightsim2grid will not work in these cases. You CANNOT use lightsim2grid in such case.
• # check 4=> not valid: the way you enforce the q_limits in pandapower is to loop and perform successive calls to the newtonpf function, in this case using the lightsim2grid equivalent is perfectly fine. You CAN use lightsim2grid newtonpf function in this case.
• # check 5 -> super weird behaviour of pandapower in this case. In this case the "distributed_slack" option should be set, see issue Inconsistent behaviour when multiple slacks on the grid (but you don't specify distributed_slack=True in the runpp function #1399 (and also maybe Maybe some issues with distributed slack Newton Raphson #1408) . And by the way, distributed slack buses are now available (since today :-) ) in lightsim2grid. The interface to use them follows the pandapower signature (cf some docs here https://lightsim2grid.readthedocs.io/en/latest/use_solver.html ). You CAN use lightsim2grid newtonpf function in this case (and I may even argue: you should use it in this case)
• # check 6 -> not valid: actually it's even the exact opposite. In lightsim2grid, only the generators are considered as slack buses. There is no concept of "ext_grid" in lightsim2grid. And by the way, this is not relevant when using the newtonpf function, ext_grid and generators with slack bus are handled before that when defining the pv , pq and ref index vectors (used in newtonpf). You CAN use lightsim2grid newtonpf function in this case.

On an external topic, with lightsim2grid, I can also perfectly reproduce the current behaviour of pandapower regarding "distributed_slack" argument. I could force to use an algorithm only valid (I believe) for "single slack" even when there is a distributed slack (as it seems to be the case for pandapower at the moment, when there are different slack and the option dist_slack is not set to True)

[rbolgaryn]

Dear @BDonnot ,

thank you for such a detailed issue!

It seems like you are currently actively engaged with combining pandapower and lightsim2grid.
Would you be interested in having an online meeting?

Best regards,
Roman

[BDonnot]

Hello,

Yes sure let's schedule such a meeting by mail (would be easier I think :-) )

I was trying recently to get "lightsim2grid" more usable yes (so improved the doc etc.) and this includes making better integration between lightsim2grid and pandapower. This is why I put "a lot" of issues in pandapower recently.

Best

Benjamin

[rbolgaryn]

Please write me an E-mail