Better battery charge controllers.

[dpinney]

USE CASES Single battery use cases implemented at inverter:

• PF correction (currently illegal).
• Peak shaving.
• Line load relief.
• Voltage control through real power injection (currently illegal).
• !!! Backup.

Multi-battery use cases: only peak shaving and line load relief.

NOTES GLD doesn't support islanding. It's a 4.0 feature.

TODO

• David reviewed and understands the docs.
• The people on this thread think we have the correct use cases.
• Never do the backup use case because it requires GLD 4.0.
• [0.5 man-month, ETA 14 Oct] Build central_dg_controller object to support control use cases above. It turns out that central_dg_controller isn't needed.
• [0.5 man-month, ETA 14 Nov] Build voltage support via real power injection. This does not need a change in the GLD code base.
• [0.5 man-month, ETA 1 Nov] real power peak shaving and line load relief via inverter "group" setting.
• Implement each single-battery case on Simple Market System.
• Make pretty demos with new capabilities (waiting for Simple Market System outputs). Handled in #285.
• Write up the results for management and take a victory lap. Handled in new issue #285.
• How much effort will it take to do voltage support (single inverter, not group)? Let's get a big feeder, put a battery at the end of the line, tell it to discharge during high load times (as sensed at the substation), and measure voltages at all the upstream nodes. And then this issue is complete.

[dpinney]

I need to gather better requirements here.

[dpinney]

We followed Gridlab team's lead on suitable controls. Relevant ticket: http://sourceforge.net/apps/trac/gridlab-d/ticket/730. Ugh, sourceforge deleted the bug tracker. New ticket location?

[jcfuller1]

Initial documentation available at: http://gridlabd.me.uvic.ca/wiki/index.php?title=Spec:central_dg_control

Most of this was implemented in ticket 730, then migrated to v3.1 release branch. Additional user documentation will be added.

[trevorhardy]

I've pushed up the battery.py module which allows batteries to be added to a feeder. Right now only Load-Following and Constant_PQ mode are supported.

[dpinney]

Hmm. I'm not sure this is ready for production. Could you move it to a new folder /omf/scratch/batteryChargeControllers/?

[trevorhardy]

Sure.

[trevorhardy]

David, what else would you like done on this battery-adding script? Are there specific bugs or problems with how it works that I can be working on for you?

[dpinney]

I'm not sure what the battery-adding script is for. It's not in the todo list in this issue. I thought you were working in the GLD code base on the central_dg_controller.

[trevorhardy]

It sounds like there may have been some miscommunication. The script that I uploaded here is used to add batteries to specified nodes in a feeder model. As part of adding those batteries the control method is specified along with any relevant parameters. These control methods are not a part of a centralized DG controller but rather individual inverter control methods that are driven by the specified control parameters which may include a specific node in the network to monitor.

In addition to this Python script, I'm also working on expanding the list of relevant control methods that are supported in Gridlab-D itself. Before I began this part of the work, the only working method (more or less) was a load-following routine. Since then I have debugged the constant PQ control mode and added a power-factor regulating mode as specified in the remarks when this ticket was opened. I was going to ask you questions about the other two methods (line-load relief and voltage regulation) but it sounds like we need to make sure we're on the same page before going any further. Is this making sense?

[dpinney]

The Gridlab-D constant PQ and PF work on the inverter/battery object sounds great. Exactly what we're looking for.

You're currently focusing on the inverter/battery objects in GLD and will work on the central_dg_controller later?

[trevorhardy]

OK, David. I talked with Andy and he was able to remove my confusion.

Thus far I have been focused on bringing functionality to the individual inverter objects so that if a single battery was added to a model it could accomplish our wish list (load-following, pf correction, line load relief, etc.).

Once we have all of these functions up and running on individual devices, I am going to be implementing a coordinated control scheme that will allow these distributed devices to to work together to achieve the goal of these same control modes (load-following, etc.). Andy and I were discussing the details conceptually this afternoon and I'm still ironing them out but it looks like this will end up as a more decentralized but coordinated scheme. All of the inverters in a feeder will use one of their existing control modes but their final output will be regulated based on the outputs of the other participating inverters. Like I said, still working on the details.

The battery.py script I wrote will still be used to populate a feeder model with batteries set up to operate in whichever mode is desired. I don't expect that script will need significant (if any) alteration based on the development we are doing in Gridlab-D itself. Its functionality is pretty straight-forward and mostly ignorant of the objects it is adding to the model.

Until then, though, I'd like to double-check the modes of operation for the batteries and make sure we get those all working before moving on. Here is the status of the Gridlab-D support so far for the control modes you have requested:

• PF-correction: Recently added. Min. and max pf thresholds are defined and the battery seeks to regulate these at the specified node. I'm working on the documentation and will send that over to you very soon.
• Peak-Shaving: Achieved through load-following control mode by setting the discharge-on and discharge-off properties appropriately and picking the correct sense object.
• Line load relief: As above, achieved through the load-following control mode where a meter is located at the upstream side of the line that is to be relieved.
• Voltage regulation: No effort to date. If this is still functionality you would like to see implemented I'll start working on it immediately.
• Backup: No effort to date and none is planned until version 4.0 of Gridlab-D due to lack of island support.

