EBC's profile - activity

In a perfect world, "initial conditions O.K." is good. In a 9 bus test system you should have perfect models since the system is small to be perturbed by dynamic model errors. But simulation models are not perfect, especially when you are working on large systems. Some "INITIAL CONDITION SUSPECT" can be ignored or accepted if Dstate is about 0.0001. For North American base cases, gas turbine models would have some large "INITIAL CONDITION SUSPECT" Dstate but are ignored by planners and operators since these models are acknowledged to have errors in modeling.

Why the Real Power P and Reactive Power Q from Line Quantities CHAN are quite different than 0? It supposes that I wouldn't injecting power, since the current is 0.

You mentioned "LINE" quantities for P and Q in your CHAN, does this mean you are monitoring a line flow and not the WTG power output at its terminal?

1. Eli's comment on unique bus numbers should apply.
2. Convert all sav to raw files.
3. Open first raw file.
4. Apply RDCH then call second raw file.
5. Solve case if possible. If case is not solving, try to see if you need to correct bus voltage phase angles.
6. Apply RDCH for the next raw file, and then solve again....until to the last raw file.

Here are some additional thoughts aside from Yagna’s:

• PDEV is basically an output file of what is being reported in the progress window ODEV is the prompt output file but you can include both PDEV output and ODEV output in just one output text file
• Given the bullets above, if this is reported in the progress window, why do you need to create an output file from PDEV/ODEV? Well, the progress window cuts its report, meaning it has line limitations. When that line limit is reached, it would cut the first reported lines so on and so forth until the simulations is completed, thus you can’t review all that has happened with and by the program. This is the reason why you need PDEV/ODEV output text log file.
• IMO, any analysis should review what is in the progress window or PDEV/ODEV. This is to ensure you simulated what you wanted and be able to catch some errors/mistakes, if any. You also want to review how the program responded or was prompted in your simulations. For example if you run a large deck of contingencies to several power flow cases, you would want to check if all contingencies converged or diverged or which case/contingency did not solve at all. Note that the ACCC output is just an output and may not show you what is in the progress report or PDEV/ODEV. You can use a text editor (I use crimson editor, again free but effective) to search for “error” or anything you would want to catch.
• For dynamic simulations, there’s a lot you want to review after the simulations. Are there initial condition suspects which are not acceptable like gen models, governor or excitation models? Are there user models which flagged errors or flags that can be ignored? Did the program prompted error during the fault of clearing or the fault? How the simulation was converging? Did you add a new model; you might want to check if there was no error after you added it. Etc, etc, etc. Again, search for the word “error” or “fault” for quick review.
• Lastly, any output (power flow or in dynamics) are just the surface of the meat. Go look what’s inside through PDEV/ODEV.

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.

Power Generation, Operation, and Control book contains a very good explanation of the load damping within a generator model, Section 9.3 page 332. Check it out.

Here's a quick turn around I have practiced with great effectiveness not using PSS/E but PowerWorld.

1. Download PowerWorld academic version.
2. Open any case in PowerWorld, choose largest case that can be loaded.
3. Go to the stability add-on.
4. Put dynamic models in each component (gens, exciters, governors, PSS, HVDC, SVC, wind turbines, etc). - PowerWorld has default dynamic data for each but you have to edit out some parameters like MVA base, etc.
5. Save the case. Run the case in PowerWorld stability and even allow PowerWorld to check and correct the dynamic data.
6. Save the dynamic data in dyr format. - PowerWorld has a feature on this.
7. Open the dyr file in a text editor. Edit as possible (bus numbers, bus names to match your case.)
8. Read dyr file in PSS/E. And you are all set!

I guess the error in mismatch comes from a diverged power flow case or you have reach the nose of the PV curve.

Read the PSSPLT Program manual. On page 4-27, it discusses the modal analysis which is of help to what you want to do.

Hi Cao, in power transfer analysis, the source system (zone/group of zones or an area/group of areas or a group of buses with generation) would increase their generation as you transfer power. At the same time, the sink or opposing system (zone/group of zones or an area/group of areas or a group of buses with generation) would decrease their generation output. In PSS/E, the source and sink (opposing system) must be defined before the power transfer is conducted.

As the program transfer power from the source to the sink, it also monitors bus voltages depending on how the user provided limits so when the power flow solution is not solving or diverging or when the voltage lower limit is hit by the power transfer, the power transfer solution/simulation stops.

amaity, I don't have a python code on this strategy...I'm sorry...usually I have an idev or python recorded but I don't have those now when I resigned from PTI...thanks.

Hi Pooya, if ever you have not find an answer to your question, I will try here...

Create a sld of the part of the big power system you are establishing a circuit equivalent including the BUS (PSS/E calls this boundary bus) where you will assign the equivalent model. Then go through equivalencing (BGEN/EEQV or whatever), when you finish the procedure, the sld is revised to reflect your equivalent. There you will be able to see your generated equivalent data.

Here's my experience with OPF in PSS/E.

I was optimizing the shunt capacitor size and location. In OPF, I defined the candidate buses with base case plus contingencies. When OPF provided the shunt compensation location and size, I simulated the case with the shunt capacitor in place and applied the contingencies, if any, and see if the voltages would be at acceptable magnitudes per criteria.

This is a good check if the OPF "really" gave the optimal capacitor size and location.

PSS/E power flow blows up, more often, because of a large phase angle difference between two buses which is seen to be a large power flow by the program.

Example, you added a new bus and connected it to an existing bus. The existing bus would have a phase angle calculated by the program but the new bus would have a default of zero phase angle, if you did not change it. Thus when power flow is called, the program sees this as a large mismatch and can't converge the solution.

So, when adding new buses, see to it that you change the phase angle equal to the phase angle of the bus where you connect it.

Also, the program will provide hints where the solution when berserk thus its good to look at the progress window.

In the US, different Transmission Owners would use different solution parameters (PAR adjustment, transformer tap/shunt compensation adjustment, interchange power flow control, FNSL or FDNS) thus when the power flow exchanged hands, it is a must that you know what are the solution options if not, the solution blows up when the right options are not applied.

ACCC is AC contingency analysis. PSS/E has DCCC which is DC based contingency analysis. ACCC accounts for Mvar while DCCC does not. Instead of doing manual contingencies, ACCC offers automatic reading of sav, and auxiliary files.

You need a solved case, a monitoring file (.mon), a subsystem file (.sub file), and a contingency file (*.con). The manual provides edetails of these files. In ACCC, you need to create a distribution factor file (dfax) from the mon, sub and con files before running the main ACCC simulation. THe output will be in *.acc file and you can read the output in PSS/E, and export to text or excel file.

HTH.

The PSS/E environment manager is used for compiling dynamic models for stability simulations. These are user models which are not part of the standard dynamic models in PSS/E. In the past, DOS compiler was used, now, Environment Manager allows drag and click for allowing PSS/E read models out of fortran or python. If you are not using any user models (*.lib or *.obj) then you don't need the Environment Manager.