Visual Solution Import (VSI)

Fundamentals

Deep-Editor is a visual tool operation and planning studies of electrical systems. Deep-Editor features a module that allows users to display operational results obtained from popular economic dispatch, Unit Commitment and Hydrothermal Coordination tools (most popular in Latin America). Deep-Editor features its own optimization tools for economic dispatch, unit commitment and hydrothermal coordination (SEEDS) as seen in the Analysis Tools section. However, Deep-Editor interface allows visualization on its own schematic results from other software cases. This tool is called Visual Solution Import (VSI for short).

The Visual Solution Import serves DeepEdit as interface with external software dispatch solutions. It features 2 major functionalities:

• Schematic Update: Update the current displayed schematic (and DeepEdit component’s) with values from dispatch software.

• Create visualization reports for displaying as DeepEdit’s tabbed reports (using both char and table views).

This section will cover the Schematic update functionalities: options, sources, formats and “how to” guidelines. The VSI reports is covered in the

Main Components:

The two main components of the Schematic Update functionality of VSI are:

• Topology Checker: This tool checks and fixes differences in components between current schematic and the dispatch software solution.

• Dispatch Solution Loader: This is the main tool to query external software files and update the results in current schematic. There are 2 different sources for external software: local and remote files.

Data Source:

Two fundamental sources are then required:

1. Schematic file: This is the schematic file that should have similar characteristics of the elements in the external software result files. That is, a schematic that contains lines, bars, generators, loads with similar nomenclature used by the external software. This process CAN BE AUTOMATED making use of the Topology Checker tool described in this section. Some “manual” visual arrangement of elements in a unilinear is still necessarily and may require additional user intervention. CE-FCFM can also prepare schematics for different output file software on request.

1. External Software Output files: In general, Deep-Editor expects the structure of files / folders / subfolders WITHOUT alterations (that is, the results as they were thrown by the software, without any modification). These are the raw native software output files. No intermediate files, user intervention or format modification is required. User may need to configure DeepEdit to currently read files in terms of file separator, comma character, date format only.

As mentioned above, the external software data can be read from 2 different sources:

1. Local output files: This is, the Deep-Editor can look for the external dispatch software output files in a local address (folder or file). The files, which are usually text file format (some according to industry standard), are read from the local disk, parsed, and loaded into the current schematic.

1. Online Software Repository (database): Deep-Editor can connect to a database (MySQL or MS Access) and extract the dispatch file information. This is a custom-designed database. CE-FCFM has a beta information system with test cases. More details in the data reading section from database.

Access to Visual import tool

Select “Visual Solution Import” option from the Analysis Tools menu as shown in Figure 54:

Figure 54. Analysis Tools

Figure 55 Shows the main VSI window. There are 3 taps related to 3 different functionalities of the tool:

• Local: This tab provides essential information for loading dispatch from local files.

• Server: This tab provides the essential information for loading dispatch from local files.

• Output: This tab provides the interface for executing the Topology Checker and additional information about the destination of the dispatch results: destination Schematic configuration, log file and destination database.

Figure 55. Visual Solution Import main interface

Topology Checker

The topology checker is a DeepEdit utility to automatically update schematic components from external software source files. It is part of the VSI and, thus, it uses the same source of information: raw dispatch software output files. The checker compares object names and connection points in the source raw external files with the object names and connections in current schematic network. The object names and connections that will be checked/fixed are:

• Object Names: Busbars, Generators, Lines, Transformers, Loads

• Connection problems: Generators->Busbars, Lines/Transformers->Busbars From/To and Loads->Busbars.

Figure 56. Topology Checker access

The topology checker is accessed from the Output tab of the main VSI window as shown in Figure 56. The tool has a convenient wizard to guide user through the topology verification and fixing process.

The topology checker will detect and fix object and connection mismatches. The list of mismatches will be presented in the interface (as tables) in the addition and edition steps of the wizard. The topology checker will delete excess components, create missing components and move (reconnect) existing but wrongly connected components in schematic (as compared to external output software files). This is performed automatically by the tool. The user must define:

• Define the type of external output software: Currently supported software includes PLEXOS, PLP and PET (Chilean must popular dispatch commercial tools).

• Location of external output software files: Full path to the external software output folder (for PLP and PET) or output file (mbd or zip for PLEXOS).

• Define the addition actions: Select the elements to be automatically created. The topology checker will suggest a default action. The left-side screenshot in Figure 57 shows an example of the addition detections.

