Power Flow User Guide

Powerflow Overview
The powerflow module performs distribution level solver methods to primarily obtain the voltage and current values in a system. Details on the different solver methods and how each object are handled are in the Powerflow guide.

Inherited Classes
Nearly all objects within the powerflow module are derived from two primary objects: node and >link. Therefore, any properties defined for these two objects are also available to any derived object. For example, a node has voltage properties, so a load automatically has these properties available as well. Any powerflow objects that inherit properties from node or link</tt> will be labeled as such. Furthermore, node</tt> and link</tt> contain most relevant default quantities. Derived objects often assume zero value or throw an error if an explicit property is not indicated. Any exceptions to this rule will be indicated in the parameter list of the particular object.

Powerflow Objects
Along with all of the properties inherited from either node</tt> or link</tt>, all objects within the powerflow</tt> module inherit two basic properties. These two properties are the phases of the object and the nominal voltage for that area of the system. These are expressed in the phases</tt> and nominal_voltage</tt> parameters of powerflow</tt> objects.

The phases</tt> property has a variety of valid inputs. These are:
 * A</tt> - Phase A of a three phase connection
 * B</tt> - Phase B of a three phase connection
 * C</tt> - Phase C of a three phase connection
 * D</tt> - Delta connected phases - this implies ABC, but explicitly specifying them is recommended
 * N</tt> - Neutral phase
 * G</tt> - Ground phase
 * <tt>S</tt> - Split phase - this represents residential level wires (2 "hot" and 1 neutral wire)

These different phases can be specified in a variety of ways. Below are some identical examples with a simple <tt>node</tt> object (which is covered in more later in this page).

object node { phases ABC; }

object node { phases "ABC"; }

object node { phases A|B|C; }

object node { phases "A|B|C"; }

The other common property is nominal voltage, which is passed into the objects using the <tt>nominal_voltage</tt> parameter. This parameter is used to ensure connected objects are in the proper region (have the same nominal voltage) and also to specify an initial value for the convergence criteria of the different solver methods. Using the same node example, a 7200 Volt nominal voltage would be expressed as:

object node { nominal_voltage 7200.0; }

Node
The node object is equivalent to a bus of the distribution system. It provides a connection point for <tt>link</tt>-based objects and a point of known voltages on the system. Three phase voltage is typically available in either wye-connected or delta-connected three phase. Wye-connected voltages are contained in <tt>voltage_A</tt>, <tt>voltage_B</tt>, and <tt>voltage_C</tt>. Delta-connected voltages are available in <tt>voltage_AB</tt>, <tt>voltage_BC</tt>, and <tt>voltage_CA</tt>.

Default Node
A minimalist node could be created with object node { name NodeOne; phases ABC; nominal_voltage 7200.0; }

which is the same as specifying

object node { name NodeOne; phases ABC; nominal_voltage 7200.0; voltage_A 7200.0+0d; voltage_B 7200.0-120.0d; voltage_C 7200.0+120.0d; bustype PQ; }

Node Parameters
As with all powerflow objects, <tt>phases</tt> and <tt>nominal_voltage</tt> are inherently part of <tt>node</tt>.

Node State of Development
Node is considered a highly developed and validated model.

Link
The link object is a connection between nodes in a distribution system. The <tt>link</tt> object is not directly useful, but is the basis for objects associated with overhead lines, underground lines, triplex lines, transformers, regulators, switches, and fuses.

Default Link
A <tt>link</tt> only requires three parameters to be specified by default. Most of the actual functionality comes through other objects.

object link { name Node1toNode2; phases ABC; from Node1; to Node2; }

Link Parameters
Again, as with all powerflow objects, <tt>phases</tt> and <tt>nominal_voltage</tt> are inherently part of <tt>link</tt>. <tt>nominal_voltage</tt> does not need to be specified for <tt>link</tt> objects.

Link State of Development
Link is considered a highly developed and validated model.

Line
The line object represents power lines in a distribution system. The line object has two implementations: <tt>overhead_line</tt>, and <tt>underground_line</tt>. Each line must be called appropriately. Information about the particular line type will be contained in other objects called <tt>line_configuration</tt>.

<tt>Line</tt>-based objects inherit properties from the <tt>link</tt> object just covered. Two new properties are also added: <tt>configuration</tt> and <tt>length</tt>.

Typical usage of an overhead line would be object overhead_line { name Node1toNode2; phases ABC; from Node1; to Node2; length 5280; configuration Best_overhead_line_cfg; }

and the typical usage of the underground line would be object underground_line { name Node1toNode2; phases ABC; from Node1; to Node2; length 5280; configuration An_underground_line_cfg; }

Line Parameters
Along with the inherited <tt>link</tt> properties, <tt>line</tt> objects have:

