SenseFlow: A Physics-Informed and Self-Ensembling Iterative Framework for Power Flow Estimation

Major:

• “With the recent expansion of power networks in scale and complexity, particularly with the integration of renewable energy sources, these conventional methods fail to provide timely and accurate solutions” lacks a proper reference to support this claim.

• Key Reference Missing: The paper omits an important comparison with Donon et al.'s work on "Neural networks for power flow: Graph neural solver." This reference should be incorporated, along with a comparative analysis, to position SenseFlow more effectively within the field.

• The 'Related Work' section at the end of the paper should appear in the introduction, as at the end of the paper, it makes it difficult to understand the novelty and unique contributions of the proposed approach.

• It is only in section 2.2 that it becomes clear that the aim is to solve the AC power flow equations; this critical point should be addressed earlier in the paper.

• The paper only compares GNN models without providing key details such as hyperparameters or specifying the loss function used in the experiments.

• There is a lack of comparison with traditional power flow methods like Newton-Raphson and Gauss-Seidel, which could provide valuable context for evaluating the model's performance. • The paper does not include a section dedicated to discussing its limitations.

Minor: • The manuscript exceeds the recommended length of 9 pages.

• Several typos are present, such as ‘physic’ instead of ‘physics’, extra brackets in section 2.1 when listing variables, and mistakes like ‘giving’ instead of ‘given’ and unclear formatting in section 3.4 (loop ¿).

• The term ‘pure student’ in Figure 4 should be clarified in the figure caption to avoid confusion.

• The authors mentioned "This makes power flow estimation not only essential but also highly frequent in operational contexts", but did not clearly show the requirements. What's the timing and accuracy requirements for such estimation? Without such information, it's hard to assess if the proposed solution is practical. The iterative approach may help with the prediction accuracy but could increase the inference time compared to traditional or end-to-end methods. A discussion of the timing and accuracy requirement as well as a discussion of the computation overhead of the proposed solution may be needed.
• What's the convergence properties and criterion for SeIter?
• The design decisions, while seemingly reasonable, appear to lack some comparison and justification with alternative designs. Could you use other global information sharing mechanism? Any other ways to incorporate slack node influence? Why EMA for self-ensembling?

The paper doesn’t appear to compare performance to classical solution methodologies, stress test the methodology in scenarios where the classical solution nonlinearly diverges due to fractal solution basin, or scale to problem sizes incompatible with classical solution methodologies. Once in the basin of convergence, the iterative methods have characterized convergence properties. It is not clear this is the case with this method as it is not shown how hard the randomized test conditions and small topology changes without demonstrating failure with classical methods. The classical methods also seem quite old. Slow convergence of local iterative solvers has been a known issue for a long time which has spurred development of scalable solver technologies. Compared to such work as in more recent algebraic multigrid solution methods as in “Nonlinear Algebraic Multigrid for the Power Flow Equations”, LLNL-JRNL-717563 (2017) running up to 2,383 node networks. The fact that Fig 4(a) is a linear-linear convergence plot rather than semilog as in Fig.1 of that reference highlights that there isn’t a good apples-apples comparison vs. traditional solution methodologies. However, the multigrid solver shows 1e-6 residuals in 16 iterations with the IEEE 300-Bus Network which does not inspire confidence that the comparison includes SoA classical methods for reference. Comparing FLOPs or wall clock of a modern classical solver vs. iterating with a 21.844M parameter network would also be important. Further, comparing scaling into large networks with O(n)/iteration computational cost with n^.3 nonlinear iteration growth is a critical component since a 300 node network does not represent a particular challenge for modern scalable classical solvers.

While I do not have high familiarity with the other referenced NN-based solution methodologies, the sheear number of assorted graph/convolutional NN approaches to this powerflow problem suggest that methods like algebraic multigrid do not perform well by comparison. The test cases chosen just do not provide a compelling case that the proposed methodology overcomes the perceived challenges of very old classical solution methods. This problem seems to be exactly the type of problem such scalable methods were designed to overcome and they show nothing like scaling to 2^14 or node network sizes or beyond, and so it’s just not clear this method would even successfully scale up and train for realistic problem sizes of the type indicated as the problem motivation.

I cannot find some convincing statement or description of how the SensFlow can handle the limitations of existing methods for solving power flow problems, which I detailed in the questions section below.

I could not find the detailed settings and parameters of their framework for the case studies, such as how many layers of VNA and SGF they have, how long does the training take, etc.