GMLC-1-4-2/battery_interface

Discretized frequency response - EV fleet

Closed this issue · 8 comments

afernandezcanosa commented

Hi @emayhorn @Hayden-Reeve @jmaguire1 @DavidWiniarski-pnnl @hlngo @yliu250

I have implemented a discretized version of the frequency response for the EV fleet. I have to keep testing it to minimize discretization error, but I will be able to finish a PR this afternoon.

Here you can see some preliminary results with randomized deadbands between 0.05 and 0.25.

frequency_response_ev_discretization_1

Also, I have two questions that I'd like to comment with you:

  • As all the fleets are referenced to the baseline, negative power means that more vehicles demand charge that in the baseline power profile. Therefore, should the fleet respond like this?

    • If f < 60 Hz, then increase grid load (more negative power referenced to the basline)
    • If f > 60 Hz, then reduce grid load (more positive power refercend to the baseline).

  • How can we decide grid convergence? This solution looks fine to me in terms of cpu cost and discretization error, but it can be interested to have a unique criteria for all the devices.

Thanks!

Hayden-Reeve commented

@afernandezcanosa

Thanks for posting the great results. To answer your questions:

  1. When the grid frequency reduces <60 Hz (typically due to loss of generating capacity) the load on the grid should decrease and the fleet should reduce charging and inject power into the grid (compared to baseline). Hence service power should be positive. For >60Hz the opposite is true.

2)I agree that the result looks good (we may want to study and tweak the dead-band). I think this result is great for now. Once @yliu250 has performance metrics we could do some runs to show that a X% increase in number of fleet members does not change the performance metric score by Y%.

Finally, will your PR include the code you used to store the data and plot it? If not could you share it as I plan to work with Yuan to standardize this in the service and hopefully have standardized post-processing library for all services.

  • 👍2
afernandezcanosa commented

@Hayden-Reeve Thanks for the response. I'll change my fleet according to your first answer and see what are the best dead-band parameters.

I will also add the initial time in the fleet request as it has been done in the PV fleet. The availability of the fleet is one of the most important aspects to study in this fleet.

Regarding the last question, I can include the script that I have used to plot the frequency responses. Also, what kind of performance metrics are you planning to include for this particular service? Just to know what kind of plots I should include.

Hayden-Reeve commented

@afernandezcanosa , I still need to close with @yliu250 on performance metrics. Will be discussed in the meeting tomorrow as well.

afernandezcanosa commented

@Hayden-Reeve @yliu250 I have changed the sign convention to be consistent with the normal grid demands when there are frequency deviations and include it in my PR #46

I am satisfied with the results at this time, but we may need to implement a more elegant solution in the future (please note that 60 - f is represented in red to have the same trend in both the power and the frequency).

discretized_freq_response

Please, feel free to reference #46 for the rest of discrete device developers in case they want to develop a similar solution. I have also included a test_autonomous_response.py file to plot the results and confirm that everything works fine.

Thanks!

afernandezcanosa commented

@Hayden-Reeve it is normally easier to reference parts of the code directly by using permalinks like this one for the discrete frequency response implementation:

battery_interface/src/fleets/electric_vehicles_fleet/electric_vehicles_fleet.py

Lines 192 to 193 in 75e94ff

self.db_UF_subfleet = np.random.uniform(low = self.db_UF[0], high = self.db_UF[1], size = (self.N_SubFleets, ))
self.db_OF_subfleet = np.random.uniform(low = self.db_OF[0], high = self.db_OF[1], size = (self.N_SubFleets, ))

For the post-processing part, see:

battery_interface/src/fleets/electric_vehicles_fleet/test_autonomous_response.py

Lines 63 to 73 in 75e94ff

fig, ax1 = plt.subplots()
ax1.set_title('Discretized Frequency Response for EVs')
ax1.plot(t-t[0], p/1000, 'b-')
ax1.set_ylabel('Service Power (MW)', color='b')
ax1.tick_params('y', colors='b')
ax1.set_xlabel('Time (s)')
ax2 = ax1.twinx()
ax2.plot(t-t[0], 60-f, 'r-')
ax2.set_ylabel('60 - f (Hz)', color='r')
ax2.tick_params('y', colors='r')

This way you can see the file where the code is placed, the path, the commit number, and the code itself. I hope this helps!

Hayden-Reeve commented

@afernandezcanosa , those are the permalinks in my comment. I am not sure they are not previewing and displaying correctly. It worked in other posts (like #53 ). Let me know if you have any suggestions on why it may not be showing up correctly. [Edit: I think it may be because I referenced your fork rather than the pull request version - will check]

afernandezcanosa commented

Exactly, permalinks only work if you reference some master branch code.