Potential shunt ordering bug in canos_pf.py and pf_losses_utils.py

[jxnscott]

Hi — I noticed a potential inconsistency in how PFDelta bus shunts are stored vs later converted into complex values.

In core/datasets/pfdelta_dataset.py, bus shunts are aggregated and stored as [gs, bs]:

• pfdelta_dataset.py:422-427
• pfdelta_dataset.py:608

Several PF-side equations then also assume that ordering:

• pf_losses_utils.py:57-58:
  • shunt_g = data["bus"].shunt[:, 0]
  • shunt_b = data["bus"].shunt[:, 1]
• pf_losses_utils.py:221-222:
  • delta_P = ... - V^2 * shunt_g
  • delta_Q = ... + V^2 * shunt_b

However, these two spots reconstruct the complex shunt term as bus_shunts[:, 1] + 1j * bus_shunts[:, 0]:

• core/models/canos_pf.py:269-271
• core/utils/pf_losses_utils.py:611-613

with the comment # (b_shunt + j*g_shunt).

If data["bus"].shunt is indeed [gs, bs], this looks swapped relative to the rest of the codebase and to the usual admittance convention Y = G + jB.

At minimum, it seems inconsistent with the PFDelta dataset ordering and the other PF-side uses of data["bus"].shunt. I would expect something closer to either:

• gs + 1j*bs if this is meant to be an admittance, or
• gs - 1j*bs if this is meant to be the shunt complex power contribution in the power balance.

Was the current bs + 1j*gs form intentional?

[AlvaroC-ML]

Hi! Thank you so much for notifying us about this, and sorry for taking some time to get back to you. We have looked into this, and you are correct. This is indeed a bug. We have fixed it, and we have verified that the new version is correct. We suspect that this should have a minor impact on CANOS, but just in case, we're rerunning the original hyperparameter tunning to verify this and we will update results in the paper accordingly.