• Define the edition actions: Select the elements to automatically delete or reconnect. The topology checker will suggest a default action. The right-side screenshot in Figure 57 shows an example of the edition detections

Figure 57. Topology Checker wizard tables

The user can optionally configure the topology checker to write and/or show the log file upon finalization.

Workflow

Usage is very straightforward as it is guided by the topology checker wizard. However, to create perfectly synchronized (with the external software) and neat schematics, it is recommended to follow this overall execution guideline:

1. Open an existent schematic or create a new schematic.

1. Run the Topology checker and take note of all missing busbars (section and copy/paste is permitted in the addition/edition section Figure 57). Cancel the checker and return the schematic.

2. Manually create and place all missing busbars using the exact same spelled names (case sensitive).

3. Run the Topology checker again and let the tool create/delete/reconnect all elements.

4. Verify if some elements are outside the visible area: This can happen when busbars are automatically created. Place the busbars. It does not matter if the generators are outside the visible are (impossible to drag and drop). Place the busbar “safely” in the visible area.

5. Run the topology checker again. Many re-connections will be suggested. Let the tool fix the connections.

6. Check for transformer connection differences (as in topology checker report). Manually fix the transformers connections.

7. Run the topology checker again to ensure perfect sync. When schematic is perfectly sync with the output software files, the topology will show a success information dialog.

8. Run the View->View Connections tool: Since topology checker places all elements in the input and output pins of busbars, many elements can end up connected to the same busbar pin. This may affect the execution of some analysis tools. Thus, it is recommended to detect and fix the several possible “more than one” connections (see the Show Connections section of this user manual).

9. Do some final (optional) manual tidy-ups to your schematic, until it looks neat and clear. Some suggested actions may include creating more busbar pins, rotate transformers, avoid lines overlapping, avoid line crosses.

Important considerations

• 1 Load per Busbar: Topology checker requires (forces) Schematic to have 1 Load per Busbar. Even if the load in external software is zero, this is not known beforehand by DeepEdit. Thus, this is a requirement. Topology checker will create and connect to Busbar.

• Loads with different names: Similarly, Topology checker will list loads with names different to Busbar name as deletion candidates. User need to manually deselect those loads from the deletion list. Otherwise, Topology checker will delete all loads with different names.

• Static Compensation: Topology checker will treat shunt compensation elements as loads with names different than the connection busbar. Similarly, to loads with different names, DeepEdit will suggest to remove these loads by default. User need to manually deselect those loads from deletion

• Busbar mismatches will always throw warnings: Busbars are critical for the network design. Thus, Topology checker will warn user to first create and locate. It is strongly recommended to take note of the busbars (copy /paste is allowed from the mismatch tables) and introduce the busbars manually to schematic. Automatically created Busbars are (all) placed in the default location (usually top-left corner of the schematic window). Thus, many busbars can overlap and all other automatically connected elements too.

• Inexistent busbars will throw an execution error when creating lines: Both source and dest busbars must be created in advanced before automatic creation of lines.

• Lines between overlapping busbars will create an error: Lines can’t be zero length in the schematic (a dot). Thus, the busbars must be at least 1 pixel away from each other. This can happen if user decide to automatically create busbars (although ill advised). This is the case of lines created from 2 new automatically created busbars.

• Topology checker will not fix transformers location: All transformer connections will be checked and reported. But since transformers pin locations are relatively fixed, they are not easily relocated between busbars. User may need to manually relocate transformers following the topology checker report suggestions.

• Topology checker should be executed more than once: This is detailed in the Workflow section of this user manual.

• Topology checker will not update components parameters. This must be done by user.

Report file

VSI will write an execution "log" file after exporting values with following information (in the same order as presented in the following list):

• Generators, Lines, Buses and Transformers which exist in output files from external software, but do not exist in current schematic.

• Generators, Lines, Buses and Transformers which exist in current schematic, but do not exist in output files from external software.

Output folder file log is configured under "Log File Location" in the "Output" of interface tab. File name (text) always is "VisualImport.log". In case of not filling the route, VSI will use the default folder of the Deep-Editor results: DEEPEDIT_INSTALATION_FOLDER / results /.Schematic Configuration

Destination Schematic File

VSI can load external dispatch into different Schematic destinations:

• Current active schematic (option “Use Current Schematic” on section “Schematic”).