Line configuration
Both <tt>underground_line</tt> and <tt>overhead_line</tt> objects take line configuration information to describe the particular line being implemented, or they can be described in their raw z-matrix values. A typical <tt>line_configuration</tt> object would be implemented as object line_configuration { name line_config_A; conductor_A overhead_line_conductor_100; conductor_B overhead_line_conductor_100; conductor_C overhead_line_conductor_100; conductor_N overhead_line_conductor_101; spacing line_spacing_200; }

or object line_configuration { name line_config_B; z11 0.45+1.07j; z12 0.15+0.50j; z13 0.15+0.38j; z21 0.15+0.50j; z22 0.46+1.04j; z23 0.15+0.42j; z31 0.15+0.38j; z32 0.15+0.42j; z33 0.46+1.06j; }

If you want to factor in line capacitance effects, the <tt>line_configuration</tt> can be extended to:

object line_configuration { name line_config_B; z11 0.45+1.07j; z12 0.15+0.50j; z13 0.15+0.38j; z21 0.15+0.50j; z22 0.46+1.04j; z23 0.15+0.42j; z31 0.15+0.38j; z32 0.15+0.42j; z33 0.46+1.06j; c11 198.52; c22 198.52; c33 198.52; }

Note that for capacitance calculations to be included in the powerflow, the module-level directive must be included:

module powerflow { line_capacitance true; }

It is highly recommended to use the <tt>line_spacing</tt> and <tt>overhead_line_conductor</tt> or <tt>underground_line_conductor</tt> objects and let the internal equations calculate the capacitance (and impedance) for the user.

Line State of Development
Line is considered a highly developed and validated model in terms of powerflow solutions, however, models may be developed to include more advanced features in the future.

Line spacing
The line spacing object describe how the individual conductors of a distribution line are arranged underground or on the support pole. A typical implementation of a <tt>line_spacing</tt> object is object line_spacing { name line_spacing_200; distance_AB 2.5; distance_BC 4.5; distance_AC 7.0; distance_AN 5.656854; distance_BN 4.272002; distance_CN 5.0; }

Line Spacing State of Development
Line Spacing is considered a highly developed and validated model in terms of powerflow solutions, however, models may be developed to include more advanced features in the future.

Overhead Line
Overhead lines are one of three specific line types incorporated into the <tt>powerflow</tt> distribution-level module. The <tt>overhead_line</tt> object will take spacing and conductor parameters and translate those values to appropriate impedance matrices based for the specific overhead transmission line configuration. A typical overhead line would be written as

object overhead_line{ phases "ABCN"; name 701-802; from node_701; to load_802; length 125960; configuration line_config_A; }

<tt>overhead_line</tt> objects are based around the <tt>link</tt> object and inherit all of its properties. <tt>overhead_line</tt> objects primarily translate the <tt>configuration</tt> options specified into a circuit equivalent, so not further properties than those provided by <tt>link</tt> are required.

Overhead Line State of Development
Overhead Line is considered a highly developed and validated model in terms of powerflow solutions, however, models may be developed to include more advanced features in the future.

Overhead Line Conductor
For overhead lines, the <tt>line_configuration</tt> object must specify the overhead line conductor types used in the particular setup. A typical <tt>overhead_line_conductor</tt> would be implemented as

object overhead_line_conductor { name overhead_line_conductor_100; geometric_mean_radius .00446; resistance 1.12; }

Overhead Line Conductor State of Development
Overhead Line Conductor is considered a highly developed and validated model.

Underground Line
Underground lines represent burial distribution cables in a powerflow system. In terms of GridLAB-D implementation, they are nearly identical to the <tt>overhead_line</tt> objects. A typical <tt>underground_line</tt> object would be written as

object underground_line { phases "ABC"; name 703-727; from node_703; to load_827; length 240; configuration line_config_7241; }

As with <tt>overhead_line</tt> objects, <tt>underground_line</tt> objects inherit all of their properties from the <tt>link</tt> object. The <tt>underground_line</tt> object again serves as a method to choose the appropriate translation algorithms to take the physical parameters of the system and create an equivalent model. As such, it has no new properties either.

Underground Line State of Development
Underground Line is considered a highly developed and validated model in terms of powerflow solutions, however, models may be developed to include more advanced features in the future.

Underground Line Conductor
Underground lines often contain concentric shielding layers around the central conductor. As a result, they require more parameters than the <tt>overhead_line_conductor</tt> objects to fully describe them. A typical <tt>underground_line_object</tt> is:

object underground_line_conductor { name ug_conduct_7210; outer_diameter 1.980000; conductor_gmr 0.036800; conductor_diameter 1.150000; conductor_resistance 0.105000; neutral_gmr 0.003310; neutral_resistance 5.903000; neutral_diameter 0.102000; neutral_strands 20.000000; shield_gmr 0.000000; shield_resistance 0.000000; }

Underground Line Conductor State of Development
Underground Line Conductor is considered a highly developed and validated model.

