What is HELM™-Flow and what other products does it compare to?
What is the HELM™ method?
You seem to imply that iterative power-flows are unreliable?
OK I get it; the HELM™ method is deterministic, not iterative. Is that all?
Could you briefly enumerate the functionalities of HELM™-Flow?
So what are the main selling points of HELM™-Flow?
What platforms is it available for?
What is the required and recommended hardware to run it?
What are the technical limitations on network size?
What capability does HELM-Flow have for representing data graphically?
Does HELM™-Flow do dynamic stability analysis?

What is HELM™-Flow and what other products does it compare to?

HELM™-Flow is an advanced power-flow simulation and analysis tool for system planners and analysts, featuring a breakthrough algorithm. On the surface, it compares to products such as Siemen’s PSS®/E and GE’s PSLF®. However it does not, as it can be used as part of a workflow along with those tools. HELM™-Flow is heavily focused on the new powerful analytical capabilities of the HELM™ power-flow method, which are unique.

What is the HELM™ method?

It is a wholly new power-flow method built on a radically different approach to the problem. It uses advanced concepts from Complex Analysis (such as algebraic curves and Padé approximants). You can learn more about it on the Wikipedia page. But in practical terms, the benefit is that it is a reliable method, that can run unattendedly: it finds the correct solution  (i.e. the most desirable operating point) when the case is feasible, and unambiguously signals “no solution” when it the case is unfeasible (voltage collapse). In other words, it always provides unequivocal results. It does away with the inherent problems of convergence in iterative algorithms.

You seem to imply that iterative power-flows are unreliable?

To a certain extent, they are. Newton-Raphson, Fast-Decoupled, Gauss-Seidel, and any other variant of these power-flow methods use numerical iteration as a way to arrive at the solution. The fact is that there is no mathematical guarantee that the iteration will converge, in general. This is highly dependent on the choice of the initial seed. Moreover, if there are several possible solutions, there is little control over the one that will be selected among them. Proximity of the initial “seed” to the desired solution increases the likelihood of converging to it, but there is never a 100% guarantee that the iterations will actually do so (the basins of attraction are fractal).

OK I get it; the HELM™ method is deterministic, not iterative. Is that all?

A reliable power-flow method is a big breakthrough in itself, as it removes many uncertainties when you’re trying to solve difficult cases that “do not converge” in other tools. In the context of real-time EMS network analytics, this enables a whole new array of intelligent applications that would otherwise be impossible to build. However, that is not all. The same new mathematical approach that produced the HELMTM method has also uncovered new analytical tools with very practical applications. The Sigma indicators are one of them: the Sigma plot and Sigma Discriminant plot offer unprecedented power for instant, visual analysis and diagnostics.

Could you briefly enumerate the functionalities of HELM™-Flow?

It contains steady-state power flow of grid models of virtually any size (only limited by the amount of RAM), extensive analysis features offered through a modern Java-based GUI, powerful graphing capabilities oriented towards analysis and diagnostics, P-V/Q-V curves, scripting, and interoperability with PSS®/E and PSLF® formats. A very unique feature is the availability of Sigma Plots (see below for specific related questions). Upcoming versions of the product will offer modules for contingency analysis and short-circuit analysis.

So what are the main selling points of HELM™-Flow?

Well, if we had to pick just one, consider this: remember those times when you were preparing a case in which you had done some changes that turned the case unsolvable under your usual tool? Remember the time you had to spend experimenting with things until you got it to converge again? Well, HELM™-Flow is the tool to use!. You can import your case in HELM™-Flow and you can obtain reliable and clear results. HELM™-Flow will give you the (most desirable) solution if the case is solvable, and it will also tell you that there’s no solution if it’s not solvable (we don’t use the word “converge” because there’s no iteration here!). If there is no solution, HELM™-Flow will also help you to quickly understand why, because it can compute where other tools cannot, and therefore identify the plausible causes. Once you solve your case in HELM™, you can export it back in the same format your current tool uses.

