HELM-Flow FAQ | Gridquant

1 de 6

http://www.gridquant.com/solutions/helm-flow/helm-flow-faq/

Products

Search...

About

Technology

News

Contact

Members Only

Try Searching for: Iterative [it-uh-rey-tiv, -er-uh-tiv] adj.- repeating; making repetition; repetitious....

HELM-Flow
Home / Products / HELM-Flow /

HELM-Flow FAQ

Technical Features

HELM-Flow FAQ

HELM Flow Training

HELM-Flow Licensing And Price

RECENT NEWS
Battelle Announced as Exclusive Distributor for
Gridquant
Read more

HELM Creator Toni Trias Presents at the DOE

Advanced Grid Modeling Workshop
Read more

Gridquant Seeking Experienced Engineer to Hire

for Team
Read more

Pages
About
Battelle
Leadership
Testimonials
Careers
Contact
Home
Members Only
Customers
Downloads
Feedback
Bug Reporting
Suggestions
Technical Questions
Release Notes
Training
Distributors
Downloads
Release Notes
Training
News
Products
HELM-Flow
HELM Flow Training
HELM-Flow FAQ
HELM-Flow Licensing and Price
Technical Features
Sitemap
Technology

Categories
Feature
Uncategorized

General questions about the product

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 direct, 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?
Whats the required and the recommended hardware to run it?
What are the technical limitations on network size?
About the HELM method
Isnt 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 could be the
causes?
So if my case solves under Q-HELM and PQ-HELM but not under Full HELM, what could be the
causes?
How does the HELM method contemplate controls?
Do Q-HELM or PQ-HELM remove or deactivate the controls?
About Sigma Plots
What does the Sigma Plot mean and how do I interpret it?
OK, so my case does not solve and Ive got many points out of the parabola: What do 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?
About the operational branch vs. the non-operational branches
What do you mean by operational and non-operational branches?
What do the strange non-operational curves mean? (PV/QV curves)
About PV instability
What do you mean by PV instability?
Then why isnt 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?
Import/export: interoperability and workflow with other tools
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 could be the
reasons for this?
My case diverges under PSS/E or PSLF, but solves OK under HELM-Flow. What could be 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?
About configuration options
How should I configure the HELM power flow? Is it difficult?
When should I try to change the defaults?
How do I choose the units to show?
Other functionalities: load/gen scaling
Does HELM Flow have facilities for load and generation scaling?
Is there a way to scale load and generation independently?
Does HELM Flow have a governor power flow?
What do the global scaling sliders do?
Other functionalities: P-V / Q-V curves

19/04/2015 12:04

HELM-Flow FAQ | Gridquant

2 de 6

http://www.gridquant.com/solutions/helm-flow/helm-flow-faq/

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

Other functionalities: contingency analysis
How do I perform a Contingency Analysis?
Other functionalities: scripting
Does the application provide scripting?
How difficult is it to learn/use JavaScript?
Is there a batch mode (headless) available for scripting?

General questions about the product

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 the new ground-breaking
HELM algorithm. On the surface, it compares to products such as Siemens PSS/E and GE PSLF. However, it does not necessarily
compete with them, as it can be used along with those tools as part of a workflow. 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 in the publications section of the Gridquants
website, and on the Wikipedia page. But in practical terms, the upshot is that it is a surefire method: it finds the correct solution when
there exist solutions, and it unambiguously yields no solution when the system is unsolvable (i.e. beyond the point of voltage collapse). In
other words, it produces 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. Either Newton-Raphson, Fast-decoupled power flow, Gauss-Seidel, or any other variant of these methods use
numerical iteration as a way to arrive at the solution. The thing is, there is no mathematical guarantee that the iteration will converge, in
general. Moreover, if there are several possible solutions, there is little control over which of those will be selected. Proximity of the initial
seed to the desired solution increases the likelihood, but there is never a 100% guarantee that you will obtain the correct solution.

OK I get it; the HELM method is direct, not iterative. Is that all?
A surefire power-flow method is a big deal in itself, as it removes so many uncertainties when youre 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 HELM
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. Upcoming versions of the product will offer short-circuit analysis and
dynamical simulations.

