Crowd simulation (indicative)

Crowd simulation plays how the crowd in one enclosure of your event site, or on the whole site, might leave through its exits, over time, on the layout you drew. It is an indicative model: it sits beside the static exit checks and never replaces them. Crowd simulation is in Beta, behind its own crowd beta flag.

What it is, and what it is not

The static check (capacity by density, exit width by the rate of passage, the escape time of the gov.uk guide's Table 4) stays the authority. The simulation adds time: where the crowd goes, which exits it uses, where it waits and when each part of the area empties, under assumptions you can see. Every figure it prints names its model and its basis. It never describes a layout as safe or compliant, never says a time meets or misses a limit, and never prints a simulated time against a limit.

The panel header always carries one line: "Indicative model of the layout and assumptions you entered. It does not replace the static capacity and exit checks, your Event Safety Management Plan or SAG review."

Opening it

On an event site, press 👥 Crowd simulation at the top of the sidebar's 11 · Analysis & Simulation — it is also on the ✅ Checks menu, after Vehicle sweep, and on the 🎪 Event menu, beside Attendance & demand. It opens a docked panel, not a dialog, so the plan stays in view while the timeline plays: on the right on a desktop, a side sheet on an iPad in landscape, and a bottom sheet you can pull up or down on an iPad in portrait. The panel has four tabs: Scenario · Results · Maps · Report.

The first time you open it on a design, a short explainer says what the maps mean, that a waiting crowd's density is a setting rather than a prediction, what the model leaves out, and why the flow time is usually longer than the static one. You can reopen it from the panel header.

The ready scenario

The panel opens on a scenario that is ready to run: Busiest zone · largest exit lost · Flow model. Press Run and you get a labelled result with no setup at all. Running it changes nothing in the design itself — its result is saved beside the design (see Saved results below) — and a scenario's settings are saved in the design only once you edit one. A scenario's name follows its settings — "Whole site · exits you blocked: 1 · Flow model" — until you type one of your own, which is kept; clear it to go back to the automatic name. Two scenarios with the same automatic name (a new scenario starts with the first one's settings) are numbered in list order, "… (1)" and "… (2)", in the picker, the copied summary, the CSV file names, the export dialog and the Event Safety Plan's headings alike.

Everything else sits in collapsed rows below it, defaults first:

• What — one enclosure: the busiest crowd zone, or any other. An enclosure is a crowd zone on site live, and its exits are the Gate objects the static check counts for it (within 2 m of its edge), so the simulation and the Exits from each enclosure check judge the same exits. Or the Whole site, to its perimeter gates: the site boundary is the edge, and the exits are the live gates within 2 m of it (our tolerance). The attendance from the demand dialog is shared among the crowd zones in proportion to their capacity, each zone at most full (our rule); people who are in no crowd zone are not modelled, and the result says how many. Each zone's own gates stay open as passages inside the site. With no gate on the boundary, Whole site is shown but cannot be picked, with the reason "This site has no gates on its boundary". With no attendance entered a whole-site run is not computed, because there is nothing to share: the site is never filled to every zone's capacity as a guess.
• Exits — Lose the largest exit (the default): the same discount the static check applies (the widest exit is taken out when there is more than one; a single exit stands alone), so both figures use the same exit set; on the whole site it is the widest perimeter gate. Or Choose the exits to block: a checklist of the exits, where you tick each one to block and every other exit stays in use. The scenario refers to each gate itself, so it follows a gate you move. A gate that is a copy in an array cannot be picked: "Pick a standalone gate: array copies are re-created when the array changes." A blocked gate that has since been deleted shows "Blocked gate not found: re-pick or remove", and two objects carrying the same reference show "Two objects share this reference: re-pick"; either way the scenario will not run until you resolve it, because a blocked gate is never quietly treated as open. Blocking every exit is refused. A gate you block that is not one of the area's exits is named under the list: inside the area ("Gate 2 of Arena (at 5.0 m, 20.0 m): a gate you blocked inside this area, not one of its exits; the run keeps it closed"), or not in it, where blocking it changes nothing in this run. Tick All exits to add a row with every exit open.
• Pre-movement — how long people take to start moving, from RiMEA's sensitivity set: rapid 0 s, speedy spread evenly over 0–60 s (the default), or slow spread over 1–5 minutes. One Run computes all three: the one you chose first, with the full timeline and maps, then the other two as figures only.
• Bases — the speed–density relation (Weidmann 1993); the gate passage rate (the Green Guide's 82 persons per metre per minute, gov.uk's 109, SFPE's 78 via the IMO guidelines, or the relation's own maximum), starting from the rate your design's exit check uses; the free walking speed inside the relation (Weidmann's own 1.34 m/s, or the DfT's 1.2 m/s, which the basis line names as a hybrid of the two sources); the queue density (below); and the route choice — congestion-aware (the routes recomputed every few seconds from a walking cost that rises with density and each exit's expected delay), or nearest exit, which says that it can leave an exit standing idle.
• Ground and audience reduction — "reduce flow rates by __ %", labelled as yours, for wet or uneven ground or an audience you expect to be slower. The tool never fills it in.
• Notes — your own commentary. It prints in the report under "Commentary (by the author)"; the tool writes no conclusions of its own.

Running

Run shows its progress ("Simulating 3:20 of about 6:00"), then the result, while the other two pre-movement cases fill in behind it ("computing…"); Stop the other cases keeps the result and marks the cases it stopped "cancelled". Cancel stops at once and keeps nothing: a cancelled run is never saved, and the scenario's earlier saved result stays as it was.

• Never automatic. Nothing runs when you edit, and no export ever starts a run.
• Out of date. Move a gate, a fence or the boundary, or change something the run reads, and the result says "Layout or inputs changed since this run. Run again." You can still play it back, striped "out of date". Renaming a scenario, editing its Notes or its Report settings, or switching to another scenario never makes a result out of date. A saved result follows the same rule (below).
• Warnings before it runs are notes, never silent fixes: an exit narrower than 1.05 m, more people than the zone's capacity, people who could not be placed, zone edges with no barrier drawn (with their length), gaps narrower than the 1 m grid (which are closed in the run), and on a whole-site run the people in no crowd zone and the length of site boundary with no barrier drawn. A zone with no exit is refused: "this zone has no exit, so there is nothing to simulate". So is an area too large to simulate at 1 m — about 1 million open cells on a desktop and 400,000 on an iPad.
• A long run asks first. The panel times a short stretch of the run on your device and shows how long the result will take. A whole site takes far longer than one enclosure — minutes rather than seconds on a large site, because it holds more people for longer — and when the result would take more than a minute (two on an iPad) the panel asks before it starts. The grid is never made coarser to save time.
• Check grid sensitivity in the Results tab re-runs the chosen case on a half-size grid (0.5 m cells, 0.25 s steps) when it fits, shows how long it will take first, and records the difference in the run log. It needs a run from this session: a saved result keeps no timeline to check against.

The results

The headline is named for exactly what the model shows: Time for the modelled population to leave through this enclosure's exits (downstream not modelled), or on a whole-site run Time for the modelled population to leave through the perimeter gates (beyond the site not modelled). It is never called an escape time or an evacuation time, because the model stops at the exits and does not show anyone reaching a place of reasonable safety.

• Comparison — beside it, in its own column, the Static check (derived): the people divided by the exit width in use times the passage rate, on the same exit set. Each row names the exits it closes — "Largest exit lost: Gate 2", or "Exits you blocked: Gate 2" when you chose them, and in words when it closes none ("Exits you blocked: none (every exit is in use)", or "Largest exit lost: none (a single exit stands alone)") — with the exits in use under it; the CSV's run-log lines and the Event Safety Plan name the same exits. A gate you blocked that is not one of the area's exits but lies inside it (an arena's own gate on a whole-site run, say) is closed by the run too, and every row names it after the exits — "Exits you blocked: none · gate you blocked inside the area, kept closed: Gate 2 of Arena (at 5.0 m, 20.0 m)" — the All exits row included, which opens every exit and keeps that gate shut; "every exit is in use" is never said while one is closed. With no exit closed, the All exits row is the same run as the row above and says so. Times against the expected order. Opening an exit does not always shorten the flow time, and a later start does not always finish later: the All exits row can be the slower, and a case whose people set off later (speedy, then slow) can finish before one that sets off sooner. Where a result has either, the panel says so once under the rows, in a box of its own, and the copied summary and the Event Safety Plan say the same: each reversal with its times and the gap ("With speedy pre-movement (starts spread over 0–60 s) it takes 15:31, 1 min 29 s less than the 17:00 with pre-movement 0 (everyone starts at once), although people set off later"), why, and by how much the order is reversed. The rows are runs of the same model on the same clock. With congestion-aware routing the note gives the likely cause, the model's route choice: the routes are recomputed as the crowd moves, from a walking cost that rises with density and each exit's expected delay (which counts everyone queuing on the way to the exit, including at a gate inside the area, such as an arena's own gate), so how the crowd divides between the gates inside the area and between the exits shifts with which exits are open and when people set off. It names each part only where it can act in the rows it compares: the exits' expected delay, and the crowd dividing between the exits, only for a row with two or more exits open (with one open, that exit's delay is the same from everywhere and changes no route); the crowd dividing between the gates inside the area only when two or more of them are open; otherwise the walking cost alone. It says "likely" because the mechanism has not been traced in full for any layout: the reversal can remain with the exit delays all but switched off. With nearest-exit routing every route is fixed before anyone moves, so there the note says the route choice is not the cause and that the cause in that layout has not been traced. It is an indicative model: differences the size of that gap do not rank the cases, and the static check is the comparison of the exits' capacity. Times are compared in whole seconds, and with no reversal nothing is said. The flow figure with no pre-movement is the comparable one, and the three pre-movement cases follow. A case that ends with people still inside has no time, and says how it ended: "not all out: 1,500 cannot reach an exit" when the gates you blocked leave people with no way out, or "not all out: 3,096 still inside when the run ended at 60:00" when the one-hour window runs out (or nothing has moved for ten minutes) — in the panel, the copied summary and the Event Safety Plan alike. The static check's escape time is not in this table: it prints only in the inputs table ("Escape time used in the static check"), so the two are never read against each other.
• Where the difference comes from — the flow time is longer than the static one by exactly the exit capacity that went unused, and the panel says which: the walk to the exits before they filled, an exit starved part-way through, or an exit standing idle after it cleared while another still had people, each as a duration in words, as the note above gives a gap: "Of the extra 5 min 29 s, 2 min 10 s is the walk to Gate 1 before people first reached it, …". It is worked out from the rapid case (no pre-movement) alone, so when that case was stopped, failed or never ran it says so instead; and it is not computed when people were still inside at the end.
• Per exit — people through it, first out (when the first person has left by it), clear (when fewer than 0.5 person is still to use it; "not reached" when the run ended with people still inside and the exit still in use, which then has no mean flow and no line on the chart), the mean flow, the peak one-minute flow and the time it ran at 95 % of its capacity or more — in two tables so they fit the panel: every exit's width, people through, first out and clear, then the flows of the exits in use (the CSV and the PDF keep one table). A flow model smears a moving front, so first-out times read early and clear times late; the grid sensitivity check shows both at half the cell size.
• Not out — people still inside at the end, always shown, even when it is 0.
• Not in a crowd zone — on a whole-site run, the people the crowd zones could not hold, who are not modelled.
• Undrawn edges — how much of the zone's edge, or on a whole-site run the site boundary, has no barrier drawn. The model treats it as closed except at gates, and says so.
• Bottlenecks — places where density stayed above the chosen line, with how long and how dense; click one to zoom to it.
• People remaining against time — a chart of the enclosure or the site and each exit.
• CSV and Copy — the remaining-people series, the per-exit table and the per-minute exit flows, each file headed with the limits text and the run log. The menu offers only what the result can produce; the day profile has its own Download button.