What platforms is it available for?

At the moment HELM™-Flow is available as a Windows application for either 32-bit or 64-bit versions of the operating system. The 64-bit version is highly recommended since it is not limited by the 2GB RAM ceiling of 32-bit Windows. Versions for Linux and MacOSX systems are planned for the near future.

What is the required and recommended hardware to run it?

The 32-bit version requires at least 2GB of RAM, but 3GB or more is recommended (although the operating system will not let you use more than 4GB), so as to max out the 2GB-per-process limit for 32-bit Windows applications. The 64-bit version requires 4GB of RAM, and we recommend 8GB or more if you plan to work with large (20,000 buses) cases.

What are the technical limitations on network size?

HELM™-Flow can run power-flows on networks of virtually any size, provided you have enough RAM in the system.

What capability does HELM-Flow have for representing data graphically?

HELM™-Flow has powerful graphical capabilities oriented towards analysis and diagnosis of insoluble cases, among which we can mention: easy-to-use network and overview diagrams, featuring color coding for several electrical magnitudes of interest; one-line bus diagrams; grid model and solution charts; user-defined charts; HELM’s unique Sigma plot; and many other diagnostic charts.

Does HELM™-Flow do dynamic stability analysis?

The current version of HELM™-Flow does not have this feature, but it is on the roadmap of the product.

Isn’t the HELM™ method just like starting always from the “flat profile”?
Is the HELM™-Flow method not numerical then?
How do you specify the precision sought in the solution?
How does the method handle zero and very low impedance branches?
What advanced FACT devices are modeled in HELM™-Flow?
What are the Q-HELM and PQ-HELM tools? How do I use them?
My case does not solve under Q-HELM. What are the causes?
So if my case solves under Q-HELM but not under PQ-HELM or Full-HELM, what are the causes?
So if my case solves under Q-HELM and PQ-HELM, but not under Full-HELM, what are the causes?
How does the HELM™ method contemplate controls?
Do Q-HELM or PQ-HELM remove or deactivate the controls?
Can HELM™-Flow recommend locations and amounts of reactive support necessary to solve a collapsed case?

Isn’t the HELM™ method just like starting always from the “flat profile”?

No, that sort of thinking is misleading, since the method is not iterative. HELM™-Flow is a constructive method, therefore you do not need to specify any voltage profile as the initial “seed”. You might have been led to think this way due to the way the method selects the power flow solution out of the multiple possible ones, but the method is truly different. Also, remember that an iterative method may be started from a flat profile and still converge to a non-operating (i.e. low-voltage) solution, or even diverge.

Is the HELM™-Flow method not numerical then?

It is numerical, but not of the iterative kind. It is a constructive numerical method, much in the same way as the algorithms that compute the sine and cosine functions in your calculator, always guaranteed to give the correct solution. In contrast, iterative methods are not always guaranteed to give you the correct answer, or any answer at all.

How do you specify the precision sought in the solution?

Since the method is based on constructing the complex power series representing the (embedded) voltages, you specify the desired precision via two configuration parameters: one, the precision goal in the summation of the power series (“Tolerance for A.C. approximants”); the other, the maximum number of terms to compute for the power series (“Max order for power series”). The method stops whenever one of these two criteria is reached. As a post-calculation check, flow balances are calculated and the user should specify two additional parameters in order to accept or reject the solution: the maximum flow balance mismatch (“Max mismatch in node”), and a percentage of buses in which you allow the solution to violate such mismatch threshold (“Max % of nodes violating mismatch”).

How does the method handle zero and very low impedance branches?

The method deals with this problem in a way that is completely analogous to the technique used in most iterative power flows: buses joined by branches whose impedance is lower than a user-specified “Jumper Threshold” value will be merged prior to the power flow computation. After the solution is obtained, the merging is undone and the flows across those branches are calculated according to topological principles.

What advanced FACT devices are modeled in HELM™-Flow?