Triplex line
The third type of line available in the <tt>powerflow</tt> module is the triplex lines. Triplex lines represent the distribution wires coming from the transformer into a typical residential home. That is, they are typically composed of one neutral wire and two "hot" wires. Triplex lines require the phase <tt>S</tt> to be specified as part of the <tt>phases</tt> parameter for proper implementation. A typical triplex line would be implemented in a similar fashion to

object triplex_line { phases AS; length 100 ft; from node_4a; to node_4; configuration triplex_config_AB; }

As with the <tt>underground_line</tt> and <tt>overhead_line</tt> objects, <tt>triplex_line</tt> objects inherit all of their properties from the <tt>link</tt> object. However, <tt>triplex_line</tt>s use a different configuration structure than the <tt>overhead_line</tt> and <tt>underground_line</tt> objects.

Triplex Line State of Development
Triplex Line is considered a highly developed and validated model in terms of powerflow solutions, however, models may be developed to include more advanced features in the future.

Triplex Line Configuration
Triplex lines utilize their own configuration description method. Since the phases are no longer described as <tt>A</tt>, <tt>B</tt>, or <tt>C</tt>, the configuration is relabeled. A typical <tt>triplex_line_configuration</tt> is given as either a geometric configuration

object triplex_line_configuration { conductor_1 trip_cond_H; conductor_2 trip_cond_H; conductor_N trip_cond_N; insulation_thickness 0.08 in; diameter 0.368 in; }

or by using an explicit z-matrix

object triplex_line_configuration { z11 1.52+0.61j; z12 +0.55+0.44j; z21 -0.55-0.44j; z22 -1.52-0.61j; }

Note: The explicit z-matrix version is an under-determined system. Ground and neutral currents will not be calculated, however, voltage and line currents will be correctly calculated.

Triplex Line Configuration State of Development
Triplex Line Configuration is considered a highly developed and validated model.

Triplex Conductor
As with the <tt>underground_line</tt> and <tt>overhead_line</tt> objects, <tt>triplex_line</tt> objects have their own conductor objects. This object describes the physical characteristics of the actual wire used in the triple line bundle. A typical implementation would be:

object triplex_line_conductor { name trip_cond_1; resistance 0.97; geometric_mean_radius 0.0111; }

Triplex Conductor State of Development
Triplex Conductor is considered a highly developed and validated model.

Transformer
Transformers provide a means to change the voltage from one node to another in the distribution system. Similar to the different <tt>line</tt> objects, a <tt>transformer</tt> object requires a configuration object to specify the details of the implementation. A typical transform implementation is

object transformer { name xfrmr_709_775; phases "ABC"; from node_709; to node_775; configuration xfrmr_config_400; }

Transformer Thermal/Aging Model
A newly added feature to transformers in 3.0 is a thermal/aging model. New parameters are placed within the transformer and and transformer_configuration in order to use this new feature. An implementation of the thermal model within transformer is

object transformer { name xfrmr_709_775; phases "ABC"; from node_709; to node_775; configuration xfrmr_config_400; use_thermal_model TRUE; climate Seattle; aging_granularity 300; percent_loss_of_life 20; }

Transformer Parameters
Transformers are derived from the <tt>link</tt> class and inherit all of its properties. The only unique property a <tt>transformer</tt> object contains is

Transformer State of Development
Transformer is considered a highly developed and validated model in terms of powerflow solutions, however, models may be developed to include more advanced features in the future. Additionally, future work may include additional transformer configurations.

Transformer Configuration
The <tt>transformer_configuration</tt> object describes the details of a particular transformer implementation. It includes information like the power rating, connection type, and nominal voltage on each side. A typical delta-delta transformer configuration would be implemented as

object transformer_configuration { name xfrm_config_400; connect_type DELTA_DELTA; install_type PADMOUNT; power_rating 500; primary_voltage 4800; secondary_voltage 480; resistance 0.09; reactance 1.81; }

Transformer Thermal/Aging Model
A new feature added to transformers in 3.0 is the thermal/aging model. New parameters are added to <tt>transformer_configuration</tt> for this new feature. This model only works with a SINGLE_PHASE_CENTER_TAPPED <tt>transformer</tt>. A typical implementation is

object transformer_configuration { name xfrm_config_400; connect_type SINGLE_PHASE_CENTER_TAPPED; install_type PADMOUNT; power_rating 500; primary_voltage 4800; secondary_voltage 480; full_load_loss 0.006; no_load_loss 0.003; reactance_resistance_ratio 10; core_coil_weight 50; tank_fittings_weight 60; oil_volume 5; rated_winding_hot_spot_rise 80; rated_top_oil_rise 30; rated_winding_time_constant 0.5; installed_insulation_life 175200; coolant_type MINERAL_OIL; cooling_type OA; }

