Powerflow objects (abstract)
[recloser]

The powerflow_object class is an abstract class that implements basic elements of powerflow solutions. More...

Modules
	Link
	Node
	The node is one of the major components of the method used for solving a powerflow network.
Functions
EXPORT int	create_powerflow_object (OBJECT **obj, OBJECT *parent)
	REQUIRED: allocate and initialize an object.
EXPORT int	init_powerflow_object (OBJECT *obj)
	Object initialization is called once after all object have been created.
EXPORT TIMESTAMP	sync_powerflow_object (OBJECT *obj, TIMESTAMP t0, PASSCONFIG pass)
	Sync is called when the clock needs to advance on the bottom-up pass (PC_BOTTOMUP).

---

Detailed Description

The powerflow_object class is an abstract class that implements basic elements of powerflow solutions.

There are two critical pieces of information:

1. phases indicates the phases which are connected by this object. This may be any feasible combination of the phase flags
   • PHASE_A for phase A connections
   • PHASE_B for phase B connections
   • PHASE_C for phase C connections
   • PHASE_N for neutral connections
   • PHASE_D for delta connections (implies A, B, C);
   • PHASE_A for split connections (requires one of A, B, or C);
   • PHASE_ABC for three phase connections
   • PHASE_ABCN for three phase connections with separate neutral
2. reference_bus indicates the bus for the reference frequency and voltage at which the solution is to be computed. The current solution method does not change the frequency nor does it consider the frequency in the powerflow calculated. The parameter is only to be used to adjust frequency-sensitive loads, such as Grid-Friendly^TM devices.

In addition, each powerflow_object defined must specify what it's parent object is for the purposes of establishing the evaluation order through the ranks. The reference bus is also propagated using the rank order.

The powerflow_object provides optional support for outage conditions when compiled with the SUPPORT_OUTAGES flag is defined in powerflow_object.h. When enabled the following parameters are also defined

1. condition indicates the device's operating condition with respect to abnormal phase configuration that would require special consideration during the powerflow solution. This can be any combination of two of the following
   • OC_NORMAL for no abnormal configuration (excludes all others)
   • OC_PHASE_A_CONTACT phase A in contact
   • OC_PHASE_B_CONTACT phase B in contact
   • OC_PHASE_C_CONTACT phase C in contact
   • OC_NEUTRAL_CONTACT neutral in contact
   • OC_SPLIT_1_CONTACT split line 1 in contact
   • OC_SPLIT_2_CONTACT split line 2 in contact
   • OC_SPLIT_N_CONTACT split line N in contact
   • OC_GROUND_CONTACT ground in contact
   • OC_PHASE_A_OPEN phase A is open
   • OC_PHASE_B_OPEN phase B is open
   • OC_PHASE_C_OPEN phase C is open
   • OC_NEUTRAL_OPEN neutral is open
   • OC_SPLIT_1_OPEN split line 1 is open
   • OC_SPLIT_2_OPEN split line 2 is open
   • OC_SPLIT_N_OPEN split neutral is open
   • OC_GROUND_OPEN ground connection is open
2. solution indicates whether special solution methods are required. The base powerflow_object only recognized the normal solution method (PS_NORMAL), but each object may add its own identifiers, so long as it does not conflict any identifiers in the object inheritance hierarchy. When SUPPORT_OUTAGES is defined, the flag PS_OUTAGE is also defined and can be used to engage an alternate solution method.

Outage support

When SUPPORT_OUTAGES is defined, the postsync pass will examine whether condition and solution are matched. If there is an inconsistency (i.e., condition != OC_NORMAL && solution == PS_NORMAL or condition == OC_NORMAL && solution != PS_NORMAL), then they will be reconciled and the solver will iterate again. Object derived from powerflow_object can inspect the value of condition to determine whether they can use the normal powerflow solution method, or an alternative method that is appropriate for abnormal conditions. Be aware that this may result in a change of state in some other object that may cause the solver to reiterate. It is highly recommended that state changes to OC_NORMAL have a non-zero delay built in (i.e., allow the clock to advanced). Failure to do so may result in non-convergence of the solver.

---

Function Documentation

EXPORT int create_powerflow_object	(	OBJECT **	obj,
		OBJECT *	parent
	)

REQUIRED: allocate and initialize an object.

Parameters:

	obj	a pointer to a pointer of the last object in the list
	parent	a pointer to the parent of this object

Returns:

1 for a successfully created object, 0 for error

Definition at line 264 of file powerflow_object.cpp.

EXPORT int init_powerflow_object

(

OBJECT *

obj

)

Object initialization is called once after all object have been created.

Parameters:

obj

a pointer to this object

Returns:

1 on success, 0 on error

Definition at line 287 of file powerflow_object.cpp.

EXPORT TIMESTAMP sync_powerflow_object	(	OBJECT *	obj,
		TIMESTAMP	t0,
		PASSCONFIG	pass
	)

Sync is called when the clock needs to advance on the bottom-up pass (PC_BOTTOMUP).

Parameters:

	obj	the object we are sync'ing
	t0	this objects current timestamp
	pass	the current pass for this sync call

Returns:

t1, where t1>t0 on success, t1=t0 for retry, t1<t0 on failure

Definition at line 304 of file powerflow_object.cpp.