Saved results

Every completed run by the design's owner or an editor is saved with the design automatically; there is no Save button. Reopen the design and its result is there, labelled "Saved result, run <date> (build <stamp>)", and the Event Safety Plan prints it without a re-run. Saving never touches the design itself: it makes no autosave, takes no editing pen and adds no undo step, so an editor can run a scenario while a colleague holds the pen.

• What is saved — the result's figures and tables, the people-remaining series, the run log, and the Clearance map with the maps you placed in the General section. The timeline itself is not saved (a single run's frames can reach tens of megabytes), so after a reload playback, scrubbing, any other map or time and the grid sensitivity check show "needs a run".
• When a saved result reads out of date — it is current only while the design gives the run exactly what it read: the layout to the millimetre, the scenario's run settings and the demand inputs, the same figures (rule-pack values and bases) and the same engine version. Reloading, opening the design on another device or the library finishing loading changes none of these, and a newer build with the same engine and figures keeps it current; its run log names both builds. Otherwise the panel shows the newest saved result as "Saved result, out of date: layout, inputs, figures or engine changed since it was run", and every export treats it as out of date: a saved result is never shown or printed as current when it no longer matches. Renaming a scenario, editing its Notes or Report settings, or switching scenario never makes one out of date.
• Three kept for each scenario — one for each set of inputs it was run on. A run on inputs already saved replaces that result; a run on new inputs adds one, and past three the one written longest ago goes, with its maps. The panel shows the one that matches the design as it is now, so undoing back to an earlier layout finds that layout's result current again if it is among the three. A colleague's run on an older version of the design adds its own result rather than overwriting the current one; but past three the one written longest ago still goes, and after an undo that can be the current one.
• A run that differs — if a new run on the same inputs ends in a different state hash from the saved result (run on another device, say), the panel says "This run's hash differs from the saved result", the new run replaces it, and its run log keeps the old hash on a Replaced line, so the difference is never lost.
• Who saves — owners and editors. Nothing run in a team viewer's view, a review or share link or an admin (support) view is saved, and an admin view does not load saved results at all. Under each result the panel says what became of it: "Saved with the design.", "Result not saved yet" when you are offline (it is kept for the session and saved when the panel or the export dialog next opens online), or that it is kept for this session only where it cannot be saved. A design saved only on this device says "Saved on this device": its results stay on the device that ran them.
• A colleague's run — the panel reads the design's saved results when it opens, when the design changes while the panel or the export dialog is open, and when you press Refresh.
• Size — saved maps have an allowance for each scenario and for each design. A map over it is not saved and is named, as is a map placed in a section after the run; the export prints "map not saved with this result: run again to include it" in its place.
• Beside the design, not inside it — an .asd export, a copy to send, a design version and Save a copy carry no saved result, so a design opened from one needs a run. Deleting the design deletes its results; a deleted scenario's results are cleared later, never within a day, so an undo that brings the scenario back finds them.