Transformer Configuration State of Development
Transformer Configuration is considered a highly developed and validated model in terms of powerflow solutions, however, models may be developed to include more advanced features in the future, and additional models may be included as needed.

Load
Load objects present a method for taking power out of the system in controlled, known amounts. While implemented as a constant load, <tt>player</tt> objects can be used to vary the load with time. <tt>load</tt> objects provide a means to implement constant current, constant power, and constant impedance losses or generation into the system. The convention is a load is a positive quantity, so generation would need to be represented as a negative number.

Loads can be a mixture of the constant current, constant impedance, and constant power types. A typical, mixed load would be implemented as

object load { phases "ABCD"; name 841; constant_current_C -0.586139+9.765222j; constant_impedance_B 221.915014+104.430595j; constant_power_A 42000.000000+21000.000000j; nominal_voltage 4800; }

Load Parameters
<tt>load</tt> objects are derived from the <tt>node</tt> objects, so all of the same properties apply.

Load State of Development
Load is considered a well developed and validated model, with a number of features. Additional features may be included as needed.

Meter
Meters provide a measurement point for power and energy on the system at a specific point. Coupled with a <tt>recorder</tt> or <tt>collector</tt>, the <tt>meter</tt> object provides a method determine how much power and energy have been used by downstream connections, as well as how much current is flowing through the meter object at the present time. A typical implementation would be

object meter { name Mtr1; phases ABC; nominal_voltage 4800.0; }

Meter Parameters
A <tt>meter</tt> object is a derivation of the <tt>node</tt> object and thus inherits all of its parameters. Most <tt>meter</tt> parameters are meant to be read-only, but can be set if the need arises.

Meter State of Development
Meter is considered a highly developed and validated model in terms of powerflow solutions, however, models using billing features have not been fully validated.

Triplex Node
Triplex nodes represent special cases of the <tt>node</tt> object. The <tt>triplex_node</tt> object still serves as connection point between different links of the system and a point of measurable voltage. However, <tt>triplex_node</tt>s are casted to represent phases <tt>1</tt>, <tt>2</tt>, and <tt>N</tt> rather than <tt>A</tt>, <tt>B</tt>, and <tt>C</tt> like normal <tt>node</tt> objects. Simplified, they operate in the split-phase level of distribution rather than the three-phase level.

Since <tt>load</tt> objects are directly derived from <tt>node</tt> objects, they are only valid for three-phase connections as well. Therefore, the <tt>load</tt> functionality has been built into the <tt>triplex_load</tt> object for split-phase level systems.

It is important to note that triplex-based objects should include the phase <tt>S</tt> somewhere in their designation.

A typical <tt>triplex_node</tt> implementation is

object triplex_node { name TPL_tAS; phases AS; voltage_1 120 + 0j; voltage_2 120 + 0j; voltage_N 0; current_1 1.0; power_1 1000+2000j; shunt_1 5.3333e-004 -2.6667e-004i; nominal_voltage 120; };

Triplex Node Parameters
<tt>triplex_node</tt> objects are technically derived from <tt>node</tt> objects as well. However due to the triplex nature of their use and the particular implementation, the normal <tt>node</tt> parameters are not available for use.

Triplex Node State of Development
Triplex Node is considered a highly developed and validated model in terms of powerflow solutions, however, models may be developed to include more advanced features in the future.

Triplex Meter
Triplex meters provide similar functionality for triplex systems that <tt>meter</tt> objects do in three-phase systems. A triplex meter provides a measurement point for power and energy on the system at a specific point. Coupled with a <tt>recorder</tt> or <tt>collector</tt>, the <tt>triplex_meter</tt> object provides a method determine how much power and energy have been used by downstream connections, as well as how much current is flowing through the meter object at the present time. A typical implementation would be

object triplex_meter { name TrplMtr1; phases AS; nominal_voltage 120.0; }

Triplex Meter Parameters
A <tt>triplex_meter</tt> object is a derivation of the <tt>triplex_node</tt> object and thus inherits all of its parameters. Most <tt>triplex_meter</tt> parameters are meant to be read-only, but can be set if the need arises.

Triplex Meter State of Development
Triplex Meter is considered a highly developed and validated model in terms of powerflow solutions, however, models using billing have not been fully validated. Additional features will be added as needed.

Triplex Load
Triplex load is similar to <tt>load</tt> and <tt>ZIPload</tt> in that load can be specified as a direct value, or as a base load, then a ZIP fraction applied to that base load. The load can be placed on phase 1 (120V), phase 2 (120V) or phase 12 (240V). Much like the <tt>load</tt> object, <tt>player</tt> objects can be used to vary the load with time. <tt>triplex_load</tt> objects provide a means to implement constant current, constant power, and constant impedance losses or generation into the system. The convention is a load is a positive quantity, so generation would need to be represented as a negative number.

