use the "profiler" extension to analyze where the expensive computations reside.

help me

remove old multi-unit charging approach from M.D. and the code.

also, we should add a sub-model to the M.D. describing how we handle multi-unit charging. in particular, describe how the input files must be configured and how to interpret the results of a model run to account for differences in home vs multi-unit charging.

this should be specified as an input data file rather than a bunch of hard coded values in initialize-drivers.

each TAZ needs a point where we consider to be the center of travel.... make it on the road network roughly population weighted

We need some sort of plot or test to help catch errors from inter-subroutine communication, to make sure all events are being scheduled correctly. For example:

1. Histogram of last time in driver's trips, compare to list of stranded drivers
2. Histogram of trip speed
3. Any excessive (or not enough) entires for a single driver within a given log (different threshold for each log)
4. Run the sensitivity analyses again, see if any potential errors pop out

let's think through how we could separate the level of the charger and the issue of access to the charger.

what would it look like if we reduced the number of charger types to 4 (L1, L2, L3, Batt. Swap) and then specified chargers that drivers have privileged access to.

so each driver would have a list (or stack or hashtable) of privileged chargers he can use, indexed by current TAZ, which would be considered alongside the public chargers in that TAZ.

this could be used to solve the problem of multi-unit chargers (b/c multiple drivers could have privileged access to a common charger) as well as non-residential chargers used in an exclusive fashion (e.g. business parks for employees only, fleet chargers, or the Tesla example).

Look into the CHTS data set (under pev-shared/data) and determine what sample size we have for the following regions of interest:

