Updates EV fleet - Discussion Price Optimization Service - Round trip efficiency

[afernandezcanosa]

@emayhorn @hlngo This PR includes the addition of charging and discharging efficiency calculations that are used to calculate the round-trip efficiency matrix.

These API variables are used by @TomEdmunds for his Price Optimization Grid service.

The variables are named according to the API convention:

            if power_demanded == 0:
                response.Eff_charge = 0
            else:
                response.Eff_charge = (power_dc_demanded*dt)/(power_demanded*dt)*100       
            if power_ac_discharge == 0:
                response.Eff_discharge = 0
            else:
                response.Eff_discharge = (power_dc_discharge*dt)/(power_ac_discharge*dt)*100

[afernandezcanosa]

@TomEdmunds @emayhorn @raselmahmud02 I have created a script to show how to compute the roundtrip efficiency by using the Beq API.

Here you can see the results:

I have also added a csv file with the results, which is inside the data folder of the electric vehicles fleet.

I assumed that the discharge efficiency is 0 when the vehicles are at home charging, is this reasonable? I don't recall exactly, but that's what I have understood from today's discussion.

[afernandezcanosa]

@can7huang I forgot to include you in the thread. Let me know if this looks good to you.

I have assumed that the discharge efficiency is 0 when the vehicles are at home charging and not being discharged, is this reasonable?

[TomEdmunds]

Alejandro,

If the vehicle is at home charging at time t, we may want to stop charging it and charge at a later time when prices are lower. This action is equivalent to injecting power into the grid at time t (like discharging a battery) and withdrawing power from the grid at some later time (like charging a battery). I would think we would want to use the actual efficiency (kwh in vehicle/kwh withdrawn from grid).

Also, do you have a hard constraint on the time when it must be charged (Trestore)? We would like that too.

Tom

From: Alejandro Fernandez Canosa notifications@github.com Sent: Monday, March 18, 2019 1:50 PM To: GMLC-1-4-2/battery_interface battery_interface@noreply.github.com Cc: Edmunds, Thomas A. edmunds2@llnl.gov; Mention mention@noreply.github.com Subject: Re: [GMLC-1-4-2/battery_interface] Updates EV fleet - Discussion Price Optimization Service - Round trip efficiency (#67)

@can7huanghttps://github.com/can7huang I forgot to include you in the thread. Let me know if this looks good to you.

I have assumed that the discharge efficiency is 0 when the vehicles are at home charging and not being discharged, is this reasonable?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/GMLC-1-4-2/battery_interface/pull/67#issuecomment-474095201, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AmujXijCush0zDrYbcuX4iBMsCxZHkmOks5vX_vvgaJpZM4b6jG6.

[afernandezcanosa]

@TomEdmunds @can7huang That makes sense. Then, this means that the discharge efficiency could be different than zero even at the times when the car is at home plugged-in, right?

Just to give you some context. We are simulating a fleet of 100 sub-fleets (each sub-fleet is a homogeneous group of vehicles) with three different charging strategies:

1. Start charging right-away.
2. Start charging at midnight.
3. Start charging as late as possible to be fully charged one hour before the Time Charge Is Needed (TCIN).

We can only control the first control strategy, which is 40 % of the fleet. The rest of the sub-fleets will be charged according to their charging strategy and we cannot control them (This is a constraint that we have assumed because most of the users that choose the last two will want to have control over their charging profiles).

For the first charging strategy, we are computing the Trestore of each sub-fleet as each of them will have a different Trestore to meet the TCIN. I don't think we could provide a unique Trestore for the entire fleet.

[afernandezcanosa]

@hlngo @emayhorn I have added P_base and Q_base to the fleet_response.py API variables and computed them in the EV fleet for the service developers to use them in the reporting. See commits 274eba3 and f5bd00a

Also, @hlngo @emayhorn Do you think would it be interesting to add the service_weight parameter as one of the variables that we can change for the integration tests? This way, we can study how the performance metrics change as a function of the weight. I think this will give us some insights about the efficacy of the different devices to provide grid services.

Thanks!

[hlngo]

@afernandezcanosa Thanks a lot. The PR looks good to me. @emayhorn What do you think about the service_weight suggested by @afernandezcanosa ? We can certainly do it but I am not sure about adding more work provided current deadline. Cc @Hayden-Reeve

[emayhorn]

@afernandezcanosa Thanks a lot. The PR looks good to me. @emayhorn What do you think about the service_weight suggested by @afernandezcanosa ? We can certainly do it but I am not sure about adding more work provided current deadline. Cc @Hayden-Reeve

@hlngo Yes I think we want to do this. It was already on my to do list to add service_weight as a parameter that can be changed in the integration test file. I will add it this weekend unless @afernandezcanosa already has code to do this.

[afernandezcanosa]

@hlngo @emayhorn @Hayden-Reeve The service_weight parameter can now be changed in the integration test.py file. In the fleet_factory, I have only included the service weight in the fleets that currently have the scaling implemented (PVs and EVs). Once the rest of device PRs are merged, we can add the service_weight into the fleet_factory.py for them.

[hlngo]

@afernandezcanosa thanks for the update

[afernandezcanosa]

@hlngo Let me know if the PR looks good and can be merged. I will probably need to make a new PR to change a couple of details about the baseline, but I think this one can be merged. I will open an issue if I have something to talk about the Price Optimization Service.

Thanks!

[hlngo]

@afernandezcanosa It looks good. I will merge it in master.