As of the current v2 version, only HVDC devices are modeled. Other FACT devices such as SVC, STATCOM, SSSC, etc. are scheduled to appear in forthcoming releases.

What are the Q-HELM and PQ-HELM tools? How do I use them?

These are two variants of the usual power flow problem, specifically designed for diagnostic purposes for those “difficult to solve” cases. PQ-HELM solves the case by switching all resistances in lines and transformers to zero, thereby solving the parallel problem of a hypothetical lossless grid. Q-HELM goes one step further by turning off all active power flows and angle differences, so that all injections (load/generation) and flows consist of just reactive power. These two HELM™-based tools are meant to be used incrementally: you need your case to be solvable under Q-HELM first, and then go on to PQ-HELM, before you attempt to solve it under the full HELM™ power flow. In the process, you will quickly gain many insights about your case.

My case does not solve under Q-HELM. What are the causes?

A case where even Q-HELM does not solve has a serious structural problem. It means that the reactive flows, which constitute the backbone of the power flow, are not feasible. Excessive reactive power demands cannot be satisfied for two possible reasons: either because generators and/or other reactive resources are maxed out, or because the transmission grid is loaded past the point of collapse. In this latter case one should first look for anomalously high values of the impedance in lines or transformers. If this was not the problem, then one should address the root causes of the excessive reactive demand. Barring errors in loads or in shunt impedances, the most likely culprits are wrongly configured controls: a wrong value for a set-point, or a mistake in the remote bus identifier can easily generate unfeasible reactive flows.

So if my case solves under Q-HELM but not under PQ-HELM or Full-HELM, what are the causes?

If the case solves under Q-HELM it means that the underlying “backbone” of the grid, the reactive flows, are feasible (you absolutely need this before being able to go on). If PQ-HELM does not solve, it means that the active power flows are unfeasible, even if the network were perfectly lossless. You need to inspect the load and generation profiles and get help from the Sigma Plot, to find out what buses are involved in the collapsed state. If the problem is not very local, scaling injections with the active power slider will also help you to get a quick feeling as to the magnitude of the load/gen excess in the system.

So if my case solves under Q-HELM and PQ-HELM, but not under Full-HELM, what are the causes?

It could be either that the system is very stressed, so that turning the resistances on (therefore losses) pushes the system over the brink of collapse; or that the grid has some anomalously high value of R somewhere on a line or transformer.

How does the HELM™ method contemplate controls?

HELM™ solves PV controls (both local and remote), ULTC controls, switched shunt controls, phase-angle regulation (phase-shifter) controls, and inter-area exchange controls. HELM™ uses a two-layered approach to deal with controls. The first layer is purely algebraic and it’s therefore fully integrated in HELM™ internals. It solves the problem without taking into account any hard limits on the control resources. A second layer then enforces those hard limits. Since this second problem does not generally have a unique solution, HELM-Flow solves it by applying a minimization principle. This minimization is based on a Lagrangian formulation of the power-flow problem, which is approximate in the general case but becomes exact in the PQ-HELM and Q-HELM limit cases. The minimization arrives at the configuration having the least amount of reactive power losses on the network. The current implementation uses efficient heuristics to mitigate the combinatorial explosion problem and to reduce the number of “bounces” (i.e. controls that were previously maxed out and that, later on during the search, need to be backed-off from their limits).

Do Q-HELM or PQ-HELM remove or deactivate the controls?

No, these two variants of the power flow enforce the same controls as the full HELM™ algorithm, whenever it makes sense to do so. For instance, Q-HELM retains all voltage controls, but not phase-angle regulation or inter-area exchanges because they do not make sense in that context.

Can HELM™-Flow recommend locations and amounts of reactive support necessary to solve a collapsed case?

One can extract this information from HELMTM-Flow solutions in an indirect way. HELM™-Flow provides three types of solutions: (1) Solved, (2) No Solution, and (3) No Solution-Relaxed Solution provided. This last case appears when the case is strictly unfeasible, but it would be made feasible if only some controls were allowed to violate their respective limits.

