Gridlab Supermodel

[dpinney]

GOAL omf.gridlabMulti model with all the things Gridlab can do on it. We want this for demoing to utilities. And we want to see how much functionality exists in Gridlab that isn't in the OMF GUI yet.

TODO

• Get a taxonomic feeder .glm with all the features on it: TOU pricing, energy storage, solar, VVO, EVs, etc.
• Save an instance of the omf.gridlabMulti model that simulates a couple months with it.
• Find the code that was run to make that .glm. Hopefully it's not 10,000 lines of Matlab. Ha! It was 9,100 lines.
• Write a list of everything that could have been put on the feeder via gridEdit.html. And a list of everything that couldn't.

[dpinney]

@jcfuller1, @trevorhardy do either of you folks have a taxonomy feeder .glm like this?

[jcfuller1]

We're heading that direction. @afisher1 is in the midst of a small addition to the code used to pull the prototypical models into the dictionary.

Do you just want a sample model to look at?

[dpinney]

I updated the top comment with what we're looking for in total. Dunno who should do it all yet.

Yeah, the taxonomic feeders need to be hacked to work with feeder.py. Cool to hear that you guys are working on an enhancement to fix that.

[jcfuller1]

Got it. We're headed down that path. Of course, we'll need to bring the house models back online and use that script. How do we want to integrate it with the current OMF structure? As a separate, stand-alone application/script that you can call, if desired, from a higher level script? Other?

[dpinney]

Of course, we'll need to bring the house models back online and use that script.

I don't think so. We just need random houses on the model. We're not looking for calibration in this issue.

How do we want to integrate it with the current OMF structure?

I assume it here refers to "...the code that was run to make that .glm.". It doesn't need to be integrated. Let's see it, whatever format its currently in, then let's decide whether to integrate.

[jcfuller1]

Ok. Got it. We'll integrate the taxonomic feeders into feeder.py, but halt there in terms of further integration.

I'll also pull a couple of example models that contain each of those elements and send them your way.

[dpinney]

I'll also pull a couple of example models that contain each of those elements

We're looking for one model with all the elements.

We'll integrate the taxonomic feeders into feeder.py, but halt there in terms of further integration.

Is there a test plan to make sure changes to feeder.py don't break compatibility with other .glms? (The test suite in feeder.py is small. _tests() in milToGridlab.py are better since they test powerflow and charting.)

[trevorhardy]

I've been able to make a model that includes CVR and solar. The script that we use to add these features to our taxonomy feeder models is having some problems with storage and hasn't implemented the EV charging at all. I'll be talking with Jason and Andy to see what they think to prospectus on this is.

[trevorhardy]

Yes, DR. I added that as well. TOU + CPP.

We'll need to talk about the specifics of how the storage will operate as that will influence how it gets added into the feeder.

[dpinney]

For this demo, I think storage should be added to every meter that has solar on it.

For a discharge patten for the storage--how about charge whenever solar generation is great than load, discharge all other times? Targeting the discharge at CPP times would be nice but maybe too hard to do.

[trevorhardy]

@afisher1 has jumped in and is under-taken this task.

[trevorhardy]

I just got done talking with @afisher1 about adding the energy storage. Right now, we don't have functionality in GridLAB-D to charge and discharge based on a house's load and the solar panels on that house. Currently, our primary application for energy storage is load-following (shaving peaks, filling valleys) and we were thinking of implementing this in such a way that each residential energy storage device executes this load-following function using a nearby neighborhood node or a more central substation node as the control signal. Do you think this would work for you?

Also, during our discussion, it became clear to me that though it is possible to add all these technologies to one feeder, there is a good chance that there will be some technologies that adversely impact each other during operation. For example, it could be possible that (and I'm making this up for discussion purposes) the energy storage device is doing load-following on the feeder and discharges to raise the feeder voltage while the VVO system is simultaneously trying to lower it to conserve energy.

I read in this issue's opening post you mentioned you were hoping to demonstrate GridLAB-D functionality; this might be more easily accomplished using just one technology per feeder. I don't have a super clear picture of the end goal so this suggestion might be off base but I wanted to make sure you understood some of the limitations of building this super-feeder. If you could clarify your end goals a little better we could make sure that we're headed down the right path.

[dpinney]

I don't have a super clear picture of the end goal

I want a .glm with everything on it. Anything Gridlab can simulate I want it on there.

it is possible to add all these technologies to one feeder, there is a good chance that there will be some technologies that adversely impact each other during operation

Showing this to distribution engineers would be awesome! It would show them what a naive combination of technology could do. It would start an amazing conversation.

this might be more easily accomplished using just one technology per feeder

I want to be able to demo everything Gridlab can do. Also, I want to demonstrate what happens when you combine every distribution technology available. Also I want to check to see if the feeder is usable/editable in the OMF's GUI. Switching between multiple (5? 10?) feeders to do all of these things is a lot harder than just using 1 .glm.

Right now, we don't have functionality in GridLAB-D to charge and discharge based on a house's load and the solar panels on that house. Currently, our primary application for energy storage is load-following (shaving peaks, filling valleys) and we were thinking of implementing this in such a way that each residential energy storage device executes this load-following function using a nearby neighborhood node or a more central substation node as the control signal. Do you think this would work for you?

If the Gridlab batter (inverter, right?) can do load following, why can't each battery follow the house it's attached to? If that's not possible per house, then per "nearby neighborhood node" would be fine.

I'm surprised this megafeeder doesn't already exist. I thought this issue would take maybe 30 minutes of work. I thought there was a Matlab script out there that would put whatever you want on a feeder no problem.

Do you want to do a call to discuss this? I proposed a time for tomorrow, or let me know if it's not needed or what time you want to move it to.

[trevorhardy]

I got your meeting invitation; we'll go over all of this then.

[dpinney]

What's the status of this? When can we run the GLM?

[dpinney]

Changed named to "Gridlab Supermodel" since that sounds friendlier than "craziest". I still think that craziness can teach us things.

[dpinney]

The model was committed to /omf/omf/scratch/glmSuperModel/ by @trevorhardy. He's still working on diesel and wind generators.

[dpinney]

Glm runs. Still need the other items on the todo list.

[dpinney]

On my todo list now.

[dpinney]

Done in cf775342a32dabfca369f37ef65d3f7bce67b7f4