-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
EV #152
base: develop
Are you sure you want to change the base?
EV #152
Conversation
Also fix call to ElectriVehicle struct
This also reduces excessive dV creation
Add EVSE sizing and cost
Avoid extraneous switching and incentivize plugging in when EV arrives and staying plugged until it leaves
changes for review
we dont want to double count EV energy requirements in energy balance
allow seasonally varying EV schedules and SOC levels
account for power to energy conversion correctly.
add total EV loads time series to ElectricLoads output key
max_c_rate::Float64 = 1.0 | ||
ev_on_site_start_end::Array{Array{Int64, 1}, 1} = [[0,0],[0,0],[0,0],[0,0]] # This should **maybe** be an array of arrays (meant to be array of tuples, could convert) | ||
ev_on_site_series::Union{Array{Int64, 1}, Nothing} = nothing | ||
soc_used_off_site::Array{Array{Float64, 1}, 1} = [[0.2,0.8],[0.2,0.8],[0.2,0.8],[0.2,0.8]] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rathod-b what do the two values in the inner arrays mean? I was thinking there's just one "SOC used" value for each quarter. The ev_on_site_start_end have two values because you need the start and end timestep.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The pair of values in each array can represent the typical incoming EV SOC and desired outbound EV SOC for each quarter. I was thinking that the outbound SOC can be different based on quarters, allowing us to model higher desired SOCs in the summer and winter due to HVAC use and comparatively lower desired SOCs in Fall/Spring. Hopefully this makes sense. Maybe I should rename this fieldname to ev_arrive_depart_soc
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I thought that might be the case. We currently we also have leaving_next_time_step_soc_min
and back_on_site_time_step_soc_drained
which are placeholders for custom hourly/15-minute data that would be a separate way to enter this data (along with ev_on_site_series
, but that might be redundant if we have the first two series data). I think you already know this, so no need to respond.
add missing end statement in EV tests
Also update ev test
initial changes for testing
test osim with ev, rm some bugs
update how EVs are included in osim
minor updates, combine EVs and BESS into 1 battery during outage simulation.
Include a number of
ElectricVehicle
s that have most attributes ofElectricStorage
with additional attributes such as:Define the
EVSupplyEquipment
(EVSE is a common industry term to describe the charging station and related controls) which includes the electric capacity (kW) and cost of discrete options to represent different classes/levels of charging stations, such as level 1, 2, and 3. The ability for the EV to discharge back to the site load (V2G) is also defined here.