Furthermore, in such cases HELM™-Flow provides the violated control limits and the bus mismatches at the buses where the relaxed solution needed to inject additional reactive power. From this indication, one can easily infer the location and amount of reactive support needed to get a feasible case.

What does the Sigma Plot mean and how do I interpret it?
OK, so my case does not solve and I’ve got many points out of the parabola: What can I do now?
How do I measure the distance of a node to the parabola in the Sigma Plot?
Is there a way to short-list the worst nodes of the Sigma Discriminant plot?

What does the Sigma Plot mean and how do I interpret it?

The Sigma Plot displays the values of the Sigma indicators, a complex-valued dimensionless magnitude that represents the state of each node in a given solution (or non-solution!). The rules are simple: if all nodes are lying inside the parabola, there is a solution; if one or more happen to lie outside the parabola, there is no solution (the system is collapsed). The distance of the points to the parabola cannot be used literally as a measure of the distance to voltage collapse, but the visual patterns formed by the dots have been proven to be a useful diagnostic tool. The most salient characteristic is that the Sigma values are well defined even when there is no solution, so that they offer a diagnostic where other tools just can’t. The “outlier” nodes will give a quick clue as to where to look for the reasons why the case is not solving. You need to be aware of one detail, though: the plot only shows points corresponding to electrical nodes, not buses. Some buses may have become reduced prior to the actual power flow (either through the Jumper Threshold treatment, or some other network-reduction mechanisms, such as Kron’s reduction), and therefore they will not appear explicitly in the plot.

OK, so my case does not solve and I’ve got many points out of the parabola: What can I do  now?

There is no general recipe, but the Sigma Plot will offer many quick clues. Sometimes the collapse is due to problems that are highly local; in that case the Sigma Plot will reveal those nodes as clear outliers. However, sometimes the causes may be more global, and then the troublesome points will appear more evenly spread out. In that case you may need to start a systematic approach by working your way up from Q-HELM to PQ-HELM, and then on to the full problem. See the questions above on the Q-HELM and PQ-HELM tools, in the section about the HELM™ method.

How do I measure the distance of a node to the parabola in the Sigma Plot?

Use the Sigma Discriminant plot: this displays a direct measure of the distance of each node to the parabola. Positive distances mean the point is inside, and negative distances mean the dot is outside the parabola. Its particular value is dimensionless and abstract, though. It’s useful to compare cases, but it does not provide the traditional notion of “distance to collapse” in terms of MW and MVAr margins. To obtain a concrete value of the margin to collapse you would still need to compute a PV curve, where you would be actually choosing a particular way in which the load and generation is varied as it approaches collapse.

Is there a way to short-list the worst nodes of the Sigma Discriminant plot?

Yes, you only need to select “Show table” from the menu that appears on the right by clicking anywhere on the plot. This will show the data points that are displayed on the plot, and you can now order them by the value of the discriminant. You can also apply any other filters provided by the application, in order to narrow down the list to your particular subset of interest.

What do you mean by operating and non-operating solution branches?
What do the strange-looking non-operational curves mean? (PV/QV curves)
How can I check if a case solved in other tools contains buses on non-operational branches?

What do you mean by operating and non-operating solution branches?

The power flow problem is multi-valued. This means that there are several mathematical solutions to the equations, but of course only one of them is the “real world” one. This is easy to see in the two-bus model, for instance. If you look at its PV nose curve, the solutions on the “upper branch” correspond to a higher voltage and lower current flow through the transmission line; while the solutions on the “lower branch” correspond to a lower voltage and a much higher current flow. Although both solutions are physically possible in the lab, power transmission grids are obviously designed to be operated on the upper branch, which we call the “operating branch”. The other solutions would have higher transmission losses. Additionally, they are expected to be dynamically unstable, because their P-V and Q-V sensitivities are reversed (there may be cases where they are made stable, but these solutions are still undesirable from the point of view of losses). What is not sufficiently recognized, however, is that iterative methods can produce solutions in which one or more buses lie on low-voltage branches! HELM™-Flow, on the other hand, is guaranteed to always give you a well-characterized solution: HELM’s solution is the maximal analytic continuation of the state given by the energized and unloaded (i.e. zero flow) network.

