AdamF's profile - activity

Interesting question. Maybe start by developing a function to determine the number of busses/branches along the shortest route between any two busses. Apply this function to every bus in the case relative to a single bus (slack) and sort the results.

... worry about the dyre order anymore. I just thought of one way to do it: we could have a python script look through the vars and find unique sets of consecutive var values that would correspond to certain models. These models don't changes very often so this might actually be a workable fix.

Currently, we place the user models at the beginning of the dyre file in a certain order so that we can just count the var locations and know where they are stored. This practice dates back a long ways and I'm looking for a more flexible way to find these var locations so that we don't have to ...

Is there any way to use python to find the starting var number for a user-written model? It seems like you should be able to provide the name of the user model and get PSSE to tell you where the vars are for that model.

I'd love to be able to use this info in a solution program so perhaps I will encapsulate the redirect, solve, and parse in a python module, or even a class. I'll be happy to post my work if I get to it some day. Thanks for the advice. -Adam

Now I do remember seeing those APIs at one point, thanks for the reminder:) I'm guessing that the solution results for each iteration would probably not be too hard to parse as they are consistently organized in the progress output.

Is there a way, from within python, to access solution results after performing a newton solution? The things I would like for my programs to access are:

1. Number of iterations to solve (if solved)
2. Largest MW/MVAR mismatch
3. Individual iteration largest change - P,Q,V,A as reported in progress window.

I could theoretically get the number of iterations by repeatedly solving the case while varying the iteration limit and checking psspy.solved() for non-convergence but this is somewhat ridiculous.

The only way that I can think of to get this information is to direct the progress device to a file and then parse the data from the file. Has anyone written code for doing this? Could you share it?

pssehalt_2 seems to stop PSSE from using hours and clears out PSSE's working memory. I haven't tested whether it will load a different DLL after 'halting'. The problem is that after 'halting' PSSE and then trying to 'init' PSSE again, it often crashes both PSSE and python.

This may also provide a way around my issue with not being able to reliably stop or halt PSSE within a python script. Ideally, I would have VBA call one script to read in dyre data, save a snapshot, and compile usermodel code, then call another script to bring up PSSE with the compiled DLL. V32:(

Thanks for the info, very useful. I already have a VBA Excel GUI developed for handling some power flow related data. I'd like to expand the capabilities of the VBA program by calling up python written PSSE interface to get data from cases or even update cases with data from Excel. more...

I have not used shell() before but I'll definitely give it a try. It sounds a bit clunky and maybe slow using fileio if there is to be a lot of data moving back and forth. I'm still curious if there is a way to instantiate python-written classes directly in VBA or if they are incompatible. Thanks

Thanks for the information, very interesting. I'll have to try another editor at some point but I'm a bit concerned about maintaining compatibility with other PSSE/python users who are using IDLE. Any info regarding psspy.pssehalt_2()?

I'd like to be able to write functions in python to interface with PSSE and then call them from a VBA macro in MS Excel. Has anyone attempted this? Perhaps it could be done by writing a python class and compiling it to some form that can be imported into VBA, just a guess.

I run PSSE as often as I can through python, copying in the code provided by PTI to provide system paths which allow the import of psspy. My scripts can then be executed by double clicking them or running them through a python environment if debugging is necessary. This is a broad description of my approach to saving my own time when working with PSSE. It has the benefit of reducing the hours used on my PSSE license as well.

When I upgrade PSSE versions from time to time I get new dongles and therefore don't need to be ultra-conservative on hours so I try to target only those tasks which are most wastefull of my time. Here's one example:

Here is a very generic sample of python code for loading a set of cases one at a time and performing some operation on all of them.

psspy.progress_output(2, 'transcript.txt',[0,0])
psspy.prompt_output(2, 'transcript.txt', [2,0])
psspy.report_output(2, 'transcript.txt',[2,0])
cases = ['2013SUM','2013FAL','2013WIN'] #usually many more than three cases
for case in cases:
    psspy.case('MyCaseSeries-' + case + '.sav')
    psspy.runrspnsfile('MyIDEV-' + case + '.sav')
    #perform other tasks...
    psspy.fdns([1,2,1,1,1,0,0,_i])
    ival = psspy.solved()
    if ival == 0: 
        psspy.save('MyCaseSeries-' + case + '-improved.sav')
        print case, 'solved:)'
    else:
        print case, 'not solved:('

This code will write all the gory details of my process into 'transcript.txt' but will provide me with easy to read output on the python terminal to indicate whether the cases solved after making changes. I often run dozens of idevs on a set of 16 or more cases using this method.

I am having some issues stopping or halting PSSE.

When I use psspy.stop_2(), PSSE stops successfully but my python code also stops executing and the interpreter closes, preventing the rest of my program from running. Why does stop_2 have the power to crash the python interpreter?

When I use psspy.halt_2(), one of the following happens, depending somehow on whether the PSSE GUI has been running or IDLE has been re-started since the last attempt.
1) PSSE halts successfully allowing my code to continue executing, but the usual message box telling me how many hours are left on my hourly dongle appears and pauses the execution of pyton code until dismissed manually. The message box can be somewhat annoying and reduces the effectiveness of my program.
2) PSSE crashes and displays a message box: "Failure of license thread! Please shutdown this program within 1 minute and then notify PTI." Sometimes Python continues executing my code after this and sometimes Python crashes too before finishing my program.

I have also noticed that sometimes, even though there is no visible evidence of PSSE or python running, my hours get used up after running a python script. This is one reason that I would like to reliably stop PSSE in my scripts. The other reason is that I would like to be able to compile a DLL and then restart PSSE in order to load the new DLL, all within the same script.

I am using PSSE V32.1.2 - hourly dongle license, Python 2.5.1, Windows 7.