search

pnnl / tesp

Other
39 stars 37 forks source link

SGIP1 load oscillations #46

Closed trevorhardy closed 3 years ago

trevorhardy commented 3 years ago

The v1.0.0 implementation of the SGIP1 example shows oscillations in the power system load but not price. These oscillations are only present in the transactive case and are more dominant in the first day of the two-day simulation prior to the outage on day two that drives prices higher.

The energy storage devices show these oscillations as well but are in load-following mode within GridLAB-D and its unclear if these devices are the cause or another indication of a broader problem.

validation_transactive_bus_loads2

validation_transactive_bus_prices

validation_transactive_bus_loads4

trevorhardy commented 3 years ago

I've been doing some digging the past day or so and have found the following:

  1. As revealed in the SGIP1b.csv, both the responsive and unresponsive load at bus 7 is 0 MW.
  2. Relatedly, the aggregation of the GridLAB-D bids is being approximated as a 0-order fit.
  3. The co-simulation message exchange does appear to be in place between the substation and PYPOWER (e.g. unresponsive_MW)
trevorhardy commented 3 years ago

substation1b.log is showing an error in helpers.parse_fncs_magnitude:

parse_fncs_magnitude does not understand pypower

That method is being called in substation.py in the fncs_substation_loop and only in one spot. The value it should be receiving is the LMP via FNCS but somehow pypower is getting put in. PYPOWER is the sender of the message and full topic name is pypower/LMP_B7. I'm going to keep digging.

trevorhardy commented 3 years ago

As part of adding HELICS support, to publish the LMP fncsPYPOWER.py is checking for variable (pub_lmp) that was only being set by the HELICS portion of the code but not the FNCS portion. A test was made on that variable's existence to determine if the LMP should be published; due to FNCS not setting the variable the LMP was never getting published. Checking a fix now.

trevorhardy commented 3 years ago

Well, my fix didn't work. Hoping to dig into it later.

trevorhardy commented 3 years ago

I think I was wrong about my conclusion on the bug. I think the HELICS iteration is using pub_lmp as a flag for HELICS use.

The FNCS publication is never happening, though so I'm going to keep digging.

trevorhardy commented 3 years ago

OK; I got fooled by that lack of flushing to file of Python print() commands I was using for debugging.

FNCS publication is being reached by PYPOWER and I just hooked up the fncs_tracer and verified that pypower/LMP_B7 is getting onto the FNCS message bus.

trevorhardy commented 3 years ago

For some reason fncs.get_values("LMP") (the key for pypower/LMP_B7) in substation.py is returning pypower. The key "LMP" is what is returned a line or two before by fncs.get_events().

trevorhardy commented 3 years ago

I'm in the trenches of debugging confusion and have to go on to something else so I'll leave with this summary:

  1. fncs_tracer shows that pypower/LMP_B7 is a numerical value (well, string since we're using FNCS).
  2. print statements in substation.py show that even by the very first time step, fncs.get_value("LMP") returns pypower. The only time I see a reasonable value returned by this call is when I ask for on the first time step right after being granted a time, prior to the traditional method of fncs.get_events() to determine which keys need to be used to get new values.
trevorhardy commented 3 years ago

Resolved with Tom's patch. validation_transactive_bus_loads2

Still other issues with the controller being very price responsive during the first day. I'll open another issue for that.