GMLC-1-4-2 / battery_interface

Implemenation of Device Models and their Battery Equivalent Interface
MIT License
5 stars 0 forks source link

Updated plots and spinning reserve metrics, NaN signal #66

Closed jingjingliu2018 closed 5 years ago

jingjingliu2018 commented 5 years ago

Added P_togrid and P_base to regulation and spin reserve services; updated multiple metrics in spin reserve; in spin reserve, when there's no event, changed from "0" to "NaN" It's not working with either battery or EV fleets yet, but assuming it would once device models are updated to handle NaN signals.

afernandezcanosa commented 5 years ago

@jingjingliu2018 @emayhorn I think we talked about having the availability to respond to None requests instead of NaN requests. The EV fleet has the availability to respond to None requests at this time. Thanks!

jingjingliu2018 commented 5 years ago

@afernandezcanosa @emayhorn @rhosbach I don't disagree. But I want to understand better whether we can go with NaN as an alternative because we are getting quite a few errors when we tried None. I'm not deep enough in Python to know all the differences NaN and None will make for us. Would changing to NaN be easy or problematic for EV? Any thoughts on whether we can go with NaN instead?

afernandezcanosa commented 5 years ago

@jingjingliu2018 @emayhorn @rhosbach,

NaN and None are different python types. We could have agreed to use any of them, but we finally agreed to provide our fleets the capability of handling None requests because seems to have more sense, but it is just a convention.

See examples of PVs and EVs of how we are handling None requests.

https://github.com/GMLC-1-4-2/battery_interface/blob/bdd2558a2b241d5c265d29cc3efc459a516a4950/src/fleets/PV/PV_Inverter_Fleet.py#L826-L829

https://github.com/GMLC-1-4-2/battery_interface/blob/bdd2558a2b241d5c265d29cc3efc459a516a4950/src/fleets/electric_vehicles_fleet/electric_vehicles_fleet.py#L290-L294

rhosbach commented 5 years ago

Thanks @afernandezcanosa (and @jingjingliu2018) . I think I've got the code handling None values on our end as opposed to NaN values. I've tested that it runs on the BatteryInverter fleet for all of January (though P_togrid and, by extension, P_base are empty), and it also appears to run for January 1st for the EV fleet (that fleet takes much longer to run than the BatteryInverter fleet, which is why I only tested for a day).

If either of you notice any issues on your end, please let me know.

afernandezcanosa commented 5 years ago

@rhosbach @jingjingliu2018 Thanks! Yes, the EV fleet takes much longer to run. Probably because the default number of sub-fleets is 100. I ran it in the past for three days with three consecutive events in January and the results looked good.

I need at least 100 sub-fleets to have enough variability because, at this stage of the code, the EV fleet is only able to respond turning on/off batteries (probably, once we have a good experimental understanding about how to modulate the power, we can update the code).

emayhorn commented 5 years ago

Thanks @afernandezcanosa (and @jingjingliu2018) . I think I've got the code handling None values on our end as opposed to NaN values. I've tested that it runs on the BatteryInverter fleet for all of January (though P_togrid and, by extension, P_base are empty), and it also appears to run for January 1st for the EV fleet (that fleet takes much longer to run than the BatteryInverter fleet, which is why I only tested for a day).

If either of you notice any issues on your end, please let me know.

@rhosbach Did you ever commit your code that handles 'None' values? I tried running a reserve service/EV integration test with the latest code you committed and I am getting an error.

jingjingliu2018 commented 5 years ago

Sorry we failed to commit those changes. It should be in the PR now.

On Wed, Mar 27, 2019 at 6:38 AM emayhorn notifications@github.com wrote:

Thanks @afernandezcanosa https://github.com/afernandezcanosa (and @jingjingliu2018 https://github.com/jingjingliu2018) . I think I've got the code handling None values on our end as opposed to NaN values. I've tested that it runs on the BatteryInverter fleet for all of January (though P_togrid and, by extension, P_base are empty), and it also appears to run for January 1st for the EV fleet (that fleet takes much longer to run than the BatteryInverter fleet, which is why I only tested for a day).

If either of you notice any issues on your end, please let me know.

@rhosbach https://github.com/rhosbach Did you ever commit your code that handles 'None' values? I tried running a reserve service/EV integration test with the latest code you committed and I am getting an error.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/GMLC-1-4-2/battery_interface/pull/66#issuecomment-477158190, or mute the thread https://github.com/notifications/unsubscribe-auth/AlzNqVUP9fWEeLghPeHOZL2kyRFljjbvks5va3RHgaJpZM4b1N3w .