What do the strange-looking non-operating curves mean? (PV/QV curves)

HELM™ power flow always provides the (most desirable) operating power flow solution, but when computing P-V/Q-V curves in HELM™-Flow you have the option of showing the “non-operating” curve. To be precise, this option actually plots an approximation to the low-voltage solution branch that meets HELM’s branch at the nose point. This approximation is only exact near the nose point, and it gets worse as you move away from it. That’s why the lower curve sometimes exhibits a weird oscillating behavior. The idea here is to get a rough image of the shape of the curve near the nose point, in order to see if the lower branch is too close to the operational one, in voltage value. If this is the case (“thin” nose shapes), then you know that there’s a higher chance that iterative tools might be giving you a non-operating solution for that particular bus.

How can I check if a case solved in other tools contains buses on non-operating branches?

The recommended strategy would be to check the Q-V sensitivity in all PQ nodes in the system. A solution in a PQ node is considered high-voltage when increasing the reactive power demand at the node causes its voltage to decrease. If this sensitivity is reversed in sign, the solution is considered to be in a low-voltage, non-operating branch.

For PV nodes the case is different—you will find an explanation in the next section.

What do you mean by “PV instability”?
Then why isn’t HELM™-Flow giving me the operational solution for these “unstable” PV nodes?
So how do I detect these “unstable” PV nodes in HELM™-Flow?
So are iterative methods unable to detect “unstable” PV nodes?
Will this “instability” appear in stressed real-time models?

What do you mean by “PV instability”?

A PV node is unstable if it happens to be on the “wrong side” of its Q-V curve. This corresponds to a negative value of the dV/dQ sensibility. Since controls in power systems assume that increasing the Q injection will increase the node Voltage, a naive AVR voltage control on such a node would destabilize the system. It is therefore a non-operating solution of the power flow problem, acording to the above definitions. This is typically the result of a bad voltage setpoint V (actually, what matters is the interplay between P and V). It is not uncommon to find this in large, “stitched together” models where voltage setpoints have been heavily modified by hand. Read on the rest of the FAQs in this section to learn what to do about this problem.

Then why isn’t HELM™-Flow giving me the operating solution for these “unstable” PV nodes?

Because it is actually the mathematical formulation of the powerflow problem that is forcing the PV bus to be on the “wrong branch” in this case. As we mentioned above, HELM™-Flow will always give you the high-voltage solution, but in this case things are different: by specifying certain combinations of P and V, it is possible to force the system to be on the low-voltage branch. HELM™-Flow cannot give you the corresponding operational solution because it has a different voltage setpoint V. You can easily see this if you perform the following experiment on an unstable PV node: change its bus type to PQ, and convert the generator into a load injecting exactly the same amount of P and Q as in the previous solution, and solve again the power flow. You will see that the voltage changes to a higher value! So the proper way to solve this is to correct the value of the setpoint V (set it higher), or P (set it lower), or both, in order to operate this PV bus out of the wrong zone.
Note: bus 191 in the standard IEEE-300 test case is a good example of this effect.

So how do I detect these “unstable” PV nodes in HELM™-Flow?

One of the big advantages of HELM™ is that it can detect unstable PV nodes automatically and reliably. This optional check can be requested by checking the “PV instability analysis” option in the configuration window. This will reveal all unstable PV nodes without significantly increasing the computation time of the power flow.

So are iterative methods unable to detect “unstable” PV nodes?

By itself, an iterative power flow method cannot detect this. Moreover, if you perform the little experiment mentioned above, that is, switching the node type to PQ and then turning the generator into an equivalent load, you are likely to still obtain the same non-operational solution, because the iterative method cannot tell the difference. Therefore you would have to perform a sensitivity analysis on every node to find out the sign of dQ/dV.

