Please unsubscribe me from your email list. I did not ask to be on this list.
On Mon, Jan 13, 2020 at 10:26 AM Larry Arps <laa...@gmail.com> wrote: > Please unsubscribe me from your email list. I did not ask to be on this > list. > > On Mon, Jan 13, 2020 at 10:57 AM Brunswick Computers < > k...@brunswickcomputerservice.com> wrote: > >> >> >> >> >> REMOVE this email address from your spam. >> >> >> >> >> >> *From:* bounce-124269900-85421...@list.cornell.edu < >> bounce-124269900-85421...@list.cornell.edu> *On Behalf Of *Florian >> Bennewitz >> *Sent:* Monday, January 13, 2020 10:43 AM >> *To:* MATPOWER-DEV-L@cornell.edu >> *Subject:* implementation of generator reactive power capability curve >> in load flow >> >> >> >> Hello everybody, >> >> >> >> first of all I wish you a happy new year. >> >> >> >> For the purpose of my thesis, I needed to consider more detailed reactive >> power limits of synchronous generators. This mainly includes the influence >> of the terminal voltage to the operation chart of the generators. Hence I >> wrote the function genreacpowercapcurve_rev() (see attachment), which is >> implemented in runpf_rev() directly before the lines, where gens with >> violated Q constraints are identified (see further annotations to >> runpf_rev() below). Basically, genreacpowercapcurve_rev() calculates the >> Q-limits of each generator according to the well-known operating chart. >> >> >> >> Some annotations regarding genreacpowercapcurve_rev(): >> >> - The calculation of the operation chart of a round-rotor-generator >> needs one further parameter, the stationary reactance in the d-axis. For >> my >> purpose, I wrote that number in gen(:,13), because I do not use any >> OPF-code from Matpower. However, salient-pole-generators are currently not >> considered. >> - One further parameter needed is the so called practical static >> stability limit, which defines a safety margin to the theoretical static >> stability limit at theta=90° at the under-excited side of the operating >> chart. I included this as mpopt.pf.static_stab_lim, which is by default >> 70°. >> - The set point regarding active power injection can be inadmissible >> in the theoretical case of very low terminal voltages. Currently, this is >> considered to be an infeasible problem. >> - The rated voltage of the generator is currently set to the base >> voltage of the terminal bus, which might not be true in general. >> >> >> >> Some annotations regarding runpf_rev(): >> >> - The application of the reactive power capability curve is activated >> with mpopt.pf.consider_q_cap_curve, which is 0 by default. >> - The application of voltage-dependent-reactive-power-limits yielded >> a problem with the PV-PQ-change of generator-busses, which violate their >> reactive power limits. In the original runpf(), in this case a generator >> is >> fixed to the reactive power limit by converting its [Pg,Qg_lim] to a >> negative load, i.e. -[Pg,Qg_lim] are stored in mpc.bus. Thereafter, the >> limited power injection remains unchanged in further iterations. This is >> correct, if the respective reactive power limit does not change further; >> but it is wrong, if the reactive power limit changes with terminal voltage >> magnitude. Hence, further iterations are needed, until the limited >> reactive >> power injection shows convergence with the terminal voltage magnitude. >> However, this issue caused some changes in the runpf_rev(), which I tried >> to comment thoroughly. The relevant rows in runpf_rev() are the following >> ones: >> - rows 196, 203-205: some initializations >> - rows 246-256: implementation of genreacpowercapcurve() >> - row 263: adaption of if-clause >> - rows 301-346: correction of PV-PQ-change and calculation of >> ratio_qg_change, which indicates the aforementioned convergence >> behavior >> - The convergence of the outer loop is assumed, if ratio_qg_change < >> mpopt.pf. q_lim_gen_tol, which is 0.01 by default. >> >> >> >> A first small test looks fine for me. However, I guess there are major >> possibilities to improve this, at least my style of writing this code. ;) >> So hopefully there will be some good ideas on this. >> >> >> >> Last but not least a huge thank-you for the tremendous work on Matpower >> to Dr. Zimmermann and all the others! >> >> Kind regards from Germany, >> >> Florian Bennewitz >> > -- Thanks, Dennis
