Configuring Power Flow
PFService (Power Flow Service)
The main application that runs the majority of the Oracle Utilities Network Management System Distribution Management business logic is the Power Flow service. If your environment will be running any applications listed in the previous section (except Web Switching and FLISR), you must add the Power Flow Service as a system service by updating the $NMS_HOME/etc/system.dat file. There are 3 main sections where this service needs to be defined: the service, program and instance sections. See the $NMS_BASE/templates/system.dat.template file for examples of how to configure the Powerflow Service. Search for PFService in the file and copy those lines to $NMS_HOME/etc/system.dat file. Make sure all lines are uncommented so that they are active. You must restart the system services in order for the Powerflow Service to be properly monitored by SMService.
The command line options for PFService are:
• pfdbs: Use a dedicated database connection, rather than the common pool. Requires a corresponding PFDBService instance to be defined in system.dat
Non-Converged Islands
When PFService encounters apparent model errors that preclude a solution for an island, the island is marked as "Non-Converged" and the Power Flow solution attempt is stopped. The island at this point is ‘disabled.’
To output the list of disabled islands to the PFService log file:
Action any.PFService dump_disabled_islands
When the model has been rebuilt with data to solve the error, you may re-enable the island:
Action any.PFService reenable_island <source alias or handle>
Power Flow Inheritance
PFService uses class inheritance to determine which devices in the model have certain properties, or can be considered for certain actions. The classes used for inheritance are:
• pf_backfeed_detect: the set of classes that should be checked for backfeed power violations.
• pf_dist_gen: the set of classes that should be treated as distributed generation units.
• pf_capacitors: the set of classes that should be treated as shunt capacitors.
• pf_feeder_cls: the set of classes that should be treated as feeder head circuit breakers.
• pf_lines: the set of classes that should be considered as conductors with power flow attribution (e.g., catalog data).
• pf_loads: the set of devices that should be considered as load points for powerflow analysis (e.g., load interval and ratings data).
• pf_transformers: the set of devices that should be considered as transformers with power flow attribution.
• pf_regulators: the set of devices that should be considered as voltage regulators with power flow attribution. Regulators will be similar to transformers except rated in amps and violations will be flagged in terms of amps.
• pf_sub_xfmr: the set of devices that should be considered as substation transformers with power flow attribution.
• pf_isolate_switch: the set of classes to consider for isolate operations in suggested switching.
• pf_restore_switch: the set of classes that indicate which devices should be considered as tie points within the model.
• pf_scada_isolate_switch: the set of classes to consider for SCADA isolate operations in suggested switching.
• pf_scada_restore_switch: the set of classes that indicate which devices should be considered as SCADA enabled tie points within the model.
• pf_opf_enabled_devices: the set of classes which needs to be selected by default to take part in the volt-var operations in the study mode.
• pf_opf_excluded_devices: the set of classes which should not appear in the controllable devices list of study mode volt-var gui.