search

NREL / hive

HIVE™ is a mobility services research platform
https://nrelhive.readthedocs.io/en/latest/
BSD 3-Clause "New" or "Revised" License
22 stars 9 forks source link

Handle grid throttle scenario in time_to_fill in powercurve_ops #177

Closed clintonsteiner closed 1 year ago

clintonsteiner commented 1 year ago

To deal with the grid throttle scenario, what might be a good thing in the future would be to pass some max charge time argument. that at least can be set to int((sim.end_time - sim.sim_time) / sim.timestep_duration_seconds)

So in the scenario where the grid is throttled during charging, then 10 minutes later begins working again, we want to ensure we dont exit too early.

See https://github.com/NREL/hive/issues/146 for more backstory

clintonsteiner commented 1 year ago

Taking a look at this now

clintonsteiner commented 1 year ago

https://github.com/NREL/hive/pull/182 Link to PR lives here, will probably want to play around with some of the assumptions we are making

Manhattan scenario time increased to 232.56 seconds from 184.81 seconds

robfitzgerald commented 1 year ago

Manhattan scenario time increased to 232.56 seconds from 184.81 seconds

and i'm seeing why, the manhattan scenario is using "shortest_time_to_charge" charging dispatch. which, i mean, "shortest_time_to_charge" is a lot more sensible of a heuristic, but, a good deal more compute intensive and implies more perfect information for drivers about charge times at stations. was there a discussion amongst pycon folks to make this change?

unnecessary details

there's some tuning that could improve on these runtimes via the h3_search_resolution. the default charge search performs a 2-level expanding ring search, and the size of the search rings (h3_search_resolution parameter in HIVE) changes how big those hexes are in the search. if the rings are very small, we see more hexes in each expanding ring, but less stations per ring. that would do better in a denser scenario. this is set manually; in the future, we could target some average stations per hex and set it programatically, but, eh, scenario development is something we don't do everyday to warrant that kind of approach yet.

clintonsteiner commented 1 year ago

No sorry, just using that shortest_time_to_charge to test the changes in a compute intensive way. Removed this and opened up a fixed PR

nreinicke commented 1 year ago

Closed by #184