Loads can be a mixture of the constant current, constant impedance, and constant power types. A typical, mixed load would be implemented as

object triplex_load { phases "AS"; name tplex_load; constant_current_1 -0.586139+9.765222j; constant_impedance_2 221.915014+104.430595j; constant_power_12 4200.00+2100.00j; nominal_voltage 120.0; }

Triplex Load Parameters
<tt>triplex_load</tt> objects are derived from the <tt>triplex_node</tt> objects, so all of the same properties apply.

Triplex Load State of Development
Triplex_load is considered a well developed and validated model, with a number of features. Additional features may be included as needed.

Regulator
Regulators are essentially tap-changing transformers that attempt to maintain a voltage level at a specified point in the system. Regulators are one of two objects in the <tt>powerflow</tt> module that incorporate a form of automatic control. To take full advantage of this functionality, simulations of greater than one time step (time-varying simulations) are recommended. Similar to <tt>transformer</tt> and <tt>line</tt> objects, regulators require a <tt>regulator_configuration</tt> to determine many of their operating parameters.

A typical implementation would be

object regulator { name Reg799781; phases "ABC"; from node_799; to node_781; configuration reg_conf_79978101; }

Regulator Parameters
A <tt>regulator</tt> object is a derived class from <tt>link</tt> objects. Therefore, all of the parameters available to the <tt>link</tt> object apply here as well.

Regulator State of Development
Regulator is considered a well developed and validated model in terms of powerflow solutions, however, models may be developed to include more advanced features in the future. Additional configurations, controls, and/or losses may be included as needed.

Regulator Configuration
The <tt>regulator_configuration</tt> object describes the details of a particular <tt>regulator</tt> object implementation. This includes details such as the control scheme, regulator type, sensing information, and time delays. A typical regulator configuration would look similar to

object regulator_configuration { name reg_conf_79978101; connect_type 2; band_center 122.000; band_width 2.0; time_delay 30.0; raise_taps 16; lower_taps 16; current_transducer_ratio 350; power_transducer_ratio 40; compensator_r_setting_A 1.5; compensator_x_setting_A 3.0; compensator_r_setting_B 1.5; compensator_x_setting_B 3.0; CT_phase "ABC"; PT_phase "ABC"; regulation 0.10; Control MANUAL; control_level INDIVIDUAL; Type A; 	tap_pos_A 7; tap_pos_B 4; }

Regulator Configuration State of Development
Regulator Configuration is considered a well developed and validated model in terms of powerflow solutions, however, models may be developed to include more advanced features in the future. Additional configurations, controls, and/or losses may be included as needed.

Capacitor
Capacitors are used for reactive power compensation and voltage support scenarios. The <tt>capacitor</tt> implements a switchable set of capacitors. <tt>capacitor</tt> objects are one of two objects in the <tt>powerflow</tt> module that incorporate a form of automatic control. To take full advantage of this functionality, simulations of greater than one time step (time-varying simulations) are recommended. Single-phase powerflow connections (phase <tt>S</tt>) are not supported by capacitors at this time. A typical capacitor implementation is

object capacitor { phases ABCN; name CapNode; phases_connected ABCD; control MANUAL; capacitor_A 0.5 MVAr; capacitor_B 0.5 MVAr; capacitor_C 0.5 MVAr; control_level INDIVIDUAL; switchA OPEN; switchB OPEN; switchC CLOSED; nominal_voltage 7200; }

Capacitor Parameters
<tt>capacitor</tt> objects are derived from <tt>node</tt> objects, so any parameters of the <tt>node</tt> object are available as well.

Capacitor State of Development
Capacitor is considered a well developed and validated model in terms of powerflow solutions, however, models may be developed to include more advanced features in the future. Additional configurations and controls may be included as needed.

Fuse
Fuse objects are used to place a current limitation between two nodes. If the current is exceeded, the fuse will open and prevent further current flow. Due to limitations in the Forward-Back Sweep algorithm, fuses only affect the first downstream node. If other loads exist downstream, they will cause an oscillatory voltage swing that has no real representation. <tt> reliability</tt> module functionality only exists in the Newton-Raphson solver at this time. A minimalist <tt>fuse</tt> could be implemented as

object fuse { phases "ABC"; name node1-node2; from node1; to node2; }

A typical <tt>fuse</tt> object would be implemented, with the same parameters as above, as

object fuse { phases "ABC"; name node1-node2; from node1; to node2; current_limit 9999.0 A; 	mean_replacement_time 3600.0; repair_dist_type NONE; }

Fuse Parameters
<tt>fuse</tt> objects are derived from <tt>link</tt> objects, so all of those properties are available.

Fuse State of Development
Fuse is considered a well developed and validated model in terms of powerflow solutions. Reliability functionality has been tested and validated, but is not fully vetted and may change as advanced functionality is included.

