Electric Vehicle Artificial Inertia Results

[Hayden-Reeve]

@afernandezcanosa ,

When I run the latest code I get constant p_service from EVs for AI (see below). I think a key reason is that the AI service is implementing Fleet_Request with a delta time of 0.0333 seconds. Your code then turns this into integer seconds resulting in a dt of 0 rather than the 1 you used in your testing. The result seems to be that the same frequency is called over and over again as self.ts is used to march forward time. Would it be possible to have ts=<1 second so time increases correctly but then round it later when calling your fleet performance? @yliu250 , @emayhorn , do you have any ideas or suggestions?

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

https://github.com/GMLC-1-4-2/battery_interface/blob/bdd2558a2b241d5c265d29cc3efc459a516a4950/src/fleets/electric_vehicles_fleet/test_autonomous_response.py#L27-L28

[afernandezcanosa]

@Hayden-Reeve Thanks for bringing this issue! Yes, that seems to be the problem. We were discussing this issue in the past and the problem is that the EVs are not able to respond to dt <= 1 sec due to physical constraints. You can change the code to allow it and it will run, but it is not realistic according to our testing.

@emayhorn @yliu250 I guess that one possible solution could be to change the time step in the AI service to run it against the EV fleet. I am pretty sure that some other devices won't be able to respond to subsecond requests either.

[Hayden-Reeve]

@afernandezcanosa ,

Thanks for the suggestion (not sure why I did not think of that - maybe too much travel)! When I set the artificial inertia ts = 60/60 (instead of 2/60) it produces a much better results (and speeds things up).

@yliu250 , is this OK from a simulation accuracy? I think it will have to do. We could look at how performance metrics change as a function of ts for devices that can run faster than 1 second. Or we could continue to down-sample EV and see how the results change. We can discuss at the next meeting. If this approach is OK I recommend that AI's ts be set dynamically based on the device type.

https://github.com/GMLC-1-4-2/battery_interface/blob/bdd2558a2b241d5c265d29cc3efc459a516a4950/src/services/artificial_inertia_service/artificial_inertia_service.py#L34

[Hayden-Reeve]

@afernandezcanosa ,

I ran the EV AI case through other times of day and found cases when the P-service is negative. This does not make sense to me. Do you have any ideas on what may be going on? See results below for 7pm GMT (seems reasonable) and 12 noon GMT (large negative P-service at the start).

[afernandezcanosa]

@Hayden-Reeve,

Thanks for bringing this question! There is a reason behind the negative service power.

We considered that the best possible way of defining the baseline case was to run a multi-day Montecarlo simulation with different driving patterns (10-20 days seems reasonable) and store the results (p_base, SoC) in csv files (if you change the parameters of the fleet, you must run the MC simulation and store the baseline again).

This way, we can avoid the possible random bias encountered when you just run one simulation (the other option is to run simulations with ~10,000 sub-fleets and update the baseline each second, but this option is computationally expensive).

Let's suppose that in the simulation that you are running there are 5 sub-fleets of 2,000 vehicles each that have already arrived home and have selected the charging right-away strategy. These will start charging and we will have a negative service power.

We thought that this way of computing the baseline will give us more flexibility as we can have more sub-fleets that are being charged with respect to the baseline case, and therefore, negative service power.

Does it make sense?

[afernandezcanosa]

Actually, at 12:00 PM, we will have many sub-fleets that are being charged at work and other places that are purely uncontrolled. I guess that the best way to avoid this will be to run the same service with 5-10 different random seeds and average the result.