The day profile

The Results tab also carries Crowd over the day (day profile): people on site, arrivals a minute and the entry queue, minute by minute over the gate window, with the busiest minute of arrivals, the peak entry queue and when it clears — at the end of its last queue, so a queue that empties between two arrival peaks, or a second wave after the peak, still counts, and a queue still there a day after the gates close "does not clear within a day of the gates closing", with how that was read, as a clear time is ("(minute by minute)", and on the piecewise-linear basis that basis too, since the static check beside it can still clear) — the holding area the peak needs, a chart and a CSV. Two clear times, each saying how it was read. The sidebar, the static check and the Event Safety Plan's movement section read the queue at the end of each hour, so they give the hour's end by which it is gone; the day profile gives the minute. For one design they can read "by the end of the first hour after the gates close (checked hour by hour)" and "57 min after the gates close (minute by minute)" — the same queue at two resolutions — and the panel, the day CSV and the day section of the report print both, the static check's beside the minute: "Static queue check: clears by the end of the first hour after the gates close (checked hour by hour)". The static check holds each hour's arrival rate constant, as the default arrival basis does, so on that basis the minute never falls after the hour's end it is checked by; on the piecewise-linear basis it can, and the minute figure then says so: "3 h 1 min after the gates close (minute by minute, with arrivals piecewise-linear within each hour; the static check holds each hour’s rate constant, so it can read earlier)". It is worked out from what the demand dialog already holds — the attendance, the gate window and the arrival curve — and the entry lanes you have drawn: the queue model's arithmetic at one-minute steps. So it needs no Run, is never saved and is never out of date.