So what are the main selling points of HELM Flow?

Well, if we had to pick just one, consider this: remember those times when youre preparing a case in which you have done some changes
that render the case non-solvable under your usual tool? Remember the time you had to spend tweaking things until you got it to
converge? HELM Flow is the tool to use in that case. You would import your case in HELM Flow and you would obtain reliable and clear
results. HELM Flow will give you the correct solution if the case is solvable, or otherwise tell you that theres no solution because its not
solvable (we dont use the word converge because theres no iteration here!). If it didnt solve, HELM Flow would help you quickly
understand why, because it can compute where other tools cant. 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.

Whats the required and the 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 anyway), so as to max out the 2GB-per-process limit for the application. The 64-bit version requires 4GB of RAM, and we
recommend 8GB or more if you plan to work with large (N>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.

About the HELM method

Isnt 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 and therefore you do not need
to specify any voltage profile as the initial seed. You may have been lead to think that because of the way in which the method selects the
correct operative 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-operational 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. By contrast, iterative methods are not always

19/04/2015 12:04

HELM-Flow FAQ | Gridquant

3 de 6

http://www.gridquant.com/solutions/helm-flow/helm-flow-faq/

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 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 allowed mismatch (Max mismatch in node), and a percentage of buses in which you
allow the solution to violate that 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, 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 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 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 of the 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 could be 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 could be the
causes?
Either that the system is very stressed, so that the switching on of resistances (therefore losses) pushes the system over the brink of
collapse; or 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 its fully
integrated in the HELM internals. It solves the problem without taking into account the hard limits on the control resources. The second
layer then enforces those hard limits. It performs an intelligent search guided by a minimization principle, arriving at the configuration with
the smallest transmission losses. It uses efficient heuristics that avoid bounces (i.e. controls that have 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.

About Sigma Plots

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 (and non-solutionmore on that just now). 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 gives a measure of the distance to voltage collapse. 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 cant. The outlier nodes will give a quick clue as to
where to look for the reasons 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
mechanism or the Kron reduction), and therefore they will not appear in the plot.

OK, so my case does not solve and Ive got many points out of the parabola: What do I do now?
There is no general recipe here, 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. Other times the causes may be more global and then the trouble
points will appear 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.

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. This provides a quantitative indicator of the distance to voltage

19/04/2015 12:04

HELM-Flow FAQ | Gridquant

4 de 6

http://www.gridquant.com/solutions/helm-flow/helm-flow-faq/

collapse. Its particular value is dimensionless and abstract, though. Its useful to compare cases, but it does not provide the traditional
notion of margin to collapse in terms of MW and MVAr. To obtain a concrete value of the margin to collapse youd still need to use a PV
curve, where youre 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 by right-clicking 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 area of interest.

About the operational branch vs. the non-operational branches

What do you mean by operational and non-operational 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 the PV nose curve, the solutions on the
upper branch correspond to a higher voltage and lower current flow through the transmission line; 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 operate on the upper branch, which we dub the operational branch. The other solutions
would be unstable in real power grids because their P-V and Q-V sensitivities are reversed and therefore voltage controls would
destabilize the grid. What is not sufficiently recognized, however, is that iterative methods can and very often do provide solutions where a
few buses happen to lie on the non-operational branch! HELM Flow, on the other hand, is always guaranteed to give the operational
solution.

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

HELM power flow always provides the operational solution, but when computing P-V/Q-V curves in HELM Flow you have the option of
showing the non-operational curve. To be precise, this option actually plots an approximation to the non-operational curve that meets the
operational one at the nose point. This approximation is only exact near the nose point, and it gets worse as you move away from it. Thats
why the lower curve sometimes exhibits weird oscillating behavior. The idea is to get 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 theres a higher chance that iterative tools might be giving you a non-operational solution for that particular bus.

About PV instability
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 Voltage, the PV voltage control on such
a node would destabilize the system. It is therefore a non-operational solution of the power flow problem. 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 tweaked. Read on the rest of the FAQs in this section to learn what to do about this problem.

Then why isnt HELM Flow giving me the operational solution for these unstable PV nodes?
Because you are forcing the bus to be on the wrong branch. As we mentioned above, HELM Flow will always give you the operational
solution, but in this case things are different: by specifying P and V, you are forcing the system to be on that branch. HELM Flow cannot
give you the corresponding operational solution because it has a different voltage V. You can easily see this if you perform the following
experiment on an unstable PV node: change the 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! The way to solve this is to
correct the value of V, or P, or both, in order to operate this PV bus out of the wrong zone.

So how do I detect these unstable PV nodes in HELM Flow?

On of the big advantages of HELM is that it can detect unstable PV nodes automatically and reliably. With other tools you would have to
check the sign of the V-Q sensitivities at every PV node. By contrast, HELM Flow can quickly check on every node if theres any
difference between the solution as a PV type and the solution as a PQ type (because the solution as PQ is mathematically guaranteed to
be operational). This optional check can be requested by checking the PV instability analysis box in the parameters configuration
windows. 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 dV/dQ.

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 tweaked. In a real-world network it
is impossible to operate a PV node on the wrong side of the Q-V curve, as the controls would make it unstable.

Import/export: interoperability and workflow with other tools

Does import/export preserve all non-used information in the case file?
Thats 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 it is put 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
PTI PSS/E (*.raw): versions from 24 to 30
EUROSTAG (*.ech): version 4.5
IEEE common format (*.cdf)
The following formats can be exported from HELM Flow:

19/04/2015 12:04

HELM-Flow FAQ | Gridquant

5 de 6

http://www.gridquant.com/solutions/helm-flow/helm-flow-faq/

GE PSLF (*.epc): version 18

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 could be the
reasons for this?
The most likely reason is that you are using different configuration settings for the power flow. Go to the Parameters Configuration window
and start by checking 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: check the box Jumper threshold only for reactance when
you are comparing with PSS/E solutions, and uncheck Transformers can be considered Jumpers if you are comparing to PSLF. And
lastly, review the requirements on the precision of the solution and the flow balance mismatch thresholds for acceptance of the solution.
Ultimately, do not forget that iterative methods can yield spurious convergence results in cases where the solution (or non-solution) is close
to the voltage collapse point. You should use the Sigma Plot in this case, to analyze how badly collapsed the case really is.

My case diverges under PSS/E or PSLF, but solves OK under HELM-Flow. What could be 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 Flows 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 HELMs solution as the
new starting seed. This way you are quite likely to obtain convergence, as 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 oneshould 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 on the operational branch for all buses. A rather more
subtle source of differences may arise from the treatment of control resources: iterative methods saturate and bounce-off controls from
their resource limits in ways that are quite different from the way they are handled in HELM-Flow. 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 applying physics-based principles and using an OPF-like optimization approach. This produces a
solution with lower transmission P and Q losses.

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?
We cannot tell which one of those two is the correct operational solution, because an iterative power flow is inherently unreliable in that
respect. It might be that neither one of them is correct! But we do know that the solution provided by HELM Flow is guaranteed to be the
operational one.

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.

About configuration options

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 tells the system how hard it should try to obtain the optimal
configuration of (possibly) saturated controls during the last stages of the power flow method (its the number of maximum expansions
allowed in an A*-search algorithm). 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: 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 only allows scaling loads, which then scales generators in the designated Area, Zone, or Owner accordingly.
Upcoming versions will allow finer-grained control over the way load and generation can be scaled. Of course, the way to achieve the

19/04/2015 12:04

HELM-Flow FAQ | Gridquant

6 de 6

http://www.gridquant.com/solutions/helm-flow/helm-flow-faq/

ultimate, finest degree of control is though Scripting.

Does HELM Flow have a governor power flow?

The current version does not implement this yet. But since the HELM power flow core already supports the concept of a distributed swing
bus, 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 diagnostic purposes 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 (please 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 also 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. On the other hand, 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.

Other functionalities: contingency analysis

How do I perform a Contingency Analysis?
At the moment 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.

How difficult is it to learn/use JavaScript?

For the purposes of writing HELM Flow scripts, JavaScript is actually rather easy to pick up, as most of the heavy lifting is already done in
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.

Products

| About

| Technology

| News

| Contact

| Sitemap

2012 Gridquant

19/04/2015 12:04