Draft Notes and Potential Guidelines Associated with MOD
Date: May 12, 2015
During the course of MOD development, we have observed that for majority of the power flow data fields there are direct one to one connections between PSS®E and PSLF. Data conversions for such data fields between the two software platforms are relatively more straightforward. However, for a number of data fields the direct one to one connections are not there. Special considerations were taken in MOD to make sure such data records are converted properly between the two platforms.
In the following we are noting MOD’s approach for treating several such data fields where there do not exist the direct one to one connections between the two software platforms.
Most of the discussions in this document are for your information. In a few places, we are recommending potential WECC guidelines that would involve actions by WECC and/or WECC members.
Area, Zone and Owner
Several of the PSS®E records do not have the direct reference to Area / Zone / Owner that the PSLF records have, therefore care must be taken to ensure that records originating from PSS®E reflect the correct associations in both software platforms. The following is the default behavior in MOD:
Adding a new device:
For new equipment added from a PSS®E project, the area / zone will be assigned based on the bus area / zone. For branch type records, the non-metered end bus will be used to assign the association.
Modifications to existing device ( already in the MOD system base case):
For PSS®E projects where the area / zone for a bus is changed, during the project import MOD will augment the project to apply changes to the appropriate equipment in the base case to reflect the area / zone association change. As above for branch type records, the non-metered end bus will be used to assign the association.
For such an existing data record from a PSS®E area that is not modified by any PSS®E project, the base case area and zone numbers are retained.
If an individual user wants to override the default behavior, the project can be directly edited within the MOD GUI to assign the appropriate PSLF Area / Zone to the data record. If the MODIFY or ADD record for the device already exists within the project, the user simply needs to locate the record and set the PSLF Area / Zone field to the desired new value. If the record does not exist, a new MODIFY record can be added for the device to set the PSLF Area field.
MOD also has the following restrictions related to the bus area numbers:
For a three-winding transformer in a PSLF area, the midpoint bus should also be in a PSLF area.
Area number for a bus should not be changed from one of the PSLF areas to one of the PSSE areas, or vice versa. In other words, a bus that is in one of the PSLF areas should not be reused as a bus in one of the PSSE areas, or vice versa.
The second restriction above is for near term. Siemens has been undertaking MOD changes to accommodate bus area migration between a PSLF area and a PSSE area.
To maintain consistent numbering for buses generated during the conversion process, the binary mapping file(.epc2raw) generated by the WECCLF converter needs to be maintained within MOD. It is important that this be done from the initial creation of the database schema during the first MOD system base case import. When a user imports the base case from MOD Administrator, the user will be prompted to select the bus mapping file. This will be used during the import process to generate the proper bus numbers.
The MOD File Builder menu on the MOD home web page has options for uploading and downloading the binary bus mapping file. All users will be able to download the mapping file. Only administrators with the “Model Configuration” privilege in their user role will have access to the “upload” option.
After importing the initial base case for MOD, the administrator user needs to upload the bus mapping file to MOD. After this, all MOD File Builder users need to download this file for MOD File Builder to use while creating projects. (This file is needed in addition to the MOD Config file already available for download, and the target location can be same as where Config file is designated.
Discussions in this section (Section 2) can potentially be developed into a guideline item.
In PSLF, VSCHED is a data field in bus data table, while in PSS®E it is not. VSCHED is a data field only in generator data table in PSS®E.
Although in PSLF there is a VSCHED data entry for every bus, it is used only for generator and SVD voltage controls. Only the VSCHED entries associated with the buses which voltages are regulated by generators or SVDs are actually used.
Therefore, when converting data from PSS®E platform to PSLF platform, MOD focuses on VSCHED entries associated with the generator and SVD voltage control records in PSLF platform.
For those buses which voltages are regulated by generators, MOD converts VSCHED entries by a direct assignment because VSCHED is an existing data field in both platforms for such buses.
For those buses which voltages are regulated by SVDs, MOD populates VSCHED entries in PSLF platform using the following equation when importing PSS®E projects in MOD.
VSCHED = (VSWHI + VSWLO)/2
where VSWHI and VSWLO are the controlled voltage upper and lower limits in switched shunt data table in PSS®E platform.
It should be further noted that VSCHED data entries other than those associated with the buses which voltages are regulated by generators or SVDs remain unchanged when MOD converts data from PSS®E platform to PSLF platform.
Line shunts data
Line shunts are modeled as part of the line data records in PSS®E platform while they are modeled in fixed shunts data records in PSLF platform. If a line shunt in PSS®E platform is modified such that its admittance is zeroed out, the corresponding line shunt in PSLF platform is switched off. If such line shunts are desired to be removed from the PSLF cases, users need to delete them manually. This can potentially be developed into a guideline item for line shunts data being modified by PSS®E projects.
Fixed tap, variable tap and maximum and minimum tap ratios
In this document, the term variable tap is used to refer to tap ratio associated with the on load tap changer. The variable tap in PSLF is also referred to as TCUL. In PSS®E, the variable tap can be modeled using Winding 1 off-nominal turns ratio (WINDV1).
In PSLF, “from” winding has a fixed tap and also a variable tap. While in PSS®E, Winding 1 has only one off-nominal tap.
Because of this modeling difference, when variable taps are converted between the two platforms, TCUL values are not directly assigned to WIND1 values, or vice versa. Instead, the following equation is used by MOD.
WINDV1 (in pu) = tapfp + tapp – 1
where WINDV1 is the Winding 1 off-nominal tap position in PSS®E, tapfp is the “from” winding fixed tap ratio in PSLF, tapp is the “from” winding variable tap ratio (TCUL) in PSLF.
Similarly, the following equations are used when MOD converts maximum and minimum tap ratios between PSLF and PSS®E.
RMA1 (in pu) = tapfp + Tmax – 1
RMI1 (in pu) = tapfp + Tmin – 1
where RMA1 and RMI1 are upper and lower limits of Winding 1 off-nominal tap ratio in PSS®E, and Tmax and Tmin are upper and lower limits of “from” winding variable tap ratio in PSLF.
Also, when transformer data is converted from PSS®E platform to PSLF platform, tapfp is always set to 1.0 because there is not a corresponding data field in PSS®E.
Additionally, for any new or modified transformer projects in PSS®E platform, if Tmax=0, MOD sets the value to 1.1. Similarly, if Tmin=0, MOD sets the value to 0.9.
Transformer tap control type
For a (voltage or power) controlling transformer in PSLF platform, if either Vmax=Vmin or Tmax=Tmin, the transformer type is changed to 1 (non-controlling type).
Transformer zptr zptx ztsr ztsx and vnomt
For any two-winding transformer, MOD gives “0” value to zptr, zptx, ztsr, ztsx and vnomt data fields, as these are for three-winding transformers.
Loss assignment data for three-winding transformers
Due to differences in loss assignment modeling for three-winding transformers between the two software programs, exact conversion of the loss assignment data cannot be achieved.
The default approach presently used by MOD is discussed in the following.
In PSLF, ALOSS, ALOSSS and ALOSST are primary, secondary and tertiary winding loss assignment factors. In PSS®E the corresponding field is NMETR, the non-metered end code.
When converting the loss assignment data from PSS®E platform to PSLF platform, ALOSS, or ALOSSS, or ALOSST is set to 1 based on the winding non-metered end code, and the remaining two are set to 0.
When converting the loss assignment data from PSLF platform to PSS®E platform, the conversion table listed in the following is used by MOD.
Primary to tertiary and tertiary to secondary MVA base
For a 3-winding transformer in PSLF platform, if tbasept (primary to tertiary MVA base) is 0, MOD sets the value to be the same as its primary to secondary MVA base. Similarly, if tbasets (tertiary to secondary MVA base) is 0, MOD sets the value to be the same as its primary to secondary MVA base.
Long IDs and Name Fields
In PSLF, long ID is a data field for transformer data records, while it is not in PSS®E. The data field that is a close match is transformer name.
MOD’s default behavior is that if there is a PSS®E project that adds or modifies a transformer record from a PSS®E area, the long ID for the transformer is populated using the transformer name. If a transformer record from a PSS®E area is not modified by any PSS®E project, long ID from the base case is retained.
Similarly, if a load in a PSSE area is not modified, the long ID from the base case is retained. For new loads added by PSSE projects, the long ID is kept blank. The MOD user can manually enter the long ID.
For both long IDs and name fields, some data conversion takes place if character data is outside the standard ASCII “printable” characters. Characters outside the acceptable set will be converted to a question mark (“?”) in the database. Also, the comma (“,”) character will be translated into an underscore (“_”) character because the comma is used as a special character within the data converter code.
For a full list of acceptable characters, please see an ASCII printable character reference, e.g.: http://www.w3schools.com/charsets/ref_html_ascii.asp
Transformer tap control step
When converting transformer tap data from PSS®E platform to PSLF platform, MOD’s default approach for determining the sign of the transformer tap control step is as follows:
If the regulated bus is the same as the from bus, the transformer tap control step is given a positive sign; if the regulated bus is the same as the to bus, the transformer tap control step is given a negative sign.
If the regulated bus has the same base kV as the from bus has, the transformer tap control step is given a positive sign; if the regulated bus has the same base kV as the to bus has, the transformer tap control step is given a negative sign.
Users are advised to check if the above default approach works correctly for your transformers. If not, the sign should be corrected manually.
Siemens has been evaluating a new approach that will eventually remove this limitation in long term.
SVD/switched shunt data
6.1 Multiple SVDs on one bus
In PSLF, multiple SVDs can exist on one bus. An SVD is uniquely identified by both a bus number and an id. In PSS®E, switched shunts do not have id data field. One bus can host only one switched shunt.
When data for multiple SVDs on one bus is converted from PSLF platform to PSS®E platform, one of the SVDs is assigned to the original bus and the rest are assigned to dummy buses connected to the original bus by zero impedance branches.
6.2 Modifications to SVD data
When creating multiple new SVD records on a single bus, there is the potential in the converter to reorder the PSS®E switched shunt records on the generated bus numbers which created inconsistencies with the MOD system base case. To overcome this issue in MOD File Builder, for any SVD modifications it is necessary to delete the base case switched shunt records and add all the related switched shunt records again with the newly generated bus numbering.
In PSLF, if VBAND<=0 for type 3 or 4 SVDs, Vrefmax and Vrefmin are used in place of VBAND. Since PSS®E does not have VBAND data field in switched shunt data table, when converting switched shunt data from PSS®E platform to PSLF platform, MOD sets VBAND to 0 and populates Vrefmax and Vrefmin using VSWHI and VSWLO (which are upper and lower limits of voltage control range in PSS®E). This action takes place only for new or modified SVDs from PSS®E areas. If a type 3 or 4 SVD is not modified by any project, its VBAND value in PSLF platform stays unchanged.
HVDC DC bus data
DC bus is not a data field in PSS®E, but is a data field in PSLF. When new two-terminal HVDC projects in PSS®E platform are imported in MOD, MOD generates new DC buses for data in PSLF platform. If desired, users can manually change these DC bus numbers in or outside MOD. This item should be worked into a guideline.
The equipment ID has a length of two characters in both PSS®E platform and PSLF platform. MOD removes the leading or trailing blank space if an ID has only one character.
Numerical data limitations
9.1 Generator Zsource impedance
For Zsource impedance data, PSS®E has a maximum limit of 9999. If real or reactive part of Zsource impedance is greater than 9999, it is set to 9999.
9.2 HVDC converter alpha/gamma maximum limit
When PSS®E exports raw data file, it assumes an upper limit of 90 degress for alpha max or gamma max data entry. If this limit is exceeded, PSSE will change the data field to asterisks in the raw file. When the raw file is read into PSS®E, an error message will be printed in the progress window.
9.3 Numerical data too small or too large
When PSS®E exports raw data file, any data that is too small or too large (e.g., 3.8e-12, 2.3e19, etc.) such that it exceeds the numerical limit PSSE has for a data field, PSS®E will change the data entry to asterisks in the raw file. When the raw file is read into PSS®E, an error message will be printed in the progress window. Users are advised to manually modify the relevant data entry in the raw file.
Share with your friends: