Handle grid throttle scenario in time_to_fill in powercurve_ops

[clintonsteiner]

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 #146
for more backstory

[clintonsteiner]

Taking a look at this now

[clintonsteiner]

#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]

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]

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]

Closed by #184