• Schematic from DeepDB.mdb or DeepDB.db (option “Use Schematic from DeepDB.db” on section “Schematic”).

VSI allows updating the DeepEdit data base (called DeepDB.db) with current squematic by clicking the “Update” button, once the “Update DeepDB.db with schematic” option is selected. This function works like “Save Database” from “File” menu in the main Deep-Editor frame.

Dispatch Solution Loader: Import from local files

User must follow this procedure to load dispatch results from supported software into current schematic:

• Open schematic desired to be used for the import process. Use normal Deep-Editor interface to open the schematic or load from database.

• Launch VSI interface: Select menu Analysis Tools / Visual Solution Import.

• (Optionally) execute the topology checker: It is recommended to first execute the topology checker if the schematic is not synchronized with the output software or the user is unsure about it. This process will still detect and execute the topology checker, but it is recommended and entire workflow for obtaining desired results (see section Workflow of the Topology Checker).

• Configure the path to input files: Button "Browse" displays the file browser window. Select input folder. IMPORTANT: Read notes about PLP / PCP and OSE2000 button.

• Select output type (section Supported Formats): Deep-Editor will not automatically select this field. This must be defined by user.

• Select case: define the datetime information of the dispatch instance that should be loaded in schematic. Output files can contain dispatch results ranging from 1 week to even years, as well as several simulations (hydrology). The user must enter in the Time Control table the individualization of the dispatch to be loaded in schematic. The table below shows the required fields as a function of the type of output software.

• Click “Load” to start the file reading and schematic update process. This process can take several minutes, depending the size of the output software files.

Table 1. Time Control: software Dispatch definition Fields

Figure 58. Dispatch loader from Local Files

Note about PLP/PCP files:

PLP and PCP are 2 Chilean traditional software used by the system operator and many other local agencies. Output files for these software is traditionally shared by the Chilean market operator in 2 different folders: entry (known as IPLP) and exit (OPLP). Since the routine needs to read files in both folders, VSI expects that the specified directory points at the “parent location” (or parent folder) of both input and output folders. Table 2 shows the exact expected nomenclature. The required file structure is clearly illustrated in Figure 59.

Table 2. PLP and PCP folder Nomenclature

Figure 59. Folder structure for PLP and PCP files

From the figure:

• The correct route to read from PCP must be: C: \ Work \ Cases \ PCP

• The correct route to read from PLP should be: C: \ Work \ Cases \ PLP

  As mentioned before, VSI assumes that the user stores the input (.dat) and output (.csv) files arranged in subfolders called "IPCP" and "OPCP, respectively.

Note about OSE2000 Files

OSE2000 is another Chilean software commonly used by the Chile regulator and other local agencies and market participants. The required folder structure for OSE2000 is:

• BarCMg: Folder with output (annual) busbar files.

• CeGen: Folder with output (annual) generation result files.

• LinFlu: Folder with output (annual) with line flow result files.

Figure 60. Folder structure for OSE2000 files

Dispatch Solution Loader: Importing from Repository

Procedure to load results from supported external software by VSI is described as follows:

Figure 61. Dispatch loader from dispatch case repository

• Select "Retrieve from external source" on "Server" tab.

• Configure source base data (optional in "Configure DB" configuration window Figure 62)

• Execute the depository database query to retrieve cases (click on Retrieve Cases). VSI will query and retrieve available cases and populate the “Available Cases in Database” list.

• Upon finalization, the user can then select (click) the desired case from the available cases list.

• Select the format: In the case of the CE-FCFM server, the nomenclature used to label PCP cases is as System = SING. In the same way, the PLEXOS cases are identified as System = "SING". This selection is NOT automatic, the user must indicate the correct option.

• Select the dispatch specification to load. See section Dispatch Solution Loader: Import from local files for details of the required fields (same definition).

Figure 62. VIS interface: External dispatch repository configuration window

Notes about CE-FCFM repository

The software is pre-configured to extract data from PCP (Chilean SIC) and PLEXOS (Chilean SING) from a MySQL database server hosted by the CE-FCFM on IP route 146.83.6.25 (port 3306). Approximately 100 cases between 2011 and 2012 are available on this location.

This beta server is no longer maintained by CE-FCFM.

Please contact the CE-FCFM or DeepEdit project manager (see section Contact Information) if you wish to configure a PCP, PLP, OSE or PLEXOS or another software-related database on a local or public server.