Discuss / decide on how to treat simulation fidelity

[futurechris]

The kickoff meeting had a brief discussion on simulation fidelity being adjustable.

So far as I know, improving simulation fidelity is not a primary goal of this project, but we will still need to consider fidelity shortcuts in our implementation. These will also help define what the simulator is doing.

If anything below is a facet we'll want to be able to change easily, then we'll need to architect the simulator appropriately to make that possible.

I'm not sure what the completion of this ticket requires. Perhaps we want to use this to create sub-tickets to analyze the PF&R data for whether any of these approximations look like they're throwing away a lot of information?

Otherwise, this ticket mostly serves as a set of architectural constraints.

---

Following are some of the facets the previous simulator cut fidelity on, based on my reading of the 2009 paper, "Simulation-based Optimization of Resource Placement and Emergency Response". Feel free to comment with other things you think are important, whether they come from the paper or just occur to you.

In no particular order:

• In general, stochastic parameters are replaced with fixed approximations, derived from the data. This helps simulation speed, but we should evaluate whether any given approximation is appropriate in Portland.
• Travel time is one of these, but deserves a special call-out:
  • It’s approximated based on distance traveled, binned. Travel speed is lower the shorter the distance traveled.
  • Because we know from our previous analyses that call density is highest in Portland during rush hour, it seems like modeling travel time more accurately may prove important.
• Distance is taxi-cab (sum of x and y distance traveled)
  • We know this would be a very poor estimate in some parts of Portland (FMA 27?).
• Units are considered to be out of service until they return to their home stations, as opposed to reality, where once in awhile they might be dispatched while returning to their station, or may be switched to a different call at any point during the call.
  • This may matter more in a city like Portland, given the size and scope. We have seen such events in the data, but I don't think anyone's computed frequency.
• Calls were binned based on required resources (i.e., if two call types require the same complement of units, for roughly the same amount of time, we can treat them as interchangeable)
• Personnel and vehicles are grouped into “units” - this seems to be how PF&R actually works, so not sure we’d benefit from adding fidelity here.
• Only simulated 4 most common unit types (engines, trucks, ambulances, battalion chiefs).
  • We’ll want to evaluate this for PF&R as well.
• “In our current simulation, when multiple units occupy a single station, the personnel of one unit may not operate the vehicles of another unit.”
  • May want to verify that PF&R doesn't rely on personnel-vehicle mismatch in their normal operations.
• If I read correctly, the simulation assumes stable resources (stations roughly 'fully staffed' all day), when in reality staffing will vary by time of day, and day of week (and this can have a significant impact on turnout time)
• “Response District Grid - Without explicit knowledge of CFD response districts, we have drawn response districts by overlaying the service area with a two-scale grid.”
  • We might have better details on this, or may be able to get them from Mark.

[kielejocain]

I have started a Wiki page to hold some thoughts on how we might begin to organize code to allow for flexibility and extensibility in dealing with various fidelities. It's under the page Product Design. I've only begun to try to organize some thoughts, and I would strongly encourage (if not beg) others to consider how we might be able to solve some of these problems.

I certainly don't intend anything I wrote to be the final answer; please edit anything I wrote there or comment/critique it here in this discussion.