Will this “instability” appear in stressed real-time models?

Not likely! Unstable PV nodes are a typical artifact of planning cases, where voltage setpoints have been modified. In a real-world network it is impossible to operate a PV node on the wrong side of its Q-V curve, as the AVR controls would make it unstable.

Does import/export preserve all non-used information in the case file?
What file formats and versions are supported?
Do the various versions of the PSS®/E format get auto-detected by HELM™-Flow?
My case converges under PSS®/E or PSLF®, but does not solve under HELM™. What are the reasons for this?
My case diverges under PSS®/E or PSLF®, but solves OK under HELM™-Flow. What are the reasons for this?
The solution under PSS®/E or PSLF® is different! Which one should I trust?
My other power flow tool can give a different solution depending on the starting point (flat-start or the previous state). So which one of these is HELM™-Flow giving me?
Can I inspect in HELM™-Flow the solution present in the imported file, without running a power flow?

Does import/export preserve all non-used information in the case file?

That’s right, HELM™-Flow will always try to preserve all the information that is present in the case file that is not actually used by HELM™, and then put it back in the file when it gets exported.

What file formats and versions are supported?

The following formats can be imported into HELM™-Flow:

• GE PSLF® (*.epc): up to version 18
• Siemens PTI PSS®/E (*.raw): versions from 24 to 33
• EUROSTAG (*.ech): version 4.5
• IEEE common format (*.cdf)

The following formats can be exported from HELM™-Flow:

• GE PSLF® (*.epc): version 18
• Siemens PTI PSS®/E (*.raw): versions 24-26, 29, and 30
• Excel (*.xls)

Do the various versions of the PSS®/E format get auto-detected by HELM™-Flow?

No, the user needs to specify the version to use when importing. However, the application does try to guess the correct version of the PSS®/E format from the contents of the file. If the version chosen by the user does not match the one guessed by HELM™-Flow, the user will be warned and prompted with a proposal to pick the correct one.

My case converges under PSS®/E or PSLF®, but does not solve under HELM™. What are the reasons for this?

The most likely reason is that you are using different configuration settings for the power flow calculation. Go to the Configuration Parameters window and start by reviewing the settings for automatic taps in ULTC transformers, phase angle regulators, and switched shunts; the enforcement of VAR limits on generators; and the enforcement of area interchanges. Make sure you do not have enabled the option “Move remote PV controls to local”. Then review the settings for the “Jumper Threshold” option: if you are comparing to either PSS®/E or PSLF®, uncheck the option “Transformers can be considered Jumpers”; additionally, in the case of PSS®/E you will need to enable the option “Jumper threshold only for reactance”. And lastly, review the requirements on the precision of the solution and the flow-balance mismatch thresholds for acceptance of the solution. Remember also that some iterative tools relax constant-power loads (turning them into constant-impedance) when the voltages drop too low, so you might want to disable this feature in those tools when comparing cases. Ultimately, do not forget that iterative methods may converge to different low-voltage solutions, particularly when the case is close to a voltage collapse point. You should use the Sigma Plot to analyze cases that are near the infeasibility limit, or just outright infeasible.

My case diverges under PSS®/E or PSLF®, but solves OK under HELM™-Flow. What are the reasons for this?

As stated above, the most likely reason is that you are using different configuration settings in both tools. Or maybe you are not finding “the right seed” in your iterative power flow, in which case this highlights one of HELM™-Flow’s most useful workflows: once you have solved a case in HELM™-Flow, you can export it back to your current tool (PSS®/E or PSLF®) and try to solve it there using HELM’s solution as the new starting seed. This way you are very likely to obtain convergence, since the seed is exactly the solution. However, please remember that iterative methods are inherently unreliable, so there is always a small chance that it will not converge either (this chance is higher as the solution approaches voltage collapse).