Let me know what you think of this; we can discuss it over the phone as needed.

[dpinney]

TODO list in top comment updated.

Simple Market System model in OMF repository in directory /omf/scratch/simpleMarket/

[trevorhardy]

Here's an update on my progress over the past week.

Most of my time has been spent working on getting the group pf regulation working in a stable and at least semi-effective manner. As of this morning, I'm feeling pretty good about the functionality of this controller and have completed my internal testing and evaluation. I'll be updating our code base on Sourceforge later today (hopefully), making these new operating modes available to all.

If I remember correctly, we were going to pass on the voltage regulation via an inverter and, assuming this is still the case, my next step will be to implement the new inverter control modes on the simpleMarketModel as a demonstration of how they are used and how they perform.

Unfortunately, between some time-off this week and a last-minute urgent project, I don't expect to get back to working on this until next week. With the updated code-base, it should be very possible for somebody else to pick this up if its completion becomes urgent. Otherwise, I look forward to getting back to it next week.

[trevorhardy]

I ended up with a little more time this week and was able to push the example simpleMarketModels with the new inverter/battery objects along with a spreadsheet with the results of those examples up to the repository. They can be found at:

/omf/scratch/batteryChargeControllers/

As discussed on the phone with David, the most problematic operation mode is group PF regulation due to the lack of information sharing between the inverters. I've done a lot of testing trying to refine the code and I think I've got it stabilized; if anybody finds cases where the inverters misbehave, let me know and I'll look into it.

[dpinney]

Thanks Trevor, this looks great.

I looked through /omf/scratch/batteryCharge and the .xlsx and had a few questions:

1. Is it possible to do group line load relief?
2. For line load relief, are the inverter settings the same as peak shaving just with a different sense_object? Actually, flipping back and forth between single_batt_line_relief... and single_batt_peak_shaving..., it appears they have the same sense node just slightly different threshold settings. Is this intended?
3. That spike on all the peak-shaving charts around 7 PM*--could that be avoided with different threshold settings? For a utility trying to reduce their demand charges, highest daily peak is the one that needs shaving.
4. For the group switching, what communications does the model assume? For example, do we assume all inverters can exchange data with each other? I hope no faster-than-light communication is assumed. :wink:
5. How much effort would it take to do the voltage support use case (single inverter, not group)?

*Spike:

[trevorhardy]

1 - Yes, it is possible to group load-line relief. I didn't include it in the demonstration as the simpleMarketModel doesn't really have a common line that both batteries would feed up into. I've tested it on another system and it works just fine.

2 - This is another limitation of the simpleMarketModel as the only node upstream of any line happens to be the same node as used in the peak-shaving demo. Again, the functionality of using the inverter/battery is identical (both operating in LOAD_FOLLOWING); its just a matter of whether you make your sense object that of a meter directly upstream of a line or at the head of a feeder. The difference in settings was more to make the behavior of the system more interesting rather than a necessity of the inverter/battery's operation.

3 - The spike there gets through because the battery has run out of charge and is no longer able to effectively limit the power flow at the feeder head by discharging. It is possible to clip that spike by changing the thresholds to less aggressively discharge (move the "discharge.." settings higher) and/or more aggressively charge (move the "charge.." settings higher). You could also just use a bigger battery but some may or may not consider that cheating.

4 - There is no actual real-time communication assumed. All that is assumed is that each inverter knows the total installed capacity for the group it is in, something that is assumed would not change during normal operation. It is easy to imagine ways in which this setting could become inaccurate (outages, batteries added to feeder in phases rather than all at once,...) but the assumption (of knowing the total size of the group) is not unreasonable (particularly for utility-owned assets) and it provides a demonstration of just how effective control could be with no communication infrastructure.

5 - I will defer to Jason and Andy to see how difficult it would be to add voltage regulation.

[trevorhardy]

I've chatted with Jason and Andy and it seems like the basic framework for doing voltage regulation shouldn't be too hard to implement. Like the power-factor regulation, though, getting a good control system in place will probably be a bit tricky. There are a few specific complications we anticipate:

• Since there is no such thing as voltage injection, we will necessarily have to try to regulate voltage indirectly through reactive power injection. It would probably take some research on our part to find a simple but mostly effective strategy (assuming one exists).
• Since we will be injecting reactive power, the effects of this power on voltage will be primarily local. If the sense object is not local, it will likely not be very effective in providing the necessary voltage support and has the potential to make things worse (raising the voltage too much).
• Like the power-factor regulation, this will be a reactive-power-only strategy meaning it will be subject to the VA limitations of the inverter. If the battery is providing real power to the network, this will limit the amount of reactive power that can be injected.

We should probably discuss more in depth what you have in mind and where you think the effort/results sweet spot is. My time to work on this is limited for a week or so but I should at least have time to talk it over in the near future. Let me know what you're thinking.

[dpinney]

Nice. I'll send a meeting request so we can figure out:

