cajief's profile - activity

One approach is to use the set of model "IND" functions that retrieve the starting indexes for various STATEs,VARs, and so on. The exact function used depends on the model type: mdlind is used for generator plant models, lmodind is used for load models, etc. Generally the functions are defined in Section 7 of the API, but you may have to hunt a bit for the specific model type.

For example, assume the real output power of a generator at bus 10000 is stored in VAR(L+15) of the generator model. A VAR channel can be added with the code below. ival represents the starting VAR index of that specific model. No modifications to the code below are required for different dyr files :

ierr, ival = psspy.mdlind(10000,"""1""", 'GEN','VAR')
psspy.var_channel([-1,ival + 15 ] ,"""POUT""")

Majid, is it possible there is a common bus to the source & sink subsystems? In order to clearly define an interface and dispatch area between the two systems there should be not be any electrical overlap. Try and remove the common elements between the two subsystems and see if there error persists.

A .raw file (or .sav file) contains all the information needed to perform load flow calculations and is the electrical model of the system.

A .sub file is used to define smaller "subsystems" within the larger load flow system in the .raw file. The .sub file accomplishes this through defining groups based on certain load flow characteristics: areas, buses, voltage levels, etc. This is then used to create a DFAX file for ACCC analysis. More information about this is in the "Linear Network Analysis" portion of the Program Operation Manual, or search for "DFAX".

For example, imagine you are performing contingency analysis with different voltage criteria between the HV and LV networks. This can be specified through thoughtful combinations of the .sub file and the .mon file. Overall the "sub" file helps one to focus in on the results within the area of interest and can cut out lots of noise from electrically distant portions of the case.

There's an API add machine angle statistics as outputs for a given subsystem:

ierr = psspy.chsb(sid, all, status)

Where status is an array of 6 elements and Status(4) = 8 for machine angle statistics for a given subsystem. Six channels are added with the average angle, largest angle, smallest angle, angle spread, largest angle bus, and smallest angle bus. This can also be accomplished through the menu items Dynamics>>Define simulation output by subsystem>>machine angle statistics.

If you need to multiple "relative" angles for the same run or would like to determine the other reference angles, then I suppose this will have to be done when plotting the results.

Just throwing this out there, but sometimes the things act strange if you have too many out files open at once, or out files of the same name. Also there is really limited error output if your out file/channel strings are wrong. Does recording with a new PSSE window and only one out file work OK?

One other thing to try if you're using Windows 7 is to run in XP compatibility mode, which has worked for some issues. There's instructions on the PTI website on how to do this. Other ideas, are to: re-make the idev, recompile/build the dll, and try to initialize a flat run.

Right on - I wasn't aware of the subprocess32 module when I did this. Sounds like it'll be useful for further iterations! Thanks

In the past I've gone the path Jervis has recommended. In my case, the issue was that PSSE would crash during the fault list or have a criteria violation.

Python was in control using the subprocess command to launch PSSE with an IDEV argument. It was kind of a hack-job but basically it would periodically check if the PSSE process was still running and also scan the log file for violation notifications. If violations were detected, then it would kill the process, make some modifications, and re-run it.

I guess the important question is - what is causing your simulations to hang? What is the best way to detect this condition?

Here's some code below that can be improved upon. The idev it's launching is "run_stab_wvoltage". I remember the first argument to Popen being somewhat sensitive to special characters.

import subprocess
try: #to open pss/e with the newly created idv.
        pssdsInstance = subprocess.Popen(
         ["C:\\progra~1\\pti\\psse30\\pssbin\\PSSDS430.exe",  '-buses','80000','-inpdev', 'run_stab_wvoltage.idv'],
         cwd= activation_path + "\\" + case + "\\", #path where launching PSSE from
         shell=False,
         creationflags=512|16 #CREATE_NEW_PROCESS_GROUP|CREATE_NEW_TERMINAL
        )
        logging.info( "PSSE Successfully Launched! Running %s\%s\%s at %d MW" % (case, condition, faultName, faultMW))
except:
        logging.warning( "ERROR WITH POPEN and PSS/E")

