perolofl's profile - activity

It is not possible to change the unit for channels written to an outfile (.out) in PSSE.

Use a function in Plotbook to recalculate the values before plotting.

The slack bus generator will always inject the necessary Mvar to keep the scheduled voltage. Adjust the Mvar injection by nearby generators, fixed shunts, switched shunts, FACTS, etc., in order to change Qgen of the slack bus.

It is not clear what you want, but I assume you should change the active power generation (Pgen) in your ”system”.

You can't generate a .dyr file from .sav. A saved case has only load flow data.

The script should enter the needed dynamic models for the converter. It can write a add dynamic data file (.dya) and then read the file to add the information to the snapshot.

Library models can be added directly with API: psspy.add_plant_model, without the need of a .dya file.

In addition to @acd1's answer I want to clarify that the number of steps are:

Nsteps = (Rmax-Rmin))/STEP = (1.1-0.9)/0.00606060606 = 33.

The number of tap changer positions are always Nsteps+1, i.e. NPOS = 33+1 = 34 in this case. Normally, the number of positions are odd numbers so there may be something wrong with the given data here. With 33 tap positions the steps size would be: STEP = 0.2/(33-1) = 0.00625!

Can you show the tripping messages?

What is tripping? Loads, lines, generators, etc.?

The CONs are described in Note 3 in the Model Data Sheet.

