[x] Move the daily_values multiplier out of the get_total_hdv_daily_vmt function (currently modifying the sample data's annual_vmt) via this equation
daily_vmt_total = daily_values * annual_vmt
and into the smart_charging function to modify the bev_vmt scalar via these equations
Line 274: outputelectricload * daily_values[day_iter] / (daily_vmt_total[day_iter] * 1000) * bev_vmt
Line 221: cost += tripload * daily_values[day_iter] / 1000 / daily_vmt_total[day_iter] * bev_vmt
[x] The same edit above holds for both the LDV and HDV process (Lines 295 and 244 in the LDV code)
[x] Change get_total_daily_vmt to return a vector with each day's total VMT, as the name of the function suggests
[x] Merge the get_total_hdv_daily_vmt and get_total_daily_vmt into one function. This will require adding something to the HDV dataset signifying only one type of day exists in this data, whereas the LDV data has weekdays and weekends separated. Perhaps this could be generalized to have any number of "types of days" instead of assuming only weekdays vs weekends. This also should be generalized to be a vector of any length, not hard coded as 365 as it currently is.
[x] We should double-check that the function generate_daily_weighting works for the HDV dataset, since that does not have the weekday and weekend differentiation. In the HDV case, we still want the monthly variation along with the rural and urban variation
Vehicle Filtering Edits
[x] Remove the vehicle range filtering from the `get_total_hdv_daily_vmt' function
[x] Instead, modify the data sent to the immediate and smart functions by removing vehicles that drive more than that input range (e.g. 100 miles) is able to support (see next bullet for one potential implementation)
[ ] Add a function (or perhaps repurpose the calculate_charging function) that for each vehicle, assumes a full battery at the start of the day, with the starting state of charge a calculation based on the battery range (e.g. 100mile, 200mile, etc) and vehicle's fuel efficiency (kwhmi). Then, calculate the state of charge for each vehicle over the course of their trips in the sample data, including the increases to the state of charge when dwell times allow for charging. If at any point the SOC goes below zero (and with a cap maxing the SOC to never exceed 100%), then that vehicle should be filtered out for this particular set of inputs.
Other Edits discovered
[ ] The lines currently in 48-50 of the smart_charging_HDV.py file are extraneous and should be removed
if veh_type.lower() == "ldv":
newdata = data_helper.load_hdv_data("lhdv", filepath)
Daily VMT Edits
[x] Move the
daily_valuesmultiplier out of theget_total_hdv_daily_vmtfunction (currently modifying the sample data'sannual_vmt) via this equationdaily_vmt_total = daily_values * annual_vmtand into thesmart_chargingfunction to modify thebev_vmtscalar via these equations Line 274:outputelectricload * daily_values[day_iter] / (daily_vmt_total[day_iter] * 1000) * bev_vmtLine 221:cost += tripload * daily_values[day_iter] / 1000 / daily_vmt_total[day_iter] * bev_vmt[x] The same edit above holds for both the LDV and HDV process (Lines 295 and 244 in the LDV code)
[x] Change
get_total_daily_vmtto return a vector with each day's total VMT, as the name of the function suggests[x] Merge the
get_total_hdv_daily_vmtandget_total_daily_vmtinto one function. This will require adding something to the HDV dataset signifying only one type of day exists in this data, whereas the LDV data has weekdays and weekends separated. Perhaps this could be generalized to have any number of "types of days" instead of assuming only weekdays vs weekends. This also should be generalized to be a vector of any length, not hard coded as 365 as it currently is.[x] We should double-check that the function
generate_daily_weightingworks for the HDV dataset, since that does not have theweekdayandweekenddifferentiation. In the HDV case, we still want the monthly variation along with theruralandurbanvariationVehicle Filtering Edits
[x] Remove the vehicle range filtering from the `get_total_hdv_daily_vmt' function
[x] Instead, modify the data sent to the
immediateandsmartfunctions by removing vehicles that drive more than that input range (e.g. 100 miles) is able to support (see next bullet for one potential implementation)[ ] Add a function (or perhaps repurpose the
calculate_chargingfunction) that for each vehicle, assumes a full battery at the start of the day, with the starting state of charge a calculation based on the battery range (e.g. 100mile, 200mile, etc) and vehicle's fuel efficiency (kwhmi). Then, calculate the state of charge for each vehicle over the course of their trips in the sample data, including the increases to the state of charge when dwell times allow for charging. If at any point the SOC goes below zero (and with a cap maxing the SOC to never exceed 100%), then that vehicle should be filtered out for this particular set of inputs.Other Edits discovered
smart_charging_HDV.pyfile are extraneous and should be removed if veh_type.lower() == "ldv": newdata = data_helper.load_hdv_data("lhdv", filepath)hdv_cat = 1