• No locations. It says so: "Site-wide totals from your attendance and arrival curve; no locations are modelled."
• Illustrative. It carries the banner "Illustrative: driven by our assumptions" whenever one of its inputs is ours, which in this release is always: departures follow one shape of ours, with nobody leaving before the gates close. A custom arrival curve the demand dialog refused is named, with the default shape used in its place.
• Arrivals within each hour. The arrival curve gives one share an hour, so by default the rate is held constant within each hour, which claims no shape inside it; on that basis the minute-by-minute queue equals the hourly queue model at every hour boundary. The alternative, piecewise-linear, keeping each hour's total, is ours. It never reads below the hourly model, and reads more whenever the arrival rate crosses the lanes' capacity inside an hour, because the hourly figure lets lane capacity left unused early in an hour serve arrivals later in the same hour. A table sets both bases beside the hourly model at every hour boundary, whichever one you show, with that reason. Hours count from the gates opening: hour 1 is the first hour, and a figure taken at an hour boundary belongs to the hour it ends — the queue 6 hours after opening is "the end of hour 6", in the panel, its table, its CSV, the sidebar and the PDF alike; a moment inside an hour reads "hour 7, minute 25". After the gates close a time is how long since they closed, in words: "the entry queue clears 57 min after the gates close (minute by minute)", "1 h after the gates close", and the table's rows after the close read "+1 h", "+2 h" under the heading "After the gates close", as the Event Safety Plan's hour-by-hour queue table labels them. With no opening time set the panel says so once. Your choice is remembered for you on this device, not saved in the design.
• Not computed, with the reason, when no attendance is entered or no entry lanes are drawn — never a 0.