Switch
Switch objects are used to change topology and add or remove elements from a powerflow system. When a switch is opened, no current flow is permitted and the downstream objects will be effectively removed from the system. A typical switch implementation is

object switch { name switch1; phases ABCN; from node_250; to node_243; status CLOSED; }

Switch Parameters
Switch objects are derived from <tt>link</tt> objects and share all of those available parameters. <tt>switch</tt> objects have additional parameters of

Switch State of Development
Switch is considered a well developed and validated model in terms of powerflow solutions, however, models incorporating fault analysis, reliability, and other advanced features have not been validated.

Recloser
<tt>recloser</tt> objects are a special type of <tt>switch</tt> that open at the detection of a fault condition and will close if the fault condition is removed or isolated within a certain period of time. The time is typically determined by the number of closing tries and the time between tries. <tt>recloser</tt> objects work with both the <tt>FBS</tt> and <tt>NR</tt> solver methods, but their reliability functionality only works with the <tt>NR</tt> method. A typical recloser implementation is

object recloser { name recloser_2; phases "ABCN"; from node_2a; to node_2b; retry_time 1s; max_number_of_tries 3; }

Recloser objects inherit for switch and therefore share all parameters belonging to both <tt>switch</tt> and <tt>link</tt>. <tt>recloser</tt> objects are exercised only by the <tt>reliability</tt> module at this time.

Recloser State of Development
Recloser is considered a validated model in terms of powerflow solutions and <tt>reliability</tt> integration. However, testing has been limited and feature additions may still be necessary.

Relay
Relays are used to provide momentary breaks in the system and are implemented as reclosers. A <tt>relay</tt> object only functions in on a basic level and does not provide any <tt>reliability</tt>-module-functionality at this time. It is untested in the <tt>NR</tt> solver and a <tt>recloser</tt> object is suggested instead. A typical relay would be implemented as

object relay { name recloser_A; phases ABCN; from node_1; to load_5; time_to_change 1.0s; recloser_delays 5.0s; recloser_tries 5; }

Relay Parameters
<tt>relay</tt> objects are derived from <tt>link</tt> objects, so all of those parameters should be available.

Relay State of Development
Relay is considered a well developed and validated model in terms of <tt>FBS</tt>-based powerflow solutions, however, models incorporating fault analysis, reliability, and other advanced features have not been validated.

Substation
Substations were used to connect distribution powerflow in the <tt>powerflow</tt> module with PowerWorld through the <tt>network</tt> module. The <tt>substation</tt> object converts the sequence voltage provided by the <tt>network</tt> module to three-phase swing bus voltage for the unbalanced three-phase powerflow solution. The <tt>substation</tt> object also passes the unbalanced three-phase powerflow solution to back to the <tt>network</tt> module as an single power value representing the average load on all three phases of the swing bus. Furthermore, the <tt>substation</tt> object sets which phase is the reference phase for the distribution powerflow. A typical substation implementation is

object substation { name SubS; bustype SWING; parent network_node; reference_PHASE_A; phase ABCN; nominal_voltage 7199.558; }

In order to properly connect the substation object to the <tt>network</tt> module, the substation object's parent must be a pw_load object.

Substation Parameters
The <tt>substation</tt> object is derived from the <tt>node</tt> object in the <tt>powerflow</tt> module. As a result, all parameters of that object are definable as well.

Substation State of Development
The only transmission powerflow software that substation currently works with is PowerWorld. Please note that the specific the transmission current and impedance loads are converted to complex power values first and then posted to the proper properties(load_current and load_impedance) in the pw_load object. The average_transmission_power_load value must be added to the average_distribution_load before posting to pw_load(load_power).

Substation's three phase voltages are determined differently dependent upon three scenarios. If there is a pw_load object attached to the substation object, then the three phase voltages are determined by the sequence voltage value read from the pw_load object. The three phase voltages are determined by the positive_sequence_voltage property if there is a player object populating that property in the absence of a pw_load object. In the absence of a player object and a pw_load object, the three phase voltages are determined by user input or the substation object's powerflow parent just like any node object. If there is no pw_load connected to the substation then the substation doesn't post the average_distribution_load, average_transmission_current_load, average_transmission_impedance_load, and average_transmission_power_load properties.

Parametric Load
Parametric loads provide a <tt>load</tt>-like object that allows the load to vary based on other conditions in the system. This may be things such as weather conditions or even time-of-day scheduling. Further details on parametric loads can be found in the Industrial and agricultural loads page. A typical parametric load would be called as

object pqload { name pqload1; phases ABC; Zp 200 ohm; Zq_T 250 F; 	Im 300; Ia 45; Pp 100; Pp_T 3; Pq_T 1; nominal_voltage 2400; }

Parametric Load Parameters
The <tt>pqload</tt> object is directly derived from the <tt>load</tt> object and thus derived from the <tt>node</tt> object as well. As such, parameters of those two objects are also available for use, but most <tt>load</tt> parameters will probably be overwritten.