The transformer phase shift will only affect currents at the other side of the transformer. I.e., the currents at bus 4. Here there are no current at bus 4 (no generator and grounded wye-winding at bus 3.

There is nothing missed in my example. Please take you time and model the same system yourself, and you will understand that the results are correct. You have misunderstood the theory.

See my updated answer!

This is a PSSE forum only!!!!

1: For renewable models normally Pmax is entered into Mbase of the generator, so here 30 MVA.

3: You are right. They mean 30 MW for 4 hours.

Model NRCGP3U may be used to supervise and trip generators in an area, zone etc.

Check the DYRE-file for any call of 'NRCGP3U'.

Check also spreadsheet Dynamics Data - Protection Models - Machine for any tripping models.

Edit:

Check if option "Scan generators exceeding speed deviation threshold" is enabled in Dynamic Simulation Options:

However, the progress window trip message looks like this so it is not causing your trip:

 Machine 1  at bus    3018: PU speed Deviation=    0.05057; PU overspeed Threshold=    0.10000
 MACHINE 1  AT BUS   3018 [CATDOG_G    13.800] TRIPPED AT TIME = 1.4300

For 3-winding transformers, all windings have tap changer data.

Yes, there is no sorting for 3-winding transformers: I = winding 1; J = winding 2, K = winding 3.

In raw data bus I is the "Winding 1" bus and bus J is the "Winding 2" bus. Winding 1 is the winding where the tap changer is located. So, the first bus number (I) is always Winding 1 bus in raw data.

In PSSE the transformers are sorted with the lowest bus number as "From Bus" and the other as "To Bus". Here the location of the tap changer (at Winding 1) is defined by the check box "Winding 1 on From end". If I > J, then J becomes "From bus" and I becomes "To bus".

It is the correct way to do the black start simulation.

Every generator to be connected to the system during the simulation must be on-line as stand-alone islands in load flow, i.e., each generator bus is a swing. Note, one island for each generator to be synchronised.

Synchronising is done during simulation by switching on the step-up transformer. Each generator will have 0 pu speed deviation (50/60 Hz) up till the point of synchronisation. Be sure to synchronise when the frequency and the bus rotor angles of the two transformer buses (generator bus and high tension side) are fairly close.

Can you show the tripping message from Progress Window?

It can be done in the GUI:

1. Select a transformer in the 2 Winding spreadsheet
2. Ctrl-c to copy the data to the clipboard
3. Click the first column on the empty last line
4. Ctrl-v to paste the data.
5. Change the id from e.g. 1 to 2
6. Press enter to exit edit mode

A transformer can be duplicated in python in the following way:

1. Write raw data for the subsystem consisting of ibus and jbus
2. Change id of existing transformer
3. Read raw data files with existing transformer

The python code:

import os

def duplicate_transformer(ibus,jbus,ickt='1',ickt2='2'):
    """ Duplicates 2W transformer ickt between ibus and jbus
    """
    rdcfile = 'copy_transformer_dummy_file'
    # Write data for existing transformer to raw data files
    psspy.bsys(11,0,[0.0,0.0],0,[],2,[ibus,jbus],0,[],0,[])
    psspy.rawd_2(11,0,[1,1,1,0,0,0,2],0,rdcfile+'.rac')
    psspy.rwsq_2(11,0,[1,1,1,1,1],0,rdcfile+'.seq')
    # Change id of existing transformer
    psspy.mbidbrn(ibus,jbus,ickt,ickt2)
    # Read raw data files with existing transformer
    psspy.rdch(0,rdcfile+'.rac')
    psspy.resq(rdcfile+'.seq')
    # Delete raw data files
    os.remove(rdcfile+'.rac')
    os.remove(rdcfile+'.seq')

# Duplicate transformer in savnw network
duplicate_transformer(152,153,'1','2')

The limitation is in the governor model, It is called Vmax, Tmax, Pmax or something else.

Since line id is a character the value is stored in array CHRICN.

Try:

CALL BRNINT(ICON(M),ICON(M+1),CHRICN(M+2),'STATUS', STATUS, IERR)

No, PTI doesn't publish such information.

Use KM to get the line information:

CALL GETFTC(KM,II,JJ,ID)

returns the bus sequence numbers II and JJ and the line ID. The external bus numbers are:

IBUS = NUMBUS(II)
JBUS = NUMBUS(JJ)

The two VSC-HVDC library models do not have any frequncy control built-in.

With model VSCDCT you can add an external signal modulating the power order. For that you can use an auxiliary signal model in PSSE´s library.

Under the same IF statement put VAR(L+1) = STATE(K+x)

In mode 1: VAR(L)= -1. In mode 3: IF(ETERM(MC)<0.2 AND VAR(L)<-0.5) VAR(L)=TIME. This will store the first time voltage goes below 0.2 pu in VAR(L).

Why are you using DSRVAL to get the time? It is already available in common variable TIME.

Do you want to write your own user moderl version of REECAU1?

The simulation time is already available in variable TIME, so there is no need for DSRVAL.

At each time step the value of the STATE is in the STATE array. I don't understand the question.

You don't have exactly the same solution in load flow and at initialisation. The generators and loads are converted the load flow is solved with TYSL. This explains the difference in the line flow values. Very normal and shouldn't cause any initial conditions suspect.

Which STATE has suspect conditions? What kind of block is it (lag, integrator, washout, etc)?

What are the STATE and DSTATE values?

Branch id entered as character, e.g. '1', will be stored in CHRICN. If branch id is entered as an integer in DYRE-file the value is stored in ICON. Try the following

IF (CHRICN(I+2).EQ.'$$') WRITE(CHRICN(I+2),'(I2)') ICON(I+2)

where I+2 is the index of the branch id. This line will convert integer id to character id in array CHRICN

In this way the id will always be stored in CHRICN.

The manual is misleading in this aspect. Maximum Pmech (e.g. governor parameter Tmax, Pmax or Vmax) should be set a value corresponding to Pmax in load flow. Too many examples show Tmax=1 or higher, which is wrong.

Of course the limits for DEGOV can be calculated from those data.

Tmax = Pmax/Mbase

Tmin = Pmin/Mbase

If RSORCE>0, the limits should be slighlty adjusted with the resistive losses in the generator.

Same data as typical data in manual PAG-II. Except for Xd" which is 0.25 in manual.

Can you show the GENSAL data?

There is no message in progress window when reading the DYRE file?

So, still unstable with only two generator models! Which model are you using?

This post is redundant. See post "Modulate Power in a VSC Converter" .

Do you have SWS, HVDC or FACTS models?

All generator trips during a simulation should be written to log file, if progress window is redirected. Search the file after simulation.

@Pasnos proposal No 2 is better.

Yes, why not?

Your data looks ok. It may be a bug in rev 33.4.

Maybe a too short time constant in a generator model. Check the time constants in all generator models (GENSAL, GENROU, etc)

Try to disable all exciter models (or governor models) and see if it makes it stable.

Another method is to enable "Display network convergence monitor" and check dynamic models located at or close to the bus with highest mismatch at the first iteration at each time step.