The maps

The Maps tab shows one map on the plan at a time; every legend names its model, basis, grid and time window.

• Clearance (the default) — when each cell last held 0.05 persons per m² or more (half a person on a 10 m² patch), the definition printed with it. It has no density colours, so a first look is not a wall of red.
• Density now — persons per m² at the time on the timeline.
• Peak density — the highest density each cell reached.
• Time above a line — how many seconds each cell spent above a density line you choose, on its own time scale.
• Congestion — how long each cell's speed in the model stayed below the congestion speed, which is derived from the speed–density relation (RiMEA's definition).

The density maps draw published reference lines at 2, 3, 4 and 5.4 persons per m². They are not limits, and the legend says so beside the capacity factor the capacity check uses (0.3 m² a person, 3.3 persons per m², standing).

A waiting crowd's density is your setting. In a model like this a queue packs to whatever limit the model has, so the queue density is an input: 3.3 persons per m² by default (the standing capacity factor's density), or 2, 4 or 5.4. Cells held at it are hatched "waiting crowd at the queue density you selected". Cells at 5.4 persons per m², the limit of the speed–density relation, get their own hatch: no result there is relied on.

The timeline

A playback bar at the bottom of the plan: restart, play and pause, a scrub slider, speeds of 1×, 2×, 5× and 10×, and a clock that reads T+mm:ss from the start. Marks on the track show each quarter of the people out and each enclosure's clearance. On the plan each exit is circled and labelled open, cleared, lost (the largest, taken out) or blocked (one you chose), and a gate you blocked inside the area is crossed out as "closed (yours)", in the Event Safety Plan's maps too. Only one player shows at a time: opening the crowd timeline pauses and hides the vehicle swept-path player. With reduce motion set on your device the bar opens paused; scrubbing always works. Playback is on the 2D plan in this release, and it needs a run from this session (a saved result keeps no timeline).

The crowd layer never appears in the project card thumbnail, in the planning PDF's plans, in DXF or in the sheet manager's outputs. Export PNG captures the canvas as you see it, so a PNG taken while the crowd layer is showing includes it.

In the Event Safety Plan

