Labels

Concept Link IconSee Also

 

Using Labels for Identification

Most data objects (such as buses, generators, loads, switched shunts, transmission lines, areas, zones, and interfaces) may have alternative names assigned to them. These alternative names are called labels. Labels allow you to refer to equipment in the model in a way that may be unique to your organization. Labels may thus help clarify which elements are described by a particular set of data, especially when the short names employed by the power system model prove cryptic. Furthermore, since labels are likely to change less frequently than bus numbers, and since a label must, by definition, identify only one power system component, they may function as an immutable key for importing data from auxiliary files into different cases, even when bus numbering schemes change between the cases. Labels must be unique for devices of the same type, but the same label can be used for a device of a different type.

Information dialogs corresponding to buses, generators, loads, switched shunts, transmission lines, areas, zones, and interfaces feature a button called Labels. If you press this button, the device’s Label Manager Dialog will appear. The Label Manager Dialog lists the labels associated with the device and allows adding, deleting, and modifying labels. The Labels (All) field (variablename = LabelsAll) in a Case Information Display lists all of the labels that have been associated with a device. The device's primary label is the one that is listed first in this field. This field lists all labels assigned to a device as a comma-delimited string. Even though multiple labels may be assigned to a device, any label can be used to import data from auxiliary data files. The Label Manager Dialog can be used to assign labels or the string of labels can be entered directly in the Labels (All) field.

Labels can be used to map data from an auxiliary data file to a power system device. Recall that auxiliary data files require you to include a device’s key fields in each data record so that data may be mapped to the device. Labels provide an alternative key. Instead of supplying the bus number to identify a bus, for example, you can supply one of the bus’s labels. The label will enable Simulator to associate the data with the device associated with that label. This mechanism performs most efficiently when the primary label is used, but other labels will also provide the mapping mechanism. The Label (for use in input from AUX or Paste) field (variablename = Label) is used for importing data using labels and will display only the primary label if more than one label has been assigned. Keep in mind that all devices read via an auxiliary file using the label field should have a non-blank label. Otherwise, information for that device will not be read. Even if the primary or secondary key fields are provided with the device, as long as the label field is present, that is the only field that will be used to identify the device. New devices cannot be created by simply identifying them by label. Either the primary or secondary key fields must be present to create a new device and the label field should not be present.

Again, it is important to remember this: a single power system device may have multiple labels, but each label may be associated with only one device of a particular type. This is the key to enabling data to be imported from an auxiliary file using labels.

Saving Auxiliary Files Using Labels

All devices that can be identified by labels will have the Labels (All) and Label (for use in input from AUX or Paste) fields available in their case information displays. In order to save auxiliary files that identify devices by label, the two label fields should be added to the case information display prior to saving the data in an auxiliary file. Keep in mind that devices with blank labels cannot be identified when loading in an auxiliary file, so avoid saving auxiliary files by label if all devices do not have labels.

Many devices require SUBDATA sections. These sections have custom formats specific to the type of information that they contain. When saving auxiliary files with devices that require SUBDATA sections, the user can choose to use primary or secondary key fields or labels to identify devices in the SUBDATA sections. The user will either be prompted when saving the devices, or there is an option to change the key field to use when saving subdata sections on the PowerWorld Simulator Options dialog under the Case Information Displays category. When choosing to use labels, if a device has a label, it will be used. If it is a device that can be identified by buses and bus labels exist, bus labels will be used. Finally, if the device does not have a label and the buses do not have labels, the primary key for the device will be used for identification.

Devices that have SUBDATA sections that contain other devices that can be identified by labels include: contingencies, interfaces, injection groups, post power flow solution actions, and owners.

The setting to choose which identifier to use for the SUBDATA sections does not just apply to SUBDATA sections. Often when saving groups of options, this setting will apply to everything being saved with those options and not just the SUBDATA sections. This includes contingency options, ATC options, limit monitoring settings, and PVQV options. In these cases, there will be a prompt asking the user to decide which identifier to use in the auxiliary file.

Loading Auxiliary Files SUBDATA Sections Using Labels

