From GridLAB-D Wiki
Jump to: navigation, search

Frequency

Discussion with M.Elizondo - 23:15, 5 March 2012 (UTC)

The equation listed for frequency is really only valid when connected to a large system. If not connected, you need to explicitly model all losses on the system as well, which may be difficult. Since you are solving for all of the individual dynamic states, you technically have the frequency information. For a microgrid scenario, taking the average of machine speeds is a much better indicator of frequency. Frequency could also be calculated by differentiating the voltage angle at each individual bus, but this may cause sharp discontinuities.

Ftuffner 16:36, 12 March 2012 (UTC)

Changed phrasing to indicate the overall equation requires losses to be inclusive. Also added suggestion of averaging machine speeds

Melizondo 17:22, 12 March 2012 (UTC)

After thinking a bit more through, I would recommend to only make available, machine speeds (without combining into average), and bus frequency (calculated as the derivative of the bus voltage angle).

Estimating a single frequency of the system can be confusing and detached from the real world. What you have in the real world is the speeds of the generators (measured at each generator and not combined centrally) and the frequency calculated from voltage measurement (you can measure this anywhere in the system).

There are two uses of frequency simulation outputs: - If you want to look at the dynamic performance of the system, you can look at the speeds of several generators (and get the average if you want). The user should make this post-processing if needed. We should only make machine speed available. - If you want to take automatic actions during the simulation based on frequency, like under-frequency load shedding, or demand response, you should take local measurements of frequency. The only way to do this in the real world is from the voltage measurement.

Consider making frequency measurements (calculated as derivative of voltage angle) available at each bus. Making frequency measurements available at each bus can be very useful to implement Grid Friendly Appliances (use a local measurement of frequency).

Ftuffner 23:07, 12 March 2012 (UTC)

I agree this may be a useful way to implement GFA functionality. For the purposes of the overall system and what we seek to initially study, I don't think "localized" frequency will be directly implemented. All of the information will be there, but it will be left to individual devices to calculate a voltage-angle-derivative-based frequency term when they need it. The "average" frequency on the main solver object will provide a relative sense of how grid frequency is behaving. If devices require a different average or more specific implementation, all relevant data should be available to them to make the necessary internal calculations.

Dchassin 17:20, 13 March 2012 (UTC)

Frequency only makes sense as a global value when taken in context of a phasor model. If we have separate a phasor models for each device then we should have separate frequencies and we have to explain how we reconcile them in the solution. If we have a single phasor model for the whole system we need to address the errors this introduces locally when the devices are not exactly synchronous or have harmonic components. Most likely these cannot be easily addressed so we just need to explain the impact or solution approach.

Ftuffner 22:01, 13 March 2012 (UTC) =

Discussions with Dchassin showed the flaw in the frequency implementation. Phrasing has been altered and the presence of phasor notation indicated in the frequency updates. Device-level phasors will be implemented, with a reconciliation to a system-level estimate.

Ftuffner 23:01, 16 March 2012 (UTC)

Further information on how the system-level estimate is being reconciled added to specifications.

Solver timing

jcfuller 1 March, 2012 (UTC)

I didn't see anywhere a mention of how the <1s function re-merges back the the >=1s functionality, i.e., how often do they re-update w/ each other? Is it required every one second interval, or only if the main function call loop (>=1s) had originally called for an update, or does the information get passed back to the main loop and a decision made from there? I guess it might be implicit in your timestep section, but it might be good to explicitly discuss.

Ftuffner 22:59, 5 March 2012 (UTC)

Updated Solver timing section to reflect continual powerflow solution. The static powerflow solver will still be called regularly inside the dynamic solver. Attempts will be made to make this a reduced, faster call, but it may end up being a full solver_nr call at each "micro-timestep".

Discussion with M.Elizondo - 23:15, 5 March 2012 (UTC)

The reconciliation of the static and dynamic powerflow modules should be unnecessary. If the dynamic states are being solved properly and the interactions across the network are sufficiently captured, the dynamic powerflow solution at a "static instance" should be the same, so long as all appropriate devices are being handled properly.

Ftuffner 16:36, 12 March 2012 (UTC)

Updated text to reflect dynamic and static solver interactions and how they should be the same, given the incremental powerflow requirements of the dynamic solver.

Dchassin 18:27, 13 March 2012 (UTC)

This is a very confusing discussion. The dynamic solution is not the steady solution at each timestep. The steady solution is the limit of the dynamic solution as <math>t\rarr\infty</math>, so far any finite <math>t</math> there's simply no justification for assuming the solution is steady.

Ftuffner 22:01, 13 March 2012 (UTC)

Changed discussion to attempt to clarify how static and dynamic powerflow components are interacting - mainly in that "static" components are being modeled as fixed portions of the dynamic system and adjusting to its influences.

Dchassin 18:25, 24 May 2012 (UTC)

It's my understanding that the modified Euler method has a cumulative time-integral error that becomes apparent after several seconds of continuous simulation. Can the discussion address a) whether this problem will be significant over the expected time horizon the dynamic run intervals, and b) if so, how it will be mitigated? If the problem is significant and cannot be mitigated, can we discuss whether one of the other known methods of solving dynamics is preferred?

DC Exciter

Discussion with M.Elizondo - 23:15, 5 March 2012 (UTC)

A thyristor rectifier exciter may be a much better choice for the first implementation. It's a simpler model, and it is probably more representative of modern distributed diesel generators that would be found on a microgrid.

Ftuffner 16:36, 12 March 2012 (UTC)

Posted equations for implementation of simple thyristor-rectifier exciter

Exciter - voltage droop control

Discussion with M.Elizondo - 23:15, 5 March 2012 (UTC)

It may be worthwhile to model voltage droop controls into the exciter as well. This may aid eventual implementations and reactive power considerations a "fully connected" grid may not experience. It should also aid in ensuring the reconciliation of the dynamic and static powerflow answers.

Ftuffner 16:36, 12 March 2012 (UTC)

Incorporated load compensation equations into exciter equations (defined <math>V_{Comp}</math>, which was already in the equations). I believe this is the voltage droop control mentioned.