PQ Load State of Development
PQ Load is considered an experimental model and has not been validated at this time.

Volt-VAr Control
With multiple feeders attached to a common point, it is often useful to coordinate the voltage regulators and capacitors on the system. The <tt>volt_var_control</tt> object coordinates selected <tt>regulator</tt> and <tt>capacitor</tt> objects on the system. Using voltage measurements at <tt>node</tt> object points, the <tt>volt_var_control</tt> tries to maintain a desired voltage. In addition to voltage measurements, the <tt>volt_var_control</tt> utilizes a power measurement at a <tt>link</tt> object to determine how to switch various <tt>capacitor</tt> objects on the system in and out of service. Due to differences in the timing of power calculations in the Forward-Back Sweep and Newton-Raphson powerflow solvers, capacitors may switch at slightly different intervals for the same system. The overall control behaves the same in both solver methods, but this difference in capacitor timing may result in different final operating points. A typical Volt-VAr Controller implementation is

object volt_var_control { name IVVC37; control_method ACTIVE; capacitor_delay 10.0; regulator_delay 5.0; desired_pf 0.98; d_max 0.8; d_min 0.1; substation_link "SubTransNode-799"; regulator_list "reg799-781,regnode799-U0081"; capacitor_list "CapNode_A,CapNode_B"; voltage_measurements "load829,1,load841,1,load825,1,U0029,2,U0041,2,U0025,2"; minimum_voltages 2500.0; maximum_voltages 3000.0; desired_voltages 2600.0; }

Many of the parameters on the Volt-VAr Controller can be left unspecified. When unspecified, default values or criteria are enacted. A minimalist implemenation would look similar to

object volt_var_control { name IVVC37; regulator_list "reg799-781,regnode799-U0081"; capacitor_list "CapNode_A,CapNode_B"; }

Volt-VAr Control Parameters
The <tt>volt_var_control</tt> object only derives properties from general <tt>powerflow</tt> module sets. It may share similar names to <tt>node</tt> and <tt>link</tt> parameters, but it is not a subclass of either of these objects.

VoltVar Control State of Development
VoltVar Control is considered a well developed model, but has not been fully validated at this time. Advanced features and additional controls may be added as needed.

Volt Dump
This object allows the user to collect all of the voltages in the system into one *.csv file at a given run time. Voltages are placed in the *.csv output file with format

Default Volt Dump
The minimal amount of code to specify a <tt>voltdump</tt> object is

object voltdump { filename output_voltage.csv; }

which will produce an output file of the given name in the format shown above, and will display the voltage of every node in the glm file.

Volt Dump State of Development
Volt Dump is considered a well developed, but unvalidated model. Additional features may be included as needed.

Current Dump
This object allows the user to collect all of the currents in the system into one *.csv file at a given run time. In all cases, this is the current flowing INTO the link object (as defined by the to/from convention). Currents are placed in the *.csv output file with format:

Default Current Dump
The minimal amount of code to specify a <tt>currdump</tt> object is

object currdump { filename output_current.csv; }

which will produce an output file of the given name in the format shown above, and will display the current of every link object in the glm file.

Current Dump State of Development
Current Dump is considered a well developed, but unvalidated model. Additional features may be included as needed.

Impedance Dump
Impedance dump allow the impedance and line equation matrices to be output into an XML file for debugging or further use.

See the impedance_dump page for information on the assumed equations, which are from "Distribution System Modeling and Analysis" by William Kersting.

Default Impedance Dump
The minimal specifications for <tt>impedance_dump</tt> are

object impedance_dump { filename impedance_output.xml; }

Like other "dump" objects in powerflow, additional parameters can be added to describe when to run (runtime) and for only link objects with a specific groupid:

object impedance_dump { group "class=overhead_line"; runtime '2020-12-11 01:00:00'; filename impedance_output.xml; }

Impedance Dump State of Development
Impedance Dump is considered a well developed, but unvalidated model. Additional features may be included as needed.

Bill Dump
Similar to <tt>voltdump</tt>, <tt>billdump</tt> allows users to generate a single file where all customers' bills are written from <tt>triplex_meter</tt> to a single output file in a similar format

Default Bill Dump
The minimal specifications for billdump are

object billdump { filename bill_1.csv; }

where the previous month's energy and bill for all triplex meters within the system will be placed into bill_1.csv. Additional parameters can be added to describe when to run (runtime) and for only meters with a specific groupid:

object billdump { group "Residential_tm_solar"; runtime '2012-04-01 01:00:00'; filename residential_solar_bill.csv; }

Bill Dump State of Development
Bill Dump is considered a well developed, but unvalidated model. Additional features may be included as needed.

