search

matsim-org / matsim-libs

Multi-Agent Transport Simulation
www.matsim.org
489 stars 449 forks source link

EV: confused about charging #1960

Open nkuehnel opened 2 years ago

nkuehnel commented 2 years ago

Hi everyone,

I'm a bit confused about the implementation of charging.

There are two interfaces,

ChargingPower: https://github.com/matsim-org/matsim-libs/blob/master/contribs/ev/src/main/java/org/matsim/contrib/ev/charging/ChargingPower.java

and BatteryCharging (which extends ChargingPower): https://github.com/matsim-org/matsim-libs/blob/master/contribs/ev/src/main/java/org/matsim/contrib/ev/charging/BatteryCharging.java

In BatteryCharging, there is the calcEnergyCharged method, which returns the amount of energy charged based on a given period: https://github.com/matsim-org/matsim-libs/blob/d90a10cae203dcd55b3425887058fc8b18048849/contribs/ev/src/main/java/org/matsim/contrib/ev/charging/BatteryCharging.java#L30

In ChargingPower, there is the method calcChargingPower https://github.com/matsim-org/matsim-libs/blob/d90a10cae203dcd55b3425887058fc8b18048849/contribs/ev/src/main/java/org/matsim/contrib/ev/charging/ChargingPower.java#L34

The actual charging typically takes place in the ChargingLogic, such as the ChargingWithQueueingLogic: https://github.com/matsim-org/matsim-libs/blob/d90a10cae203dcd55b3425887058fc8b18048849/contribs/ev/src/main/java/org/matsim/contrib/ev/charging/ChargingWithQueueingLogic.java#L58-L61

Here it makes use of the calcChargingPower(...) method to calculate the difference in state of charge. However, the calcChargingPower(...) does not have an argument for the period of time and the result is statically multiplied with the chargePeriod/chargeTimeStep defined in the EvConfig. This could make the calculation slightly inaccurate for larger time steps and more complex charging curves (which is probably fine in most cases). However, since we also have the calcEnergyCharged method in BatteryCharging interface, couldn't we just pull this method up to the ChargingPower interface and get rid of the calcChargingPower method? In the worst case both methods could even contradict each other in an implemented class. The advantage of using the calcEnergyCharged method directly in the charging logic would be that we could pass the charging time step as an argument for more accurate charging even in longer time intervals.

Or did I miss something?

nkuehnel commented 2 years ago

Ah I just realised that we just recently introduced the calcEnergyCharged(...) method in BatteryCharging. Maybe the calcChargingPower(..) method in ChargingPower has just become obsolete then...

michalmac commented 2 years ago

The initial idea was that in order to simulate charging, we only need the ChargingPower interface, which is easier to implement (and faster to compute). It works well if we simulate charging with relatively small time steps.

The BatteryCharging interface extends ChargingPower and introduces methods for computing charging times/energies in a longer time horizon (e.g. charging time until the SoC reaches 90%, or recharged energy given 1 hour of charging). These additional methods are useful for instance in the eVRP context, where we need to plan charging along with other tasks.

Right now VariableSpeedCharging implements only ChargingPower, whereas FixedSpeedCharging and FastThenSlowCharging implement both interfaces (BatteryCharging and ChargingPower).

I will add some java docs to both interfaces.

michalmac commented 2 years ago

@nkuehnel Perhaps we could improve the naming (BatteryCharging and ChargingPower) to avoid confusion in the future? Do you have any suggestions?

nkuehnel commented 2 years ago

@michalmac Thanks for the clarification!

Do you have any suggestions?

mh how about having something similar to BasicPlan/BasicLocation, e.g., "BasicCharging" and then we could have "ExtendedCharging" or "DetailedCharging" or even just keep "BatteryCharging"?