I have a script that uses a for loop to iterate through a list of faults on a case. I was wondering if there was a way to check if pss/e is getting hung up on the fault it is running and move on to the next iteration of the loop?
(edit to include code from @drsieb01 's comment)
Example:
for fault in os.listdir('faultfile'):
psspy.runrspnsfile(...file path..)
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!
PSS/E has a feature PDEV and ODEV commands where you can output to a text file which basically logs everything that is happening in the dynamic runs/simulations. This is a good practice in North America where they review this log file before even looking at the outputs or plots.
Based on your edit,
The response files can be waiting on user input, like you suggest, and unless it gets some input will wait forever.
It sounds like you'd prefer to skip the result if it takes too long. Perhaps you could consider running the response in a subprocess and interrupting when an error occurs?
http://stackoverflow.com/questions/11...
This question here considers how to interrupt a command that is taking too long. It looks like there is a great library called subprocess32http://pypi.python.org/pypi/subproces...
which has a timeout parameter included. Then you'd need to write your PSS/E command the same way you'd call it from the commandline:
from subprocess32 import STDOUT, check_output
seconds = 5
env = {"PATH": "c:\Program Files\PTI\PSSE32\PSSBIN"}
output = check_output("psse32 -rspfile %s -nogui" % rspnsfilename,
timeout=seconds, shell=True, stderr=STDOUT, env=env)
Are you talking about dynamics or powerflow?
I'd comment if I could, but I think it'd be helpful if you could post your script and elaborate on what you mean by getting "hung up" on a fault.
Asked: 2013-08-01 15:24:04 -0500
Seen: 1,627 times
Last updated: Aug 11 '13
whit loves you. Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
Sorry, I forgot to say that I am running dynamics. By "hung up" I mean that some error in the fault file has caused pss/e to pause and wait for some input, basically anything that would not return from the psspy.runrspnsfile command.
Example: for fault in os.listdir('faultfile'): psspy.runrspnsfile(...file path..) I'm just unsure if handling the exception with a try/except would handle this case since it is waiting on a return from another function.
So the problem lies in your response file? Those files can be waiting on user input, and 'hang' indefinitely