Fault Check
The <tt>fault_check</tt> object performs "support/islanding checks" on objects inside the <tt>powerflow</tt> module. Its primary purpose is to determine if a particular node or link is still in service after a reconfiguration or fault event. <tt>fault_check</tt> is set up to operate as an independent topology checking object, but does have ties to the <tt>reliability</tt> module and the <tt>restoration</tt> object's functionality. The <tt>fault_check</tt> object only works with the <tt>NR</tt> <tt>solver_method</tt> at this time. Other solvers may be incorporated at a later date. A typical <tt>fault_check</tt> object would be implemented as

object fault_check { name fault_check_obj; check_mode ONCHANGE; output_filename outage_check.txt; }

As with other objects, not all of the parameters need to be specified. A minimal implementation would be similar to

object fault_check { name fault_check_obj; }

Fault Check Parameters
The <tt>fault_check</tt> object only derives the base <tt>powerflow</tt> module properties. However, these <tt>powerflow</tt>-based properties are not needed and are omitted from the list below.

Fault Check State of Development
The <tt>fault_check</tt> object has been rigorously tested for topology checking and islanding operations and is considered well-developed and validated on that functionality. The original implementation was developed in conjunction with the <tt>reliability</tt> module and the <tt>restoration</tt> object. That functionality has been tested and is considered validated, but rigorous testing has not been conducted and additional features may be added at a future date.

Motor
In Development.

Motor Parameters
In Development.

Motor State of Development
In Development.

Restoration
As the <tt>powerflow</tt> module interacts with the <tt>reliability</tt> module, portions of the system may become isolated. The <tt>restoration</tt> object attempts to do feeder reconfiguration to close the isolated sections back into the system. The <tt>restoration</tt> object requires <tt>reliability</tt> or some reliability-like actions to function properly, as well as the <tt>fault_check</tt> object. The <tt>restoration</tt> object only works with the <tt>NR</tt> solver method at this time.

A <tt>restoration</tt> object can be implemented as:

object restoration { name RestorVal; reconfig_attempts 3; reconfig_iteration_limit 5; populate_tree TRUE; }

Restoration State of Development
The <tt>restoration</tt> object is considered highly experimental at this time.

Series Reactor
The series reactor is a link object designed to model a series reactance on each of the three phases.

object series_reactor { from node1; to node2; phases ABC; phase_A_impedance 1+1j; phase_B_resistance 2; phase_C_reactance 3; }

Series Reactor State of Development
Series reactor has been tested, but not fully validated.

Sectionalizer
<tt>sectionalizer</tt> objects provide a means to isolate faulted portions of a system. <tt>sectionalizer</tt> objects work in conjuction with the <tt>reliability</tt> module and the <tt>recloser</tt> objects. <tt>reliability</tt> will automatically open a <tt>sectionalizer</tt> if an upstream <tt>recloser</tt> is present, and has "tries" available. <tt>sectionalizer</tt> objects should work for both solver methods, but the <tt>reliability</tt> functionality only works in the <tt>NR</tt> solver.

A minimal <tt>sectionalizer</tt> implementation is:

object sectionalizer { name Test_Section; phases ABC; }

with an equivalent representation of:

object sectionalizer { name Test_Section; phases ABC; phase_A_state CLOSED; phase_B_state CLOSED; phase_C_state CLOSED; operating_mode BANKED; }

<tt>sectionalizer</tt> objects behave exactly like <tt>switch</tt> objects, aside from their <tt>reliability</tt> coordination. <tt>sectionalizer</tt> objects inherit all <tt>switch</tt> properties and default to a banked operation mode. No new parameters are introduced in sectionalizers.

Sectionalizer State of Development
<tt>sectionalizer</tt> objects are based on <tt>switch</tt> objects and share a common state of development. NOrmal operation is tested and verified. <tt>reliability</tt>-based actions are validated, but not fully tested at this time.

Power Metrics
The <tt>power_metrics</tt> object is used by the <tt>reliability</tt> module to calculate relevant <tt>powerflow</tt> metrics. The <tt>power_metrics</tt> object calculates the IEEE 1366-2003 metrics for evaluating the reliability indices of a power system.

A minimalist <tt>power_metrics</tt> implementation is

object power_metrics { name PwrMetrics; }

with an equivalent of

object power_metrics { name PwrMetrics; base_time_value 60.0; }

<tt>power_metrics</tt> objects are primarily output objects.

Power Metrics Parameters
<tt>power_metrics</tt> objects do not inherit properties from any module. Individual metrics are described in the <tt>reliability</tt> user's guide and in the IEEE 1366-2003 standard.

Power Metrics State of Development
The <tt>power_metrics</tt> object is tested and validated with the <tt>reliability</tt> module. However, it has not been fully validated and is considered experimental at this time.

Emissions
In Development.

Emissions Parameters
In Development.

Emissions State of Development
In Development.

=See also= Powerflow