René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"QAPage","mainEntity":{"@type":"Question","name":"Performance Scalability","text":"
I have been testing the scalability of PGM vs the likes of Pandapower and PowerFactory, and from my findings PGMs performance time scales linearly as a function of the number of network nodes, as opposed to the others having a trend of n^2.
\n
Am I correct with these results, and could you explain as to why it scales like this?
","upvoteCount":1,"answerCount":1,"acceptedAnswer":{"@type":"Answer","text":"
Hi @ConnorG51 ,
\n
Thank you for your valuable input. Apologies for our late response. Apparently, there was an issue regarding notifications and we completely missed this discussion.
\n
\n
For radial grids, our algorithms scale as O(N).
\n
For meshed grids, however, our algorithms scale as O(N²), but even then, most steps scale O(N). In addition, depending on what and how you benchmark, we may cache the state, meaning that the O(N)-scaling steps usually dominate the calculations for reasonably small N. Only for extremely large amounts of nodes will the quadratic behavior come into play. I do not have exact numbers at the moment for where that transition happens, but we would be very happy if you are able to share your results with us. Inspiration may come from the benchmark done in this PR
\n
\n
I hope this answer and the more extensive one below help you continue your research. Please let me know if there's anything else we can help you with. I'm now subscribed to this discussion, so response should be much faster.
\n
Kind regards,
\n
Martijn
\n
Long answer
\n
In an attempt to give a more elaborate answer, I will break it down as much as I can. We do several optimizations to try and get the scaling as close to optimal as possible. See also performance guide for a quick overview of tips and tricks a user might use to obtain better performance without going into detail. The different types of optimizations involve the different layers of the core design.
\n
Conventions
\n
Let's call N the total amount of components, n the amount of nodes and e the amount of edges (Branch and Branch3 components) and a the amount of non-edge components that connect to nodes (Appliance) and o the amount of components that connect to other components (Sensor and Fault). Therefore, N = n + e + a + o.
\n
Note that:
\n
\n
for pretty much all practical use cases:\n
\n
e > n > 1
\n
a > 1 and a may be a > n or a <= n
\n
\n
\n
for power flow calculation:\n
\n
o >= 0
\n
\n
\n
for state estimation:\n
\n
o >= n (see the comment on observability)
\n
\n
\n
for short circuit calculation:\n
\n
o >= 1
\n
\n
\n
\n
Breakdown
\n
Interfacing
\n
\n
input step is O(n + e + a + o) on average
\n
update step is O(N_{update}) on average\n
\n
Depending on the data, in some batch cases, it can be reduced to one single call for the entire batch instead of for every scenario.
\n
\n
\n
output step is O(N)
\n
\n
Topology
\n
Topology step containing graph optimization depends heavily on the type of network:
\n
\n
Depth-first search: O(n + E)
\n
If the graph contains cycles containing at least 4 edges: minimum degree ordering is O(n e + e²/n)\n
\n
this can become an expensive step
\n
We are working on some improvements, see also PowerGridModel/power-grid-model#433 and its follow-ups
\n
\n
\n
Reorganization of components: O(N)
\n
\n
Ybus construction
\n
O(N)
\n
\n
Some steps are skipped when updating if the topology doesn't change
\n
\n
Solving
\n
This may depend on the calculation type and solver used. We assuming constant amount of iterations for iterative approaches
\n
\n
Preparing of the matrix equation: O(N) on average\n
\n
May depend on type of calculation and solver
\n
\n
\n
LU decomposition: O(e²/n)\n
\n
We make use of the fact that the data is expected to be extremely sparse
\n
It relies very heavily on the reorganization of the topology step (depth-first + minimum degree) by means of 'fill-in's (see https://en.wikipedia.org/wiki/Minimum_degree_algorithm)
\n
For some solvers, this happens only once as long as the topology does not change
\n
For others may be required for every iteration (e.g. Newton-Raphson state estimation, see also its documentation)
\n
\n
\n
Solving the matrix equation: O(e)
\n
\n
Summary/conclusion
\n
Overall, depending on what your data looks like, which solver you use and whether you benchmark batches or clean runs from scratch, your scaling may be:
\n
\n
O(n e) if you take the construction of the model into account (meshed grids)\n
\n
(near-)radial grids are significantly faster and may run in O(n + e)
\n
Although the complexity will remain the same, hopefully, the construction will become even faster in the future
\n
\n
\n
O(e² / n) if you do not take the construction into account
\n
O(n + e) if you choose a fast solver (e.g. linear power flow), do not update topology, do a single calculation first and then benchmark only runs of the power grid model after that. This allows some type of \"precalculation\"
\n
For radial grids, the overall performance is O(n + e + e²/n) = O(N)
\n
For meshed grids, the overall performance is O(n e) = O(N²)
\n
","upvoteCount":1,"url":"https://github.com/orgs/PowerGridModel/discussions/24#discussioncomment-8744444"}}}