-- Jingjing Liu, P.E., CDCP, BEAP, CP EnMS – Industrial, SEP Performance Verifier – Industrial

Program Manager Building & Industrial Applications, Energy Technologies Area Lawrence Berkeley National Laboratory Phone: (510) 486-5410 Email: JingjingLiu@lbl.gov psheaffer@lbl.gov Web: https://industrialapplications.lbl.gov/

emayhorn commented 5 years ago

@afernandezcanosa I am testing peak management service with electric vehicles. Before I run the simulation, I did have a new baseline generated. At the start of the simulation, P_req=0 is sent to the fleet for an entire day. From the response, I noticed that P_service is not 0 as expected. What is causing the power demanded to deviate from the baseline when there is a '0' P_req?

afernandezcanosa commented 5 years ago

@afernandezcanosa I am testing peak management service with electric vehicles. Before I run the simulation, I did have a new baseline generated. At the start of the simulation, P_req=0 is sent to the fleet for an entire day. From the response, I noticed that P_service is not 0 as expected. What is causing the power demanded to deviate from the baseline when there is a '0' P_req?

@emayhorn Good question! As we have a lot of variability (driving patterns are extremely impredictible), we thought that it will be great to provide a P_base from Montecarlo simulations of at least 10 random seeds. Then, when you run a process request, you only run it for one random seed, and therefore it will deviate from the baseline (although it should very close most of the time) by definition.

If we really want to avoid this, we can run for 10-20 random seeds and calculate the average, which will be very very close to zero.

We could have defined the basline different, but I think this way is more realistic. Is it make sense?

Thanks!

afernandezcanosa commented 5 years ago

Also, I'd like to point out that most of the EVs have uncontrollable charging strategies. People charging at work, other places, or at home with Charging modes 2 and 3 are uncontrollable. Only charging overnight at home with charging mode 1 is controllable (which in the current model is about 40 % of the fleet).

emayhorn commented 5 years ago

@afernandezcanosa I think there may be an issue. The difference is not small. With 401 MW fleet rating, P_service is computed to be greater than 100 MW in response to '0' P_req.

It seems you are using two different methods to obtain the baseline and the response to P_req as well as different seeds to initialize the baseline and the main run. I am not completely sure, but this could be the cause of the large difference.

Also, when P_req='None', I'm thinking it may be better to have the fleet respond with P_service = 0. What do you think about that?

afernandezcanosa commented 5 years ago

@emayhorn Yes, you are totally right. This is very good point that we discussed so much in the past and perhaps we overcomplicated the problem. The difference is not small because of the resolution of the simulation you are running.

If we run the forecast with an hour-by-hour resolution. Then, it will have a very different P_service than zero as the baseline is calculated with a second-by-second resolution. See example below.

image

We have a very good calculation of the baseline as it is based upon Montecarlo simulations trying to reproduce as much as variability as possible (Otherwise you will have to run it for 10,000 sub-fleets or so and it will take many hours to run each request). So, I think this situation is fine as this is the normal operation of the fleet. If we really want to change this, I can think of two different solutions:

  1. Redifine the baseline and base it only on the random seed that is being used. This way the fleet will only respond to negative requests by delaying charging of fleets that are being charged with Charging Mode 1. (I think that this solution will be simplyfing the model and decrease the accuracy of the P_base, but it will solve this 0 issue). (Also, this will take me some time to recode it and I will have to change a good portion of the report, but I will be find if this is necessary).

  2. Respond with P_service = 0 when P_req = None and forget about all the calculations that are being done in the simulate method (I can return the rest of the API variables and only change this variable).

Also, I think if you just need to generate a new baseline for the peak management service, I think you can just decrease the sim_step (the shorter, the better) and see if this makes P_service goes to zero.

What do you think?

emayhorn commented 5 years ago

@afernandezcanosa I think you should go ahead and make the change to respond with P_service = None when P_req = None. This is would be consistent with the latest version of the device model report (section 3.4.3): P_service = P_togrid - P_base, when P_req != None P_service = Null if P_req = None

However this change does not help to resolve the error between baseline and P_togrid when P_req = 0. I will test the peak management with a shorter time step to see if that helps resolve the issue. I may have to make some modifications to the code to account for a smaller time step since I am dealing with an hourly drive cycle. Will get back to you on this.

afernandezcanosa commented 5 years ago

@emayhorn Ok, I will go ahead and change that this weekend. Also, let me know what happens with smaller time steps, but I am sure the results will be better (Although not zero as the baseline power is calculated as explained in the report).

To run the peak management service, is required to run the forecast method, isn't it?