1. A clearer use case for voltage support and estimated level of effort. (I think the use case should probably be PV system at the end of a long line--can power injection reduce spikes?)
2. Moving the simple market system examples to a bigger feeder. I should do this to check my understanding of the work you did.
3. Could you send me any Gridlab bug tracker tickets you opened as part of this work?

[trevorhardy]

3 - I think these are the only ones I've opened for this effort: https://sourceforge.net/p/gridlab-d/tickets/896/ https://sourceforge.net/p/gridlab-d/tickets/900/ https://sourceforge.net/p/gridlab-d/tickets/904/

[dpinney]

Final todo (voltage control test) updated in top comment.

Hypothetical output we might expect from voltage control test:

[trevorhardy]

(Eventually) got a model put together that will work for us and ran a few simulations on it. Annotated feeder model:

Voltage at circled nodes:

As you can see, the performance is roughly like the sketch in the previous comment guessed it might be. A couple of interesting notes:

• The effects are definitely stronger the closer a node is to the battery.
• Even at very high power levels, dramatic increases in voltage do not develop. At the highest power level (1/12th of the feeder's entire load), voltage rise is only 1.5V at the node closest to the battery.
• I would suspect that the effect of voltage support will be greatly impacted by the particulars of the feeder.

So batteries definitely can help voltage by providing real power output and the effect is local and not overwhelming. Interestingly, I ran the same study using reactive power only and the effects on voltage are definitely more noticeable:

It wouldn't make sense, though, to install energy storage to simply supply reactive power since this is mainly a function of the inverter and no real power (that is, power from the battery) is used. The inverter acts like a distribution-level FACTS device or an expensive variable capacitor.

We could implement the voltage control function in GLD like we did the power factor regulation function; the inverter's reactive power output is defined by a voltage regulation function and is subordinate to the real power function of the inverter (load-following, line relief,...). This makes the voltage regulation function a second-class function and thus may prevent it from accomplishing its goal (as is also the case for power factor regulation). It is also unclear to me if we could use the same sense object as in the real power function as it is often far upstream of the energy storage device. Reactive power provides a local effect that may or may not reach that sense point and improve the voltage to a specific level.

Another option is to not explicitly support voltage regulation but offer the existing power factor regulation function as a good alternative. Improving the power factor on the feeder as a whole will improve the voltage profile. We already have this function implemented and though it won't guarantee any specific voltage level, it will raise the voltage near the energy storage device.

In summary:

• Using real power for voltage support is not as effective as using reactive power (assuming there are reactive loads on the feeder).
• Using reactive power from the energy storage inverter as a primary function of the device is an expensive way to improve the voltage profile. There are less expensive means of accomplishing this goal.

Options for our next step in terms of GLD:

1. Implement voltage regulation as a real power function.
2. Implement voltage regulation as a first-class function using reactive power.
3. Implement voltage regulation as a second-class function using reactive power (like we've done with PF correction) using the real power sense object.
4. Implement voltage regulation as a second-class function using reactive power (like we've done with PF correction) using a separate reactive power sense object.
5. Don't implement voltage regulation and suggest users achieve voltage support with the existing power factor regulation. (A checkbox in OMF?)

If the OMF users have a strong felt need for using energy storage for voltage regulation, I would say we need to do 4. As a bonus, a reactive power sense object could also have some benefits in the power factor regulation function.

Maybe the real problem for co-ops, though, isn't reactive power per se but long lines with relatively high resistances. If this is case, real power may be necessary; I don't know enough about the co-op world to offer an informed opinion. If real power is necessary, we should do 1.

If this voltage regulation is not a strong felt need but a "nice to have" we should do 5 and throw a graph up in the OMF interface showing the effects of power-factor regulation on the feeder voltage profile.

[dpinney]

These tests were excellently done, fast, well-documented, and the results surprise me a little in how effective the end-of-line-sense-substation approach worked.

Let's do option 5.

I think we will need real power injection later. We don't need a Gridlab code change for this yet, since we can fake it with 2 inverters at the end of the line.

Could you commit these graphs and glms in the /omf/om/scratch/batteryChargeControllers/ directory?

What did you use to draw the annotated feeder diagram?

[trevorhardy]

Graphs are on their way up.

The feeder diagrams I found at: http://emac.berkeley.edu/gridlabd/taxonomy_graphs/

Any Grildlab-D Taxonomy Feeder graph is kind of fake because the model they are based on only defines distances between two connected nodes (line length) and not direction. These are nice in that they look "realistic" (that is, like we expect a distribution feeder should look) and allow you to get some sense of where the significant branches of the feeder are.

For the annotation I used my Mac's built-in PDF viewer, Preview. It has annotation tools to add highlights, circles, text boxes, that kind of stuff. I'm sure there is an equivalent in the Window's world but you'll have to find it for yourself.

[dpinney]

I see the graphs in fee2442fd7ed6f6f9cb15094bec52a7f53bdd388. Nice.

You've met all the needs, so the issue is closed.

Congratulations on closing issue #66. This has been open for a long time.