I then used the following commands to see/modify what the process was up to, although you could certainly do something fancier.

pssdsInstance.poll()       #Still running?
pssdsInstance.terminate()  #Kill the process

Good luck!

Hi Sheng, out of curiosity - have you found the built in PSSE PV/QV tools useful? I've observed that the built in modules haven't seemed consistent with previous results and other PV tools, even when trying to apply the same methodology. Any tips on using the built in tools?

What activity is causing the error? FYI sometimes when plotting, using PSAS, etc. the following default folder (win7) fills up with temp files: "C:\Users\<user>\AppData\Local\Temp". In the past when doing lots of plotting I've had to clean the folder, upon receiving a similar error message.

Hey I think the issue you're seeing is due to how percent loading is calcualted on transformer vs. non-transformer branches. Transformers are by default on MVA loading whereas non-transformer are current expressed as MVA loading (assumes nominal voltage). Look in the Program Operation Manual for more on this, specifically ACCC and RATE. ACCC reports the line end with the larger loading.

Yeah that's the idea. IDEV or Python, just something so that you can easily investigate contingencies of interest in isolation. Some CON files I've used have up to the max number of elements (18 I think) per contingency and it's a PITA to disable each element, especially for N-1-1.

Along these lines - it would be useful to have some kind of converter which takes specific contingencies from a CON file and creates IDEVs for more detailed analysis. I made a script which does this (not very robust) but does anyone have a "clever" solution for this (rather than recording)?

PSS/E prints it's output to different "devices" depending on the activity: progress, prompt, and report. The progress output is the one producing the messages you're referring to. To change how the program interacts with these devices there are some API commands.

ierr = progress_output(islct, filarg, options)
ierr = prompt_output(islct, filarg, options)
ierr = report_output(islct, filarg, options)

You can disable these output devices by setting ISLCT=6. However, it's good practice is to save these log files in case something goes awry or for future analysis (i.e. ISLCT=2 & filarg=output file name).

Having the output go to the PSS/E GUI can slow things down when there's a lot of text being printed. Check out the API documentation for more details.

Your approach sounds good. Perhaps we could begin with one of the generic IEEE cases and make some topology/setting tweaks to create the problem? This way there are no data privacy issues. I agree that notification only is much simpler and a logical first step before developing a resolution.

Has anyone put any effort towards developing a python script to detect loop flows/circulating VARs in a large system? If not, how would you approach the problem?

For a simple case (parallel off-tap transformers connected to a single bus) it may not be that difficult, but can the algorithm be expanded to more general cases? I realize that the detection itself is not trivial and there are a number of papers on the subject.

It would be cool to see what the community could come up with!

Sample papers (might not be the best on the subject):

"Circulating MW and MVAR in power systems" Link to abstract (behind paywall)

"Fast Algorithms for Detecting Circular VAR Flows in Large Power-Flow Models" Link - pdf

"On Detecting and Removing Undesired Reactive Loop Flows" Link - google

Not sure how tricked-out your PSSE installation is but in the "Dynamics" menu there is the "Launch NEVA Eigenvalue Analysis" and "Build Matrices for LSYSAN program" options. These might give the matrices. Not sure since LSYSAN output isn't in text format & I don't have the NEVA module installed...

Check out the following API calls: 1) psspy.iterat() 2) psspy.maxmsm(), psspy.sysmsm 3) Not sure how to accomplish this besides the procedure you suggested.

I believe you're referring to the "Summation" property in SLDs. If you look at your toolbar containing the diagram options it's the little "Σ" on the far right. A box with some instructions should pop up.

For more info in PSS/E 30 you can refer to the 2.19.9.4 in the Users Manual or for PSS/E 32 see section 3.8.3 in the GUI Users Guide.

As far as I know there aren't any API's for this functionality. Good luck!

There are a number of ways to do this in Python. One approach is to use "splitext" instead of "basename":

filename, extension = os.path.splitext(savecases)

or if you're only interested in the file name and not the extension...

filename = os.path.splitext(savecases)[0]