The solution under PSS®/E or PSLF® is different! Which one should I trust?

Again, check all your configuration settings first, as stated in the two questions above. All other things being equal, the solution you should trust is the one given by HELM™-Flow, which is mathematically guaranteed to be the high-voltage one (to be precise: the analytic continuation of the state given by the energized and unloaded network.).

A rather more subtle source of differences may arise from the treatment of control resource limits: iterative methods enforce limits by saturating and bouncing-off controls from their resource limits (as in the so-called PV—PQ bus “type-switching”), in ways that are quite different compared to what HELM™-Flow does. An iterative method results in a set of saturated controls that is just the outcome of the complex and unpredictable nature of a numerical iteration. By contrast, HELM™-Flow finds the optimal state of saturated controls by applying physics-based principles and using an OPF-like optimization approach. This produces a solution with lower reactive power losses. This provides a valid criterion for trusting which is the better solution in this case.

My other power flow tool can give a different solution depending on the starting point (flat-start or the previous state). So which one of these is HELM™-Flow giving me?

That’s right, the power flow equations have multiple physical solutions, and iterative methods may produce any of them, in a somewhat uncontrolled manner. Without information from a State Estimator, there is no way to know for sure which of those is the actual operating point of a given power system. And without detailed modeling about the system dynamics (including all controls), there is no way to tell which among all those solutions would be stable. Still, a steady-state power flow engine should strive to calculate the most likely (or at least the most desirable) operating point, in the absence of all this extra information.  HELM’s answer to this problem is to always calculate the well-characterized solution that makes most sense: HELM’s solution is the maximal analytic continuation of the reference state given by the energized and unloaded (i.e. zero flow) network.

Can I inspect in HELM™-Flow the solution present in the imported file, without running a power flow?

Yes, this can be easily done by running the option “Flows from imported solution”. This will read the voltage and angle values that came in the imported case file and compute the power flows from them. You can then inspect and analyze that solution just as any other power flow solution produced by HELM™-Flow.

How should I configure the HELM™ power flow? Is it difficult?

HELM™ power flow is quite easy to configure, really. Most options should be familiar to anybody who has run other power flow tools. For instance, all the options for enabling or disabling controls are quite standard (with the exception of an option for moving remote PV controls to the local bus). The Jumper Threshold functionality is a bit more flexible and has more options in order to behave closer to other tools. The option “Maximum expansions” is quite HELM-specific, but it just allows the user to set an exiting parameter for the A*, in order to limit the computation time (this is in the context of the enforcement of limits). Lastly, the options for controlling the desired level of precision are discussed in the question above, “How do you specify the precision sought in the solution?”

When should I try to change the defaults?

You should mainly consider changing the options for enabling/disabling controls, and the options for the Jumper Threshold. The rest of the options have default values that are valid for the vast majority of cases.

How do I choose the units to show?

This can be easily configured for the whole application if you open the GUI configuration options and go to the tab “Units”. You can independently configure your preferred units for voltages, angles, active power, reactive power, apparent power, flow balance mismatch power, line rate power, and line current.

Other functionalities: load/gen scaling

Does HELM™-Flow have facilities for load and generation scaling?

Yes, HELM™-Flow provides two different ways to scale load and generation. One is the more traditional one, available from the menu Edit ? Load Scaling, in which all load across one or more areas, zones, or owners can be scaled up/down while the generators across one or more areas, zones, or owners (possibly different from the ones chosen for loads) can make up for the needed power. This option performs a realistic scaling, taking into account possible resource limits. The other option is non-conventional and it is really intended for diagnostic purposes only: active power injections (for both load and generation) may be globally modulated via a configuration slider that goes from 0% to 200%. This option does not observe limits on active power in generators, though.

Is there a way to scale load and generation independently?

