bnordman
commented
7 years ago For reference, in the CERC/CBERD Software Plan gdoc:
https://docs.google.com/document/d/1K-vN7nccwuoyYfaD5ufACi7qxN8Hv9pAPjJHnzYh_Yk/edit on page 3 it says: Special forms of grid controllers include local generation, and a connection to the conventional utility grid.
Most of the features described in the CBERD doc are also wanted for CERC, though I realize many more time-urgent for CBERD.
For how to signal that the grid is down, eventually we will have two mechanisms that could be used. First, disconnecting the wire between a building GC and the utility grid. Second, all GC-GC power exchanges will be negotiated, and a GC can announce to the other one that it wants to immediately cease the exchange. The second one seems easiest to do. We can probably have that in a few weeks but in the interim I suggest that there be a "magic price" that the utility grid announces that the building GC knows means to stop any power exchange with the utility. A kludge but temporary.
For simulations, utility grid prices can be a generic schedule as we have for other features in the system. For real-time operation could be a schedule or some other source.
For fixed-period metering, the grid agent can have an Initial Event on the period (e.g. 5 minutes) which will trigger logging that will have the meter values. The event doesn't have to result in any messages or other changes.
A power capacity exists at each device port and for each wire. I am not sure that these need to be changeable. A device can be unable to deliver that capacity (or any power at all) at any given time but the capacity limit is still there.
Devices should always be able to communicate so if one stops doing so the one at the other end of the link should stop any power exchange on it until communications are reestablished.
As we discussed, PV is a type of grid controller.
What does "Allow multiple DR scenarios (see Mary Ann’s email)" refer to?
Demand limiting. A GC can raise the price or drop devices from getting power any time it wants to to keep demand under a limit.
Having a battery in an EUD is no problem. We already have a notebook EUD. I assume more and more EUDs will have batteries.
Does a plugstrip make any decisions?
Should I edit the CBERD gdoc? (could be just suggestions) add comments to it?
--Bruce
On Fri, Feb 24, 2017 at 4:49 PM, CJKohler notifications@github.com wrote:
Based on a discussion we just had with Bruce, he proposed that we don't create a PowerSource class, but the baseclasss should be GridController that can be a generator, or a utility meter, or a full featured grid controller that does price blending. Some GC will have more capabilities as others. Ask Bruce if you have more questions.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/LBNL-ETA/LPDM/issues/1#issuecomment-282444334, or mute the thread https://github.com/notifications/unsubscribe-auth/AJKznyAhKvrsryE1DOqDzgttPwPZik8cks5rf3qKgaJpZM4MLzoq .
-- Bruce Nordman Lawrence Berkeley National Laboratory nordman.lbl.gov http://nordman.lbl.gov BNordman@LBL.gov 510-486-7089 m: 510-501-7943
Modify GC so it can take multiple power sources with each a price, capacity enabled/disabled state is represented by the capacity, set to 0 if it is disabled. Conceptually a utility meter is like another generator, generic powersource class Price blending logic: start with “available” power source with lowest price, max out capacity, add next available more expensive power source, continue up until you meet the load. Need to figure out how to handle battery. Implement both marginal and average pricing algorithm, with a parameter on the grid controller to indicate which algorithm to use for a given scenario
Create the utility meter class from the “PowerSource” baseclass
https://docs.google.com/a/lbl.gov/document/d/141om3E5fSy1yjgEWe0jHpfPxsP903EpA-zvpqBZDoIU/edit?usp=sharing