The various SUBDATA sections that represent references to other objects can also be read using labels. Examples include contingencies, interfaces, injection groups, post power flow solution actions, and owners. When reading a SUBDATA section such as this, PowerWorld makes no assumption ahead of time about what identification was used to write this SUBDATA section. Instead, an order of precedence for the identification is as follows

 

Identification

Explanation

Example

1

Key Fields

assumes that the strings represent Key Fields

BRANCH 8 9 1

2

Secondary Key Fields

assumes that the strings represent Secondary Key Fields

BRANCH Eight_138 Nine_230 1

3

Labels for component objects

the key/secondary key fields for some objects consist of references to other objects. An example of this is the BRANCH object that is described by the From Bus, To Bus, and Circuit ID. This assumes that labels of the component objects are used.

BRANCH Label8 Label9 1

 

4

Labels

Assumes that the string represents one of the Labels of the object

BRANCH LabelForBranch

Special Use of Labels

There are a few special cases where objects have fields that identify other devices. These devices can be identified by label but not in the conventional means because the label field applies to the object that contains the device and a SUBDATA section is not necessary. These special cases include: (Note all fields given below are by variable name because the use of labels is most relevant with auxiliary files.)

ATC Scenarios

ATC Scenario change records usually contain primary key fields to identify the devices that should be adjusted during the scenario. If using labels, these primary key fields will be replaced with a single Label field. The use of this field is different because the Label field refers to the device in the change record and not to the change record itself. When labels are used with ATC scenarios, device labels only can be used. Bus labels cannot be used to identify devices for which no label exists but a bus label does.

ATC Scenarios are saved in an auxiliary file if choosing to Save Settings on the ATC Dialog.

ATC Extra Monitors

ATC Extra Monitors identify either branches or interfaces to monitor during the ATC analysis. These devices are identified in the WhoAmI field of ATC Extra Monitor records. Usually, the WhoAmI field is a special format that contains key field tags. Optionally, this field can use the label of the device for the extra monitor. If the device label is not available, the standard format will be used. There is no option to use bus labels if they exist and the device labels do not.

ATC Extra Monitors area saved in an auxiliary file if choosing to Save Settings on the ATC Dialog.

Model Conditions

Devices in Model Conditions are usually identified by the WhoAmI field which is in a special format that contains key field tags. Optionally, this field can use the label of the device. If the device label does not exist, the standard format will be used. There is no option to use bus labels if they exist and the device labels do not.

Model Expressions

Model Expressions contain Model Fields. Model Fields are identified by the WhoAmI fields in the Model Expressions. Usually, the WhoAmI fields are in a special format that contains key field tags. Optionally, these fields can use the label of the device associated with the Model Field. If the device does not exist, the standard format will be used. There is no option to use bus labels if they exist and the device labels do not.

Bus Load Throw Over Records

Bus Load Throw Over Records are used with contingency analysis. These records have an option to identify the bus to which the load will be transferred by either number or name_kV combination. If choosing to identify objects by label, the BusName_NomVolt:1 field will contain the label of the bus instead of the name_kV combination.

Bus Load Throw Over Records will be saved in an auxiliary file if choosing to Save settings on the Contingency Analysis dialog.

Injection Group Participation Points

All participation points and the injection groups to which they belong can be listed on the Injection Group Display. Load, generator, and shunt devices that can be assigned to a participation point must be identified by bus and ID. The bus can be identified by either the number or name. When identifying by name, the BusName_NomVolt field is used to provide the name_kV combination for the bus. If choosing to identify devices by label, this field instead will contain the label of the device. If the device does not have a label but the bus does, the bus label will be used instead in conjunction with the ID of the device. Even if the device does contain a label, the ID field must be included in any auxiliary file that is going to be loaded because it is a key field. Injection groups can be included in other injection groups. Injection groups can be identified by label, even though this is not a normal thing to do. If any injection groups have labels and these injection groups are included in other injection groups, their labels will also appear in the BusName_NomVolt field. If they do not have labels, they will be identified by the injection group name that appears in the PPntID field.