The Event Safety Plan export button opens a short options dialog first (it also holds the cover page's fields — see Schedules, reports & exports). With crowd simulation switched on it adds Include crowd simulation (remembered on this device) beside the security tick, which starts off every time the dialog opens. It lists what the PDF will contain and each scenario's state with its source — current from this session, current from a saved result (with its date), current with some maps not saved, out of date, or not run — and what the PDF will print for each. Nothing in the dialog runs a simulation unless you press its Run the N included scenarios button, which runs, one after another, each included scenario that is not current or lacks a placed map; the export button itself never runs one.

• With Include crowd simulation on, the PDF gains an Evacuation scenario (indicative) section after the movement section: the limits text, the inputs and basis table, the comparison, the per-exit table with its definitions, the pre-movement cases, not out, the maps you placed in the general section (Clearance by default; each map's Report setting is General section or Not in report), the people-remaining chart, the run log and your Notes.
• A saved result prints in full, with its source under the scenario's name and in the run log: "saved result, run <date> on <device>, build <stamp>; exported on build <stamp>". A placed map it does not hold prints "map not saved with this result: run again to include it".
• A result that is out of date prints "Crowd simulation: out of date, not included. Run it again from the Crowd panel." A scenario with no current result, from this session or saved, prints "not run". The export always completes.
• A Crowd over the day (indicative) section follows. It prints the day profile's figures only when every input behind them is yours or sourced, on the constant-within-each-hour basis whatever the panel shows; because the departure shape is ours in this release, it prints one line instead ("Crowd over the day: illustrative only…"), and the figures stay in the panel and its CSV. Without attendance or entry lanes it prints "not computed" with the reason.
• Every crowd section is followed by the verification appendix (below), with the build it came from.
• With the tick off, the Event Safety Plan is exactly the document it was before crowd simulation existed.

Verification

The Flow model is checked against analytic cases and against the published test cases a flow model can answer — from RiMEA 4.1.1, the IMO's evacuation-analysis guidelines (MSC.1/Circ.1533) and NIST Technical Note 1822 — at their full sizes. The tests written for models of individual people that a flow model cannot answer (stairs, demographics, assigned routes, counterflow) are listed as not applicable, with the reason, never left out. A test with a criterion only some passage rates can meet is run on those rates and listed as not applicable on the others. The whole site, blocked exits and the day profile have rows of their own: every perimeter gate opens the boundary, the whole-site population never exceeds the attendance, a blocked exit stays shut, and the day profile on the constant basis equals the hourly queue model at every hour boundary.

The results are reported in three groups, never as one count: implementation checks (the code does what the method says), behavioural verification (the model behaves as the tests expect) and validation against measured crowds, of which there is none yet. Headline counts use the behavioural group only. The summary prints as an appendix of every crowd section, with the engine version and build, and says in plain words that none of it is validation against measured crowds. Figures in its reasons are shown to at most 4 significant figures, as the crowd section's inputs are. It is not yet published as a page of its own.

What it leaves out

• No crowd pressure, crush, smoke or panic mechanics, and no forces between people.
• One crowd moving at one free speed: a deterministic flow model on a 1 m grid, not a model of individual people. It shows nothing finer than a 1 m cell.
• It stops at the enclosure's exits, or at the perimeter gates on a whole-site run, and shows nothing beyond them.
• A whole-site run places people in the crowd zones only, so nobody queuing at an entrance, in a car park or on an approach is counted.
• Zone edges, and the site boundary on a whole-site run, with no barrier drawn are treated as closed except at gates, and their length is printed.
• The density of a waiting crowd is the queue density you select, not a prediction; results at 5.4 persons per m² are at the limit of the speed–density relation.
• The day profile places nobody: it is site-wide totals of arrivals, the entry queue and people on site, with departures on a shape of ours.
• No fire or smoke is modelled, so no egress margin is computed or printed.

It supplements, and does not replace, the static capacity and exit-width calculations, a competent crowd-safety assessment, your Event Safety Management Plan or Safety Advisory Group review. Every figure names its basis; figures marked as our assumption have no published source.

What this release covers, and what comes later

This release covers one enclosure at a time or the whole site, emptying through its exits with the largest exit lost or the exits you block, on the Flow model, played on the 2D plan, with the maps, the results, the CSV, the day profile of arrivals and the entry queue, saved results and the Event Safety Plan section above. Planned next, in this order of work (no dates):

• population profiles by event type — children, older visitors, slower walkers, wheelchair users and groups;
• security scenarios — invacuation into safer areas, hold in place and moving away — printed only under the security key, as supporting evidence for Martyn's Law readiness and never a verdict;
• the crowd over the opening times, with heatmaps of the day and a ground drape in 3D;
• walking figures in 2D and 3D on a model of individual people, and comparing scenarios side by side.

Sources

The speed–density relation is Weidmann's (1993): a free speed of 1.34 m/s and a jam density of 5.4 persons per m², whose flow peaks at about 1.225 persons per metre per second (73.5 a minute) at 1.75 persons per m² — our computation, and every derived figure is recomputed from the free speed in use. The pre-movement cases and the congestion speed follow RiMEA 4.1.1; the SFPE passage rate is quoted from the IMO guidelines; the Green Guide and gov.uk rates are those the exit check already uses. The numerical choices — the 1 m grid, the time step, the queue density, the clearance threshold and the route-choice damping — are ours, and so are the whole site's share of the attendance by capacity, the day profile's piecewise-linear arrival basis and its departure shape; the panel and the report badge them so. Each source, the page it was read on and how it may be reused is listed with the others under Sources and what is ours.