• Just the Upstate Region
• All of the counties in the "North State Super Region" (see http://www.superregion.org/)
• North State Super Region plus all of the counties in the central valley that don't have big cities (no cities >150k people)

Look at place.csv (which I believe should have a row for every trip taken, double check this) as well as long_distance.csv. Please read the documentation sufficiently to understand the difference between places and long_distance.

Also, feel free to make some summaries of the data, in addition to sample size the following kinds of summaries are of interest:

• distrbutions of trip distance by time of day, county, trip purpose, etc.
• distributions of dwell time at destination if possible to extract
• other ideas you come up with

do a read of the OD input to set n-nodes

definitely do this in a new branch, but please push this branch to github so I can see / play with it as work progresses:

create a new setup procedure called "setup-in-batch-mode"

• this procedure will assume that everything (all globals, drivers, etc.) starts at the exact same initial state except for the charging infrastructure which will vary from run to run
• the key purpose of this mode is to SKIP loading all of the driver data from a file (except for the first run), instead we will keep the same agents from the previous run and reset their state variables
• this will be called from the R scripts that do the batch processing
• so setup-in-batch-mode should test if there are any turtles created yet, if not then it knows this is the first run and it executes "setup"
• during setup-drivers (the existing setup version), every driver should make a copy of their itin lists (add new driver variables to do this) which will serve as the "master" version of their itins, i.e. a copy that is used to reset the working itin (which may get modified during the run). do some profiling of memory consumption with/without this addition, if the itin's represent most of the memory used by drivers, we may need to take a different approach.
• if setup-in-batch-mode finds that agents already exist, then it should do the following:
  • reset tazs (just clear drivers-in-taz)
  • reset chargers (clear current-driver, num-sessions, and energy-delivered)
  • reset drivers (see setup-drivers to see where state varaibles should begin) which should overwrite the itin lists with the master version.
• add two new functions to add/remove a single charger of a particular level from a taz, this will be used by the R script to modify the infrastructure scenario for the next model run. note that the list n-levels must be modified in addition to creating or killing the charger agent AND chargers-by-type must be recreated using the code in setup-chargers (at the end of the foreach sort tazs loop). make the commands behave like so:
  • add-charger
  • remove-charger

instead of using my-od-index throughout the code, do the following:

• add a variable to driver breed, call if "current-od-index"
• rename "my-od-index" procedure to "update-od-index" which will be a procedure called from a driver context, this procedure will update current-od-index variable using the same formula
• add update-od-index to the code at any point in which the destination taz changes for a driver (so in update-itinerary, but maybe in other places as well)
• now change all of the places where "my-od-index" was used and have them use "current-od-index" instead

Verify that model runs with the changes are identical to without.

for PEVI-nolog.nlogo, currently only the lines that use "log-data" are being commented out. as found by profiling, it's critical that we also comment out all commands that are only relevant to logging.

for example, in "arrive" the lines

let #is-scheduled true
if item current-itin-row itin-change-flag = 1 [ set #is-scheduled false ]

are not needed because #is-scheduled is only used to log data. there are numerous more examples of this in arrive and throughout the whole code base.

instead of maintaining a separate copy of PEVI.nlogo and PEVI-nolog.nlogo, please do the following:

• add a flag to the end of every line in PEVI.nlogo that should be commented out when logging is not needed, e.g.:

  let #is-scheduled true ;;; LOG
  if item current-itin-row itin-change-flag = 1 [ set #is-scheduled false ] ;;; LOG

• write a script (Colin can do this) that takes PEVI.nlogo as input and spits out PEVI-nolog.nlogo as output with all of the appropriate lines commented out.

the code has been updated to consider all chargers (not just available chargers) during the "last resort" calculation of break-up-chargers (see 9b01ed1).

make sure model description reflects this change

not needed in model

rework the model description to remove any inherent assumption that drivers reside within the simulation domain. it may be useful to refer to the code to figure out where these assumptions lie.

external trip distances -- using the OD data from Shasta, currently based on length of external trips to/from Shasta (randomly with an average of 25 miles)

PHEV assignment -- currently we assign drivers PHEVs if

• max trip longer than their range
• journey length longer than 1 full battery + amount they could charge at L2 during their max dwell time

If we keep this, drivers passing through the region will have PHEVs... if we don't keep this, we will be building infrastructure to serve some extremely aggressive itineraries....

optimization -- now based on minimizing the total cost to drivers (in terms of time) + investment in charging infrastructure. Sum of delayed time * 12.5 (discounted over 10 year horizon) + EVES installed cost.

• to more realistically capture time wasted, we needed to improve the realism of strandedness in the model. we came up with two types of strandedness, "hard" and "soft" strandings. A hard stranding means a person simply can't make it to their destination because they don't have enough charge and there is no EVSE that they can driver to. A soft stranding means a driver who needs a charge to make their next trip has waited around for too long, beyond a threshold we randomly assign between 0.5 and 2.5 hours).
• When a driver experiences a stranding we assume they temporarily abandon the vehicle. They either find a 110V outlet to plug into and come back later, or they come back later when they know the L2/L3 charger will be available. So they stop their actions for the rest of the model run and we levy a penalty on their delay time meant to simulate the time spent dealing with the problem, 6 hours for hard stranding and 4 hours for soft stranding.

for starting-soc and external-trip distribution files, if the file is not found and a default distribution is assumed, please print a warning to the screen to remind the user, e.g.:

"warning, no file found for starting-soc input distribution, uniform distribution between 0 and 1 is being assumed."

Note, please modify the model description before implementing in code. Feel free to lift language from this issue to do so.

In order to allow for inter-regional travel, we will add a special type of TAZ to the model.

These will be TAZs with a negative id number. They must be specified in the charger-input-file, e.g.:

;TAZ L0 L1 L2 L3 L4
1 1 1 1 0 0
2 1 1 1 0 0
3 1 0 0 0 0
-3 0 0 0 0 0
4 1 1 1 0 0
10 1 1 1 0 0
11 1 1 1 0 0
-11 0 0 0 0 0
12 1 1 1 0 0

Here TAZ -3 and -11 would indicate that TAZ 3 and 11 are gateway TAZs. In the driver-input-file, these TAZs can be referenced as origins or destinations, e.g.:

;driver from to depart home
1 1 15 7.22050404269248 1
1 15 20 13.7043858014513 1
1 20 -3 21.112122523063 1
2 -11 33 7.18663204205222 0
3 2 3 8.40144729008898 0

In the model implementation, external TAZs are treated just like regular TAZs (in fact, they should be allowed to have chargers if the user so chooses), except for a couple of key behaviors...

• External TAZs do not have a home charger.
• External TAZs do not get added to the neighboring TAZ list of any other TAZ
• Distance and time lookups on external TAZs involve a random draw. See below.

distance-from-to and time-from-to

In these procedures if the origin or destination has a negative id, then the distance or time is estimated as the sum from the internal TAZ to the gateway plus a random value drawn from a distribution controlled by a new input file called external-trip-distribution-input-file which will hold a distance and corresponding time distribution like so:

;draw-bound ext-dist ext-time
0 0 0
0.1 5 0.3
0.2 15 0.4
0.3 25 0.5
0.4 30 0.55
0.5 33 0.6
0.6 50 1
0.7 75 1.2
0.8 85 1.3
0.9 97 1.5
1 100 1.55

In the same way that random draws are taken from the starting-soc distribution, we will randomly draw from the distance/time distribution to select a distance/time for any trip that begins/ends at the external TAZ.

Every driver should hold a new variable called external-distance external-time that are initialized to -1 and only updated once per model run (make sure these get reset during batch mode resets).

When the random draw is made, BOTH distance and time are set, this way the distance and time will be directly relatable. In future calls to distance-from-to and time-from-to, the previously drawn value should be returned (so a test for a value of -1 will happen before the draw is allowed to proceed).

I'd like to add the model description to the repository so we can collaborate on it as if it were code (especially using the issue tracker). This will make it easier to maintain different versions of the document for different versions of the model (Humboldt / Upstate / Delhi / etc).

To do this I don't want it in word format, rather let's collaborate on it in markdown format. So the first step will be to convert the existing document into markdown. See the github markdown readme to get started. There are tons of other references on markdown online.

When we need outside feedback, we'll convert from the markdown version to word using "pandoc". See this issue for the skinny on installing pandoc.

Then we'll incorporate feedback back into the markdown document. It's a pain, but I since you and I will do most of the editing, I think the benefits of textual manipulations outweigh incorporating outside feedback.

min(timeUntilDepart,
fullChargeTimeNeed,
journeyChargeTimeNeed

available-chargers is called a lot and could be improved by using a stack instead of a list in chargers-by-type. this will require adding a new variable "available-chargers-by-type" which will be a list of stacks.

it is unclear if this change will reduce overall computation time because extra effort will be needed to push/pop chargers from the list of available, so this should be done in a branch and compared.

Also, an extension will need to be written to extend java stacks to netlogo.

Please use the netlogo variable naming conventions:

all-lower-case-with-dashes

The reason the model description is written with camel case (e.g. timeUntilDepart) is because the dashes are too easily confused with the minus operator. But definitely use the exact same words for the variables (e.g. use time-until-depart for timeUntilDepart).

Leaving this as 1 issue because they are very similar

setup PEVI with small number of drivers (0.5% pen) but don't run

export-world to a file

compare loading from this file (using import-world) vs loading running setup-drivers

analyze the file format to see if we might be able to reformat our itineraries

with new version of PEVI, redo sensitivity analyses that we conducted last January and add the following experiments:

• multi-unit-search-tolerance

T.B.continued

Some drivers are assigned new trips starting at times beyond the model run (for example, assigning a trip for day 5 in a 4 day run). These cause the model to crash in the "arrive" subroutine. We have a temporary fix, but we should fix the root problem

We should create a global "table" which is Netlogo's word for a hashtable/hash/dictionary to allow lookup of TAZ agents by any arbitrary integer that don't need to be ordered or start at 1.

See email I sent to you with subject "Table Benchmark" for an example of how to do this.

During setup-tazs, you'll want to add the tazs to the table as they are assigned their id from the charger input file. You'll need to remove the constraint in this procedure that requires sequential ordering of tazs in the charger file.

Finally, all locations in the code where we refer to a TAZ by number (e.g. "taz #") needs to be changed to use the table instead.

Discussion of dealing with "external" TAZs will be in another issue.

take the Shasta travel model TAZs and generate a set of proposed aggregated TAZs for review.

AT the end of submodels defined in the markdown document, but we've made more changes than that. Determine which submodels need another evaluation, possibly to determine if they work with new data types.

We need to think through adding the following features:

• Battery-swapping: this will be a new charger-type.
  • I think we could name it level 4 and just give it a very high rate of charge, something commensurate with the time it would actually take to visit the station (E.g. to charge 20kWh in 3 minutes is 400kW). This would avoid needing special logic about charge times, but when unrealistically make the charge time longer for people with lower SOC, but the couple of minutes difference is probably negligible.
  • Regardless, there is a bunch of logic that is hard-coded to expect charger levels 0-3, so we need to modify them all. I think that we can treat battery-swapping the same as level 3 in all regards as it is used in almost identical circumstances (more like a gas station and less like a destination).
• multi-unit dwellings: this will also be a new charger type, perhaps level -1
• this will be a cross between level 0 and level 2. drivers will need a boolean flag multi-unit-home? to mark if they live in such a residence. those drivers will not have access to a level 0 charger when home, rather they will be able to access a -1 level charge but there will be a finite number of these chargers.
• since this one is logically different from the existing charger types, it will take a bunch more code modification than the battery-swap

use this issue to track changes to M.D. that aren't linked to any other issue.

Seek charger has been updated to include instructions for special-permissions chargers.

try running PEVI with, monitor run time (using profiler extension) and memory consumption:

Drivers:

6k
24k
48k
96k
192k
384k
768k

TAZs:

52
104
208
416

do a line-by-line review to ensure that the code matches the model description, note that at least one modification happened to the code but not the M.D. in #5

this will require find/replace in the netlogo code, several R scripts, and all params.txt files throughout the project (both the repo and pev-shared).

there's a lot of code duplication between the batch mode and regular setup modes, refactor these.

experiment with 1 vs 2 at a time

experiment with skip.rate of 1 vs 3 vs 8, analyze stability of 1

change clusterApply to clusterApplyLB, but this may require changing how break.pairs is used...

we use "taz" everywhere, so it doesn't make sense to keep "node" as a name for them.