The current version (v2.2.*) allows scaling loads globally across designated Areas, Zones, or Owners (varying either just P, or PQ with a fixed power factor). Independently of the loads, the user may choose compensating generation to be provided by any other designated Areas, Zones, or Owners. Upcoming versions will allow finer-grained control over the way load and generation can be scaled, as well as incorporate a governor-power-flow mode (a.k.a. distributed slack). Of course, the way to achieve the ultimate, finest degree of control is through Scripting.

Does HELM™-Flow have a governor power-flow?

The current version v2 does not implement this yet. Upcoming versions will soon implement a fully featured governor-response power-flow.

What do the “global scaling” sliders do?

As mentioned above when discussing load scaling, these sliders are meant for quick diagnostics only. They modulate values globally, for the entire network. The slider for Resistance will modulate the resistance values for lines and transformers, thus providing a way to continuously go from the full case to the PQ-HELM™ limit (pleaseHow do I perform a Contingency Analysis? refer to the questions above on the PQ-HELM and Q-HELM tools). In the same vein, the sliders for active power injection and swing/phase-shifter angles provide a way to continuously approach the Q-HELM limit (this limit is achieved when all angles and all active power injections are zero). It is useful to think of these sliders as “mathematical” in nature, since the scaling they perform does not observe possible resource limits. For instance, you may surpass active power generation limits. To prevent mistakes when using these diagnostic tools, the changes do not get saved to the case model; you would have to use the normal load-scaling facility for that.

Other functionalities: P-V / Q-V curves

Does HELM™-Flow compute P-V and Q-V curves?

Yes, HELM™-Flow computes P-V and Q-V curves, using also the HELM™ power flow method. The results are guaranteed to be accurate even when getting very close to voltage collapse points. Additionally, the HELM™ methodology allows the study of the nose section of P-V or Q-V curves (i.e., the very vicinity of voltage collapse) with higher performance and reliability than traditional continuation power flows.

What generators/loads are adjusted when generating PV and QV curves? Is this configurable?

In the current version of HELMTM-Flow, no generators/loads are adjusted when generating PV/QV curves: all additional needed power comes from the swing bus. However, the current roadmap of the product contains several projected features regarding PV/QV curves: configuration options for defining custom sets for varying load/generation, and custom buses for monitoring the results; governor power-flow and AGC simulation; visualization of limit violations; custom actions and RAS; configuration of contingencies and contingency analysis launcher; and generation of reports. All these functions are already available in the real-time product AGORA (Advanced Grid Observation Reliable Algorithms), an advanced EMS system, and will be transferred to HELMTM-Flow code.

Other functionalities: contingency analysis

How do I perform a Contingency Analysis?

As of the current v2 version, this has to be done through scripting, as the application does not provide facilities for configuring Contingency Analyses through the graphical user interface. Some example scripts are provided, which are rather easy to modify, manipulate, and extend as desired.

Other functionalities: scripting

Does the application provide scripting?

Yes, HELM™-Flow provides extensive scripting facilities via an easy-to-use embedded JavaScript interpreter. JavaScript is language based on open standards, commonly used on the Internet (where it powers dynamic HTML pages in all web browsers), and as an embedded scripting engine in thousands of industry applications.

How difficult is it to learn/use JavaScript?

For the purposes of writing HELM™-Flow scripts, JavaScript is actually rather easy to pick up, since most of the hard work is taken care of by the internal HELM™-Flow objects. It is therefore more important to understand the API (Application Programming Interface), that is, the way to access, configure, and control the internal Java objects. A Scripting Tutorial and the full API documentation is provided in the application Help files. Many examples are provided, covering everything from the very basics to quite advanced use.

Is there a batch mode (headless) available for scripting?

Yes, scripts may be launched either from within the interactive GUI, or from batch scripts running the application and the JavaScript scripts in “headless” mode.

Can HELM™-Flow be invoked from third-part application?

Yes, it can be easily integrated with third-party applications. For instance, HELM™-Flow has been integrated into the software platform developed by the joint EU Project iTesla (an R&D project funded by the European Union Framework 7 Programme, in which Grupo AIA participated).