diff --git a/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/00-document-info.mdx b/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/00-document-info.mdx new file mode 100644 index 000000000..9a81fa68b --- /dev/null +++ b/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/00-document-info.mdx @@ -0,0 +1,29 @@ +--- +title: Document Info +reportDate: July 2020 +reportType: Computer Program Document +reportTitle: LifeSim +reportSubTitle: Technical Reference Manual +reportAuthors: ["U.S. Army Corps of Engineers, Risk Management Center"] +reportAbstract: +reportAcknowledgments: xx +reportSubjectTerms: +responsiblePersonName: Woodrow Fields +responsiblePersonNumber: ###-###-#### +citationGuide: "Risk Management Center, LifeSim Technical Reference Manual, Davis, CA: U.S. Army Corps of Engineers, Institute for Water Resources, 2020. Accessed on {enter current date here}." +--- + +import Link from "@docusaurus/Link"; +import addBaseUrl from "@docusaurus/useBaseUrl"; +import DocumentMetadata from "@site/src/components/DocumentMetadata"; +import NavContainer from "@site/src/components/NavContainer"; + + + +# Document Information + + diff --git a/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/00-version-history.mdx b/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/00-version-history.mdx new file mode 100644 index 000000000..0fc4c3deb --- /dev/null +++ b/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/00-version-history.mdx @@ -0,0 +1,24 @@ +--- +title: Version History +--- + +import Link from "@docusaurus/Link"; +import NavContainer from "@site/src/components/NavContainer"; +import TableVersionHistory from "@site/src/components/TableVersionHistory"; + + + +# Version History + + diff --git a/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/01-preface.mdx b/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/01-preface.mdx new file mode 100644 index 000000000..c4b97226f --- /dev/null +++ b/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/01-preface.mdx @@ -0,0 +1,49 @@ +--- +title: "Preface" +--- + +import Link from "@docusaurus/Link"; +import addBaseUrl from "@docusaurus/useBaseUrl"; +import Button from '@site/src/components/Button'; +import Citation from "@site/src/components/Citation"; +import CitationFootnote from "@site/src/components/CitationFootnote"; +import Figure from "@site/src/components/Figure"; +import FigureInline from "@site/src/components/FigureInline"; +import FigReference from "@site/src/components/FigureReference"; +import NavContainer from "@site/src/components/NavContainer"; +import ProcessList from "@site/src/components/ProcessList"; +import TableReference from "@site/src/components/TableReference"; +import TableVertical from "@site/src/components/TableVertical"; +import VersionSelector from "@site/src/components/VersionSelector"; + + + +# Preface + +The U.S. Army Corps of Engineers (USACE) Life Loss Estimation (LifeSim) software allows you to evaluate the life loss and economic damages +resulting from a single flood scenario. + +The LifeSim software is developed at RMC, which is a division of the USACE Institute for Water Resources (IWR). The first version of LifeSim (Version 1.0) was +released in 2017. This Technical Reference Manual was tailored for Version 2.0 of the LifeSim software. + +Woodrow Fields leads the LifeSim development team. Stephanie Owen and Brennan Beam provided review and support throughout the development of this +manual in 2020. Jason Needham and William Lehman contributed significantly to all versions of LifeSim. Lea Adams was the Chief of the Water Resources Systems Division, +and Chris Dunn was the director during the development of Version 2.0 of the +software. + +This Technical Reference Manual was originally prepared for the USACE Hydrologic Engineering Center (HEC) by HDR Engineering, Inc. Additional +information can be found in the LifeSim User's Guide. LifeSim manuals +are available on this RMC Software Documentation website and +the RMC website. + +#### Software + + + +LifeSim Version 2.2 is available for download as a self-extracting setup package. + + \ No newline at end of file diff --git a/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/02-executive-summary.mdx b/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/02-executive-summary.mdx new file mode 100644 index 000000000..63d0332c1 --- /dev/null +++ b/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/02-executive-summary.mdx @@ -0,0 +1,48 @@ +--- +title: "Executive Summary" +--- + +import Link from "@docusaurus/Link"; +import addBaseUrl from "@docusaurus/useBaseUrl"; +import Citation from "@site/src/components/Citation"; +import CitationFootnote from "@site/src/components/CitationFootnote"; +import Figure from "@site/src/components/Figure"; +import FigureInline from "@site/src/components/FigureInline"; +import FigReference from "@site/src/components/FigureReference"; +import NavContainer from "@site/src/components/NavContainer"; +import ProcessList from "@site/src/components/ProcessList"; +import TableReference from "@site/src/components/TableReference"; +import TableVertical from "@site/src/components/TableVertical"; +import VersionSelector from "@site/src/components/VersionSelector"; + + + +# Executive Summary + +Welcome to the Risk Management Center's LifeSim Technical Reference Manual. The main purpose of the LifeSim software is to help study teams better +understand the consequences of a flood event. + +LifeSim is a spatially-distributed, dynamic simulation modeling system for estimating potential life loss and economic damages from flood hazards. A +hazard is a natural or man-made event that threatens to overwhelm and injure life and/or property, e.g., a flood, toxic plume, or wildfire. LifeSim +explicitly models the warning and mobilization of people potentially exposed to the hazard and predicts the spatial distribution of fatalities within +buildings and on road networks expected to be impacted by the hazard. Although LifeSim was developed for dam and levee safety analyses, the software +is not limited to breach flood hazards (RMC, 2021) . The key component of LifeSim's methodology is that +the magnitude of life loss depends on whether +people evacuate successfully and whether those who fail to evacuate can find adequate +shelter (Aboelata, Bowles, and McClelland, 2003) . + +LifeSim is built around a database. Each component exchanges data with other components throughout the database, which includes various GIS layers and +tables. Default relationships and values are provided for many inputs. LifeSim's methodology reflects its early authors' understanding of the factors +affecting life loss. Simply put, LifeSim determines people and assets that would be subject to a certain flood, how people evacuate or seek shelter, +and estimates damages and fatalities for those people and assets caught by the flood. + +This technical reference manual describes the methods, internal algorithms, and computations that LifeSim uses to calculate fatalities and damages +resulting from floods or other hazards, and to display the spatial distribution of those consequences. A strong understanding of these internal +processes will increase the user's ability to identify model limitations, provide suitable inputs, communicate the importance of results, and help +validate decisions that LifeSim supports. + + \ No newline at end of file diff --git a/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/03-introduction-and-overview-of-lifesim.mdx b/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/03-introduction-and-overview-of-lifesim.mdx new file mode 100644 index 000000000..990e54d5d --- /dev/null +++ b/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/03-introduction-and-overview-of-lifesim.mdx @@ -0,0 +1,358 @@ +--- +title: "Introduction and Overview of LifeSim" +--- + +import Link from "@docusaurus/Link"; +import addBaseUrl from "@docusaurus/useBaseUrl"; +import Citation from "@site/src/components/Citation"; +import CitationFootnote from "@site/src/components/CitationFootnote"; +import Equation from '@site/src/components/Equation'; +import EquationNoRef from '@site/src/components/EquationNoRef'; +import EquationReference from '@site/src/components/EquationReference'; +import Figure from "@site/src/components/Figure"; +import FigureInline from "@site/src/components/FigureInline"; +import FigReference from "@site/src/components/FigureReference"; +import NavContainer from "@site/src/components/NavContainer"; +import ProcessList from "@site/src/components/ProcessList"; +import TableReference from "@site/src/components/TableReference"; +import TableVertical from "@site/src/components/TableVertical"; +import VersionSelector from "@site/src/components/VersionSelector"; + + + +# Introduction and Overview of LifeSim + +## Introduction + +An evaluation of the risk associated with flood defense infrastructure may be undertaken for a variety of reasons, including periodic risk +assessments, regulatory compliance, emergency response planning, and assessment of risk reduction measures. Risk is a function of hazard, performance, +and consequence. Therefore, evaluation of life loss and economic damage is an important element of these risk assessments as well as future planning +and design efforts. + +LifeSim was developed to: + +- Effectively support reduction of life-safety risks associated with flooding; +- Evaluate existing and residual risks against tolerable risk guidelines; +- Calculate economic consequences (e.g., direct structural, indirect, and agricultural); +- Understand life-loss dynamics associated with floods; and +- Create or improve existing emergency action plans. + +LifeSim is a spatially-distributed, dynamic simulation modeling system for estimating potential life loss and direct economic damages from flood +hazards. It explicitly models the warning and mobilization of people potentially exposed to the hazard and predicts the spatial distribution of +fatalities within buildings and on road networks expected to be impacted by the hazard. Although LifeSim was developed for dam and levee safety +analyses, the software is not limited to failure flood hazards (RMC, 2021) . + +LifeSim is founded on the LIFESim method developed by Utah State University's Institute for Dam Safety Risk Management (see, e.g., Aboelata and Bowles, +2005) . The USACE Hydrologic Engineering Center (HEC) released the first version of HEC-LifeSim in July 2017. This +technical reference manual reflects the initial release of LifeSim Version 2.0 and subsequent releases. + +## Purpose of this Technical Reference Manual + +This technical reference manual describes the methods, procedural steps and computations that LifeSim uses to calculate fatalities and damages +resulting from floods or other hazards. A strong understanding of these internal processes will increase the user's ability to identify model +limitations, provide suitable inputs, communicate the importance of results, and help validate decisions that LifeSim supports. + +The format of this manual was designed to answer the following questions about LifeSim: + +For each parameter: + +- What is it, and what are its fundamental properties? +- How is it used by the application? +- How does it influence the simulation results? +- Why was the default chosen? Where did it come from? Why is it the best option, if it is? +- Where can you find more information? +- What should you consider if you want to change the value from the default? + +## LifeSim Overview + +LifeSim simulates the outcomes of event-exposure (Aboelata, Bowles, and McClelland, 2003) . Examples +of events are dam failure, levee failure, or any +flood of given severity. Exposure refers to the people and resources that are exposed to the event. Exposure cases can include different seasons, +day/night, weekend/weekday conditions affecting the size and distribution of the PAR. Various aspects of a warning and evacuation system can be +described and tested. + +The key component of LifeSim's methodology is that the magnitude of life loss depends on whether people evacuate successfully and whether those who +fail to evacuate can find adequate shelter (Aboelata, Bowles, and McClelland, 2003) . + +Research by the original developers of LIFESim showed that warning time is a relatively poor predictor of whether people will evacuate successfully. +The time that is required to evacuate may vary dramatically from one location to another based on how quickly emergency management officials can +deliver individual warnings; how urgent, credible, and frequent the warnings are; the nature of sights, sounds, and vibrations that provide natural +warnings; selected modes of evacuation; the mobility of the population in question; the size of family groups; the distance to safety; barriers, such +as fences and bridges; and many other factors. For those who do not evacuate, survival depends on the ability to reach adequate shelter from the +flood. + +Factors affecting life loss include (Aboelata and Bowles, 2006) : + +- Flood severity +- Population at risk (PAR) location + - Downstream distance + - Elevation +- Structural resilience +- Warning system + - Coverage + - Effectiveness throughout the day +- Mobilization + - Believability of messaging + - Knowledge +- Roads + - Capacity + - Destinations +- Vehicle and human resilience +- Human mobility +- Willingness to evacuate + +The progression of the hazard and people's responses to the hazard are dynamic processes, i.e., they are characterized by constant change over time. +LifeSim simulates the interaction of these processes. For example: + +- The hydraulic inputs are a spatially-distributed time series of depth and velocity of flooding. +- Evacuation modeling shows the spatial redistribution of population using dynamic simulation of vehicle traffic and pedestrian movement over time. +- During evacuation, interaction of people with the hazard is governed by time series of depth at structures and along roads. +- The loss of shelter study component provides progressive damage assessment throughout the flood event. + +LifeSim uses agent-based modeling. An “agent” is an evacuating vehicle or a pedestrian group. Group size is a parameter defined at the occupancy type +level (e.g., a school might be a group size of 30 to simulate school buses). During an evacuation, agents are interacting with the roads, other +vehicles, and the incoming hazard. After the warning and evacuation process has been simulated, LifeSim calculates lethality for those people that are + exposed and direct damages due to the hazard. Agent-based modeling allows LifeSim to: + +- Track individuals throughout the warning and evacuation process. +- Identify where people are most at risk of losing their lives, whether it is on roads or in structures. +- Support a detailed analysis of a range of alternatives based on both structural and nonstructural measures for reducing potential life loss. +- Allow individual agent decision making through uncertainty sampling using Monte Carlo techniques. + +LifeSim helps study teams better understand the consequences of a flood event by showing how loss of life varies as a function of time and space in +addition to the following variables: + +- Warning issuance time +- First alert diffusion +- The PAR's protective action initiation +- The PAR's evacuation potential +- Flood dynamics +- Loss of shelter + +This information can be used to: + +- Assess life safety risk reduction for planning purposes. +- Evaluate existing and residual risks against tolerable risk guidelines (see ER 1110-2-1156 for additional information). +- Understand life-loss dynamics associated with floods (or other hazards). +- Create or improve emergency action plans. +- Assess cost effectiveness or other justification of risk reduction measures (see EM 1110-2-1619 and ER 1105-2-101 for additional information). + + describes the general inputs needed to set up a LifeSim model and perform specified operations. + +
+ +The following list includes general information required for any given scenario to construct a representative model in LifeSim. + +- Hydrologic inputs, hydraulic inputs and system performance are needed to define the flooding scenario to be evaluated. These will include +information about flood magnitude and timing, levee or dam performance functions, and floodplain inundation information. These variables are combined +in a hydraulic model and imported into LifeSim as hydraulic events. +- Time for when consequences will be estimated, such as day or night, workday or weekend, and off-season or peak season for visitors. +- Information about the flood warning system for each study area or sub-area, and the probable response of the public to the warnings. +- Information about fatality rates as a function of flood water depth and velocity. +- Rural or urban nature of the study area. +- Critical infrastructure at risk. +- Sources and magnitudes of uncertainty. + +For analyses that include life loss, LifeSim is organized to follow a warning-evacuation +(Chapter Warning and Protective Action Parameters) timeline +that is enacted by dam or levee owners, +emergency managers, and citizens, as shown in . Each component of the warning-evacuation timeline +is discussed in other parts of this +manual (Chapters Warning and Protective Action Parameters and Road Networks, Destinations, and Evacuation Parameters). + +
+ +## LifeSim's Procedural Steps + +LifeSim runs multiple iterations, or potential outcomes, through a Monte Carlo engine. The simulation period for each LifeSim iteration run commences +with the earlier of the first evacuation warning or first hydraulic timestep and continues until either the hydraulic time-series data has stopped or +each evacuating group has finished their actions. + +Given information about the hazard, PAR, structures, and road network, LifeSim does the following: + + + Estimates the hydraulic characteristics (depth, velocity, and depth x velocity) at each structure and each + road segment over time for a given flood event. + + ), + }, + { // STEP 2 + title: ( + <> + Samples the time that a warning is issued to the population in each Emergency Planning Zone (EPZ) relative + to the hazard occurrence (e.g., dam or levee failure). + + ), + }, + { // STEP 3 + title: ( + <> + Separates the population into evacuating groups where the group size is determined by the occupancy type. + + ), + }, + { // STEP 4 + title: ( + <> + Propagates the first alert throughout the population, and estimates the time that the population in + each structure receives the first alert. + + ), + }, + { // STEP 5 + title: ( + <> + Determines when each group will take protective action (if at all) once they receive the first alert. + + ), + }, + { // STEP 6 + title: ( + <> + Determines if the group will attempt to evacuate to a destination or remain in their structure and evacuate + vertically. Each group will attempt vertical evacuation if they do not leave the structure. If a group + attempts protective action but water has already reached them, they will evaluate the non-evacuation depth + at their structure or initial road. The non-evacuation depth for the initial road is determined by the group's + threshold for willingness to enter a flooded road. + + ), + }, + { // STEP 7 + title: ( + <> + Tracks evacuating groups on the road network as they evacuate. Evacuating groups become immobilized when: + + ), + child: [ + { + title: ( + <> + Their fording depth is exceeded, or + + ), + }, + { + title: ( + <> + A safe destination cannot be found when attempting to re-route. + + ), + } + ], + }, + { // STEP 8 + title: ( + <> + Assigns groups to a hazard zone (none, low hazard, high hazard). + + ), + child: [ + { + title: ( + <> + People who evacuated and reached their destination safely are assigned to “none.” + + ), + }, + { + title: ( + <> + People that mobilized but were caught are assigned to a hazard zone (low or high) based + on the maximum hydraulic conditions of the road segment they are on and their vehicle/human stability. + + ), + }, + { + title: ( + <> + People who did not mobilize are assigned to a hazard zone (low or high) based on structural stability of available shelter + and human submergence at maximum flood depths. + + ), + } + ], + }, + { // STEP 9 + title: ( + <> + Calculates life loss in each group by applying a fatality rate sampled from the assigned hazard zone to each person + in the group exposed to the flood hazard. + + ), + }, + { // STEP 10 + title: ( + <> + Estimates the total life loss as the sum of the life loss for all structures and vehicles caught while evacuating. + + ), + }, + { // STEP 11 + title: ( + <> + Calculates direct property damages at each structure from the maximum hydraulic conditions at the structure using + the structure's stability criteria and depth-damage functions sampled from the structure's occupancy type. + + ), + } + ]} +/> + +The flow logic for determining hazard zone for people exposed to the hazard (Steps 6-10) is shown in . + +For Steps 1-10, see Chapters Computational Procedure, +Consequences, and +Uncertainty and Sampling Methods for additional information. + +
+ +## LifeSim Validation Efforts + +Calibration and validation of simulation-based life loss models such as LifeSim are challenging. Calibration of a specific model, which is the process +of verifying that results match well with field measurements for a range of magnitudes of events, is obviously not possible. Validation of the +methods in LifeSim to provide reasonable forecasts of potential life loss can be achieved by applying the model to historic events. However, the data +required to properly validate the methods using a historic event are rarely available. Understanding where people were located at the time of the +event, when they were warned, how they were warned, and the decisions they made related to if and how they evacuated is practically impossible to +obtain (Needham, Fields, and Lehman, 2016) . + +Nevertheless, USACE has successfully validated the methods in LifeSim with specific events. Each event's LifeSim model and description of its data inputs and lessons learned +are available on this RMC Software Documentation website at LifeSim Validation Studies. + +The validation efforts include the following events: +- Feijão Dam failure in Brumadinho, Minas Gerais, Brazil (2019), +- South Fork Dam failure in Johnstown, Pennsylvania, United States (1889), +- Kinugawa Levee failure in Jōsō (常総市), Ibaraki Prefecture, Japan (2015), +- New Orleans Levee System (validation effort available on East Bowl only) failure during Hurricane Katrina landfall in Louisiana, United States (2005), +- Kelly Barnes Dam failure in Toccoa Falls, Georgia, United States (1977), +- Malpasset Dam failure in Fréjus, Côte d'Azur, France (1959), +- Edenville Dam and Sanford Dam failures in Midland County, Michigan, United States (2020), +- Oroville Dam flood control outlet spillway emergency in California, United States (2017), and +- Teton Dam failure in Madison County, Idaho, United States (1976). + +The validation efforts show that the LifeSim methodology, including its assumptions on various inputs, provides results +reasonably close to what happened (Needham et al., 2020 and Risher et al., 2017) . + + \ No newline at end of file diff --git a/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/04-hydraulic-data.mdx b/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/04-hydraulic-data.mdx new file mode 100644 index 000000000..f53fc21fd --- /dev/null +++ b/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/04-hydraulic-data.mdx @@ -0,0 +1,296 @@ +--- +title: "Hydraulic Data" +--- + +import Link from "@docusaurus/Link"; +import addBaseUrl from "@docusaurus/useBaseUrl"; +import Citation from "@site/src/components/Citation"; +import CitationFootnote from "@site/src/components/CitationFootnote"; +import Equation from '@site/src/components/Equation'; +import EquationNoRef from '@site/src/components/EquationNoRef'; +import EquationReference from '@site/src/components/EquationReference'; +import Figure from "@site/src/components/Figure"; +import FigureInline from "@site/src/components/FigureInline"; +import FigReference from "@site/src/components/FigureReference"; +import NavContainer from "@site/src/components/NavContainer"; +import ProcessList from "@site/src/components/ProcessList"; +import TableReference from "@site/src/components/TableReference"; +import TableVertical from "@site/src/components/TableVertical"; +import VersionSelector from "@site/src/components/VersionSelector"; + + + +# Hydraulic Data + +## Chapter Overview + +Hydraulic data are critical components to computing damages and life loss in LifeSim. Hydraulic data sources in LifeSim are generally model output from +hydraulic modeling systems, such as HEC-RAS (Hydrologic Engineering Center’s River +Analysis System software v.5.0 or later) or FLO-2D (FLO-2D +Software, Inc., 2022) . For detailed life loss assessments, an unsteady hydraulic modeling approach (one-dimensional or two-dimensional, as appropriate) +is used to develop the inundation boundaries, arrival times, depths, and velocities necessary to estimate potential loss of life. LifeSim +interpolates the depths and velocities at roads and structures between hydraulic time steps. A shorter hydraulic time step will generally provide more +hydraulically accurate computations, but also require more memory and take longer to simulate. If direct economic damage estimates are the only +required output, a single maximum depth grid is the only hydraulic input requirement. + +In addition to providing the spatially distributed (gridded) time series of depth and velocity, a hydrograph representing the hydraulic event must be +provided. The hydrograph is a visual aid used to help develop the warning and protective action timeline. It is not used in the computations. + +To support a detailed risk assessment, several flood scenarios are typically modeled and simulated. This range of scenarios could include breaches at +different reservoir pool elevations or river levees as well as non-failure scenarios where flooding could lead to potential life loss. Other important +considerations in hydraulic modeling include breach parameters and coincident hydrologic conditions (e.g., reservoir inflow, tributary flows and +stages, status of interior drainage system). Often these additional considerations are handled through sensitivity and uncertainty analyses, and a +range of potential life loss results are provided for each scenario rather than a single value (Needham, Fields, and Lehman, 2016) . + +This chapter covers the various hydraulic input options LifeSim can use for simulations. LifeSim will use the combination of floodplain depths and +velocities to calculate damages to structures, damages to agricultural assets, indirect economic impacts, and life loss consequences. + +## Import from HEC-RAS + +LifeSim can read hydraulic data directly from HEC-RAS output produced with HEC-RAS Version 5.0 or later. To directly read the HEC-RAS output, LifeSim +implements the .NET library RASMapper, developed by HEC to sample hydraulic information. RASMapper has robust sampling methods (e.g., sloping water +surfaces for 2D hydraulics) to estimate depth and velocity at any location for any time step. The hydraulic time step in HEC-RAS is defined by the +Mapping Output Interval. + +LifeSim will automatically name the hydraulic file based on the plan name from the HEC-RAS output file. Once the data is imported into LifeSim, the +file name can be edited if desired. + +## Import from FLO-2D + +LifeSim can import hydraulic results directly from FLO-2D result files and convert them into a time series of depth and velocity compressed GeoTiff +files. During the conversion process, LifeSim also creates summary grids of maximum depth, velocity, depth times velocity, and depth times velocity +squared for each grid cell. The GeoTiff files are stored in the hydraulics directory of the LifeSim study. The ability to link directly with the +hydraulic results reduces data processing time as converting hydraulic information to a software specific format is not needed. + +## Import from Grids + +When hydraulic model results cannot be directly imported, model results must be converted into a time series of depth and velocity grids for use in +LifeSim. If the grids are spaced at regular time intervals, the import process is greatly simplified. Otherwise, for irregular time intervals the user + must input each time step and associate it to an individual depth and velocity grid cell. Other hydraulic characteristics are calculated from the +depth and velocity grids as needed. + +Hydraulic grid datasets can be imported into LifeSim in many gridded formats including tagged image file (*.tif), ArcInfo GRID (*.asc), and ArcGrid +(*.flt). + +## Import from Summary Grids + +The summary grids import method bypasses the need for LifeSim to calculate (pre-process) hydraulic characteristics. Instead, the necessary raster +files are imported directly. Post-processing tools for several different hydraulic modeling programs, such +as TUFLOW and MIKE-21, can be used to +generate summary grids. Allowable file types include *.tif, *.flt, ESRI Grid, and *.vrt. The six hydraulic characteristics that can be represented by +summary grids are maximum depth, maximum velocity, maximum instantaneous depth-times-velocity, arrival time for life loss calculations, arrival time +for agriculture calculations, and flood duration for agriculture calculations (see ). + + + +A maximum depth grid represents the maximum depth that occurs in each grid cell over the course of a hydraulic simulation. Like maximum depth, maximum +velocity and D*V (DV) represent the greatest velocity and instantaneous DV that occurred in each grid cell. DV is an important variable for +stability criteria. More detailed discussion can be found in +Section Building Stability Criteria. Because +the maximum depth, maximum velocity, and maximum DV grids are not +time dependent, LifeSim cannot simulate evacuation on roads when utilizing this style of hydraulic data. + +An arrival time grid represents the point in time that flood water of a given depth reaches each cell. When modeling the evacuation process for life +loss, LifeSim assumes that after a given flood depth is reached, individuals remaining in a structure will no longer be able to evacuate on roads, +thus they will remain in the structure and vertically evacuate. For agricultural damage calculations, the arrival time grid is used to determine when +water arrives at crop locations. + +Duration grids contain information about the duration of time that a cell is inundated. Duration grids are used only for agricultural computations to +determine damage to crops and replanting potential. + +## Defining Hazard Occurrence and First Timestep + +For analysis scenarios where a hydraulic time series is used, the first hydraulic timestep marks the beginning of the hydraulic input. It has no +bearing on other simulations within LifeSim. For example, warnings and evacuations could begin prior to the first hydraulic timestep, or well after. +The first hydraulic timestep marks the first instance in which the hydraulic input interacts with the other model inputs (and subsequently leads to +consequences). Users must define the first hydraulic time step when using the **Import from FLO-2D**, **Import from Grids**, or **Import from Summary Grids** +options (see ). If using the **Import from HEC-RAS** option, the first hydraulic time step will automatically populate. + +
+ +The hazard occurrence time must be set by the user and is defined as the instance when the hazard occurs (i.e., dam failure). In the case of a +structural breach or failure scenario, the hazard occurrence should be defined as the moment of failure (see ). +In some cases, such as internal erosion failure, there is no instantaneous moment of failure. The user must exercise discretion when assigning hazard +occurrence times to such scenarios. Typically, no matter how gradual the failure, there is a point in time where the discharge increases dramatically +at the point of failure, or at least more than any other timestep. With internal erosion, that point is usually when the roof of the pipe collapses +into a full breach. + +
+ +Hydrographs downstream of the failure location can be helpful to determine the hazard occurrence time in cases of instantaneous failure, such as a +gate failure or total embankment collapse where a sharp increase in flow is observed. More information on the hazard occurrence time and its role in +the warning and evacuation timeline is discussed in +Section Hazard Occurrence Time. + +In the hydraulic data import study component, once the hydrograph data are imported the user defines the hazard occurrence +time (). + +
+ +## Generating Hydraulic Summary Information + +Once hydraulic information is imported into LifeSim, the user can generate a hydraulic summary for any point or line GIS shape feature. This creates +an output shapefile that contains the defined summary hydraulic data at each feature in the input shape data. The user can specify which hydraulic +outputs to include in the output summary, such as maximum depth, maximum velocity, maximum depth times velocity, maximum depth times velocity squared, + and arrival time of depth and velocity at user specified intervals as shown in . + +The hydraulic summary data can be useful in identifying potential issues in the structure inventory or road network, such as structures that are +inundated too quickly due to bad placement or bridges that have water under them prior to the flood event. + +
+ +## General Modeling Guidelines + +### Considerations for Hydraulic Modeling for Consequence Assessment + +The user should consider the following when populating the LifeSim model with hydraulic data: + +- LifeSim interpolates depth and velocity between hydraulic time steps; shorter hydraulic time steps will provide more accurate results. Generally, +hydraulic model output should be no greater than a 15-minute time interval. +- Anything in the hydraulic model that impacts flood depth, velocity, or arrival time can impact LifeSim results. +- 1-Dimensional (1D) storage areas do not capture velocities of water or flow paths for accurate arrival time information. Instead, they assume a level pool +condition filling from the lowest point in the storage area. If a 1D storage area does not capture the nature of flooding for the study area, consider +a 2D representation to better reflect flooding of roads and structures. +- The hydraulic modeling hydrograph output interval and mapping output interval should be sufficient to capture steep hydraulic grade lines (and the +peak) without compromising quality. +- Grid size and location should be compatible with the placement of roads, structures, and agricultural land. If grid cells are too large, they could +extend beyond channel limits and damage items they should not. + +### Considerations for Multiple Hazard Events + +When assigning the hazard occurrence time during a failure in normal weather conditions, the point is straightforward. However, if a flood is occurring – +leading to failure – there may be confusion of when the “hazard” occurs. Discretion and flexibility are given to the user. However, the main +consideration is that the time selected and warning times should be internally consistent. Often with large flood events, an evacuation is called based +on expected flows out of channel or overtopping downstream levees. A failure of the facility under study adds a larger flood wave on top of the +expected one. Historically, this second failure flood wave triggers a second round of evacuation notices to a larger area (a.k.a double warning). Users +may set the hazard occurrence at the first sign of flooding and manipulate warning and evacuation curves to represent the two warnings, or more +commonly, use the failure time as the hazard occurrence and create EPZs that separate the first high-flow warning zone from the second failure warning +zone with different warning times for each. + +### Discussion of Sensitivity to Depth, Velocity, and Arrival Time (Breach Parameters) + +LifeSim samples the uncertainty of many parameters but does not currently include uncertainty in the hydraulic input. Hydraulic input data are +assumed to be known with certainty. However, with all hydraulic modeling, uncertainties exist and should be considered. Often, the factors that affect +model results most significantly are the failure scenario and breach parameters when simulating dam and levee failures. These parameters are highly +uncertain and can affect model results miles downstream (although typically lessening with distance from the hazard source). If breach parameters +impact flood depth, velocity, arrival time, or warning time, they will likely impact LifeSim results significantly. Breach parameter sensitivity +testing is recommended to understand these impacts. + +To test the sensitivity of breach parameters on LifeSim results, the user would: + + + Run HEC-RAS using a set of breach parameters. + + ), + }, + { // STEP 2 + title: ( + <> + Use HEC-RAS results as input to LifeSim. Run LifeSim. + + ), + }, + { // STEP 3 + title: ( + <> + Re-run HEC-RAS using a different set of breach parameters. + + ), + }, + { // STEP 4 + title: ( + <> + Re-run LifeSim using HEC-RAS results from Step 3. + + ), + }, + { // STEP 5 + title: ( + <> + Compare LifeSim results from Steps 2 and 4. + + ), + } + ]} +/> + + \ No newline at end of file diff --git a/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/05-structure-inventory-and-associated-properties.mdx b/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/05-structure-inventory-and-associated-properties.mdx new file mode 100644 index 000000000..1ec8f1b20 --- /dev/null +++ b/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/05-structure-inventory-and-associated-properties.mdx @@ -0,0 +1,1452 @@ +--- +title: "Structure Inventory and Associated Properties" +--- + +import Link from "@docusaurus/Link"; +import addBaseUrl from "@docusaurus/useBaseUrl"; +import Citation from "@site/src/components/Citation"; +import CitationFootnote from "@site/src/components/CitationFootnote"; +import DocTabs from "@site/src/components/DocTabs"; +import Equation from '@site/src/components/Equation'; +import EquationNoRef from '@site/src/components/EquationNoRef'; +import EquationReference from '@site/src/components/EquationReference'; +import Figure from "@site/src/components/Figure"; +import FigureInline from "@site/src/components/FigureInline"; +import FigReference from "@site/src/components/FigureReference"; +import NavContainer from "@site/src/components/NavContainer"; +import ProcessList from "@site/src/components/ProcessList"; +import TableReference from "@site/src/components/TableReference"; +import TableVertical from "@site/src/components/TableVertical"; +import VersionSelector from "@site/src/components/VersionSelector"; + + + +# Structure Inventory and Associated Properties + +## Chapter Overview + +A structure inventory represents geospatial locations that contain damageable elements, typically a structure such as a home. Structure inventories +are required by LifeSim to estimate direct economic damage for a flood event and initial population distribution. LifeSim can accept structure +inventories in the form of point shapefiles generated outside LifeSim or downloaded from a National Structure Inventory +(NSI) database . See Appendix E for a +discussion of NSI 2026. This chapter describes how structure inventories and their attributes are used in LifeSim. + +The structure inventory must have the attributes defined in regardless of source. When importing from a +shapefile, the user can specify required attributes () by associating them with the shapefile attributes. If a + required attribute is missing from the source shapefile, a user-defined default value can be globally assigned to all structures. The NSI has all of +the required attributes which are included during import. + + + +## Occupancy Type + +Structure occupancy types define common information for similar structures. Data used by the occupancy type include: + +- Depth-percent damage functions (structure, content, and other) +- Structure value uncertainties +- Foundation height uncertainties +- Evacuation parameters +- Structural submergence criteria + +The location of these parameters is in the LifeSim *Occupancy Type* window, shown in . + +Each structure is required to have an occupancy type. Default occupancy types used in LifeSim follow the naming convention developed for HAZUS +(FEMA, 2019) and are listed in Appendix E. + +Damage categories represent a grouping of occupancy types. LifeSim default damage categories are residential, commercial, industrial, and public. The +user may specify their own occupancy types with unique depth-damage functions and uncertainty parameters. Structure inventories imported from the NSI +will automatically have the LifeSim default occupancy types defined as attributes. + +
+ +### Depth-Damage Functions + +For each occupancy type in the structure inventory, depth-damage functions are specified as shown in . A +depth-damage function is included for each default occupancy type for structure, content, and vehicle damage +(USACE, 2003 and FEMA, 2019) . All curves can be edited by the user, and user-defined curves can be added. +Structure damage is also computed using structure stability criteria. Refer to Section Structure, Content, Vehicle, and Other Damage for +additional information on structure damage computations. + +
+ +### Evacuation Parameters Defined by Structure Occupancy Type + +In LifeSim, some evacuation parameters are specified by occupancy type. summarizes the various evacuation +parameters, potential ranges for each, and the impact they have on the model outcome. + + + +#### Population in Structure Warned at the Same Time + +By default in LifeSim, all occupants within a single structure of any occupancy type (except multi-family residential [RES3]) receives a warning at the same +time. This assumes that for all structures sharing the occupancy type, no matter how large or disconnected the structure, a system can warn the entire + building at once. In a large department store or warehouse, this would take the form of an intercom as most large office buildings have emergency +warning systems. Apartment buildings do not have such systems, therefore the default assumes each apartment acts as an independent residence. This +does not account for apartments having close proximity to each other where residents are more likely to receive a first alert from their neighbor +either as a verbal tip or visual cue. + + + All occupancy types except multi-family residential (RES3) + + ) + }, + { + title:"Range (Best Practice)", + child:( + <> + On or off + + ) + }, + { + title:"Source Data / Considerations", + child:( + <> + Determines if population within a structure is warned independently or together. + + ) + }, + { + title: "Sensitivity to Results", + child:( + <> + Low-High + + ) + } +]} +/> + +#### Population in Structure Takes Protective Action at the Same Time + +By default, only four occupancy types (agricultural, single-family residential, institutional dormitories, and nursing homes) take protective action at +the same time. This parameter is only available when the occupants in the structure are warned at the same time, therefore the first alert and +protective action timeline should be the same for all evacuation groups within the structure. With the population in a structure taking protective +action at the same time, all groups within a structure will evacuate nearly simultaneously. This assumes that single-family residences will choose to +evacuate using a single or multiple vehicles at the same time. Institutional dormitories such as prisons and school housing, as well as nursing homes, +contain residents that often lack the means to mobilize independently, and whose safety is a liability to the party operating the residence. The +default for these occupancy types are set to evacuate at the same time using busses or a similar system of mass transit. + + + Only on for AGR1, RES1, RES5, and RES6 + + ) + }, + { + title:"Range (Best Practice)", + child:( + <> + On or off, only available to population warned at the same time. + + ) + }, + { + title:"Source Data / Considerations", + child:( + <> + Determine if population within a structure can mobilize independently. + + ) + }, + { + title: "Sensitivity to Results", + child:( + <> + Low-High + + ) + } +]} +/> + +#### Probability of Access to Roof or Attic + +This parameter refers to an occupant's chances of reaching either the roof or attic when evacuating vertically, providing them with increased +above-ground height that increases their chances of survival depending on the hydraulics present at their structure. The current default for all +occupancy types for probability of access to the roof or attic is 0.95, meaning that 95% of occupants will reach the roof or attic when evacuating +vertically. A minority of occupants (5%) with full mobility will either lack the knowledge to access the roof or attic, be in a building that does not + have access, or choose not to try. Those occupants with limited mobility are excluded from accessing the roof or attic. + + + 0.95 + + ) + }, + { + title:"Range (Best Practice)", + child:( + <> + 0-1.0 + + ) + }, + { + title:"Source Data / Considerations", + child:( + <> + Parameter set based on structure access, not population mobility. + + ) + }, + { + title: "Sensitivity to Results", + child:( + <> + Sensitive to depth of flooding and arrival time. + + ) + } +]} +/> + +#### Fraction to Roof vs Attic + +This parameter defines subsets of those with access to the roof or attic, and refers to the highest level attained by an occupant who is able to +access the roof or attic. A percentage will be able to access the roof while others will be stuck in the attic. Users should consider many structure +types do not have an attic, so the fraction for that occupancy type should highly favor going to the roof. Also, LifeSim does not explicitly track +people who go to the attic first and then end up on the roof. The default for all occupancy types for fraction to roof vs. attic is 0.9, meaning that +90% of occupants who are able and have access will go to the roof. The default assumes that most people would ultimately continue to the roof if +confronted with water in the attic, although some may be trapped. The default fraction assumes that a minority of occupants (10%) who have evacuated +to the attic will lack the knowledge, will, or ability to reach the roof, if needed. + + + 0.9 + + ) + }, + { + title:"Range (Best Practice)", + child:( + <> + 0-1.0 + + ) + }, + { + title:"Source Data / Considerations", + child:( + <> + Parameter set based on structure access, not population mobility. Variable with percentage of structures with attics. + + ) + }, + { + title: "Sensitivity to Results", + child:( + <> + Low + + ) + } +]} +/> + +#### Fraction of Population that Evacuate in Vehicles vs on Foot + +The default for the fraction of people evacuating on foot or by vehicle is set to begin the evacuation model using 100% vehicle evacuation. Roadway +data are relatively readily available, but data on sidewalks, paths, and other infrastructure is minimal. Therefore, those evacuating on foot do so +along the same roadway segments utilized by vehicular traffic. This may not accurately capture the population evacuating on foot as they are forced to + use roadway networks and would otherwise likely cut through areas like parks and other surfaces not accessible to vehicles. Currently LifeSim does +not have the capability to add a pedestrian network for people evacuating on foot. + + + 100% + + ) + }, + { + title:"Range (Best Practice)", + child:( + <> + 0-100 + + ) + }, + { + title:"Source Data / Considerations", + child:( + <> + Use of road network for pedestrians. Location dependent. Availability of public transport. + + ) + }, + { + title: "Sensitivity to Results", + child:( + <> + High + + ) + } +]} +/> + +#### Evacuating Group Size + +The evacuating group size, or number of people per evacuating vehicle, must be defined. This variable is defined by occupancy type with a default of +three people per vehicle for all occupancy types except RES5 (institutional dormitories). The default is based on a family evacuating together in a +standard automobile. If the warning is issued during daytime hours, most people would initially leave commercial and industrial structures (places of +employment) alone in their vehicles resulting in a much smaller average group size. However, after leaving the workplace, people would likely convene +with their family at home and evacuate as a group, resulting in an evacuation group size closer to three. These additional stops, known as “trip +chaining,” are not included in LifeSim simulations. In LifeSim, people travel directly from their structure of origin towards their chosen destination. + +For RES5 structures, the evacuating group size default is 48 people per vehicle. This is based on historical evacuations of these types of structures, + which typically use busses to move large numbers of people. + + + 3 for all occupancy types except RES5. 48 for RES5 + + ) + }, + { + title:"Range (Best Practice)", + child:( + <> + 1-48 + + ) + }, + { + title:"Source Data / Considerations", + child:( + <> + Based on capacity of vehicle used for evacuation. + + ) + }, + { + title: "Sensitivity to Results", + child:( + <> + High if structures have high number of occupants and road network is congested. + + ) + } +]} +/> + +### Submergence Criteria + +Submergence is defined as a water level at a structure that can affect probability of survival. Submergence criteria are used to define the threshold +between high hazard and low hazard conditions when people are trapped in a flooded structure. They are defined by occupancy type and are used in +coordination with the roof and attic accessibility described above. The threshold of submergence is an uncertain parameter sampled uniquely for each +structure. A description of each submergence criteria, their applications, and default values are shown in . + + + +The structure submergence criteria come in three types: defined as A, B and C in . Submergence criteria A is +measured from the floor of the highest story in a building and used by people with limited mobility. The assumption in the default values is that +people with limited mobility can get to the highest floor in any building (possibly with assistance from others), but that they do not climb or swim. +Submergence criteria B is measured down from the ceiling of the highest story, representing an air pocket in a deeply flooded structure. Criteria B is + used for people without limited mobility that do not have access to the roof. This criteria is also used for people who go to the attic instead of +the roof. The assumption in the default values is that people will climb on top of something to stay above the water. + +Submergence criteria C is measured from the top of the roof. It is used by people without limited mobility who access the roof. The assumption in the +default values is if the water is higher than the roof, it must be slow moving or the structure would have already collapsed (and no vertical +evacuation calculated). However, there may be some velocity and exposure to external elements like debris/rain/wind, so the values are lower than +criteria A. + +The following is an example calculation using for reference for water that is 18 feet deep at the structure. The +in-structure depth is 15 feet (15 = 18 - 3). For a two-story building with no attic access and assuming the thresholds sampled the best estimate, Criteria +A is 14 feet (14 = 9 + 5), Criteria B-top floor is 17 feet (17 = 9 + 9 - 1), Criteria B-attic is 23 feet (23 = 9 + 9 + 6 - 1), and Criteria C is 28 +feet (28 = 9 + 9 + 6 + 4). A person with limited mobility would be in the high hazard zone, but those who are able bodied in the structure would be +low hazard. + +
+ +## Building Stability Criteria + +Building stability criteria refer to the hydraulic conditions used to determine whether or not a structure collapses when exposed to flooding. +Generally, stability criteria thresholds are defined as a function of depth and velocity relative to the first floor of the structure. During a +simulation, if both the depth and velocity reach a point above the functional threshold, then the structure is assumed to collapse. + +Building collapse is considered a high hazard situation for human safety and can have a significant impact on estimated life loss. LifeSim 2.0 +stability criteria must be assigned to each structure within the structure inventory prior to running a simulation. The building stability criteria +used in LifeSim builds on what was initially developed as the Loss-of-Shelter function by +Aboelata and Bowles (2005) . Users can create their own +stability criteria thresholds or select from a set of stability thresholds included in the software. The LifeSim default building stability criteria +are based on five common construction types (Appendix F). The +five construction types are as follows: + + + Engineered: Steel and reinforced concrete construction where the walls are non-load bearing and instead the columns and beams + carry the load. Walls may be masonry, wood, glass, etc. and are susceptible to collapse separate from the superstructure. + + ), + }, + { // STEP 2 + title: ( + <> + Wood-Anchored: Typical wood frame structure with load bearing walls that is bolted or anchored to the foundation and therefore + less susceptible to floating off the foundation. Heavy construction structures made of heavy materials such as large timbers, homes with a brick + façade, and homes with 2 or more stories are also more likely to resist floating and therefore may also be considered “anchored.” + + ), + }, + { // STEP 3 + title: ( + <> + Manufactured: Prefabricated houses that are constructed off-site and then assembled at the building site in sections e.g., mobile + homes. + + ), + }, + { // STEP 4 + title: ( + <> + Masonry: Unreinforced stone or block structures. + + ), + }, + { // STEP 5 + title: ( + <> + Wood-Buoyant: Typical wood frame structure with load bearing walls that is not anchored or bolted to the foundation and is + therefore highly susceptible to floating off the foundation. + + ), + } + ]} +/> + +Most available research regarding structural flooding focuses on monetary damage models using depth-damage (in dollars) functions as opposed to +stability. Appendix F summarizes +a literature review of the best available information to date regarding stability and proposes recommended stability +criteria for each construction type. Due to the variability in the functions presented, uncertainty is applied to the recommendations where +applicable. Uncertainty is included to inform risk characterization by accounting for natural variability in hydraulic conditions and imperfect +knowledge regarding construction types, quality of building components, weight, and other variables that can impact the overall stability of a given +structure. + +### Assigning Structural Stability in LifeSim + +When importing structures from a shapefile, the user must assign structure stability functions. Stability criteria are assigned to structures using +rules that relate stability functions to the structure's attribute values. LifeSim has default rules that assign stability criteria for structures with +specific construction and/or occupancy types. shows the default stability criteria assignment list when importing +a shapefile. + +
+ +The user may also edit the default rule list by clicking on the “Create Rule” button as shown in . Here, the user +has flexibility to set a rule based on any of the structure attributes within the inventory and select whether that rule should go into effect if +“Any” or “All” of the criteria are satisfied. The rules are a “rule stack” so the order in which the criteria are defined is important. Meaning, if +two rules could be applied to the same structure, the higher rule will dominate. The user should also take care to make sure all structures are +covered by at least one rule or stability criteria will not be assigned. + +The structure stability criteria can be re-assigned after import using the *Stability Criteria Assignment Tool*. + +
+ +## Number of Stories + +Number of stories must be defined for all structures within the LifeSim model. It must be defined as any non-negative integer. Some structures can +have zero stories such as a tent/campground, construction site, or field. Otherwise, number of stories should include all habitable stories within a +structure. The height of the structure should not impact defining number of stories. For example, a 30-foot warehouse with a single floor should be +assigned one story, while a residence of the same height with three floors should be assigned three stories. This parameter does *not* include +basements, attics, or accessible roofs, which are accounted for via different inputs in the software. + +The following elements of LifeSim are generally dependent on the number of stories: + +- Vertical evacuation potential +- Stability criteria +- Structure and content damages + +People within structures have increased vertical evacuation potential with additional stories. In LifeSim, it is assumed that all occupants – regardless + of age or mobility – can access higher stories within a structure. In general, a larger number of stories increases the chances of survival for +occupants caught within a structure. + +The number of stories can also affect the stability threshold for structures within the inventory. For USACE stability functions based on CH2M Hill +(1974) , there is a positive relationship between number of stories and stability threshold, assuming +that taller structures are built with stronger +foundations, which are less likely to collapse due to flooding. + +The number of stories can impact the total damage to a structure and contents. For example, a two-story structure will incur less damage with 4 feet of +flooding than a one-story structure. The USACE and FEMA have established depth-damage functions for structures with different numbers of stories. +Default depth-damage functions are specified in LifeSim for residential and non-residential structures. The default residential functions for +structure and contents for residential structures are based +on EGM 04-01 (USACE, 2003) . Non-residential functions are based +on the functions defined in HEC-FIA (USACE, 2015a) . + +## Construction Type + +The construction type refers to the predominant building material, which can often differ from the structure's appearance. For example, a single +family home might have walls coated with stucco or a brick overlay, but because it is framed and supported with wood, it should be assigned a “wood” construction + type. The same principle applies to structures with steel frames. + +The construction type parameter is used primarily to define stability thresholds for each structure. It is not used in the LifeSim computations. +Structures imported into LifeSim from NSI are automatically assigned a construction type. The construction type inputs +listed in are standard within the NSI. + + + +Other construction types may be input by the user and assigned to structures, but they will not automatically be assigned a stability function because + the default rules only encompass structures with NSI default construction types. User-defined rules must be set to ensure these structures are +assigned a stability function. + +## Heights (Foundation, Ground Floor, Above Ground, and Attic) + +Foundation, ground floor, above ground floor, and attic heights are used within LifeSim to define the vertical evacuation potential for each +structure. A diagram of the key structure height attributes is shown in . + +
+ +LifeSim uses the structure heights and a vertical evacuation model (explained in +Section Vertical Evacuation Within Structures) to +simulate how occupants caught within a structure +move up and away from flood waters. The height within the structure that occupants can reach and depth of flooding at the structure are necessary to +establish the submergence criteria, which is discussed in more detail in +Section Submergence Criteria. + +Structure height components must be defined for all structures within an inventory. The NSI only contains the foundation height parameter. The +remaining three height parameters (ground floor, above ground, and attic height) must be imported from another source, manually assigned, or use +default values available within LifeSim. + + shows default height values assigned by LifeSim. + + + +## Population Parameters + +LifeSim requires four population parameters defined for each structure. These include the under 65 population and over 65 population for both 2 pm +(daytime) and 2 am (nighttime). It can be difficult to estimate the population for each structure in a structure inventory if it does not already +exist. LifeSim has the capability to populate existing structures using data from the U.S. Census Bureau. + +### Population Parameters Defined by Alternative + +In LifeSim, some population parameters are specified by the alternative model component. describes the various +population parameters, potential ranges for each, and the impact they have on the model outcome. + + + +#### Fraction Limited Mobility (Under/Over 65) + +Age is often used as a proxy for people with limited mobility and ability to self-rescue. The population in LifeSim is split into over and under 65 +years old because it is a common dividing line in Federal data sets. The fatality rate applied is the same for all ages, but the chance that an +elderly person reaches a low hazard zone (like a roof or attic in a flooded house) is less due to their higher probability of having limited mobility. + The phenomenon has been demonstrated in several flood events where elderly people (especially those living alone) are overrepresented in the fatality + data (Jonkman et al., 2009 [Hurricane Katrina]; Jonkman et al., + 2018 [Hurricane Harvey]) . An exception + is when elderly people are living in multi-generational homes such as in +Japan (Risher et al., 2017) . + +In LifeSim 2.0, a fraction of population with limited mobility is treated separately for population over 65 and under 65. Limited mobility is used to +determine vertical evacuation potential, i.e., the ability to access areas such as a roof. If a person has been determined to have limited mobility, +LifeSim assumes that that person will not be able to evacuate above the highest story of a building to access the roof or attic. LifeSim assumes able +bodied people without roof or attic access will climb onto furniture or take other measures inside the structure to stay above the water, but people +with low mobility will not take these actions and will be subject to lower submergence thresholds. + +The fraction of population with limited mobility is a user-specified parameter entered separately for population over and under age 65. This parameter +is specified by alternative and applied to the structure inventory as a whole. The default values in LifeSim are based on the 2017 national average +of people with “ambulatory difficulty” from U.S. Census Bureau +data: 22.6% (over 65), and 5.1% (under 65). This +information comes from the American Community Survey (ACS) 5-Year Estimates . + +The U.S. Census Bureau tracks six types of disabilities in the “non-institutionalized population:” + +- Vision difficulty +- Hearing difficulty +- Cognitive difficulty +- Ambulatory difficulty +- Self-care difficulty +- Independent living difficulty + +The U.S. Census Bureau also defines a generic disability status that varies by age +(see here for definitions). The ambulatory difficulty survey question +asked respondents if they had “serious difficulty walking or climbing stairs.” + +Using the non-institutionalized population as the basis for the percentage creates some limitations to the data. It can be applied to a community +at-large but is not valid for institutional structures, especially those dedicated to caring for people with disabilities (e.g., hospitals, nursing +homes). Non-institutionalized General Quarters (GQ) facilities are included in the data. The institutionalized GQ population includes (but is not +limited to) people living in adult correctional facilities, juvenile facilities, nursing facilities/skilled nursing facilities, in-patient hospice +facilities, residential schools for people with disabilities, and hospitals with patients who have no usual home elsewhere. The non-institutionalized +GQ population includes people living in college/university student housing, military barracks, emergency and transitional shelters, and group homes +(Brault, 2008) . If institutional facilities are a significant percentage of the PAR, the overall percentage +with limited mobility may need to be raised. + +The ACS data is available by state, county, city, or census tract and easy to parse. The fraction of limited mobility may vary significantly by +region and year. Care should be taken to use a rate that represents the impacted area. + +Data also show the rate increases dramatically for populations over 75. If the impact area has an over 65 population that tends to be much older than +average (e.g., senior living communities), the rate could be raised. + +Children are not considered separately from adults. Children are lumped together with adults under 65 because it is assumed if there is a child +present, there is an adult nearby to help them overcome any mobility limitations. Conversely, adults over 65 usually won't have a younger adult with +them. + +#### Fraction That Can Swim + +Swimming ability is assigned randomly to the total population within the inventory based on a user defined percentage of people with swimming ability. + This is defined at the alternative level. + +In LifeSim, swimming ability is always considered when human stability is a factor in the computations. It is used to sort people into high and low +hazard zones when they are exposed to deep but slow-moving water. These conditions do not cause structure failure and can be easily survived for a +time by people who can swim. This includes scenarios in which a car loses stability but a person does not know if they will be in a low hazard +situation instead of high hazard. + +It is assumed the swimming population can reach a lower risk situation if exposed to these conditions, but people in these conditions who cannot swim +are placed in the high hazard zone. It is important to point out that if a person is assumed to have limited mobility, they will not be able to swim. +The stability of swimming people is shown in . Swimming ability is applied for people evacuating on foot. + +The best practice range of swimming ability is 40% to 85% and may vary widely by region. In a 1994 survey by Gilchrist et al. (2000), respondents +self-reported that 63% could swim at least one pool length. A 2014 survey by the American Red Cross stated that 80% of people claimed they can swim, +but only 56% of the swimmer group reported they can perform the five basic water competencies, indicating people have an overconfidence in their +abilities. Based on those results, only 45% of all people can perform basic water competencies. Both surveys also noted significant demographic trends + in swimming ability for age, race, and gender. + +The Red Cross “water competencies” are focused on the ability to self-rescue. These critical water safety skills are the ability to, in this order: +step or jump into the water over your head; return to the surface and float or tread water for one minute; turn around in a full circle and find an +exit; swim 25 yards to the exit; and exit from the water. If in a pool, you should be able to exit without using the ladder. + +
+ +### Longitudinal Employer-Household Dynamics (LEHD) Population Assignment Method + +The LEHD program is part of the Center for Economic Studies at the U.S. Census Bureau. The LEHD program produces high quality, cost effective, public +use local labor market data and demographic data. LEHD data are based on different administrative sources, primarily Unemployment Insurance (UI) +earnings data and the Quarterly Census of Employment and Wages (QCEW), censuses and surveys. LifeSim uses data on where workers live and work to +inform where people are at different times during the day. + +Below is a summary of the steps and processes LifeSim uses to import population from LEHD into the structure inventory. The current implementation is +only for U.S. Census 2010 data. Future implementations will include other years. + + + Determine which counties overlap the structure inventory. + + ), + }, + { // STEP 2 + title: ( + <> + Download census block data from each county that overlaps the structure inventory. + + ), + }, + { // STEP 3 + title: ( + <> + Use point in polygon testing to associate which structures are within each census block. + + ), + }, + { // STEP 4 + title: ( + <> + Get population data for each census block from the census data. + + ) + }, + { // STEP 5 + title: ( + <> + Download the LEHD Origin-Destination Employment Statistics (LOADS) data for each state that the structure inventory is in. + + ), + }, + { // STEP 6 + title: ( + <> + Get total jobs to and from census blocks that have been determined from step 3. + This includes working population in census blocks coming from other states. + + ), + }, + { // STEP 7 + title: ( + <> + Get fraction of population 65 years and over by census block. + + ), + }, + { // STEP 8 + title: ( + <> + For each census block in the collection of overlapping census blocks, LifeSim determines the total population split out by non-residential and residential. + + ), + child: [ + { + title: ( + <> + Residential population in a census block is determined using the following formulas: + + ), + freeform: ( + <> + + + + +

where:

+
+

RPU65 D = Residential Daytime Population Under 65 Years of Age.

+

RPO65 D = Residential Daytime Population Over 65 Years of Age.

+

RPU65 N = Residential Night-time Population Under 65 Years of Age.

+

RPO65 N = Residential Night-time Population Over 65 Years of Age.

+

PR = Residential Population in census block from census data.

+

PRW = Residential Population working in other census blocks.

+

FE = Fraction of population in census block that is over the age of 65.

+
+ + ), + }, + { + title: ( + <> + Non-residential population in a census block is determined using the following formulas: + + ), + freeform: ( + <> + + + + +

where:

+
+

NRPU65 D = Non-Residential Daytime Population Under 65 Years of Age.

+

NRPO65 D = Non-Residential Daytime Population Over 65 Years of Age.

+

NRPU65 N = Non-Residential Nighttime Population Under 65 Years of Age.

+

NRPO65 N = Non-Residential Nighttime Population Over 65 Years of Age.

+

PNRW = Non-Residential Working Population (from other/current census block).

+

FE = Fraction of population in census block that is over the age of 65.

+
+ + ), + } + ], + }, + { // STEP 9 + title: ( + <> + Distribute the population to structures based on their occupancy types and households. + + ), + child: [ + { + title: ( + <> + At each census block, the total daytime and nighttime household for residential and non-residential is calculated based on the structures in the + census block and their occupancy types. Each structure is then assigned a household weight value as the structure household value divided by the total + household value for the structure damage category for both day and night. + + ), + freeform: ( + <> +

+ A table of default household values for occupancy types is provided in below. +

+ + ), + }, + { + title: ( + <> + Population is then determined per structure for day, night, over 65, and under 65 years of age by taking the population values calculated in Step 8 + and distributing them to the structures based on the weights calculated in Step 9a. Residential population + values (e.g., RPU65 D) are distributed to + residential occupancy types and non-residential population is distributed to non-residential occupancy types. + + ), + } + ], + }, + { // STEP 10 + title: ( + <> + Once the population has been distributed to the structure inventory, the results are saved to the structure inventory attributes. + + ), + } + ]} +/> + + + +### Human Stability Criteria + +People can be caught in open flood waters if they are evacuating by foot or they abandon a trapped vehicle for a nearby structure, high ground, or a +destination. In these cases, pedestrian safety is compromised affecting their ability to remain standing or to traverse flood water and is considered +as a function of the depths and velocities of the flood water at that location and human stability +criteria (Russo et al., 2013) . A +person's ability to remain standing is defined in LifeSim as thresholds of depth, velocity, and DV or DV2. If instantaneous depth and +velocity at a person's location exceeds the velocity or DV thresholds, then the person is assumed in a high hazard situation. If only the depth +criterion is exceeded, then a person's hazard classification is dependent on the person's ability to swim. The human stability criteria flow logic is +summarized in . + +There has been significant scientific research in a person's ability to remain stable in flood waters. Most of the known research has been summarized +in Shand et al., 2011 , as demonstrated in . + +Shand's summary of existing research shows uncertainty about the depths and velocities required to cause a person to lose stability. Naturally variable + factors such as footing, clothing, shoe type, and a person's health can all play into an individual's ability to remain standing in flooding water. +The default functions in LifeSim for human stability pulled heavily from the research documented in Shand et al., 2011. In LifeSim, it is assumed that +anyone with limited mobility, especially the young, will be with an able-bodied person who can help. The default function in LifeSim for human +stability are shown in . + +
+ +
+ +
+ +## Property Value + +Property values are attributes required by LifeSim for damage computations. The user can define any or all of the property values. Definitions of the +different property values used in LifeSim are listed in . + + + Contents value is the value of the contents associated with the structure and does not include the structure value. This + value is often based on a content-to-structure-value + ratio (EM 1110-2-1619). + , + rowSpan: 1, + colSpan: 1 + }, + { value: "Vehicle value includes the value of any vehicles associated with the structure.", rowSpan: 1, colSpan: 1 }, + { value: "Other value is the value of “other” property such as a garage associated with the structure, but does not include the structure value.", rowSpan: 1, colSpan: 1 } + ] + ] + } + alt="Definitions of property values." + caption="Definitions of property values." + colWidths={[20, "auto"]} +/> + +## General Modeling Guidelines + +The user should consider the following when developing a structure inventory for a LifeSim study: + +- The user should always verify and check structure inventory data, especially structure placement, occupancy type, and foundation height as these +attributes are used for damage and fatality estimates. Structure inventory files can be edited directly in LifeSim without going to an outside +program. The user can validate data using aerial imagery from web services such as Google Maps. + +- The spatial extent of the inventory should include anything that could possibly be impacted, typically the maximum inundated area. + +- One best practice for estimating foundation heights and structure types would be to use Google Street View or conduct a drive-by survey. + +- Depth-damage functions are defined in LifeSim by the structure occupancy type. For residential structures, confirm that the occupancy type matches +the number of stories. For example, a single-family residence (SFR) with no basement with number of stories set to 1 should also have the occupancy type set as RES1-1SNB +(SFR one story, no basement) in order for the correct depth-damage function to be assigned. + +- The 2020 census data may be outdated in some places depending on development and migration trends. Consider adjustments to the growth of population from + the 2020 data until the next census data is released. Most counties or large municipalities will have a population growth rate + since the last census and may also have estimates for future growth. + +- While the NSI is a great resource for the USACE, it is by no means perfect and should be reviewed thoroughly prior to use. Recommended user quality checks +and known limitations of NSI 2026 are detailed in +the NSI Technical +References FAQs. Some of the most common NSI data issues include: + - Alignment and placement of structures. + - Population distribution in structures. + - Occupancy type definition. + - Foundation heights. + +- Spot-checking your population data is a manual process. How population is distributed in structures should be reviewed. The user should ensure +population estimates match the structure type (e.g., a mobile home with 100 people is not realistic). A quick check could include sorting inventory +attributes by population and verifying the number of people associated with each occupancy type is appropriate. + +- When importing population from either the LEHD or NSI data source, the structures along the maximum inundation extent may only partially cover a +census block (see ). In this case, only a portion of structures within the census block are included but they +are populated with the total population in the census block. This may lead to over-populated structures around the perimeter. + +
+ +- In LifeSim, the PAR is calculated as the number of people within structures subject to inundation at the time of warning issuance. This does not +always include the entire population within the model, as people outside of the inundated area when the warning is issued would not be considered PAR. + However, those people outside the inundated area could still take protective action and be included in the traffic simulation. Depending on user +preference, the structure inventory (and thus the population within the model) can be defined as only the structures subject to inundation, in which +case the total population of the model and the PAR would be equal. + +- Currently “trip chaining” is not considered in LifeSim. Trip chaining is when a person makes multiple stops during the evacuation. For example, a +mother may receive the first alert at work and drive to pick up her children at school before exiting the flooded area. LifeSim will only simulate the + mother's evacuation from work to the destination she can reach fastest and not consider any stops in-between. The implications of ignoring trip +chaining are the incorrect spatial distribution of population at the start of evacuation, misrepresentation of traffic congestion, and incorrect +destination selection. There is currently no method to approximate trip chaining in an evacuation scenario. + + \ No newline at end of file diff --git a/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/06-warning-and-protective-action-parameters.mdx b/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/06-warning-and-protective-action-parameters.mdx new file mode 100644 index 000000000..ddb0a577a --- /dev/null +++ b/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/06-warning-and-protective-action-parameters.mdx @@ -0,0 +1,912 @@ +--- +title: "Warning and Protective Action Parameters" +--- + +import Link from "@docusaurus/Link"; +import addBaseUrl from "@docusaurus/useBaseUrl"; +import Button from '@site/src/components/Button'; +import Citation from "@site/src/components/Citation"; +import CitationFootnote from "@site/src/components/CitationFootnote"; +import Equation from '@site/src/components/Equation'; +import EquationNoRef from '@site/src/components/EquationNoRef'; +import EquationReference from '@site/src/components/EquationReference'; +import Figure from "@site/src/components/Figure"; +import FigureInline from "@site/src/components/FigureInline"; +import FigReference from "@site/src/components/FigureReference"; +import NavContainer from "@site/src/components/NavContainer"; +import ProcessList from "@site/src/components/ProcessList"; +import TableReference from "@site/src/components/TableReference"; +import TableVertical from "@site/src/components/TableVertical"; +import VersionSelector from "@site/src/components/VersionSelector"; + + + +# Warning and Protective Action Parameters + +## Chapter Overview + +The warning and protective action framework used in LifeSim builds on decades of research in Protective Action Decision Making (PADM), specifically +drawing on its application to environmental disaster response as advocated by M. Lindell, C. Prater, R. Perry, D. Mileti, J. Sorensen, and others. The + warning and protective action parameters taken together describe the flow of information and decision making from discovery of a problem to people +taking protective action against the hazard. + +Two types of protective action are modeled in LifeSim, horizontal evacuation (by car or on foot) and vertical evacuation (seeking the highest point in + a structure). Other types of protective action such as rescue are not yet modeled. The data required to validate a rescue model is not readily +available. The warning and evacuation (protective action) system redistributes the population from their initial locations at the time that a warning +is issued to new locations with assigned hazard zone categories, i.e., no hazard, low hazard, or high hazard. LifeSim does this through simulation of +the warning issuance time, first alert diffusion, protective action initiation, and evacuation-transportation processes. Redistribution includes +horizontal evacuation in a vehicle or on foot along road networks and vertical evacuation within structures. + +LifeSim includes a suite of pre-set warning and evacuation parameters that were developed using the findings of Mileti and +Sorensen, 2015 . Users are able to adjust these parameters to better reflect the specific situation in the study area. + +In this chapter, each parameter is defined, research and development is presented, and its role and effect on the LifeSim simulation is explained. +Definitions are provided for warning and protective action parameters. The defined parameters are related to warning issuance, first alert diffusion, +and protective action initiation for evacuation areas that must be defined when configuring a LifeSim life loss simulation. + +Within the *Research and Development* sub-sections, warning and protective action parameters are explained using an example case study. The case study used +is the Oroville Dam emergency spillway incident, which took place near Oroville, California in February 2017. Geologists and other dam safety managers +became concerned when erosion downstream of the spillway was head cutting back toward the emergency spillway control weir more rapidly than expected. +If erosion continued toward the emergency spillway, they feared a monolith could fail leading to the failure of adjacent monoliths causing a complete +spillway failure. The USACE RMC LifeSim validation study of the Oroville incident is available +at LifeSim Validation Studies - Oroville. + +## Warning and Evacuation Timeline + +The LifeSim warning and evacuation timeline (illustrated in ) identifies points in time and the time periods +between the points in time (delays) required to warn and evacuate the PAR. + +The points in time include: + +- Hazard occurrence time +- Imminent hazard identified +- Emergency Management Agency (EMA) notified of hazard +- Evacuation warning issued +- First alert received by public +- Evacuation begins +- Destinations reached + +The periods between the points in time are referred to as delays. They include: + +- Imminent hazard identification period +- Hazard communication delay +- Warning issuance delay +- First alert diffusion delay +- Protective action initiation (PAI) delay +- Evacuation delay + +This timeline starts just prior to the hazard initiating. The period of time between when the hazard is identified and the hazard occurs is defined as +the **imminent hazard identification** period. It is important to note that the **imminent hazard identification** can happen before or after the hazard +occurs. Next, the **hazard communication delay** is the period of time it takes for whoever identified the hazard to alert the EMA. Once the EMA is +notified of the hazard, information regarding the hazard (i.e., a warning) must be communicated to the public. The time period it takes for EMAs to +compile the message and issue a warning is the **warning issuance delay**. At this point in time, the warning is issued to the PAR. It takes time for the +warning, or first alert, to be disseminated to the public. This period of time is referred to as the **first alert diffusion delay**. Once the population +receives the first alert, they will decide to take protective action or not. This decision process is the **PAI delay**. If they decide to take action and +evacuate, the time period it takes for them to reach their destination is the **evacuation delay**. For the evacuation to be successful, the protective +action has to begin in time for the population at risk (PAR) to reach safety before the hazard arrives. + + graphically displays the warning and evacuation timeline used in LifeSim. The timeline comprises time periods, or +delays, between points in the timeline. All time periods on the timeline are cumulative from left to right. Each delay can be represented with +uncertainty in LifeSim. The **first alert diffusion** and **PAI delays** are modeled with natural variability. +Refer to Chapter Uncertainty and Sampling Methods for +discussion on LifeSim sampling. + +
+ +Three “entities” are involved in the warning and evacuation timeline: + + + The dam or levee owner or operator + + ), + }, + { // STEP 2 + title: ( + <> + The emergency management agency + + ), + }, + { // STEP 3 + title: ( + <> + The PAR + + ), + }, + ]} +/> + +LifeSim makes certain assumptions about who is responsible for various actions, and how these actions interact to determine the duration + of time periods in the warning and evacuation timeline. The LifeSim user must gain an understanding of whether these assumptions reflect their study. + The entities, their roles, and their impacts on the warning-evacuation timeline are shown in . + + +
  • Detects the potential or actual failure.
    • +
  • Weighs decision to notify emergency management agencies.
    • +
  • Notifies emergency management agencies.
    • +
  • Carries out standard operating procedures related to the dam failure to the extent possible.
    • + + ), rowSpan: 1, colSpan: 1 + }, + { value: ( +
      +
    • Receive notification from dam owner/operator.
      • +
    • Weigh decision to warn the public.
      • +
    • Warn the public.
      • +
    + ), rowSpan: 1, colSpan: 1 + }, + { value: ( +
      +
    • Receives first alert.
      • +
    • Mobilizes (starts to evacuate).
      • +
    • Travels toward the fastest path to an accessible safe destination.
      • +
    • Reaches a safe destination or is caught in transit.
      • +
    + ), rowSpan: 1, colSpan: 1 + }, + ], + [ + { value: "The actions of the dam or levee owner/ operator impact the Warning Delay Time. In some cases, a bystander or other observer detects the failure mode. In that case, the incipient or actual failure may be reported directly to an emergency management agency.", rowSpan: 1, colSpan: 1 }, + { value: "The actions of the EMAs affect the Warning Delay Time, the First Alert Diffusion Time, and the Protective Action Initiation.", rowSpan: 1, colSpan: 1 }, + { value: "The characteristics and actions of the population (or sub-populations) affect the First Alert Diffusion and the Protective Action Initiation Time.", rowSpan: 1, colSpan: 1 } + ] + ] + } + alt="Entities, roles, and impacts on the warning and evacuation timeline." + caption="Entities, roles, and impacts on the warning and evacuation timeline." + colWidths={[15, "auto", "auto"]} + footnotes={[ + "*Note: There may be one or several sub-populations.", + ]} +/> + +## Emergency Planning Zone (EPZ) + +### Definition of an EPZ + +An EPZ is a geospatial area where the warning and evacuation characteristics are homogeneous; the EMA responsible for evacuating people within the EPZ + will have the same evacuation planning and preparedness, community participation and awareness, and types of flood warning systems available. The EPZ + should also be subjected to relatively similar conditions, such that messaging would be the same to everyone in the zone. For example, a community +divided by a flooding river may be all in one jurisdiction and subjected to similar flooding and arrival time on both sides of the river, but the +warning message might instruct them to evacuate at different times or in different directions. In this case, two separate EPZs should be defined. + +EPZs can be defined by well-known political boundaries, geographical features such as rivers, and/or major roads. EPZ boundaries usually coincide with + boundaries of a city, county, or other defined area in which a single emergency manager or sheriff has jurisdiction. The identification of +geographical features is especially important because these can serve as evacuation impediments. Mountains, peninsulas, islands, and rivers can all +restrict the number, directions, and capacities of evacuation routes (Lindell, 2013) . + +EPZs are defined in LifeSim with a shapefile. The user may define as many EPZs as desired – including EPZs inside the boundary of another, such as for +hospitals, prisons, or other facilities that have their own unique warning and evacuation procedures. Other characteristics that may call for a +separate EPZ include distance from the hazard, demographics, and other factors that isolate a geographically-specific group. + +People evacuating from within an EPZ will automatically choose the destination they can reach in the shortest travel time. If evacuation is being +simulated, simulating traffic can be turned off for all structures in an EPZ. Turning off evacuation for an EPZ assumes that anyone in that EPZ who +takes protective action to evacuate away from their structure will reach safety. + +The following parameters are defined at the EPZ scale and are used for warning and evacuation for the population within each EPZ: +- Imminent hazard identification period +- Hazard communication delay +- Warning issuance delay +- First alert diffusion delay +- Protective action initiation delay +- Simulate traffic +- Available destinations + +For example, four EPZs were initially considered for the 2017 Oroville Spillway incident: Butte County, Sutter County, Yuba County, and Yuba City. Butte County +is closest in proximity to the dam, Sutter and Yuba Counties are downstream of the dam, and Yuba City is the largest city within Sutter County and had a +specific evacuation order separate from the county. The final validation model has 10 EPZs, each with its own set of warning and evacuation parameters based on +location, city, and county information – available for download below. + + + +## Hazard Occurrence Time + +### Definition of Hazard Occurrence Time + +The hazard occurrence time is defined as the point in time when the hazard (e.g., dam failure, levee overtopping) occurs. It is the anchor point for +all other time-dependent warning and evacuation parameters within the simulation. The time must be manually defined by the user. More information on +defining the hazard occurrence time in LifeSim may be found in +Section Defining Hazard Occurrence and First Timestep. The +hazard occurrence time is not dependent upon human perception of the +hazard; it happens regardless of whether anyone is aware of it. Thus, the hazard occurrence time may or may not be witnessed by personnel at the +hazard source (e.g., dam or levee). + +The hazard occurrence time can occur before or after recognition (identification) of the hazard. The hazard and its occurrence time is defined once +for each hydraulic scenario (floodplain). + +In the *Simulations* study component, the hazard occurrence time is set to one of twelve default times of day (every two hours; +see ). The date and time of the hydrograph used to define the hazard occurrence becomes irrelevant as the anchor + point is redefined. Multiple times of day can be selected for the same simulation, with 2 AM and 2 PM being the most common selections, representing +day and night conditions. If any parts of the alternative are dependent on modeling differences by time of day, the time of day selection should be +coordinated with those assumptions. For example, a dam only staffed during the day may have a very different imminent hazard identification time +during working and non-working hours. + +
    + +### Research and Development + +Because the hazard occurrence point in time describes a physical state, research is not required. However, users may want to familiarize themselves +with differences in terminology that exist for the various phases of a breach. For consistency with the HEC-RAS definition, the hazard occurrence time + is the beginning of the "breach formation time." This time is physically characterized in HEC-RAS as the point when the structure breach begins +opening. Other references may include excessive leakage from the structure as part of the formation time. + +For the 2017 Oroville Spillway incident, there was no hazard occurrence time identified as a breach of the emergency spillway did not occur. Since the + breach of the emergency spillway weir was avoided by drawing down the reservoir, we cannot say when it would have happened. However, the discussion +and estimates of expected breach times highlight the uncertainty that is likely to exist for any real emergency. + +Warnings are sent with estimates of expected flood arrival times, but they are highly uncertain. Users should remember when developing the warning and + evacuation parameters that in real-life, the emergency managers do not have a hydrograph of the event post-fact. They are making decisions with +limited information. + +## Imminent Hazard Identification Time + +### Definition of Imminent Hazard Identification Time + +Imminent hazard identification time is the parameter that links the warning and evacuation process to the hydraulic data. Imminent hazard +identification time is the point in time at which someone (typically the dam or levee owner) recognizes that a life-threatening flood is going to +occur or is occurring and determines that the PAR needs to be evacuated (see ). + +An example is the point in time when an inspector becomes aware that a dam is overtopping and eroding rapidly. In this case, an early imminent hazard +identification may be possible if the overtopping and erosion could be forecasted, or late if it was unexpected and no one was on-site to witness it. + +The imminent hazard identification time may occur before or after the hazard occurrence time (i.e., to the left or the right of hazard occurrence time + on the LifeSim timeline). Thus, it may be positive or negative. A positive time indicates a late identification, made after the hazard has occurred. A + negative time (before the hazard occurrence) indicates an early identification of the hazard. + +The imminent hazard identification period typically includes: + +- Observation of an abnormal condition that would lead someone to consider a flood and/or failure may be imminent. The observation may be: + - A physical observation by a person (i.e., seepage) + - A forecasted condition (extreme incoming flood likely to exceed design capacity) + - An unexpected change in a monitored gage (e.g., embankment deformation, flow, seepage) + +- Recognition that the observation is indicative of an imminent flood hazard. For example, understanding the implications of the observation, e.g., +“will this seepage lead to a breach?” + +- Recognition that people may be in harm’s way and need to be evacuated. + +- Sufficient confidence in the assessment to alert the authority responsible for evacuation. + +The imminent hazard identification time parameter can be defined with uncertainty in LifeSim. The uncertainty includes considerations of when +something might be observable, is someone there to see it, is there a technical understanding of the severity of the observation/forecast, how long +does the process of failure take before the hazard occurrence (breach initiation time). + +### Research and Development + +The imminent hazard identification time is one of the most important and sensitive factors impacting total life loss. It is an area that includes +several tracks of ongoing research. One area is on physical modeling of breach progression, especially for embankment erosion that is advancing with +laboratory experiments and software development. Robin Fell and others (2003) have +documented the amount of time it takes for embankments of different +materials to progress from a visible leak to breach. ERDC (Robbins and Wibowo, 2012) are experimenting +with backward erosion piping progression. USDA +ARS developed an empirically based software called WinDAM C that models breach progression of embankments undergoing internal erosion or overtopping +erosion (Morris et al., 2018) . Dr. Wu developed a software that simulates the physics of breach +development called +DLBREACH, collaborated and implemented into HEC-RAS. The +HEC-RAS version of DLBreach combines the breach development +algorithms from Wu (2013) with HEC-RAS hydraulics. HR Wallingford developed models based on Dr. Wu’s research that simulate the physical process of breach progression (HR +Breach, EMBREA) (Risher and Gibson, 2016) . A detailed analysis of the imminent hazard identification may include sampling of the embankment material +for erodibility properties and modeling with one of the breach models to understand the uncertainty around the breach progression time. + +Another area is the decision-making process for the owners of flood management infrastructure. The lack of physical understanding and/or ability to +observe the breach process must figure into the decision-making time. The lack of understanding limits the ability for early detection until the +observable signs present overwhelming evidence that a problem may progress to a breach. When evaluating the hazard identification time, you should +also consider the presence or absence of monitoring equipment, staffing, and inspection protocols. Early observation of a changing condition by +personnel or instrumentation may allow an imminent hazard to be identified sooner and reduce the hazard communication delay. + +An example of imminent hazard identification is shown in from the 2017 Oroville Spillway incident. It shows that + 90 minutes elapsed from the time observers became concerned about erosion on the spillway to the time that officials identified a potential spillway +breach. + +Other historic events exist where the hazard identification time has been documented as summarized . The +historic case histories help highlight the differences between when the hazard is initially observed and when the decision is made to begin the +evacuation process. + +
    + + + Teton Dam + , + rowSpan: 1, + colSpan: 1 + }, + { value: "Laurel Run Dam", rowSpan: 1, colSpan: 1 }, + { value: "Canyon Lake", rowSpan: 1, colSpan: 1 }, + { value: "New Delhi Dam", rowSpan: 1, colSpan: 1 }, + { + value: + <> + Kelly Barnes Dam + , + rowSpan: 1, + colSpan: 1 + }, + { + value: + <> + Oroville Dam + , + rowSpan: 1, + colSpan: 1 + }, + ], + [ + { value: "Seepage, first filling of dam", rowSpan: 1, colSpan: 1 }, + { value: "Overtopping", rowSpan: 1, colSpan: 1 }, + { value: "Overtopping", rowSpan: 1, colSpan: 1 }, + { value: "Overtopping", rowSpan: 1, colSpan: 1 }, + { value: "Unknown", rowSpan: 1, colSpan: 1 }, + { value: "Spillway failure", rowSpan: 1, colSpan: 1 } + ], + [ + { value: "June 5, 1976 7:00 AM, slightly turbid leakage noted", rowSpan: 1, colSpan: 1 }, + { value: "None, not even flash flood warnings until after failure", rowSpan: 1, colSpan: 1 }, + { value: "June 9, 1972, severe thunderstorms and flash flood warnings", rowSpan: 1, colSpan: 1 }, + { value: "July 24, 2010 3:30 AM, vortex noted 40 to 50 feet south of structure", rowSpan: 1, colSpan: 1 }, + { value: "None, unmanned dam", rowSpan: 1, colSpan: 1 }, + { value: "February 12, 2017 ~2:00 PM, concern about the rate of erosion headcutting toward the emergency spillway", rowSpan: 1, colSpan: 1 } + ], + [ + { value: "June 5, 1976 ~10:43 AM, decision to call county sheriff and notice given to begin evacuation", rowSpan: 1, colSpan: 1 }, + { value: "None, no one was present at the dam", rowSpan: 1, colSpan: 1 }, + { value: "June 9, 1972 ~10:39 PM, decision to evacuate", rowSpan: 1, colSpan: 1 }, + { value: "July 24, 2010 ~10:29 AM, emergency managers ordered evacuation", rowSpan: 1, colSpan: 1 }, + { value: "None, no one was warned", rowSpan: 1, colSpan: 1 }, + { value: "February 12, 2017 ~3:30 PM, rate of erosion downstream headcutting toward the emergency spillway was more rapid than expected and an evacuation was deemed necessary", rowSpan: 1, colSpan: 1 } + ], + [ + { value: "June 5, 1976 11:55 AM, crest collapses", rowSpan: 1, colSpan: 1 }, + { value: "July 20, 1977 2:35 AM", rowSpan: 1, colSpan: 1 }, + { value: "June 9, 1972 ~10:45 PM", rowSpan: 1, colSpan: 1 }, + { value: "July 24, 2010 1:00 PM", rowSpan: 1, colSpan: 1 }, + { value: "November 6, 1977 1:30 AM", rowSpan: 1, colSpan: 1 }, + { value: "N/A", rowSpan: 1, colSpan: 1 } + ] + ] + } + alt="Case study examples of documented hazard identification time." + caption="Case study examples of documented hazard identification time." + colWidths={["12%", "12%", "auto", "auto", "12%"]} +/> + +## Hazard Communication Delay + +### Definition of Hazard Communication Delay + +The hazard communication delay is the period of time from the imminent hazard identification time to notifying the agency responsible for ordering an +evacuation (e.g., emergency management agency) (). The hazard communication delay may include the time needed to: + +- Locate a phone or phone number. +- Find alternative modes of communication if standard communication options are unavailable. +- Complete internal agency reporting or emergency protocol. +- Obtain approval to notify the EMA. +- Collect information needed by the EMA. + +
    + +Confusion and indecision may introduce uncertainty due to lack of planning for such an event. There may be uncertainty in time required for any of the + activities above. + +The user (1) defines the hazard communication delay after the imminent hazard time has been identified, and (2) defines the distribution of the +uncertainty (if modeled). The definition is made for each EPZ in each alternative. Hazard communication delay can be zero if the EMA is the hazard +identifier or they are co-located in an incident command center. + +### Research and Development + +Interviews of staff at the Oroville Incident Command Center recalled that California Department of Water Resources (DWR) geologists +observed erosion nearing the emergency spillway around 2:00 +PM. They continued to monitor it, collect information, and brought it to the incident command center around 3:00 PM. + +During discussions of the situation, around 3:30 PM, the Butte County sheriff overheard DWR staff wonder aloud, “Is the sheriff aware of this?”, +serving as his notification. The delay was longer for other jurisdictions not represented at the incident command center that were +notified later – either by the sheriff, the Butte County warning issuance, or Blackboard Connect, as +shown in (Sorensen et al., 2018) . + + + +The dividing line between imminent hazard identification time and hazard communication delay is somewhat blurred in this example due to uncertainty in + the integrity of materials near and below the structure. Geologists recognized an issue at 2:00 PM but may not have been convinced of its severity, +a requirement for imminent hazard identification. They did consider it serious enough to alert superiors and collect more information, two of the +factors noted above. Had the sheriff not overheard the conversation, the delay may have been extended further or not even resulted in a notification. + +## Warning Issuance Delay + +### Definition of Warning Issuance Delay + +As used in this context, a “warning” is a message intended to instruct recipients to take a protective action – that is, to evacuate. It is the first +public alert of an evacuation order. The term “warning” also does not include any messages about the hazard that may have been issued prior to an +evacuation order. + +The warning issuance delay, shown in , is the time that elapses from the moment the agency issuing the warning +first learns of the hazard to first release of an evacuation notice. Warning issuance delay does not include issuance of pre-evacuation information. + +Factors that influence warning issuance delay include: + +- Identification of the PAR. +- Understanding, confirming, and describing the hazard. +- Understanding and describing the potential consequences. +- Crafting an evacuation message. +- Accessing the first channel of communication. +- Obtain authorization to release an evacuation order. + +
    + +The analyst must decide whether to use one of the default functions that LifeSim provides, or use a custom function. To make this decision, the +analyst must gather information about the hazard response and warning protocols in place at the EMA for the study area and make qualitative judgments +about those factors. If none of the provided default functions appear appropriate, the user is able to develop a custom function with the help of +elicitation using the Expert Opinion Elicitation (EOE) Questionnaire +in Appendix B. If +the user has no information, use of the *Preparedness: Unknown* function is recommended. The +standard warning issuance delay functions are shown in . + +To develop a custom function (using the **Add New** button +shown in ), USACE has developed a warning and +mobilization function generator in Excel. The first tab in this tool is the EOE questionnaire, also provided +in Appendix B. Many questions from this +elicitation help the user gather information about the first alert diffusion function. The elicitation helps identify the level of preparedness of the +EMA. + +The function generator tool scores the answers to the questions and generates values for the a and b parameters of the Lindell +function (). + + + +This, in turn, defines the shape of the custom warning issuance delay function. More information about EOE and scoring results is +provided in Appendix B. + +
    + +### Research and Development + +Research conducted by Mileti and Sorensen (2017a) was used to determine how different factors +may affect the warning issuance delay during an +evacuation. The researchers reviewed historical case studies of disaster warning issuance and identified four main categories of factors that impacted + the speed at which emergency managers made warning decisions: + +- Formalization of planning and implementation procedures +- Staff experience/training and interpersonal relations +- System performance factors +- Situational factors + +The researchers developed functions to estimate warning issuance delays based on surveys of emergency managers. Delay times were based on both the +emergency manager’s estimation of a hypothetical scenario as well as actual delay times from previous warning issuances, specifically 70 cases of +chemical accidents and releases. Four different probability distribution functions were developed, shown in . +LifeSim warning issuance delay times are largely based on work by Mileti and Sorensen (2017a) . + +
    + +For the 2017 Oroville Spillway incident, DWR communicated a warning message to other organizations via Blackboard Connect about the developing +emergency spillway situation and to immediately evacuate at 4:10 PM on February 12, 2017. Following this warning, five first public warning messages +(from different EMAs) were issued to different counties and at-risk areas, including Butte County, Sutter County, Yuba County, and Yuba City. A +summary of the first public warning evacuation messages is shown in (Sorensen et al., 2018) . + + + +## First Alert Diffusion Delay + +### Definition of First Alert Diffusion Delay + +In LifeSim, first alert diffusion delay (alternatively known as warning diffusion) – shown in – is the +relationship that defines how quickly the first alert (warning) will disseminate through the population. Receipt of a first alert encompasses any +means by which such a message is received, including official notifications on television or radio, alerts received on mobile phones, local +authorities with loudspeakers, family and friends calling one another, and neighbors knocking on doors. Receipt of a first alert does not imply that +the recipient understands the content of the message; receipt only indicates awareness that something out of the ordinary is happening. + +
    + +To define the first alert diffusion function in LifeSim, the user has to select one of the dissemination speed functions provided or develop a custom +function. The best approach to use will depend on the level of effort available for the study. If no effort can be put into understanding the factors +that go into how quickly a warning will spread throughout a community, then the unknown default option should be selected. For minimum efforts, an appropriate default function can be selected by comparing the +scenario being studied to the summary of factors influencing first alert diffusion speed shown in . If the level +of effort is moderate to high, the user can perform an EOE with the EMA(s) using the questionnaire +in Appendix B. + +
    + +The first alert function is entered for both daytime and nighttime scenarios in LifeSim as an empirical curve function. The curve function can have +uncertainty defined at each ordinate. Sampling the function during a simulation is explained in more detail +in Section Warning Function Sampling. An +example of a daytime fast first alert diffusion function used in LifeSim is shown in . + +
    + +### Research and Development + +First alert diffusion delay functions used in LifeSim were developed by Mileti and Sorensen +(2017b) . The researchers collected data on warning delays +and first alert diffusion delays for historical events including floods, hurricanes, wildfires, tornadoes, volcanoes, chemical accidents, and +terrorist attacks. + +Using data from historical cases and models developed during previous research projects, the researchers developed a total of eight first alert +diffusion delay functions, shown in . + +These functions serve as the default first alert diffusion delay functions in LifeSim, with function A corresponding to the “Fast” first alert +function and curve D corresponding to the “Slow” first alert function and so on. The researchers also adjusted the functions to account for time of +day, resulting in a total of eight first alert diffusion functions. More information on first alert diffusion delay functions, how they were +developed, and how they were incorporated into LifeSim may be found in Mileti and +Sorensen (2017b) . If minimal information is +available, the user can select from one of the eight default functions in LifeSim. + +
    + +For the 2017 Oroville Spillway incident, around 86% to 89% of the PAR received a warning on +February 12, 2017 (). The first warning message was received via text messages, television, phone +calls from others, face-to-face communications, and internet/social +media. From the time the first warning was issued to when majority of the population received the first alert was within +six hours for the EPZs . + +
    + +## Protective Action Initiation Delay + +### Definition of Protective Action Initiation + +Protective action initiation (PAI) is any action taken by an individual or group to protect themselves. PAI delay, shown +in , is the period of time that starts with receipt of the first alert and ends when the recipient of the +first alert takes protective action against the hazard. During this period of time, people are confirming the severity of the situation, packing, +notifying others, protecting property, gathering family and pets, etc. + +
    + +PAI delay is important in two different evacuation scenarios. First, if little time is available before the arrival of water, people need to take +protective action quickly if they are going to have enough time to reach safety. The second scenario where the PAI delay is important is when there is + ample warning time. In this case, the maximum mobilization rate becomes one of the most sensitive parameters in the model. + +The maximum mobilization rate is not a user-defined parameter but is represented by the upper asymptote of the PAI function. It typically ranges from +5-20% but could be more under certain conditions. As discussed during the Oroville incident and documented in many other historic flood events, not +everyone will evacuate even if ordered to and given enough time. Emergency managers are usually aware of this population and may be able to provide an + estimate. Effective messaging is the best way to reduce the number of people remaining behind. + +In LifeSim, the start of protective action means “starting to move away from the area of potential flooding towards emergency shelters or other safe +destinations” (Aboelata and Bowles, 2005) . The percentage of population that takes protective action over time is represented by a PAI +function (). + +The PAI delay function is entered in LifeSim as an empirical curve function. The curve function can have uncertainty defined at each ordinate. +Sampling the function during a simulation is explained in more detail in +Section Warning Function Sampling. Here, +the function represents protective action only of those +that evacuate by leaving the structure, as this mode of evacuation is time-dependent and defined by a delay function. Vertical +evacuation is discussed further in +Section Vertical Evacuation Within Structures. + +
    + +Use of the questionnaire described +in Appendix B can +help elicit information to determine the correct level of preparedness. If minimal information is + available, the user can select from nine default functions in LifeSim based on levels of EMA preparedness and public perception of their risk. +Preparedness levels refer to the preparedness of the emergency management agency issuing the warning. + +The definitions of **preparedness** levels are as +follows: + +- High: The EMA is well-prepared to issue a well-crafted, convincing message that motivates the population receiving the message to +act. +- Moderate: The EMA is moderately well-prepared to issue an effective message. +- Low: The EMA is not well-prepared to issue an effective message. +- Unknown: There is little information about the EMA preparation or the agency releasing the warning is unknown. An average condition +between low and high is assumed with the full range of uncertainty of both. + +Initial perception refers to the perception of the people receiving the first alert. It is a function of location of the population relative to the +hazard. If, for example, the population lives within sight of the dam or river, the initial perception of dam failure is “high.” +Initial perception can also be influenced by recent events or by extremely effective and pervasive public awareness campaigns. + +Suggested definitions +of **perception** levels based on distance from the hazard are as follows: + +- High: Population less than 0.25 miles from the river or less than 0.5 miles from the dam. +- Moderate: Population around 0.25 miles from the river or 0.5 miles from the dam. +- Low: Population greater than 0.25 miles from the river or greater than 0.5 miles from the dam. +- Unknown: There is little information about the public perception of flood risk. It is represented with the full range of uncertainty +of both low and high perception levels. + +### Research and Development + +PAI delay functions used in LifeSim were developed by USACE-RMC based on research by Mileti and +Sorensen (2017c) . The researchers examined historical +cases of protective action in order to derive empirical data about protective action timelines. They developed a mathematical model of PAI that fit +the historical cases, resulting in a total of four PAI functions differentiated by perceived level of preparation, shown +in . Series A represents a high level of preparation, while series D represents a low level of preparation. + +An additional PAI function was developed with rapid initiation to represent those evacuating on foot. More information on the research, development, +and implementation of PAI functions for LifeSim may be found in Mileti and +Sorensen (2017c) . USACE-RMC expanded the functions from 8 hours to 72 hours +to accommodate longer LifeSim simulation times based on assumed mobilization at 24 hours and 72 hours. The best and worst of the four general cases +were taken as the limits of uncertainty. The nine default curves are a recombination of these general +curves based on assumed weighted answers to the EOE +in Appendix B representing risk perception +and likeliness to impact (perception). LifeSim users may +create their own custom functions based on surveyed answers to the questions. + +
    + +For the 2017 Oroville Dam Spillway incident, findings showed that most individuals sought additional information by communicating with others via +phone calls, face-to-face conversations, or the internet after receiving the first warning message prior to evacuating. Additionally, prior to taking +protective action, individuals performed various pre-evacuation activities, including securing their homes or businesses, packing items, reuniting +with family members and pets, and helping others prepare to evacuate. + +Based on a study survey of the EPZs, around 67% to 68% of the population evacuated and the PAI delay for majority of the population was around two to +three hours (). Some of the population took protective action prior to the warning issuance based on the +coverage of the situation for several days and to avoid roadway congestion if an evacuation was issued +(Sorensen et al., 2018) . + +
    + +## General Modeling Guidelines + +- The analyst may find it useful to adopt a zoned approach when defining perception for PAI delay functions. This is because people’s perception of +their risk tends to get reduced as you move farther away from the hazard source. An example of a levee breach scenario is +shown in . The terminology of "likely to impact" and "unlikely to impact" was updated to "high" +and "low," respectively, in LifeSim version 2.1 and later. + +
    + +- The default curves may be used in LifeSim for warning issuance delay, first alert diffusion delay, and PAI delay, but many studies would benefit from +functions specific to the emergency management agencies responsible for the study region. The EOE +in Appendix B is +used in conjunction with the *Warning Curve Generator* developed by USACE-RMC to generate custom functions adapted from the research of +Mileti and Sorensen +(2017a, b, c) . + +- Most EMAs in the United States follow the Incident Command System guidelines as part of +the National Incident Management System led +by FEMA. The +guidelines were developed to be flexible for any type of incident and scalable to include +multiple agencies from local to national level. In a large event, warnings and messaging are typically coordinated within this framework. Perhaps +because of this organizational and agency posture, incident planning often takes the form of “all-hazards” plans. Agencies want to be ready for any +disaster including floods, often to the detriment of flood-specific preparation. Some agencies recognize their unique risk to flooding and have +specific planning to address it. + +- Several agencies may have jurisdiction or overlapping responsibility for portions of the warning and evacuation timeline. For example, the chief of +police of a city may issue a warning, the county sheriff may issue another, and the National Weather Service or River Forecast Center may also issue +notices (but typically stop short of evacuation warnings). People may act on any of the information they deem relevant even without a mandatory +evacuation order. + +The total population included in the model does not account for people who have evacuated voluntarily prior to warning issuance. While there is no +formal method in LifeSim to simulate evacuees prior to the evacuation warning issuance, informal methods may be used to incorporate this into the +model. When assigning population to the structure inventory, those that are assumed to pre-evacuate can be removed from the structure inventory. +Additionally, the imminent hazard identification time may be manipulated to make the entire warning and evacuation timeline initiate earlier. + +Some data exists on evacuation departures prior to an official order (Sorensen et al. 2018). It may be difficult for citizens to determine if an +official order applies to them (Sorensen et al., 2018) . The data from several hurricane events suggest +that in protracted warning situations, some +people initiate action after the first warning and before what is defined as the official warning. In hurricanes, the number who leave early ranges +between 20% and 30% (Baker, 1987; Lindell, Lu, & Prater, 2005) . Early +evacuation is most likely to occur if an official warning is +delayed in what appears to be a potentially threatening situation. + + \ No newline at end of file diff --git a/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/07-road-networks-destinations-and-evacuation-parameters.mdx b/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/07-road-networks-destinations-and-evacuation-parameters.mdx new file mode 100644 index 000000000..ea2a8245f --- /dev/null +++ b/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/07-road-networks-destinations-and-evacuation-parameters.mdx @@ -0,0 +1,828 @@ +--- +title: "Road Networks, Destinations, and Evacuation Parameters" +--- + +import Link from "@docusaurus/Link"; +import addBaseUrl from "@docusaurus/useBaseUrl"; +import Citation from "@site/src/components/Citation"; +import CitationFootnote from "@site/src/components/CitationFootnote"; +import Equation from '@site/src/components/Equation'; +import EquationNoRef from '@site/src/components/EquationNoRef'; +import EquationReference from '@site/src/components/EquationReference'; +import Figure from "@site/src/components/Figure"; +import FigureInline from "@site/src/components/FigureInline"; +import FigReference from "@site/src/components/FigureReference"; +import NavContainer from "@site/src/components/NavContainer"; +import ProcessList from "@site/src/components/ProcessList"; +import TableReference from "@site/src/components/TableReference"; +import TableVertical from "@site/src/components/TableVertical"; +import VersionSelector from "@site/src/components/VersionSelector"; + + + +# Road Networks, Destinations, and Evacuation Parameters + +## Chapter Overview + +If traffic is being simulated, road network and destination data are required in a LifeSim study to represent possible routes that people can take +during an evacuation. The road network features can be categorized into multiple road types with attributes defining their census feature class code +(CFCC; see ), flow direction, and vertical offset. Destination features represent point locations on roads – +generally outside of the inundation extents – where evacuating groups travel to, and once they arrive, are assumed safe. + +The model simulates traffic along the road network starting with the first evacuating group that initiates protective action. When the evacuation is +initiated, the road network does not have vehicles on it. Once a vehicle has entered the road network, drivers are able to make decisions about their +route based on computational inputs that include traffic conditions, destination locations, depth on roads, vehicle type, and roadway classification. + +Evacuating drivers choose a destination based on the shortest travel time from their current location to a destination. If their path becomes +obstructed by either flood water or traffic congestion, drivers alter their path and destination as necessary to evacuate. Once the simulation starts, + drivers are aware of where they are on the road network and retain some memory of where they have been. A vehicle will not try to revisit a roadway +link that has already been found to be flooded. + +## Computational Inputs + +LifeSim uses a modified version of the Greenshields traffic simulation model as shown +in , , and to determine +speed of vehicles +at each time step (Mahmassani et al., 2009) . If density +becomes high enough, speeds will begin to reduce. Breakaway density is the point at which vehicles transition from free-flow speeds to congested +conditions and shift to a Greenshields model for speed and density relationships. + + + + + +where: + +> _vi_ = speed on link i
    +> _uf_ = free flow speed on link i
    +> _ki_ = vehicular density on link i
    +> _kbp_ = break point density
    +> _v0_ = stop and go speed on link i
    +> _vf_ = speed intercept
    +> _kjam_ = jam density on link i
    +> _α_ = Greenshields power term + +
    + +### Road Networks + +#### Linework + +The linework for the road network is generally imported from a shapefile or directly from the OpenStreetMap web +service. OpenStreetMap is a collaborative project to create free editable maps of the world . It is supported by a +large community of dedicated members to provide global GIS data. + LifeSim can take the road network information stored within the OpenStreetMap database and create a road network. Once the road network data is imported, + the user can edit the data by defining one-way fields and vertical offsets. + +The directionality of one-way roads in the road network is important in LifeSim computations. Direction is determined by the order of the line points, + where the first line point is the road entry and the last line point is the exit. Vehicles have unidirectional movement on a one-way road and cannot +turn around. Examples of valid and invalid representations of one-way roads are shown in . + +
    + +Road network connectivity must be thoroughly reviewed by the user. The road endpoints must be within 2 feet to allow travel from one road segment to +the next, as shown in . + +
    + +Overpasses can possibly share end points with roads underneath. In (a), vehicles would be able to incorrectly +drive from the overpass directly onto the road underneath. + +
    + +The hydraulic characteristics for a roadway link is sampled at the centroid of the roadway line segment, this means that care must be taken for long +roadway segments and steep terrain as the midpoint may not be a representative condition for hydraulics. An example of where the midpoint should be +modified is shown in . + +
    + +In (a), the road segment is long. If the hydraulic results are sampled at the centroid of the road segment as +shown in (c), the depth would be poorly represented in the first half of the road segment. If the same road +segment is subdivided as shown in (b), then the hydraulic representation would be more +accurate (d). + +#### Roadway Vertical Offset + +The vertical offset accounts for roads with elevations higher than the underlying terrain (e.g., bridges, overpasses, causeways). If the roadway is an + overpass, then the vertical offset should be set to underlying terrain plus the height to the overpass roadway. Bridge segments typically have their +midpoint over the channel and require vertical offsets to allow traffic to continue over the bridge without being impacted by the water flowing +underneath. A schematic of a bridge vertical offset is shown in . + +
    + +#### Road Classification Data + +Roads are classified in LifeSim using common feature classification codes (CFCC). CFCC codes for roadway features are summarized +in . + + + +The road classification attribute CFCC helps define common road parameters such as number of lanes, free flow speed, traffic jam density, breakaway +density, stop and go speed, and a Greenshields power term. When the user has a non-typical roadway type (for example, a highway that is 5 lanes), users + may need to create and define a new CFCC or edit an existing code as necessary to fit the individual situation (for a 5-lane highway example, the +user could set the type to A11 Primary road with limited access or interstate highway, unseparated, and set the number of lanes to 5 lanes). +The existing CFCC codes used in the LifeSim model are defaults but can be edited. However, caution should be used prior to changing these parameters +as they have a significant impact on the traffic simulation. Road classification data defaults in LifeSim are shown +in . + + + +These values can be manually adjusted by the user for each individual CFCC. describes the CFCC defaults, best +practices for selecting values, potential source data, and sensitivity of values to LifeSim results. + + + +#### Free Flow Speed + +Free flow speed is the speed at which vehicles will travel when unimpeded by other vehicles. Values can be developed by roadway segment based on +field-collected data. If speed studies are not a viable option, assumed speeds can be developed based on the posted speed limit for roadway segments. +This value should be user-defined for each roadway type as it will impact model results. + +#### Jam Density + +As congestion begins to build on the roadway, vehicles will begin to form queues. The jam density is the theoretical density when traffic flow begins +to approach zero. The Highway Capacity Manual states, “Jam density does not affect throughput, it only influences the formation and dissipation of +queues at bottlenecks. Interestingly, an increase in the jam density value reduces both the forming and recovery wave speeds. The opposite situation +occurs if jam density is decreased, in which case both the forming and recovery speeds will increase” (TRB, 2016) . + +#### Break Point Density + +Breakaway density is the point at which vehicles transition from free-flow speeds to congested conditions and shift to a Greenshields model for speed + and density relationships. In general, the break point density should not need to be modified for local conditions. + +#### Stop-and-Go Speed + +Stop-and-go speed is the speed that vehicles will travel when traffic jam conditions have been met. Stop-and-go speeds generally range between 1-15 +miles per hour (mph) with 5 mph being the general guidelines for standard rush hour traffic. However, during an evacuation, other conditions such +as higher-than-average load on the network and weather can further reduce stop-and-go speeds. Therefore, a default of 4 mph has been specified. + +#### Greenshields Power Term + +The Greenshields Power Term (α) defines the shape of the speed-density function. The Greenshields power term helps define the functional speed-density + relationship between breakaway density and stop-and-go speed. If the power term is 1, the function will be linear. + +### Destinations + +Destination points represent evacuation locations where the population is safe, specified either within the inundation area or an area outside the +maximum flooding extents. People are considered safe and are removed from the simulation once a destination is reached. Destinations are located only +on roads. However, the destination does not have to be directly on a road as LifeSim will calculate the nearest road segment to a destination. The +user should use judgment when placing destinations such that they are: + +- Equidistant from the target population since agents pick destinations based on shortest travel time +- Located at major exit roads +- Sufficiently far away from the population at risk to allow for traffic backup due to limited egress + +At the start of the evacuation process, evacuating vehicles select a destination with the shortest travel time. The vehicle will continue toward that +destination until it meets a roadway that is flooded or congested, at which point it may re-route. A vehicle that re-routes may choose to change its +destination if another can be reached in less time. + +### Vehicle Stability Criteria Defined By Alternative + +The reaction of vehicles to water is simplified into two groups in LifeSim, high clearance and low clearance vehicles. Generally, high clearance +vehicles are considered as trucks or SUVs, and low clearance vehicles are considered as cars and vans. In low velocity moderate depth water, most +modern vehicles will begin to float because they are mostly water tight. This begins around 18 inches deep for small vehicles and 24-30 inches for larger +vehicles. Many times, a vehicle will stall before losing stability, encouraging many people to exit their vehicles and continue on foot. + +
    + +Current understanding based on review of historic events is vehicles are pushed into deeper and/or faster water after stability is lost. This is a +dangerous situation whether the person exits the vehicle or not. Roadways are typically elevated on an embankment which causes flow much faster near +the downstream edge of the roadway embankment. More information on factors that impact vehicle stability has been detailed +in Appendix G. + +When the flooding conditions on a road segment exceed the stability criteria for a vehicle, only the vehicle that loses stability is considered to be +“trapped.” The trapped evacuees in the caught vehicle are assigned to the least favorable flood zone based on all combinations of flood depth and +velocity on the road segment occurring during the simulation period and the stability criteria for their evacuation mode. + +The default functions in LifeSim for low and high clearance vehicle stability are shown in . For more +information on how the defaults were selected, +see Appendix G. + + + DV (m2/s) + , + rowSpan: 1, + colSpan: 1 + } + ], + [ + { value: "1.5", rowSpan: 1, colSpan: 1 }, + { value: "6", rowSpan: 1, colSpan: 1 }, + { value: "1.3", rowSpan: 1, colSpan: 1 } + ], + [ + { value: "0.3", rowSpan: 1, colSpan: 1 }, + { value: "3", rowSpan: 1, colSpan: 1 }, + { value: "0.3", rowSpan: 1, colSpan: 1 } + ], + [ + { value: "1.2", rowSpan: 1, colSpan: 1 }, + { value: "4.5", rowSpan: 1, colSpan: 1 }, + { value: "0.8", rowSpan: 1, colSpan: 1 } + ], + [ + { value: "2", rowSpan: 1, colSpan: 1 }, + { value: "6", rowSpan: 1, colSpan: 1 }, + { value: "2.4", rowSpan: 1, colSpan: 1 } + ], + [ + { value: "0.5", rowSpan: 1, colSpan: 1 }, + { value: "3", rowSpan: 1, colSpan: 1 }, + { value: "0.6", rowSpan: 1, colSpan: 1 } + ], + [ + { value: "1.5", rowSpan: 1, colSpan: 1 }, + { value: "6", rowSpan: 1, colSpan: 1 }, + { value: "1.2", rowSpan: 1, colSpan: 1 } + ] + ] + } + alt="Default vehicle stability criteria in LifeSim for low and high clearance vehicles." + caption="Default vehicle stability criteria in LifeSim for low and high clearance vehicles." + colWidths={[20, 14, 14, 14, 14, 14, 14]} + widthMode="intrinsic" +/> + +### Evacuation Parameters Defined by Alternative + +In LifeSim, some evacuation parameters are specified by the alternative model component. describes the various +evacuation parameters, potential ranges for each, and the impact they have on the model outcome. + + + +#### Pedestrian Speed + +Pedestrian speed is set to 4 mph by default. The Manual on Uniform Traffic Control Devices (MUTCD) for Streets and Highways suggests an average, +casual walking speed of 3.5 ft/s (2.4 mph) but states that other factors should be considered. Walking speed can vary greatly based on such factors +as: physical ability, motivation, carrying load, distance traveled, and terrain. For example, elderly or young people would have a slower walking +speed. However, in an emergency situation, it is anticipated that many walking speeds would increase. In reality, there is a wide variability from +group to group. A jogging speed is considered in the range of 4 to 6 mph (Healthline, 2018) , likely +too fast to continue for a + distance or while carrying anything. Thus, 4 mph is a reasonable assumption representing a brisk walking speed for an adult applied as an average for +the population (U.S. Department of Health and Human Service, 2008) . + +#### Fraction in Cars vs SUVs and Trucks + +This parameter defines the percentage of people that will be evacuating by cars (low clearance vehicle) versus evacuating in SUVs or trucks (high +clearance vehicles). The default for vehicle type is split: half evacuate by car, the other half by SUV or truck. This parameter can be modified by +the user. It is understood that in urban areas, a higher volume and percentage of passenger cars would be expected, while in areas that are more +rural, mountainous, and less densely populated, a higher percentage of SUVs and trucks would be evacuating. The difference between high and low +clearance vehicles is only in their decision to enter flooded roads – the occupant capacity is not considered. Changes to the parameter are only +impactful to model results when many vehicles are driving through flooded roads. + +#### Fraction Who Re-Route in Jam + +Jam re-route percent is set to a default of 80%. The jam re-route has a range of 0-100 and stands for the fraction of people who will look for faster +routes to any destination when confronted with a traffic jam. The percentage is typically dependent on the population’s knowledge of the road network +and available alternate pathways to the same destination. If they find the route they are on is the fastest route, they will stay there. The default +is not 100% because some people may find themselves in a traffic jam and wait it out. People are more likely than not to consider alternate routes, +especially with real-time traffic applications on mobile devices. + +#### Vehicle Look-Forward Distance + +One of the parameters in LifeSim is the vehicle look-forward distance; at each time step in the model, the vehicle casts forward a certain distance to + determine the density ahead of them for a roadway segment. The calculated density is used to determine the vehicular speed for the time step. + +#### Effective Vehicle Length + +The effective vehicle length represents the average length of a vehicle plus a small buffer to account for the space between vehicles in stopped +conditions (e.g., a stoplight) (NEITE Technical Committee) . The effective vehicle length is commonly 20-25 ft long. The effective vehicle +length parameter is used when vehicular spillback is enabled to determine if a road segment has exceeded physical capacity. For example, if a road +segment is 100 ft long and has 6 vehicles on it with an effective vehicle length of 20 ft, then one of those vehicles will need to be moved back in the +queue. More information on the queue correction process can be found in +Section Preprocessing the Road Network. + +#### Non-Evacuation Depth + +The non-evacuation depth is the depth at the structure where an evacuating group will no longer choose to leave the structure. The default value +is 2 ft. During a simulation, prior to an evacuating group taking protective action, the depth is calculated to determine if the non-evacuation depth +threshold is exceeded. If the depth at the time of mobilization exceeds the non-evacuation depth, then the evacuating group will not leave their +structure and will evacuate vertically. + +#### Evacuation Time Step + +Within an evacuation time step, each group that has not and can mobilize since the last time step is loaded onto the road network. All evacuating groups +speeds' are calculated, their movement is predicted, and if vehicular spillback is enabled, their final positions are corrected. The longer the +evacuation time step, the farther evacuating groups will be able to move without the model recalculating speeds and positions. Note that with a larger +time step, the model will not capture traffic density conditions and interactions as well as using a smaller time step. The drawback to using a +smaller evacuation time step is increased computation time. + +#### Live Traffic Update Interval + +During a LifeSim simulation, if an evacuating vehicle reaches a traffic jam and attempts to re-route, they will find the fastest route given the +current traffic loads on the system. The live traffic update interval determines the maximum amount of delay for updating current traffic conditions. +During an evacuation, drivers would likely have information +from Google Maps, Waze, or +other apps that provide drivers real-time traveler information. + +### Willingness to Enter Flooded Roads + +Anecdotal evidence and research suggests that many people are willing to drive through flooded roads. In many flood scenarios, vehicles washed off the +road are a significant portion of fatalities. The decision-making process to enter a flooded road is complicated and not well understood. In LifeSim, +the maximum depth at which each individual vehicle is willing to ford a road is known as the “fording depth” and is assigned based on a probability +density function known as the “willingness to enter flooded roads” function. + +For each LifeSim iteration, a vehicle is assigned a random number from 0.0 to 1.0. During an evacuation, that vehicle samples either the high or +low-clearance willingness to enter function based on the vehicle type. The corresponding depth defines the fording depth for that single vehicle +through the simulated iteration. Each iteration will sample a new random variable for each vehicle. The range of possible fording depths will cover +some of the uncertainty from neglecting all other factors. If the vehicle encounters a flooded road with depth greater than that vehicle’s fording +depth, it will attempt to turn around. If a one-way or flooded road is also blocking the road behind the vehicle, it may become stuck in that location +and subject to the maximum hydraulic conditions. + +The body of research and resulting statistics used to inform and develop the willingness to enter functions are summarized +in . A more detailed summary of the previous research efforts and how they were used to develop the default +functions in LifeSim is given +in Appendix G. + + + Gissing et al., 2016 + , + rowSpan: 3, + colSpan: 1 + }, + null, + null, + { + value: + <> + Drobot et al., 2007 + , + rowSpan: 2, + colSpan: 1 + }, + null, + { + value: + <> + Pearson and Hamilton, 2014 ; Hamilton, Peden et al., 2016 + , + rowSpan: 2, + colSpan: 1 + }, + null + ] + ] + } + alt="Driver's willingness to enter flooded roads." + caption="Driver's willingness to enter flooded roads." + colWidths={[30, 18, 18, 30]} + widthMode="intrinsic" +/> + +The default willingness to enter functions in LifeSim for low and high-clearance vehicles use a truncated normal distribution. Default parameters +based on existing research are defined in . + + + +The functions are editable through the LifeSim *Alternatives* dialog +box, Evacuation Parameters tab, +where the user has the option to see the function +defining willingness to enter and change the probability distribution () for both low and high clearance vehicles. + +
    + +The lower cut off (truncation) of both tails is known as the “puddle depth,” which defines the minimum possible fording depth for all vehicles using +the function. If a vehicle encounters a flooded road below the puddle depth, it can and will ford the road safely. + +Modifications to the default functions could be made by a user with a better understanding of the key factors identified in these studies. Driving a +taller versus smaller vehicle is already considered by the two available functions and the ability to alter the proportion of each. Other factors +indicating higher likelihood to enter a flooded road can be found +in Appendix G. + +## General Modeling Guidelines + +The user should consider the following when populating the model with road networks, destination data, and evacuation parameters: + +- Error checking of public data sources. Road network shape information may have been attributed incorrectly or have issues with connectivity. +- Considerations for one-way roads and on-ramps. +- Considerations for bridges and underpasses. Vertical offsets are critical to ensuring proper traffic flow over bridges and raised roadways that would +not be impacted by flood waters. +- Vehicle stacking distance. + - Road segments may need to be extended beyond the flooded area to allow for traffic to build up. Cars arriving at a destination leave the simulation, +which may not be realistic – especially where services do not exist just beyond the flood zone and vehicles will continue down the road to find them. +The backup created by this situation may extend into the flooded area impacting later vehicles' ability to evacuate the hazard. + - For conditions where two freeways merge into one, representing a significant traffic bottleneck, the user would want to extend the roads to after the +freeways merge and put a single destination on the merged freeway. +- Smaller evacuation time steps yield more accurate results but also adds burden to the memory and computation time. +- In terms of codifying road segments, many different roadways and separation types exist, making vehicles in the network respond differently. For +example, a vehicle traveling in one direction on a two-lane, two-way road where the directions of travel are separated is considered a one-way road where +vehicles are not able to turn around if confronted with water and traffic congestion. If the same roadway were coded with a traversable median (i.e., +roads with no significant physical barriers between lanes) and if two-way links were coded, cars would be able to turn around. + + \ No newline at end of file diff --git a/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/08-agricultural-inventory.mdx b/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/08-agricultural-inventory.mdx new file mode 100644 index 000000000..f92b5a114 --- /dev/null +++ b/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/08-agricultural-inventory.mdx @@ -0,0 +1,207 @@ +--- +title: "Agricultural Inventory" +--- + +import Link from "@docusaurus/Link"; +import addBaseUrl from "@docusaurus/useBaseUrl"; +import Citation from "@site/src/components/Citation"; +import CitationFootnote from "@site/src/components/CitationFootnote"; +import Equation from '@site/src/components/Equation'; +import EquationNoRef from '@site/src/components/EquationNoRef'; +import EquationReference from '@site/src/components/EquationReference'; +import Figure from "@site/src/components/Figure"; +import FigureInline from "@site/src/components/FigureInline"; +import FigReference from "@site/src/components/FigureReference"; +import NavContainer from "@site/src/components/NavContainer"; +import ProcessList from "@site/src/components/ProcessList"; +import TableReference from "@site/src/components/TableReference"; +import TableVertical from "@site/src/components/TableVertical"; +import VersionSelector from "@site/src/components/VersionSelector"; + + + +# Agricultural Inventory + +## Chapter Overview + +When flooding occurs in agricultural areas, damage to existing crops and interruptions to the planting, growing, and harvesting of crops results in +economic impacts. LifeSim can be used to compute the economic impacts of flooding these types of areas. The computational procedure and input sources +for calculating agricultural damages have been defined in +the HEC-FIA Technical Reference Manual (USACE, 2026) . Computations +of agricultural flood +damage require a number of different inputs. + +Specifically, five inputs are required: + + + Hydraulic data: if summary grids are used, then a duration grid and agricultural arrival grid are required. + + ), + }, + { // STEP 2 + title: ( + <> + National Agricultural Statistics Service Data + + ), + }, + { // STEP 3 + title: ( + <> + Crop Budgets + + ), + }, + { // STEP 4 + title: ( + <> + Crop Values + + ), + }, + { // STEP 5 + title: ( + <> + Duration-Damage Relationships + + ), + } + ]} +/> + +The hydraulic data required to compute agricultural flood damages was discussed previously. The remaining four required inputs are described in the +sections below. + +## National Agricultural Statistics Service Data + +The National Agricultural Statistics Service (NASS) Cropland Data Layer is a product that represents the type of crop and the geographic location of +crops throughout the entire United States. NASS provides the Cropland Data Layer in GeoTiff format, where each cell represents a crop type. LifeSim +can import this data directly from the NASS API to streamline the collection of the type and distribution of crops in the study area. +The **Import Agriculture Data From NASS** option is shown in . + +
    + +Alternatively, to **Import Agriculture Data From File**, the user can go +to the NASS CroplandCROS website to download, research, +and pre-process NASS Cropland Data. + +LifeSim allows the user to import an existing crop data GeoTiff file into LifeSim. The distribution of each agricultural category in the study +area is used in combination with the planting, harvesting, and crop loss relationship inputs (described below) in the calculation of agricultural +flood damages. + +## Crop Budget Data + +Costs required to produce crops are necessary for the economic loss computations for agricultural areas. +The Crop Editor in LifeSim is used to +define the cost of planting each crop type. Monthly crop planting costs in LifeSim can be either fixed or variable. The crop planting cost input data +required for the economic loss computations is available from local Cooperative Extension System Offices, which can be found on the U.S. Department of +Agriculture's website. + +The final components of the crop planting data required are the dates of the first possible and last possible plantings. This data is used to create a + function that represents the total value of the inputs in the field at any point in the year, which is converted to a percentage of the maximum total + value of the inputs in the field to calculate the percentage damageable at any point in the year. + +The maximum total value input into the field is not necessarily equivalent to the value achieved at market for the crops pulled from the field for two + reasons. First, the harvest cost and shipping costs need to be added to all of the inputs to get the full cost to produce the crops. Second, the +value of the crop may be less than the cost to produce it. LifeSim uses a proration of the total value input less the harvest costs as a proxy for an +exposed value. + +## Crop Value Data + +Crop characteristics are necessary for LifeSim to compute the appropriate reduction in crop value due to the costs associated with harvesting. The +required input characteristics are harvest date, harvest cost, yield, unit price, and percentage of total crop value lost due to late planting. The +values for each of these parameters are defined in the Crop Editor. + +### Crop Loss Relationships + +Crop loss relationships are required for LifeSim to calculate the agricultural flood damages. Crop loss relationships in LifeSim define the percentage + of crop loss based on the number of days (i.e., duration) crops are inundated each month. + +## Computational Procedure + +This section details the computational procedures used by LifeSim to calculate agriculture flood damages at a single crop cell. The procedures assume +inundation durations throughout the project area are known and have already been input to the model. Additionally, the procedures assume that crops +are planted at the first available date after flooding and that crops will be planted immediately before an event (meaning that weather forecasting is + not considered). The computational procedures are detailed below. + + + Determine what type of crop the cell represents. + + ), + }, + { // STEP 2 + title: ( + <> + Determine the arrival of flooding for the crop cell. + + ), + }, + { // STEP 3 + title: ( + <> + Determine the duration of flooding for the crop cell. + + ), + }, + { // STEP 4 + title: ( + <> + Based on the arrival time and duration, determine if planting dates are impacted or if the crop is damaged before harvest. + + ), + }, + { // STEP 5 + title: ( + <> + If damaged during the growing season, determine if the duration is longer than the longest duration damage curve; if so, the + farmer lost all value placed in the field so far. The loss is equivalent to the marketable value minus harvest costs, prorated by + total value input to the field. + + ), + }, + { // STEP 6 + title: ( + <> + If flooding limited the ability to plant and the farmer was unable to plant the preferred crop, use the secondary crop, and the loss + will be the total marketable value for the secondary crop less harvest costs minus the total marketable value for the primary crop less harvest costs. + + ), + }, + { // STEP 7 + title: ( + <> + If the flooding made the farmer plant later than the first day of the season for the primary crop but the farmer was able to plant the primary crop, + the damages are based on a reduction in full yield due to late planting. This is equivalent to total marketable value less harvest cost times 1% + loss due to late planting. + + ), + }, + { // STEP 8 + title: ( + <> + Calculate the loss for each crop cell in the inundated area using the process described above and output the crop type, location, duration, and total + damage for each crop cell damaged. + + ), + } + ]} +/> + + \ No newline at end of file diff --git a/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/09-indirect-damages-with-ecam.mdx b/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/09-indirect-damages-with-ecam.mdx new file mode 100644 index 000000000..c5c74e4aa --- /dev/null +++ b/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/09-indirect-damages-with-ecam.mdx @@ -0,0 +1,93 @@ +--- +title: "Indirect Damages with ECAM" +--- + +import Link from "@docusaurus/Link"; +import addBaseUrl from "@docusaurus/useBaseUrl"; +import Citation from "@site/src/components/Citation"; +import CitationFootnote from "@site/src/components/CitationFootnote"; +import Equation from '@site/src/components/Equation'; +import EquationNoRef from '@site/src/components/EquationNoRef'; +import EquationReference from '@site/src/components/EquationReference'; +import Figure from "@site/src/components/Figure"; +import FigureInline from "@site/src/components/FigureInline"; +import FigReference from "@site/src/components/FigureReference"; +import NavContainer from "@site/src/components/NavContainer"; +import ProcessList from "@site/src/components/ProcessList"; +import TableReference from "@site/src/components/TableReference"; +import TableVertical from "@site/src/components/TableVertical"; +import VersionSelector from "@site/src/components/VersionSelector"; + + + +# Indirect Damages with ECAM + +## Chapter Overview + +The computational procedure and input sources for calculating indirect damages have been defined in +the HEC-FIA Technical Reference Manual (USACE, 2026) . Economic +Consequences Assessment Model (ECAM) is a computable general equilibrium model with separate datasets for each county in the United +States and is used to compute indirect economic impacts. The model computes each county’s ability to respond to external economic shocks. ECAM +requires: + + + Total capital (a summation of the structure and content values for all commercial, public, and industrial structure types) + + ), + }, + { // STEP 2 + title: ( + <> + Total labor (a summation of the daytime populations for all commercial, public, and industrial structure types) + + ), + }, + ]} +/> + +Capital losses resulting from a flood event make it more difficult (but not impossible) to produce business output. Labor losses occur when people are + displaced from the impact area, preventing them from reporting to their jobs as they would under typical circumstances. Like capital losses, labor +losses reduce the quantity and efficiency of production. Total capital and labor values can be either manually entered or imported. + +ECAM also requires users to enter the flood duration, the reconstruction period duration, and the cleanup period duration. The flood duration depends +on how quickly the flood waters recede. This data can usually be obtained from a hydraulic model. Currently, the user must provide a single value for +the entire flooded area, so thought and judgment must be given to the definition of this duration time. The reconstruction and cleanup period +durations largely depend on the types of structures located in the flooded area. This information is entered into LifeSim in the *ECAM Data Importer*, +as shown in . + +
    + +## Computational Procedure + +This section details how the capital and labor losses are calculated using the ECAM component within LifeSim. Within the calculations, the direct +damages and life loss – computed as discussed +in Chapter Computational Procedure – are utilized to evaluate the losses of capital and labor as a ratio of the overall +available capital and labor by sector. After labor losses and capital losses are calculated, they are submitted to the ECAM module as inputs. ECAM then +computes indirect losses. Specific details on calculating capital and labor losses can be found in +Section Indirect Economic Damage. + +To convert the capital loss ratio (CLr) and labor loss ratio (LLr) into a reduction in economic output, the ECAM system model +requires information about the specific nature of the economy being analyzed. The ECAM system model determines whether the economy in question is +capital or labor intensive, and what the rate of exchange is between labor and capital. Each county has a unique dataset that is used to define the +specific economic characteristics assessed in the ECAM system model. + +Statistics for production, employment, income and all other economic indicators are based upon the IMPLAN (IMpact analysis for PLANning) dataset, +unless otherwise indicated. Each of these datasets can distinguish up to 440 separate production activities, ten household types, and four levels of +government. The dataset used for evaluating indirect economics with ECAM and LifeSim has been aggregated from the full 440 sectors to 30 sectors. +Additional information on the IMPLAN dataset is available from IMPLAN Group, LLC. Additional information on the ECAM system model can be found in +Lehman, et al. (2013) . + + \ No newline at end of file diff --git a/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/10-fatality-rates.mdx b/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/10-fatality-rates.mdx new file mode 100644 index 000000000..e618b4489 --- /dev/null +++ b/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/10-fatality-rates.mdx @@ -0,0 +1,211 @@ +--- +title: "Fatality Rates" +--- + +import Link from "@docusaurus/Link"; +import addBaseUrl from "@docusaurus/useBaseUrl"; +import Citation from "@site/src/components/Citation"; +import CitationFootnote from "@site/src/components/CitationFootnote"; +import Equation from '@site/src/components/Equation'; +import EquationNoRef from '@site/src/components/EquationNoRef'; +import EquationReference from '@site/src/components/EquationReference'; +import Figure from "@site/src/components/Figure"; +import FigureInline from "@site/src/components/FigureInline"; +import FigReference from "@site/src/components/FigureReference"; +import NavContainer from "@site/src/components/NavContainer"; +import ProcessList from "@site/src/components/ProcessList"; +import TableReference from "@site/src/components/TableReference"; +import TableVertical from "@site/src/components/TableVertical"; +import VersionSelector from "@site/src/components/VersionSelector"; + + + +# Fatality Rates + +## Chapter Overview + +A fatality rate function is used to determine how many people will succumb to high or low hazard flood conditions. A fatality rate is sampled for each +group, then each individual in the group samples from the same chance of survival (more discussion +in Section Life Loss). For example, an evacuation group +of three people is caught in high hazard conditions. The group samples a 75% chance of fatality from the function. Then, each individual randomly +samples a number (0-100%) which lands above or below the fatality rate. If the randomly sampled value falls above, then the person survives. This +example results in 2 fatalities and 1 survival on average but could result in all surviving or all losing their lives. The functions used in LifeSim +are the product of an extensive research and cataloging of historic flood events. + +This chapter discusses how LifeSim uses high hazard and low hazard fatality rate functions to calculate direct fatalities. With any flood event, there + exists the potential for indirect life loss, which is not currently included within LifeSim calculations. Indirect life loss occurs when the unsafe +or unhealthy conditions present during any phase of the flood contribute to a death. This includes mortality from causes such as but not limited to +stress-induced medical conditions (e.g., heart attack, suicide, etc.), water-borne sicknesses and infections, exposure, and lack of medical attention +for treatable conditions. Previous studies of indirect life loss have estimated that up to 50% of fatalities that occur during a flood event +are indirect in nature. USACE is currently developing a method to estimate indirect life loss that is compatible with LifeSim based on parameters such + as number of evacuees and population health. + +## Development of Fatality Rate Functions + +Unlike large-scale empirical approaches to estimating life loss, LifeSim focuses the estimate of potential loss of life at the individual or small +group level. By explicitly simulating the evacuation process, LifeSim determines the location of all exposed agents, which are those people or groups +of people that haven’t reached safety when the flood arrives. The exposed population can be in structures, vehicles, or on foot. The cause of the +flood (dam failure, levee failure, hurricane, flash flood) is not relevant to the hydraulic characteristics at the agent location and the shelter +provided by the structure or vehicle in which they are located. + +After estimating the location, shelter, and hydraulic conditions for each agent in the simulation, the hazard zone for that agent must be identified. +LifeSim characterizes each agent as either being in high hazard or low hazard conditions as described below: + +- High hazard refers to those conditions where the stability criteria or submergence criteria of the person, the vehicle (if caught while evacuation in +car or SUV), or the structure (if not mobilized) has been exceeded. In that situation, the victims are typically swept downstream, buried in a +collapsed building, or trapped underwater, and survival depends largely on chance. +- Low hazard refers to those conditions where the person or group of people are exposed to relatively calm floodwaters, where their stability or the +stability of their shelter is not at risk. A hazard exists due to the potential for bad things to happen when people come in contact with water in +locations not meant for such an interaction. + +Once a hazard condition has been identified, the final step is applying a fatality rate that represents the likelihood of someone in those conditions +dying. This is an important, necessary step in the LifeSim simulation that accounts for the basic concept that people can – and often do – survive +conditions that would generally be considered un-survivable. Likewise, people can – but rarely do – die in conditions where they would be expected to +survive. + +### Development of Flood Fatality Database + +A historic flood fatality database was developed for *LIFESim*, the life loss estimation program precursor to LifeSim +(McClelland and Bowles, 2002) . The +database is categorized by hazard zone based on shelter and hydraulic conditions. This database stores fatality rates at a population group +resolution, meaning a single event can have multiple fatality rates. The three hazard zones were defined as chance, compromised, and safe. New cases have +occurred since the development of the fatality rate database. The LifeSim 2.0 development team set out to update and refine the database. When +examining historic data, the team found it difficult to clearly identify the compromised zone. One reason is that detailed accounts are easy to +classify into chance or safe zones, which is reflected in the data. The team reconfigured available information and developed two new zones: low and +high hazard. With the new zone definitions, smaller distinct groups were identified to better support an agent-based approach. New case studies +informed low and high hazard functions. The team also identified many data points that were not included in the original database but could be used to + expand it. This was an important step to maintain a significant sample size because any point that could not be verified was removed from the final +function. + +Fatality rates are categorized by population group to ensure that the hazard conditions are consistent for that group, i.e., all passengers in a car, +or all occupants of the same building, or traveling together. This level of granularity was harder to find for older events, leaving many of them to be + excluded from the new functions. A more rigid definition of group size and hazard classification makes the functions more appropriate for agent-based + modeling as used in LifeSim. + +Each population group is given a hazard classification (low or high) based on whether their stability or the stability of their structure or vehicle +was lost or they were submerged. Indirect fatalities were removed from the analysis. To calculate a fatality rate, each group in the database must +include enough information to determine the number of people who died and survived, as well as the severity of the flood conditions they were exposed +to. Most of these stories were recorded in newspapers, books, social media, and academic articles. Occasionally, the flood conditions were assumed +based on the results of modeling or other flood data points and information about the group's location. + +### Presentation of Functions + +The high hazard function contains 139 points, shown in . The high hazard function still exhibits some +availability bias in the plateaus around 1/3, 1/2, and 2/3. These represent the abundance of groups with 2 and 3 people in the dataset. It is not +clear from research, but that may also reflect the circumstances most people would find themselves in (small groups). Therefore, the function remains +as-is until more information is available. Typical points include people who were in buildings that flooded or collapsed, or vehicles that washed off +the road (fatality rate database in draft, 2019). + +Anecdotal evidence suggests many people who find themselves in low hazard circumstances are never reported because they survive. Capturing the zero +fatality rate cases is especially important for low hazard classification because there are so many people that survive. + +To overcome the lack of zeroes in the documented low hazard data, historic events were modeled in LifeSim to estimate the population that was exposed +to low hazard conditions. Case studies included the 2015 Kinugawa River levee breach, Hurricane Harvey, and Hurricane Katrina (data on New Orleans East Bowl only). The +LifeSim results provided estimates of the total number of evacuating groups that were exposed to low hazard conditions. + provides the simulated low hazard group estimates from LifeSim. Summing the average estimate for groups +in low hazard conditions results in 311,152 total population groups exposed to low hazard conditions. These results do not account for rescue +operations which would reduce the estimate further. No sources could be determined for accurate estimates of people rescued from low hazard +conditions. + +
    + + + Kinugawa Levee + , + rowSpan: 1, + colSpan: 1 + }, + { + value: + <> + New Orleans East Bowl + , + rowSpan: 1, + colSpan: 1 + }, + { value: "Hurricane Harvey (Houston Area)", rowSpan: 1, colSpan: 1 } + ], + [ + { value: "3,190", rowSpan: 1, colSpan: 1 }, + { value: "2,631", rowSpan: 1, colSpan: 1 }, + { value: "303,866", rowSpan: 1, colSpan: 1 } + ], + [ + { value: "3,266", rowSpan: 1, colSpan: 1 }, + { value: "3,121", rowSpan: 1, colSpan: 1 }, + { value: "304,108", rowSpan: 1, colSpan: 1 } + ], + [ + { value: "3,304", rowSpan: 1, colSpan: 1 }, + { value: "3,642", rowSpan: 1, colSpan: 1 }, + { value: "304,206", rowSpan: 1, colSpan: 1 } + ], + [ + { value: "3,308", rowSpan: 1, colSpan: 1 }, + { value: "3,666", rowSpan: 1, colSpan: 1 }, + { value: "304,223", rowSpan: 1, colSpan: 1 } + ], + [ + { value: "3,334", rowSpan: 1, colSpan: 1 }, + { value: "4,119", rowSpan: 1, colSpan: 1 }, + { value: "304,302", rowSpan: 1, colSpan: 1 } + ], + [ + { value: "3,485", rowSpan: 1, colSpan: 1 }, + { value: "4,734", rowSpan: 1, colSpan: 1 }, + { value: "304,524", rowSpan: 1, colSpan: 1 } + ] + ] + } + alt="Simulated estimated number of population groups in low hazard conditions for historic events." + caption="Simulated estimated number of population groups in low hazard conditions for historic events." + colWidths={[30, "auto"]} +/> + +Hurricane Harvey had more estimated to be exposed to low hazard conditions primarily due to the large population at risk, a shelter-in-place order, +and widespread shallow flooding. Documented cases of low hazard fatalities were included for each case history to ensure a representative dataset. The + resulting function is mostly zero data points making the low hazard zone only a significant contributor to overall life loss when very large +populations are found in low hazard circumstances. shows the low hazard fatality rate function zoomed into the +region with higher fatality rates. + +Typical low hazard fatalities include people who evacuated (or “fled”) through shallow water in their cars or on foot, people who were in +partially-flooded structures and experienced an unfortunate circumstance (e.g., slipped, electrocuted through water), and people who willingly entered the +flooded area to retrieve belongings or rescue others. + +
    + + \ No newline at end of file diff --git a/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/11-computational-procedure.mdx b/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/11-computational-procedure.mdx new file mode 100644 index 000000000..3a12288e2 --- /dev/null +++ b/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/11-computational-procedure.mdx @@ -0,0 +1,799 @@ +--- +title: "Computational Procedure" +--- + +import Link from "@docusaurus/Link"; +import addBaseUrl from "@docusaurus/useBaseUrl"; +import Citation from "@site/src/components/Citation"; +import CitationFootnote from "@site/src/components/CitationFootnote"; +import Equation from '@site/src/components/Equation'; +import EquationNoRef from '@site/src/components/EquationNoRef'; +import EquationReference from '@site/src/components/EquationReference'; +import Figure from "@site/src/components/Figure"; +import FigureInline from "@site/src/components/FigureInline"; +import FigReference from "@site/src/components/FigureReference"; +import NavContainer from "@site/src/components/NavContainer"; +import ProcessList from "@site/src/components/ProcessList"; +import TableReference from "@site/src/components/TableReference"; +import TableVertical from "@site/src/components/TableVertical"; +import VersionSelector from "@site/src/components/VersionSelector"; + + + +# Computational Procedure + +## Chapter Overview + +Once all input data has been specified, the user must define the number of iterations and times of day when the hazard will occur. Note that the time +of day selected is the time of hazard occurrence, not the time of warning. All computations are relative to the hazard occurrence. + +The computation process is the same for each alternative in LifeSim. The program will: + + + Calculate agricultural damages if they are included as part of the simulation. + + ), + }, + { // STEP 2 + title: ( + <> + Prepare alternative data. + + ), + }, + { // STEP 3 + title: ( + <> + Run simulation for the user-defined number of iterations for each hazard occurrence time selected. + + ), + child: [ + { + title: ( + <> + Redistribute the population based on first alert received and mobilization methods. + + ), + }, + { + title: ( + <> + If included, calculate life loss of exposed population. + + ), + }, + { + title: ( + <> + Calculate direct economic damages if included as part of the simulation. + + ), + }, + ], + }, + { // STEP 4 + title: ( + <> + The average life loss over all iterations is used to determine average labor loss and capital loss for indirect economic damages. + + ), + }, + ]} +/> + +This chapter defines a LifeSim simulation from initiation to the final state of evacuees (clear, no hazard, or low/high hazard). This chapter also +discusses how the input data are prepared for each alternative and how the population is redistributed using evacuation groups and vertical +evacuation. Agricultural damage, property damage, and ECAM are based on maximum conditions and/or duration. + +## Preprocessing - Preparation of Alternative Data + +### Preprocessing the Hydraulic Data + +Before the warning and evacuation simulation can begin, the hydraulic data is processed to define a flood time-series at each structure and road +segment. This process extracts the necessary data from the hydraulic input during the simulation process. When time-dependent hydraulic data are used +as input (all options except +Summary Grids), depth and velocity hydrographs are extracted from the hydraulic data at each structure and road. All +other necessary hydraulic parameters can be derived from those data such as arrival time, instantaneous depth times velocity, or duration of flooding. + The preprocessed hydraulic data are saved with the model and can be used for multiple simulations as long as there are no changes to the road +network, structure inventory, or hydraulic input. + +In order to conserve computational time and memory, the depth and velocity hydrographs are simplified to reduce the number of data points. +The Ramer-Douglas-Peucker algorithm is used +to reduce the hydrograph points as demonstrated in . The algorithm concentrates data points in regions of the +hydrograph with sharp changes and thins the data + points where change is minimal between points and a linear interpolation can represent the curve. LifeSim uses a default tolerance of 0.01 for +eliminating points. In , the original hydraulic data contained 6,000 data points (blue line) but was reduced to +27 points (orange) using the Ramer-Douglas-Peucker algorithm. LifeSim applies a linear interpolation between the remaining data points with very little + error introduced (black line). The strategy is particularly useful for reducing memory during long dry periods where zero depth data storage is not +needed. Fewer data points also significantly reduces simulation lookup times when comparing hydraulic data to the willingness to enter a flooded road, + for example. + +
    + +In structures, the depth is sampled from the terrain at the structure point. For roads, the midpoint of the road is used as the sampling point and the +depth is then reduced by any vertical offset. The midpoint assumption may result in problems for particularly long or steep roads +(see Section Linework). Conditions +may change along the length of road that should be represented with more detail. In this case, users should divide the road into +multiple representative segments. As demonstrated in , the Roslyndale Ave single road segment is now sampled at two locations: once +at the midpoint of the dry segment and once at the midpoint of the flooded segment. + +
    + +### Preprocessing the Road Network + +The road network is imported as GIS linework (a series of polyline segments for roads and points for destinations) and pre-processed for simulation. +LifeSim first assigns each node in the network a node identification (ID) value. Then, LifeSim identifies road segments as either one-way or two-way. +If the road is identified as two-way, the road is split into two components: one segment in one direction and another in the reverse direction, as +shown in . + +
    + +On the other hand, if the road is identified as one-way, only a single segment and direction are needed. Segments are connected based on their +coincident start point or endpoint locations in GIS. Each line segment has several properties besides the starting and ending nodes including length, +unimpaired travel time (at free-flow speed), and other attributes used to determine the fastest path to a destination. + +Destinations are related to the road network by road segments with the shortest perpendicular distance to the destination points. If a destination is +located nearest to a line segment's endpoint (side A in ), then LifeSim identifies that node as a destination. +If instead a destination is between the start and endpoint of a segment, then the segment is split so that traffic can approach the destination from +both sides. A new node is inserted where the line was broken and it becomes the destination node (side B in ). + +
    + +Now that all the road and destination connections are represented, LifeSim will find the fastest path from any node along the road network to a +destination. The optimal path (a.k.a. shortest travel time) to a destination is found using Dijkstra's shortest path algorithm with a binary heap data + structure to improve efficiency. From each node, the next node on the fastest path to a destination is stored, resulting in a table similar + to . Although several pathfinding mechanisms are available (A*, D*, and others), Dijkstra's method was +selected for its ability to quickly determine shortest paths for all nodes in the network. + +The lookup table is used to determine the fastest route to a destination from any node in the network. For example, the shortest path from +node #5 in is 5, 4, 2, 1, 0, destination. In LifeSim, the user may select to limit the destinations an +evacuee will initially consider. For example, evacuation orders may dictate to stay away from a certain area. To accommodate the categorization, a +unique table is constructed for each EPZ (where destination assignments are made). The full network graph includes all allowable destinations with the + fastest path to a destination defined for each node. + +
    + +During the simulation, the starting road network is updated with traffic density and flood information. Vehicles traveling the road network may +encounter traffic or flooding, in which case they would potentially re-route their course (more details in +Section Evacuating with Traffic Simulation). For +example, if a traffic +jam is on the segment from node 2 to 1, a re-route may select a diversion through node 3 as the fastest way to reach the destination. + +### Preprocessing the Structure Inventory + +The structure inventory includes attributes assigned to each structure. Before an evacuation iteration starts, the structure inventory must be updated +with additional information such as: + +- Structure stability criteria based on the user-defined rules. +- Which EPZ the structure is in. +- Which output polygon the structure is in (for summarizing results). +- Initial evacuation path from the structure to a destination. + +Each structure in the inventory is geographically associated to its assigned EPZ polygon, output summary polygon, and closest road segment. The EPZ +assignment allows each structure to be associated with an initial road network graph. Once the closest road to a structure is identified, the initial +path for evacuation can be defined. Each of the two nodes on the nearest road segment have a defined path to the nearest destination. The faster of +the two directions is selected based on the travel time to those nodes from the entry location on the road, plus the time from that node to the +destination. + +## Preprocessing for Each Iteration + +Each iteration is a complete simulation of the warning, evacuation, and subsequent consequences for a single event. After each iteration a sampling of +all the uncertain parameters occurs. This sampling happens at the beginning of each new iteration. The information in +Section Preprocessing - Preparation of Alternative Data above is defined +once for each alternative because it does not change with each new iteration. This is the most outer loop of the LifeSim's Monte Carlo simulation, as +shown graphically in . + +The random sampling process begins with preparing iteration seed numbers for use in a random number generator. The reason for seeding the random +number generator is to make results reproducible with the same input. Otherwise two users with identical input could have different results. Each +iteration is given a seed number that is quasi-random, unique, and reproducible. For example, if the alternative specifies 100 iterations, the model +will create 100 quasi-random seed numbers in a seed set. + +
    + +Each alternative may be repeated for different times of hazard occurrence with the same number of iterations each. The same seed set is used for each +time of day so that the i-th iteration for one time of day has the same seed as all i-th iterations for other times of day. This +allows users to compare results more directly between times of day (all else being equal) and produces a discernable pattern in the results. Note the +middle two loops of . + +Within each iteration, a random number generator is defined for sampling uncertainty and seeded with the iteration's random seed number. Then the +warning, evacuation, and consequences simulation proceeds to its end and the next iteration begins. + +The Monte Carlo simulation allows users to see the impact of uncertain parameters on the range of model results. Confidence in the results is built as +several iterations with different parameters show agreement. More discussion of the uncertainty sampling is included in +Chapter Uncertainty and Sampling Methods with an exhaustive +list of parameters sampled during each iteration. + +Note that this process is not testing for convergence on some parameter, but merely a user-defined number of iterations which provides output as a +distribution of results. The number of iterations specified is important. It is up to the user to determine if enough iterations are computed to reach +convergence of results. The user must balance the increased run time from each additional iteration with the accuracy and confidence gained in the +results. + +### Warning Function Sampling + +The warning notification and timing functions are unique for each EPZ. With each iteration, different values for the warning delays are sampled +(imminent hazard identification, hazard communication delay, warning issuance delay, first alert diffusion delay, PAI delay). The sampled imminent +hazard identification, hazard communication delay, and warning issuance delay have one value per EPZ defining the time it takes from discovery of a +hazard to when an evacuation warning is first released to the public. The below equation is used to calculate when warning is first issued for each +EPZ. + + + +where: + +> _WIEPZ_ = Warning Issuance Time at specified EPZ.
    +> _HO_ = Hazard Occurrence Time.
    +> _IHEPZ_ = Imminent Hazard Identification Time for specified EPZ.
    +> _CDEPZ_ = Communication Delay of imminent hazard to EPZ personnel.
    +> _IDEPZ_ = Issuance Delay of warning to the public at specified EPZ. + +The first alert diffusion delay and PAI delay data are sampled using curve sampling techniques to produce population delay functions for each EPZ. The +sampled first alert and PAI functions refer to a percentage of the population warned (or mobilized) over time. Since LifeSim is an agent-based model, +the population characteristics must be distributed down to the agent level as described in +Section Evacuating Groups and Their Attributes. + +### Population in Structures + +The population represented within a LifeSim structure inventory is dynamic, representing typical movement of people throughout the day and night such +as attending school or frequenting a business and returning home in the evening. The structure inventory has populations defined for daytime and +nighttime that consider these diurnal shifts. However, LifeSim needs to track the population at any time because the exact time of a flood hazard and +warning can have uncertainty. LifeSim does this by defining periods of daytime, nighttime, and transitional periods. + +During the transitional periods, the population is interpolated between the imported daytime and nighttime populations. Transitional periods are from 4 + am to 10 am and 5 pm to midnight. Examples in and are for two different + types of structures with a representative population of 100. In a typical residential structure (), the +population is higher at night and lower during the day with transitions during the morning and late afternoon. By contrast, a typical commercial or +public building might have a higher daytime population and lower nighttime population (). + +
    +
    +
    +
    + +It is most appropriate to select the population based on when the warning is first released to the public because that is when people begin to react +to the flood. Initial population distribution is interpolated at each structure using the sampled warning issuance time for each EPZ. For example, if +the hazard occurrence is set to occur at 2 am and the warning is issued 8 hours prior to the hazard occurrence at 6 pm, then LifeSim will use the +interpolated population at 6 pm. Since each EPZ's warning issuance time can be unique, they may all use different population snapshot times. + +Each EPZ uses its own warning issuance time to define the population. However, population shifts between EPZs are not tracked in LifeSim. For example: +if someone has evacuated from one EPZ and travels to another (i.e., a person gets a warning at work in one EPZ but lives in another EPZ that is not +warned until later). Also, the diffusion of the first alert may take several hours. In which case, people who have not been warned may continue with +their day as normal and change locations. These people are included at their first location and not tracked to a new location having different warning + and evacuation parameters. Likewise, there is no accounting for commute time. Everyone must be inside a structure to start the simulation. + +Four factors that define the warning issuance time in LifeSim are: + + + Time of the hazard occurrence + + ), + }, + { // STEP 2 + title: ( + <> + Imminent hazard identification time + + ), + }, + { // STEP 3 + title: ( + <> + Hazard communication delay + + ), + }, + { // STEP 4 + title: ( + <> + Warning issuance delay + + ), + }, + ]} +/> + +### Evacuating Groups and Their Attributes + +With the starting population known, it can be broken up into evacuating groups. An evacuating group travels together regardless of mode of +transportation (vehicle or pedestrian). The user specified the number of people in each evacuating group by occupancy type (see +Section Evacuating Group Size). +Groups are partitioned from among the building's population by group size with any remainder comprising the last group. Evacuating groups may be less +than the group size, but not larger. + +An evacuating group stores information such as: + +- The number of individuals in the group. +- The structure they started in. +- Availability of roof/attic access. +- Time of first alert. +- Time of mobilization (PAI, if applicable). +- Evacuation mode: in a vehicle or on foot. +- If in a vehicle, vehicle type (high or low clearance). +- Sampled stability function for defined mode of transportation. +- Depth of flooding they are willing to enter (fording depth). +- If reaching a traffic jam, whether or not they will turn around. +- The evacuation route they are on. +- Where they are on the evacuation route. +- Current speed on the evacuation route. +- Memory of flooded roads encountered during evacuation. +- If they reach their destination. +- If they get caught while evacuating. + +Each evacuating group samples from the first alert and PAI delay functions for that group's emergency planning zone to determine when the group +receives a warning and when they take protective action. Using the sampled first alert and PAI functions for each EPZ along with the evacuation +parameters defined at the occupancy type +(Section Evacuation Parameters Defined by Structure Occupancy Type), every +group is randomly assigned a time of first alert and time of PAI (). The functions represent a fraction of population over time. By +sampling with many structures and +evacuating groups over the whole EPZ, the sampled population warned (or mobilized) over time approximates the first alert diffusion function (or PAI +function). These parameters may be sampled per evacuating group or per structure depending on whether they are warned and mobilized together. + +
    + +### Attributes assigned to individuals + +Most operations during the evacuation simulation are done at the evacuating group level, but individuals show independence in LifeSim especially +during vertical evacuation and when calculating their survival in hazardous conditions. + +An individual is defined by their: +- Mobility (limited or able-bodied) +- Highest position attained in a flooded structure (roof, attic, or top floor) +- Ability to swim + +Each person within the population has either limited mobility or is able-bodied and can swim or cannot. Based on their mobility, they have a chance of +reaching higher levels than the top floor of the structure during vertical evacuation. + +### Parameter Sampling for Structures + +A number of parameters are re-sampled for each iteration and assigned to individual structures. Two general categories of parameters are sampled: +those related to consequence calculations and those related to warning and evacuation. + +The sampled consequence related parameters include: + +- Foundation height +- Depth-damage function +- Property values (including structure, contents, vehicles, and other) +- Structure submergence criteria +- Structure stability function + +All of the listed parameters are defined by occupancy type except structure stability. Structure stability criteria are sampled per structure. If two +structures have the same stability criteria assigned, they could have different sampled stability thresholds depending on if uncertainty was defined. +The stability is sampled per structure to account for the natural variability in materials and construction practices, even within the same housing +tract. + +The height of each story and attic is imported with the inventory (no uncertainty), but the foundation height may have uncertainty that is sampled and +assigned to the structure. Uncertainty about foundation heights is defined at the occupancy type level. Each structure has a foundation height +attribute. The structure's occupancy type uses the uncertainty defined at the occupancy type level with the static value at the structure to sample a +new foundation height for the structure. Property values use the same approach as foundation height to sample uncertainty. Depth-damage functions are +sampled once per occupancy type and use curve sampling to compute new depth-damage functions for each iteration. Submergence criteria are sampled once +per occupancy type for each iteration. + +## Evacuating the Structure + +All of the preprocessing of data is necessary for the evacuation simulation to begin. Now that the warning and mobilization times are known for each +evacuating group, the decision thresholds are known for each evacuating group, and the time series of depths and velocities are assigned to each road +and structure, comparisons can be made between these values to decide if the group tries to evacuate or not. The people at risk could get exposed to +hazardous conditions either in a vehicle, in a structure, or have no shelter, as shown in . + +
    + +Before evacuees can mobilize, the conditions outside the structure must be relatively safe to allow evacuation. The program does the following checks: + + + Current depth at structure. Is depth above or below the non-evacuation depth? + + ), + }, + { // STEP 2 + title: ( + <> + Look at road nearest structure. Is depth on road above the willingness to enter depth? + + ), + }, + { // STEP 3 + title: ( + <> + Number of vehicles on road. If nearest road has reached vehicle capacity based on effective vehicle length and road length, the evacuating group will + wait until next time step. + + ), + }, + ]} +/> + +Some people may decide not to mobilize at all if the evacuating group is part of the sampled fraction on the PAI function above the maximum +mobilization rate, regardless of the depths and traffic. People who do not evacuate from the structure will be able to vertically evacuate within the +structure if needed. The full logic tree is shown in . + +
    + +### Evacuating Without Traffic Simulation + +LifeSim gives users the ability to estimate the number of people who leave a flooded area without actually modeling the evacuation process. This is +done by comparison of the depth at the structure and the non-evacuation depth. If the evacuating group attempts to mobilize before the depth at the +structure exceeds the non-evacuation depth, they are assumed to succeed in their evacuation and are removed from the exposed population. Turning off +the traffic simulation also includes walking evacuation since pedestrians use the road network. + +The benefit of this option is much faster computation times because the road network is not a part of the simulation and no vehicles are tracked. The +downside is no consideration of people caught while evacuating and therefore no life loss on roads. It is best to use this function when there is +expected to be plenty of time to evacuate everyone that can and choose to evacuate or when the conditions dictate this option. Examples of this may +be long, narrow canyons with short warning times where walking up the hillside is the fastest way to safety or urban settings where most people do +not have vehicles. + +### Evacuating With Traffic Simulation + +Once an evacuating group leaves their structure, they enter a dynamic (time-dependent) environment where they interact with the road network, other +vehicles, and flood water. Each evacuating group (whether in a vehicle or on foot) is tracked as they travel from their structure along the road +network to a destination. The conditions and position of evacuating groups are updated during each evacuation timestep, representing the bulk of +LifeSim calculation time. If groups reach a destination, they are considered cleared and removed from the simulation. If they contact flood water, the +vehicle and human stability functions determine if stability is lost or not. presents an overview of the +vehicular evacuation logic; more detailed descriptions follow. + +
    + +Predicting vehicle movement is determined by using their speed and the allowable time to predict the distance they can travel. If the traveled +distance is farther than the distance to the end of the road segment, the vehicle reaches the end of that segment and has a chance to enter the next +segment. At this point, the vehicle must decide whether to continue driving on the new segment. Assuming the next road segment is dry, the vehicle +continues with an updated speed based on the next segment's CFCC attribute (or at stop-and-go speed if wet). The distance traveled over the remaining +time in the timestep is calculated and the process repeats on each segment traveled until the full timestep is used. + +Vehicles travel the road network to their intended destination at the free-flow speed unless they are impacted by something to slow them down or they +decide to re-route. A vehicle may also become “caught,” in which case it stops moving and remains in its current location. + +The conditions that may divert, catch, or slow a vehicle are: + + + Traffic congestion: (see + Section Evacuation Parameters Defined by Alternative for + more information on setting evacuation parameters). + + ), + child: [ + { + title: ( + <> + As traffic density on a road increases, vehicle speed decreases according to Greenshields' two stage formula + ( and ) until it reaches the + minimum “stop-and-go speed,” resulting in a traffic jam (traffic jam = vehicles ahead moving at stop-and-go speed). The traffic density is calculated once + per timestep and includes all the vehicles on the road between a vehicle's starting position and the look-ahead distance. Each road segment is broken into + sub-segment bins where the number of vehicles are tracked. Bin lengths are not adjustable but calculated to reduce long roads into realistic road lengths + where cars can be considered to impact each other's speeds. Before density is calculated, newly mobilized vehicles are added to the road. If a vehicle enters + a new road segment with a different free-flow speed in the same timestep, the same proportional reduction in speed is used for that segment also (there is + only one calculation of density per vehicle per timestep). + + ), + }, + { + title: ( + <> + If confronted with a traffic jam, some vehicles will attempt to find a faster alternate route. As noted above, the density is only calculated at the + beginning of a timestep so the decision to re-route for traffic can only be made at that time. + + ), + }, + { + title: ( + <> + If the spillback function is turned on, an additional correction may be applied to the vehicle location. The effective vehicle length is used to make + sure the number of vehicles on a road segment is physically possible given the number of lanes, length of the road segment, and space taken by the + average vehicle. If too many vehicles are on a road segment at the end of the timestep, the spillback function pushes the last vehicle to enter back + onto the previous road segment. This continues until each road segment is at or below its physical capacity. + + ), + }, + ], + }, + { // STEP 2 + title: ( + <> + Flood water: any water covering the road with depth greater than the vertical offset height. + + ), + child: [ + { + title: ( + <> + A vehicle may decide not to enter a flooded road segment if the depth is greater than its fording depth (see + Section Willingness to Enter Flooded Roads for + more information). In + that case, it will attempt to re-route. The decision point to re-route for flooding is at the start of each road segment and could happen multiple + times in a single timestep. + + ), + }, + { + title: ( + <> + If the vehicle tries to re-route for flooding when on a one-way road, it is caught, but may remain dry and safe. For example, if a vehicle tries to + enter a flooded freeway from a dry on-ramp, they may get caught on the on-ramp but never actually get wet. + + ), + }, + { + title: ( + <> + If a vehicle re-routes for flooding and is able to turn around, flood water may block all possible paths (all deeper than the sampled fording depth). + If there are no valid routes, then the vehicle will be caught. + + ), + }, + { + title: ( + <> + A vehicle may be caught if it loses stability on a flooded road. This can happen when flood conditions change rapidly on the road or when a vehicle + is willing to enter a road it cannot safely navigate. + + ), + }, + { + title: ( + <> + When driving through water, all vehicles move at the stop-and-go speed for that road segment. + + ), + }, + ], + }, + { // STEP 3 + title: ( + <> + A vehicle caught in water: If a vehicle is confronted with another vehicle caught on the road ahead and the road is wet, it will attempt to re-route. + If the vehicle in front is caught and the road is dry, the confronted vehicle will make its own decision to enter or re-route, + per (2) flood water. This case assumes if the evacuating group sees a stalled vehicle in water, they will consider it unsafe and not attempt to cross. + + ), + }, + ]} +/> + +Examples of vehicles in conditions from **(2) flood water** and **(3) a vehicle caught in water** are discussed in reference to . + +- **Panel A**: Vehicle 1 approaches a flooded road and decides not to enter because the depth is higher than +its willingness to enter depth (DR > DWE). Vehicle 1 is caught at that location because it cannot turn around on the one-way +road. +- **Panel B**: a second vehicle approaches Vehicle 1. Since the road in front of Vehicle 1 is clear of +vehicles and Vehicle 2 has a willingness to enter the flooded road (DWE > DR), Vehicle 2 passes Vehicle 1 and enters the flooded +road. Unfortunately, Vehicle 2 has a low vehicle stability threshold and loses stability on the flooded road (DSTAB < DR, +recognizing that the stability function also includes velocity considerations). +- **Panel C**: a third vehicle approaches, also willing to enter (DWE > DR) and with stability criteria high enough to navigate the flooded road successfully +(DSTAB > DR). However, the road is “blocked” by caught Vehicle 2, so Vehicle 3 does not enter the flooded road and is caught in +line behind Vehicle 1. Vehicle 1 and 3 represent the beginning of a traffic backup on this road, assuming the spillback function is turned on. + +
    + +#### Re-routing vehicles + +Re-routing for traffic and flooding are slightly different processes. Not all vehicles will attempt to re-route for a traffic jam (condition **[1b] +traffic congestion, traffic jam**), but all vehicles will attempt to re-route for the other flood-caused +conditions (**[2] flood water** and **[3] a vehicle caught in water**). During preprocessing for the iteration, each vehicle samples whether it +will attempt re-routing due to a traffic jam, governed by +the “fraction who re-route in a jam” parameter. + +Vehicles trying to re-route will attempt to find a new fastest path to a destination regardless of their initial EPZ destination assignment constraints + (all destinations are allowed). If a faster path to a destination is available, it will be selected. + +Vehicles are allowed to make a U-turn on most two-way roads. However, limited access +highways (CFCC code A00-A29) and +one-way roads do not allow +U-turns, and vehicles will have to go to the end of the road segment before turning around. + +Vehicles trying to re-route for traffic reasons have near real-time knowledge of the traffic conditions on the whole road network. The road network +graph is continuously updated with current traffic conditions during the evacuation simulation, based on the “live traffic update interval.” +Basically, this assumes that people will consult a device such as a smartphone with up-to-date traffic information when re-routing due to traffic +conditions. + +Each re-routing vehicle also retains knowledge of every flooded road that caused it to re-route and will not attempt to use that road segment again. +Flooded roads that were successfully crossed may be reused as part of an alternate path. Flooded roads blocked by a caught car are not known to the +vehicle unless already encountered. + +It is assumed that each vehicle re-routing due to flooding does not use live traffic and uses the initial road network graph updated from each agent's +flooded road memory to find their fastest path to a destination. + +### Evacuating on Foot + +Evacuating on foot is similar to vehicle evacuation but has some key differences and simplifications. Pedestrians evacuate in groups that stay +together just like a vehicle. They also use the same road network as the vehicles but are handled independently of the traffic even when they are on +the same road. Key differences for pedestrians are: + +- There is no pedestrian spillback function or pedestrian density considerations. Roads are expected to handle the full pedestrian population. +- Pedestrians always move at the pedestrian evacuation speed; there is no change in speed for “pedestrian traffic jams.” +- Pedestrians do not re-route for traffic (vehicle or pedestrian). +- All pedestrian groups are willing to enter a flooded road with less than two feet of water and try to re-route if confronted by deeper water. +- To get caught, the human stability function is considered for the group as a whole while on flooded roads. + +The default setting in LifeSim 2.0 is for full vehicular evacuation because pedestrians are typically a small fraction of the evacuating population. +Two exceptions to this default assumption may be long, narrow canyons with short warning times where walking up the hillside is the fastest way to +safety or urban settings where most people do not have vehicles. + +### Caught while Evacuating + +Being caught while evacuating is not the same as losing stability. A caught vehicle may be on dry land with nowhere to go (see Vehicles 1 and 3 +in ). Once an evacuating group is caught, they are subjected to stability criteria that may or may not be +exceeded. All members of the evacuating group are placed in the high hazard or low hazard zone together. + +For vehicles, first the vehicle stability is checked against the maximum conditions of the road segment where they were caught. If surpassed, the +human stability criteria are also checked. This assumes that under certain conditions, a person may exit their car and walk/swim to safety. If +vehicular stability is exceeded but human stability is not exceeded, the group will be in a low hazard zone. If both human and vehicle criteria are +surpassed, the evacuating group is placed in the high hazard zone. If no stability criteria are surpassed but the vehicle was on a wet road, they are +placed in a low hazard zone. + +For pedestrians, only the human stability function is considered (including the portion with swimming ability, if applicable). + +Everyone who isn't caught reaches a destination and is safe and cleared or remained in their structure and are subjected to vertical evacuation +criteria. + +## Vertical Evacuation Within Structures + +A subset of the population remains in their structure either by choice or because water arrived before they could mobilize. These people are subject +to the structure stability and submergence criteria. In LifeSim, all people will move to the highest story of a building, and some will continue to +move up into an attic or onto the roof as their sampled mobility and access allows. demonstrates the vertical evacuation logic. + +
    + +Vertical evacuation is not time-dependent. The logic employed by LifeSim assumes that people will continue to move vertically within their structure +as fast and as high as possible to stay above the rising water. The rate of water rise is not considered – only the maximum conditions. However, +vertical evacuation is not possible if the maximum conditions would lead to collapse of the structure (by comparison to the sampled structure +stability function). In that case, all occupants are automatically placed in the high hazard zone and the structure and contents are considered a total + loss. + +The vertical evacuation calculation begins with subtracting the sampled foundation height from the maximum depth at the structure. If the resulting +in-structure depth is less than zero, the occupants are still considered low hazard to account for people who could become trapped in a basement or +those who leave the structure (not intending to evacuate) and are impacted by the flood waters outside their house. Although rare, several stories of +this risky behavior were documented in the research to develop the fatality rate functions. If the maximum depth at a structure is less than or equal +to zero, then there is no hazard, no further calculations are required, and all occupants are deemed safe. + +If the interior depth is above zero, the next calculation is for the stability of the structure. Each structure has a sampled stability function +(discussed in +Sections Preprocessing - Preparation +of Alternative Data and Preprocessing for Each Iteration). The +structure stability criteria is tested against the time series of depths and velocities at +the structure to determine whether the structure collapses at any point during the simulation. This process only determines total collapse of a +structure. Case histories have identified instances of partial collapse where water may remove a wall and reduce the protection provided by the +shelter. If the stability function is exceeded, all people are placed in the high hazard zone and no vertical evacuation is computed. + +Once it is established that the structure is flooded and does not collapse, LifeSim must determine how high each occupant is able to move within the +structure. People with limited mobility are assumed to move to the highest floor but no higher. This simplification neglects the impact of +co-occupants to assist those with limited mobility (elderly, infants, disabled) and represents the most common condition. Several stories of +survivors and fatalities in structure flooding were +consulted (Section Development of +Flood Fatality Database). The high hazard fatality rate function includes several cases of those +with limited mobility assisted by others. Regardless of their actual position in the structure, their limited mobility in a flooded structure seems to +constitute a high hazard situation. + +Those without limited mobility have the possibility of moving into the attic or roof. For each person in each group, the roof/attic +access (Section Probability of Access +to Roof or Attic) is sampled to determine further vertical movement then split between those who go to the attic or the +roof (Section Fraction to +Roof vs Attic) to determine final location. + +Once everyone's final position is known, the structure submergence criteria are applied (as discussed in +Section Submergence +Criteria). The submergence criteria +represent the threshold depth between high and low hazard zones. If the interior depth exceeds the threshold, the occupant is placed in the high hazard +zone, and all others are in the low hazard zone. + +A special case exists for structures with zero stories. This represents a place where people are gathered outdoors – perhaps a park, campground, or +agriculture field. In this case, the structures around the people provide little protection and they are subjected to human stability criteria as if +they are pedestrians caught at their structure. + +## General Modeling Guidelines + +The user should consider the following when running a simulation: + +- The decision to enter a flooded road for evacuating groups is a function of depth. A person's inability to accurately estimate depth while in a +vehicle or on foot is not taken into account. + +- Although the model currently does not have convergence options for determining the number of iterations, convergence testing can still be calculated +in post-process. Results by iteration are available in table form which can be exported or copied for use in other applications. Convergence testing +can then be performed on the desired result (e.g., total life loss, total damage) by iteration. + +- A partial evacuation is possible by deactivating all destinations for an EPZ; no one will leave their structures. Another option to simulate partial +evacuation by EPZ is to set the maximum % initiated to zero in the PAI function. In this case, everyone will remain in structures and vertically +evacuate (a.k.a. sheltering-in-place) and will be subject to the maximum flood conditions at that structure. + +- For evacuating vehicles, the evacuation timestep and look-ahead distance are critical to ensuring vehicles do not skip over a traffic jam. As +evacuation timestep is increased, vehicles can travel farther in a single timestep. If the look-ahead distance is too short, vehicles may have initial +speeds that do not reflect a traffic jam that they will reach in a single timestep. + +- By manipulating the EPZ's simulate traffic parameter +(Section Emergency Planning Zone), the +user can turn off simulating traffic by EPZ. The traffic simulation process can + be very intensive and take a long time. It is common practice to turn off traffic simulation if the hazard arrival time is long enough for people to +reach safety for those that will take protective action in areas that will be impacted. + + \ No newline at end of file diff --git a/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/12-consequences.mdx b/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/12-consequences.mdx new file mode 100644 index 000000000..120a8aed0 --- /dev/null +++ b/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/12-consequences.mdx @@ -0,0 +1,463 @@ +--- +title: "Consequences" +--- + +import Link from "@docusaurus/Link"; +import addBaseUrl from "@docusaurus/useBaseUrl"; +import Citation from "@site/src/components/Citation"; +import CitationFootnote from "@site/src/components/CitationFootnote"; +import Equation from '@site/src/components/Equation'; +import EquationNoRef from '@site/src/components/EquationNoRef'; +import EquationReference from '@site/src/components/EquationReference'; +import Figure from "@site/src/components/Figure"; +import FigureInline from "@site/src/components/FigureInline"; +import FigReference from "@site/src/components/FigureReference"; +import NavContainer from "@site/src/components/NavContainer"; +import ProcessList from "@site/src/components/ProcessList"; +import TableReference from "@site/src/components/TableReference"; +import TableVertical from "@site/src/components/TableVertical"; +import VersionSelector from "@site/src/components/VersionSelector"; + + + +# Consequences + +## Chapter Overview + +This chapter covers how consequences are calculated in LifeSim. Consequences may be life loss, direct economic damages (e.g., property, agriculture), +or indirect economic damages. +Chapter Structure Inventory and +Associated Properties described +how LifeSim calculations re-distribute the initial population by evacuation group through emergency +response to avoid the oncoming hazard. They may have evacuated vertically in their structure or evacuated the structure by vehicle or on foot. The +result of those calculations places each evacuating group in a final location: safe, no hazard, low hazard, or high hazard. In this chapter, the +impact of the hydraulic conditions are considered for each person and evacuating group to determine direct life loss. In addition, the hydraulic +conditions at each structure and agricultural field are used to determine direct and indirect economic damages. + +## Life Loss + +Based on the assigned hazard zone categories, life-loss estimates are made using life-loss probability distributions developed by McClelland and +Bowles (2000) , updated by Aboelata, Bowles, and +McClelland (2003) , Aboelata +and Bowles (2008) , and revised by +USACE (Chapter Fatality Rates). + shows the distribution of fatality rates for population groups in the high hazard zone. + +As described in Section Population Parameters, the +population is categorized as being in either a low or high hazard zone. LifeSim can calculate life loss for each +person that ends up in either a low hazard or high hazard zone. The overall calculation is the same for both zones; only the hazard zone +function () is different. For each group that has been assigned to a zone, a fatality rate is acquired by randomly +sampling the relative frequency of exceedance. In other words, a group in the high hazard zone can be in a scenario representative of any other group +represented in the dataset. By sampling the frequency of exceedance, naturally variable occurrences such as being able to hang on to passing debris or + finding an air pocket in a submerged structure are expressed. + + provides an example for one evacuating group. Assume the evacuating group consists of three people in a structure, +and the structure loses stability. In this example, the evacuating group is considered in the high hazard zone and randomly assigned a relative +frequency of exceedance between zero and one (assume 0.58). That value on the x-axis translates to a fatality rate on the y-axis of 0.75. The fatality + rate represents, on average, 75% of the evacuating group will lose their life. + +
    +
    +
    +
    + +After the fatality rate is determined, life loss is calculated for each person in the group. To determine individual fatality, each person in the group + samples a random value between 0 and 1. If the random number is above 0.75, then the person survives. If it is below 0.75, then the person does not. In + the example case, the structure fails, so all three people are placed in the high hazard zone. However, evacuating groups in flooded structures that +do not collapse may be split between low and high hazard zones based on age and/or mobility. + +To reiterate the process, sample one fatality rate per group from either the high or low hazard function, then sample fatality per person in the +group. By sampling the hazard zone fatality rate function randomly for each evacuating group, the fatality rates sampled for all the evacuating groups + in the population define the shape of the function. For example, about 47% of evacuating groups will have 100% fatalities in their group and around +13% of evacuating groups will have no fatalities in the group. The remaining 40% of the groups have some chance of fatalities and survival defined by +the function. + +The reason for applying fatality rates at the level of the evacuating group is because conditions are going to be fairly consistent for a group. This +reason is why the data to support the functions was collected at a group level. Research suggests that members of an evacuating group impact each +other's chances of survival in complex ways that are not modeled. By capturing these hidden dynamics in the data set and applying them at the +evacuating group level, LifeSim more accurately replicates the factors leading to life loss. For example, in a family with young children, the adults +will assist the children to reach safety and be hindered themselves by providing assistance. In a group of capable adults, the overall risk may be +reduced by cooperation versus each person considered on their own. + +## Property Damage + +### Structure, Content, Vehicle, and Other Damage + +Direct damages to a building, its contents, and its vehicles are calculated for a single structure as follows: + + + +where + +> _D_ = total direct damage for a structure.
    +> s = structure.
    +> c = contents.
    +> v = vehicles.
    +> o = other.
    +> _d_ = damage (in percent) as a function of depth and depth-damage function.
    +> _v_ = property value. + +To determine the percent direct damage to buildings, contents, and vehicles, both the depth at the structure and occupancy type of the structure need +to be known. The depth is considered the maximum depth at the structure minus the foundation height. The occupancy type is specified as part of the +structure inventory and is associated with three individual depth-percent damage relationships, one each for the building, contents, and vehicles. +There is also the option to define a fourth depth-percent damage function for an additional “other” category. Therefore, the depth at the structure +can be used to determine the percentage that the three components of the structure are damaged. This percent damage can then be multiplied by the +building, contents, and vehicles values (specified in the structure inventory) to determine the total direct damage that occurs at and within a +structure. + +A schematic of the direct damage computation procedure for a building is shown in . At a depth of 7 feet, the +building is 42% damaged based on the depth-damage relationship. Multiplying the building value (100,000 USD) by the damage (42%) results in a direct +building damage of 42,000 USD. The direct damage to the contents and vehicles will also need to be added to the building damage of 42,000 USD to determine +the total damage at and within the structure. + +
    + +Damages to vehicles are not impacted by the number of vehicles that leave during an evacuation. That consideration must be made outside of LifeSim +before updating the structure inventory. The reason for not reducing the number of cars is that there are currently no good approximations for the +number of cars at each structure. Since the population shifts according to work and school considerations, the location of the car may not match the +population. + +The second consideration that can impact the direct damage computations occurs when a structure's stability criteria is exceeded. Prior to any direct +damage computations, LifeSim will check whether or not the structure lost stability. If the stability is lost, the structure, contents, and vehicles +will all automatically be assigned a total loss of 100%. + +Since collapse criteria require depth-on-structure (depth from ground minus foundation height), a structure can't collapse if flood level is below the +foundation height. + +### Agricultural Damage + +The computational procedure and input sources for calculating agricultural damages have been defined in +the HEC-FIA Technical Reference Manual (USACE, 2026) . Damage +to crops is dependent upon the value added by the farmer to the field at the time of flooding, and how much of that value is +susceptible to flooding. The damage driving parameter is duration. + +Similar to structure depth-damage relationships, it is possible for agricultural damages to increase with longer durations. However, since damage is +also a function of how hardy the plant is, the damage for a given duration may change with time. For simplicity, the damage calculation is split into +two pieces, the seasonally based value, and the seasonally based damage. A general expression of the damage calculation is as follows: + + + +where: + +> _S_ = seasonally based value as a function of date and crop type.
    +> _t_ = date.
    +> _a_ = the area of the grid cell in acres.
    +> _c_ = crop type.
    +> _V_ = the value as a function of crop type and date.
    +> _H_ = the harvest cost as a function of crop type.
    +> _B_ = the % of the total crop value that is available to be flooded due to the crop budget. + + + + + +where: + +> _D_ = damage to the crop as a function of date and duration.
    +> _d_ = duration of flooding.
    +> _L_ = the loss for the crop as a function of duration and crop type. + +To illustrate how the seasonally based value changes with time, an example plot is provided in ; here value is +expressed as a portion of total exposed value: + +
    + +As shown in , if a crop is planted late, it has a different value function. It is assumed that if the flood +does not interrupt the farmer, the crops will be planted on the first plant date. Thus, late planting will only occur if the flood start plus the +duration ends before the late plant date but after the first plant date. This is intended to reflect that farmers may adopt different schedules for +application of watering, fertilizer, and other processes in raising the crop. + +Damages also fluctuate based on seasonality. Some crops can better withstand short duration floods if they are out of critical development +stages. gives a general example of what seasonal duration damage relationships look like. + +Generally, longer durations would yield larger losses, and more mature plants would be more robust to damage. However, as +depicted in , if farmers cannot harvest their crops at the proper time, the crop could be entirely lost. + +
    + +## Indirect Economic Damage + +The ECAM component within LifeSim utilizes the direct damages and life loss, computed as discussed in +Chapter Computational Procedure. The losses +of capital and labor as a ratio of the overall available capital and labor by sector are evaluated. After labor losses and capital losses are described, they are +submitted to the ECAM study component as inputs. ECAM then computes indirect losses. + +### Capital Losses + +Capital loss results are computed through three steps: (i) calculating the total exposed value per county; (ii) calculating the losses per county +resulting from the event; and (iii) dividing the losses per county by the total exposed value per county for all non-residential structures, which +results in a capital loss ratio per county. The procedure for calculating capital loss results is listed below. + + + Calculate the total capital for county c (TCc) by summing the structure and content values for all non-residential + structures within county c using the following equation: + + ), + freeform: ( + <> + +

    + where TICc is the total industrial capital for county c, TCCc is the total commercial capital for + county c, and TPCc is the total public capital for county c. +

    + + ), + }, + { // STEP 2 + title: ( + <> + Calculate the total lost capital by summing the damages for each structure category, as computed in the direct damages computations. The total lost + capital for county c (LCc) is calculated using the following equation: + + ), + freeform: ( + <> + +

    + where LICc is total lost industrial capital for county c, LCCc is total lost commercial capital for + county c, and LPCc is total lost public capital for county c. +

    + + ), + }, + { // STEP 3 + title: ( + <> + Finally, a comparison between the lost capital for county c (LCc) and the total capital for + county c (TCc) is expressed in terms of a capital loss ratio (CLr). This ratio, which cannot be greater than 1 nor less + than 0, is calculated using the following formula: + + ), + freeform: ( + <> +

    + +

    + + ), + }, + ]} +/> + +### Labor Losses + +To compute labor losses within LifeSim, the populations for all structures within the inventory that are impacted by the event are utilized. This +means that populations in both residential and non-residential structures will be utilized to calculate labor loss based upon the population under the + age of 65 at 2:00 PM. The justification for that assumption is that although the entire population is not part of the workforce, it is assumed that +the ratio of laborers to non-laborers within the study area is fixed both geospatially and temporally. The procedure for calculating labor losses was +derived from the FEMA's formulas for estimating population damage (Table 13.2 +of Hazus-MH 2.1 +Technical Manual) (FEMA, 2020) . The methodology used in LifeSim is described below. + + + Identify the number of people located in each impacted structure at 2:00 PM. + + ), + }, + { // STEP 2 + title: ( + <> + Calculate the impact duration for each structure s (Is) in hours using the following formula: + + ), + freeform: ( + <> + +

    + where Ds is duration of flooding at structure s (hr), Cs is cleanup time at + structure s (hr), and Rs is reconstruction time at structure s (hr). Is may not + exceed 8,766 hours (equivalent to one year, or 365.25 days). Ds, Cs, and Rs are defined + by the user in the ECAM Data dropdown tab of + the Alternative Editor dialog box. +

    + + ), + }, + { // STEP 3 + title: ( + <> + Calculate the number of labor hours displaced for the working population at each structure (LHDs) using the following formula: + + ), + freeform: ( + <> + +

    + where 2000 is the number of working hours per laborer per year, 365.25 is the number of days per year, 24 is the number of hours per day, Ps is the total population under 65 in structure s, and Ls is the life loss under 65 for structure s. +

    + + ), + }, + { // STEP 4 + title: ( + <> + Calculate the total labor loss at structure s (LLs) in hours by adding the working population labor hours displaced (LHDs) to the working population labor hours lost due to life loss using the following formula: + + ), + freeform: ( + <> + +

    + where Ls is life loss at structure s and 2000 is the number of working hours per laborer per year. +

    + + ), + }, + { // STEP 5 + title: ( + <> + Calculate the cumulative labor loss for county c using the following formula: + + ), + freeform: ( + <> + +

    + where LLc is the labor loss for county c in hours, LLs is the labor loss for structure s, and n is the number of structures within county c. +

    + + ), + }, + { // STEP 6 + title: ( + <> + Calculate total population during the day (Popday) per county using the following formula: + + ), + freeform: ( + <> + +

    + where ResidDay is the daytime residential population, WorkingCom is the number of people commuting, WorkingInd is the number of people employed in the industrial sector, Hotel is the number of people staying in hotels in the census tract, Visitor is the number of regional residents who do not live in the study area, SchoolEnrollmentKto12 is the number of grade school students, College is the number of college and university students, and Pop is the census tract population. +

    + + ), + }, + { // STEP 7 + title: ( + <> + Calculate the total available workforce for county c (WFc) using the following formula: + + ), + freeform: ( + <> + +

    + where EldersFrac is the fraction of the population over age 65. +

    + + ), + }, + { // STEP 8 + title: ( + <> + Finally, a comparison between the labor loss for the county (LLc) and the available labor for the county will be expressed in terms of a labor loss ratio (LLr). This ratio, which cannot be greater than 1 nor less than 0, is calculated using the following formula: + + ), + freeform: ( + <> + + + ), + }, + ]} +/> + +### Indirect Economic Losses + +To convert the capital loss ratio (CLr) and labor loss ratio (LLr) into a reduction in economic output, the ECAM system model +requires information about the specific nature of the economy being analyzed. The ECAM system model determines whether the economy in question is +capital or labor intensive and what the rate of exchange is between labor and capital. Each county has a unique dataset that is used to define the +specific economic characteristics assessed in the ECAM system model. + +Statistics for production, employment, income and all other economic indicators are based upon the IMPLAN (IMpact Analysis for PLANning) dataset, +unless otherwise indicated. Each of these datasets can distinguish up to 440 separate production activities, ten household types, and four levels of +government. The dataset used for evaluating indirect economics with ECAM and LifeSim has been aggregated from the full 440 sectors to 30 sectors. +Additional information on the IMPLAN dataset is available from IMPLAN Group, LLC. Additional information on the ECAM system model can be found in +Lehman, et al. (2013) . + +Outputs from the indirect losses computations include the following: + +- Indirect Economic Damage Report +- Indirect Employment Loss Report + + \ No newline at end of file diff --git a/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/13-uncertainty-and-sampling-methods.mdx b/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/13-uncertainty-and-sampling-methods.mdx new file mode 100644 index 000000000..d911d001f --- /dev/null +++ b/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/13-uncertainty-and-sampling-methods.mdx @@ -0,0 +1,274 @@ +--- +title: "Uncertainty and Sampling Methods" +--- + +import Link from "@docusaurus/Link"; +import addBaseUrl from "@docusaurus/useBaseUrl"; +import Citation from "@site/src/components/Citation"; +import CitationFootnote from "@site/src/components/CitationFootnote"; +import Equation from '@site/src/components/Equation'; +import EquationNoRef from '@site/src/components/EquationNoRef'; +import EquationReference from '@site/src/components/EquationReference'; +import Figure from "@site/src/components/Figure"; +import FigureInline from "@site/src/components/FigureInline"; +import FigReference from "@site/src/components/FigureReference"; +import NavContainer from "@site/src/components/NavContainer"; +import ProcessList from "@site/src/components/ProcessList"; +import TableReference from "@site/src/components/TableReference"; +import TableVertical from "@site/src/components/TableVertical"; +import VersionSelector from "@site/src/components/VersionSelector"; + + + +# Uncertainty and Sampling Methods + +## Chapter Overview + +The process of estimating life loss caused by a hazard is complex. Complexities include uncertainty in the spatial distribution of the initial PAR, +the technological and sociological aspects of warning diffusion and mobilization, the human decision aspects of evacuation transportation, and +determining fatality for those exposed to the hazard (Aboelata, Bowles, and Chen, 2004) . By tracking +the uncertain parameters in a simulation, a better understanding of the factors driving consequences is gained. + +LifeSim employs uncertainty analysis using the Monte Carlo sampling method: the procedural steps that comprise LifeSim's methodology are repeated +iteratively with a new set of sampled input parameters until a pre-defined number of iterations has been met. Each iteration provides a new set of +sampled parameters from the uncertainty distributions (e.g., Warning Delay) resulting in a range of life loss estimates. However, LifeSim doesn't +expressly consider the following: + +- Effects of prolonged exposure to weather and other environmental factors. +- Spatial correlation of warnings. +- Indirect life loss. +- Water temperature. +- Debris or other hazards in the flood water. +- Rescue. +- Trip chaining or returning to the evacuation area. +- Initial traffic load prior to evacuation simulation. +- Hydrologic and hydraulic model uncertainties. + +## Types of Uncertainty + +LifeSim accounts for two types of uncertainty: natural (aleatory) uncertainty and knowledge (epistemic) uncertainty. + +### Natural Uncertainty + +Natural (or aleatory) uncertainty results from the natural randomness inherent in a process, or the natural process is so complex it seems random when +viewed in isolation. It is often referred to as inherent uncertainty. Here, uncertainty can be estimated and quantified based on past observations, +but it cannot be eliminated. LifeSim captures natural variability in the warning and evacuation process and estimating life loss when people are +exposed to the hazard. Examples of parameters with natural uncertainty include annual maximum flood peaks and the willingness of a driver to enter a +flooded road. These examples are a result of natural processes and human decision making that can never be completely understood or predicted. + +### Knowledge Uncertainty + +Knowledge (or epistemic) uncertainty, often referred to as reducible uncertainty, results from limited knowledge about a system—either modeled or +real. Here, uncertainty can be reduced as more information and data are obtained about a parameter providing a means of capturing knowledge +uncertainty. In theory, this uncertainty can be eliminated if complete knowledge of a parameter is obtained. For example, percent damage vs. depth +functions for an occupancy type are uncertain because each structure within that occupancy type is unique. However, one could reduce this uncertainty +by improving the understanding of each building's foundation height, structure materials, and contents. Furthermore, if one had a perfect +understanding of every building, the uncertainty could be nearly eliminated. + +### Application in Software + + catalogues LifeSim parameters that are modeled with uncertainty. The table also states the type of +uncertainty associated with each, where it is defined in the software, and the simulation level at which the parameter is sampled. Uncertainty on the +parameters for which knowledge uncertainty apply can be reduced if more information and data are obtained about the parameter of interest. For the +parameters with natural uncertainty, however, human reaction and decision making is inherent such that the uncertainty cannot be eliminated. + +Many uncertain parameters are a combination of natural and knowledge uncertainty. For example, by performing a detailed assessment of a local +community and the emergency management agency responsible for evacuating the community, we can reduce our uncertainty about how quickly the warning +will disseminate throughout the community. However, the order in which individual people will receive the warning is considered naturally variable. +Another example of both types of uncertainty being applied at a single parameter is in vehicle stability thresholds. Uncertainty can be reduced on the + thresholds required to make a vehicle lose stability, but even if all vehicles were the same make and model, other factors impact stability such as +different tire tread, underlying surface (e.g., gravel, pavement), and debris in the water. + + + +## Uncertainty Sampling + +### Distribution Sampling + +Many uncertain parameters, such as willingness to enter a flooded road, are defined as distributions in LifeSim. To estimate the parameter in a monte +carlo simulation, the distribution is sampled with a random number between 0 and 1 using a random number generator. The distribution's inverse CDF +function is used with the random number generator to provide the parameter. In other words, the random number represents a probability and the +distribution returns the appropriate value for the given probability. + +### Curve Sampling + +Curve sampling is the process of sampling a curve function from an array of distribution ordinates. In LifeSim, curve sampling is performed on +depth-damage functions, building stability criteria, first alert dissemination, and PAI functions. With each of these functions, a distribution is +defined conditional on some value such as depth or time. For example, in the depth-damage functions, each ordinate has a depth and the % damage at that + depth is defined as a distribution. + +To sample a curve function for the monte carlo simulation, LifeSim determines a random number between 0 and 1 using a random number generator. Then, +for each ordinate in the curve function the distribution is sampled using the random number as described in +Section Distribution Sampling. Monotonicity +is ensured by using the same random number for each distribution. + +### Other Sampling Procedures + +Uncertainty about the foundation height and structure values is defined using distributions at the occupancy type level. Sampling these parameters +is unique because the uncertainty is defined as a % variation around the value defined at the structure level. For example, a structure with a value +of 100 USD +(Section Property Value) samples +-50% for variation around value. The structure value used in the iteration is then 50 USD (). + + + +where: + +> _pi_ = Parameter value for iteration _i_.
    +> _ps_ = Base parameter value used for variation such as structure value.
    +> _vi_ = Variation of the value as a ratio sampled for iteration _i_. + +Another sampling procedure in LifeSim is used when applying percentage ratios for population characteristics. For example, an occupancy type contains +the fraction of population with limited mobility for both over and under 65 years old. Random sampling is used to determine which occupants have +limited mobility and which ones don't. To sample limited mobility, for each person in a structure, a random number is generated between 0 and 1. If the + sampled value is above the fraction with limited mobility for the appropriate age group, then the person does not have limited mobility. For example, +if a person over 65 years old samples a 0.1 and the fraction with limited mobility over 65 for the person's occupancy type is 0.2, then the person will +be assumed to have limited mobility. + +First alert and PAI initiation functions are defined in an iteration using curve sampling. These functions provide dissemination on a community level +but don't provide the granularity required to know when specific people will receive a warning and take protective action. The procedure for +evacuating groups is defined in +Section Evacuating Groups +and Their Attributes. The +first alert and PAI function uncertainty can be reduced with more knowledge. Sampling the curve +functions to determine when each group gets alerted and takes protective action is naturally variable. + + \ No newline at end of file diff --git a/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/14-references.mdx b/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/14-references.mdx new file mode 100644 index 000000000..14713d8ec --- /dev/null +++ b/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/14-references.mdx @@ -0,0 +1,22 @@ +--- +title: "References" +--- + +import Link from "@docusaurus/Link"; +import addBaseUrl from "@docusaurus/useBaseUrl"; +import Bibliography from "@site/src/components/Bibliography"; +import CitationFootnote from "@site/src/components/CitationFootnote"; +import NavContainer from "@site/src/components/NavContainer"; +import VersionSelector from "@site/src/components/VersionSelector"; + + + +# References + + + + diff --git a/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/15-terms-and-conditions-of-use.mdx b/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/15-terms-and-conditions-of-use.mdx new file mode 100644 index 000000000..530e53b59 --- /dev/null +++ b/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/15-terms-and-conditions-of-use.mdx @@ -0,0 +1,106 @@ +--- +title: "Terms and Conditions of Use" +--- + +import Link from "@docusaurus/Link"; +import addBaseUrl from "@docusaurus/useBaseUrl"; +import Citation from "@site/src/components/Citation"; +import CitationFootnote from "@site/src/components/CitationFootnote"; +import Equation from '@site/src/components/Equation'; +import EquationNoRef from '@site/src/components/EquationNoRef'; +import EquationReference from '@site/src/components/EquationReference'; +import Figure from "@site/src/components/Figure"; +import FigureInline from "@site/src/components/FigureInline"; +import FigReference from "@site/src/components/FigureReference"; +import NavContainer from "@site/src/components/NavContainer"; +import ProcessList from "@site/src/components/ProcessList"; +import TableReference from "@site/src/components/TableReference"; +import TableVertical from "@site/src/components/TableVertical"; +import VersionSelector from "@site/src/components/VersionSelector"; + + + +# Terms and Conditions of Use + +This RMC documentation was developed with U.S. Federal Government resources and is therefore in the public domain. It may be used, copied, +distributed, or redistributed freely. However, it is requested that RMC be given appropriate acknowledgment in any subsequent use of this work. + +Use of the software described by this document is controlled by certain terms and conditions. The user must acknowledge and agree to be bound by the +terms and conditions of usage before the software can be installed or used. For reference, a copy of the terms and conditions of usage are included +below so that they may be examined before obtaining the software. The software described by this document can be downloaded for free from +the RMC website. + +RMC cannot provide direct user assistance or support for its software to non-USACE users. In the past, for non-USACE users, RMC had provided a list of + possible vendors for assistance or support for RMC software. By direction of USACE counsel RMC has discontinued this practice and has removed the +list from our web site. Non-USACE individuals should use any internet search engine to locate a vendor that can provide support for the RMC software +of interest. + +However, we will respond to all documented instances of program errors. Documented errors are bugs in the software due to programming mistakes not +model problems due to user-entered data. + +This document contains references to product names that are trademarks or registered trademarks of their respective owners. Use of specific product +names does not imply official or unofficial endorsement. Product names are used solely for the purpose of identifying products available in the public + market place. + +Microsoft and Windows are registered trademarks of Microsoft Corp. + +Hazus-MH is a registered trademark of FEMA (U.S. Department of Homeland Security, Federal Emergency Management Agency). + +## Terms and Conditions of Use + +Use of the software described by this document is controlled by certain terms and conditions. The user must acknowledge and agree to be bound by the +terms and conditions of usage before the software can be installed or used. + +The United States Government, U.S. Army Corps of Engineers, Risk Management Center (“RMC”) grants to the user the rights to install LifeSim Life Loss +Estimation (LifeSim) "the Software" (either from a disk copy obtained from RMC, a distributor, or another user or by downloading it from a network) +and to use, copy and/or distribute copies of the Software to other users, subject to the following Terms and Conditions for Use: + +- All copies of the Software received or reproduced by or for user pursuant to the authority of this Terms and Conditions for Use will be and remain +the property of RMC. +- User may reproduce and distribute the Software provided that the recipient agrees to the Terms and Conditions for Use noted herein. + +RMC is solely responsible for the content of the Software. The Software may not be modified, abridged, decompiled, disassembled, obfuscated, or +reverse engineered. The user is solely responsible for the content, interactions, and effects of any and all amendments, if present, whether they be +extension modules, language resource bundles, scripts, or any other amendment. + +The name “LifeSim” must not be used to endorse or promote products derived from the Software. Products derived from the Software may not be called +“LifeSim” nor may any part of the “LifeSim” name appear within the name of derived products. + +No part of this Terms and Conditions for Use may be modified, deleted, or obliterated from the Software. + +No part of the Software may be exported or re-exported in contravention of U.S export laws or regulations. + +## Waiver of Warranty + +THE UNITED STATES GOVERNMENT AND ITS AGENCIES, OFFICIALS, REPRESENTATIVES. AND EMPLOYEES, INCLUDING ITS CONTRACTORS AND SUPPLIERS, PROVIDE LIFESIM "AS + IS," WITHOUT ANY WARRANTY OR CONDITION. EXPRESS, IMPLIED OR STATUTORY, AND SPECIFICALLY DISCLAIM ANY IMPLIED WARRANTIES OF TITLE, MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. Depending on state law, the foregoing disclaimer may not apply to you, and you may also have +other legal rights that vary from state to state + +## Limitation of Liability + +IN NO EVENT SHALL THE UNITED STATES GOVERNMENT AND ITS AGENCIES, OFFICIALS. REPRESENTATIVES, AND EMPLOYEES, INCLUDING ITS CONTRACTORS AND SUPPLIERS, +BE LIABLE FOR LOST PROFITS OR ANY SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF OR IN CONNECTION WITH USE OF LIFESIM, REGARDLESS OF +CAUSE, INCLUDING NEGLIGENCE. + +THE UNITED STATES GOVERNMENT'S LIABILITY, AND THE LIABILITY OF ITS AGENCIES. OFFICIALS. REPRESENTATIVES AND EMPLOYEES, INCLUDING ITS CONTRACTORS AND +SUPPLIERS, TO YOU OR ANY THIRD PARTIES IN ANY CIRCUMSTANCE IS LIMITED TO THE REPLACEMENT OF CERTIFIED COPIES OF LIFESIM WITH IDENTIFIED ERRORS +CORRECTED. Depending on state law, the above limitation or exclusion may not apply to you. + +## Indemnity + +As a voluntary user of LifeSim, you agree to indemnify and hold the United States Government, and its agencies, officials, representatives, and +employees, including its contractors and suppliers, harmless from any claim or demand, including reasonable attorneys' fees, made by any third party +due to or arising out of your use of LifeSim or breach of this Agreement or your violation of any law or the rights of a third party. + +## Assent + +By using this software, you voluntarily accept these terms and conditions. If you do not agree to these terms and conditions, uninstall the program +and return any program materials to RMC. If you downloaded the program and do not have disk media, please delete all copies, and cease using the +program. + + \ No newline at end of file diff --git a/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/16-appendix-a-glossary.mdx b/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/16-appendix-a-glossary.mdx new file mode 100644 index 000000000..1ad01774b --- /dev/null +++ b/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/16-appendix-a-glossary.mdx @@ -0,0 +1,189 @@ +--- +title: "Appendix A - Glossary" +--- + +import Link from "@docusaurus/Link"; +import addBaseUrl from "@docusaurus/useBaseUrl"; +import CitationFootnote from "@site/src/components/CitationFootnote"; +import NavContainer from "@site/src/components/NavContainer"; +import TableAcronyms from "@site/src/components/TableAcronyms"; +import TableVertical from "@site/src/components/TableVertical"; +import TableVerticalNoRef from '@site/src/components/TableVerticalNoRef'; +import VersionSelector from "@site/src/components/VersionSelector"; + + + +# Appendix A - Glossary + +## Abbreviations/Acronyms + + + +## Terms + + + + \ No newline at end of file diff --git a/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/17-appendix-b-eoe-questionnaire.mdx b/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/17-appendix-b-eoe-questionnaire.mdx new file mode 100644 index 000000000..7053d5242 --- /dev/null +++ b/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/17-appendix-b-eoe-questionnaire.mdx @@ -0,0 +1,463 @@ +--- +title: "Appendix B - Expert Opinion Elicitation Questionnaire" +--- + +import Link from "@docusaurus/Link"; +import addBaseUrl from "@docusaurus/useBaseUrl"; +import Citation from "@site/src/components/Citation"; +import CitationFootnote from "@site/src/components/CitationFootnote"; +import Equation from '@site/src/components/Equation'; +import EquationNoRef from '@site/src/components/EquationNoRef'; +import EquationReference from '@site/src/components/EquationReference'; +import Figure from "@site/src/components/Figure"; +import FigureInline from "@site/src/components/FigureInline"; +import FigReference from "@site/src/components/FigureReference"; +import NavContainer from "@site/src/components/NavContainer"; +import ProcessList from "@site/src/components/ProcessList"; +import TableReference from "@site/src/components/TableReference"; +import TableVertical from "@site/src/components/TableVertical"; +import TableVerticalNoRef from '@site/src/components/TableVerticalNoRef'; +import VersionSelector from "@site/src/components/VersionSelector"; + + + +# Appendix B - Expert Opinion Elicitation Questionnaire + +The following Expert Opinion Elicitation (EOE) questionnaire was created by social scientists Dennis Mileti and John Sorensen to collect information +about the issuance, diffusion, and content of public +alerts, warnings, and press releases for dam failures, controlled dam releases, and levee breaches or overtopping flooding in specific communities. The USACE +Dam and Levee Safety Program engaged with Mileti & Sorensen to better understand what motivates people to take protective actions during an emergency, and their +resulting research – *A Guide to Public Alerts and Warnings for Dam and Levee Emergencies* (2015) – was implemented +into the custom curve generation methodology described below. + +The expert elicitation process involves USACE specialists in life loss estimation and state and local experts in emergency response +(Emergency Management Agency [EMA]) working +together to develop a consensus on the characterization of the warning, mobilization, and evacuation process for specific flood scenarios. The EMAs +in those communities potentially impacted by a dam or levee safety flood emergency are asked the below series of approximately 50 questions related to their planning for and +standard operating procedures during emergency. These answers help Consequence Specialists identify the appropriate warning and response parameters +to use when estimating life safety risk for the dam or levee being studied. + +Contextual questions 1-4 were developed by USACE RMC and added to the questionnaire in 2022. These items reduce uncertainty pertaining to severity, timing, and proximity +of flooding to communities at risk. + +The data collected from these interviews are scored within the USACE-developed Excel generator for the Warning Issuance Curve, +Warning Diffusion Curve, and Protective Action Initiation Curve. Each default curve and information about the incorporation of this data into a LifeSim model is described +in Chapter Warning and Protective Action Parameters. + +Context-1, rowSpan: 1, colSpan: 1 }, + { value:
    C1-a
    , rowSpan: 1, colSpan: 1 }, + { value:
    C1-b
    , rowSpan: 1, colSpan: 1 }, + { value:
    C1-c
    , rowSpan: 1, colSpan: 1 }, + { value:
    C1-d
    , rowSpan: 1, colSpan: 1 }, + { value:
    C1-e
    , rowSpan: 1, colSpan: 1 }, + { value: Context-2, rowSpan: 1, colSpan: 1 }, + { value:
    C2-a
    , rowSpan: 1, colSpan: 1 }, + { value:
    C2-b
    , rowSpan: 1, colSpan: 1 }, + { value:
    C2-c
    , rowSpan: 1, colSpan: 1 }, + { value:
    C2-d
    , rowSpan: 1, colSpan: 1 }, + { value: Context-3, rowSpan: 1, colSpan: 1 }, + { value:
    C3-a
    , rowSpan: 1, colSpan: 1 }, + { value:
    C3-b
    , rowSpan: 1, colSpan: 1 }, + { value: Context-4, rowSpan: 1, colSpan: 1 }, + { value:
    C4
    , rowSpan: 1, colSpan: 1 }, + { value: 1, rowSpan: 1, colSpan: 1 }, + { value:
    1-a
    , rowSpan: 1, colSpan: 1 }, + { value:
    1-b
    , rowSpan: 1, colSpan: 1 }, + { value:
    1-c
    , rowSpan: 1, colSpan: 1 }, + { value:
    1-d
    , rowSpan: 1, colSpan: 1 }, + { value:
    1-e
    , rowSpan: 1, colSpan: 1 }, + { value:
    1-f
    , rowSpan: 1, colSpan: 1 }, + { value:
    1-g
    , rowSpan: 1, colSpan: 1 }, + { value: 2, rowSpan: 1, colSpan: 1 }, + { value: 3, rowSpan: 1, colSpan: 1 }, + { value: 4, rowSpan: 1, colSpan: 1 }, + { value: 5, rowSpan: 1, colSpan: 1 }, + { value: 6, rowSpan: 1, colSpan: 1 }, + { value: 7, rowSpan: 1, colSpan: 1 }, + { value: 8, rowSpan: 1, colSpan: 1 }, + { value:
    8-a
    , rowSpan: 1, colSpan: 1 }, + { value:
    8-b
    , rowSpan: 1, colSpan: 1 }, + { value:
    8-c
    , rowSpan: 1, colSpan: 1 }, + { value:
    8-d
    , rowSpan: 1, colSpan: 1 }, + { value:
    8-e
    , rowSpan: 1, colSpan: 1 }, + { value: 9, rowSpan: 1, colSpan: 1 }, + { value:
    9-a
    , rowSpan: 1, colSpan: 1 }, + { value:
    9-b
    , rowSpan: 1, colSpan: 1 }, + { value:
    9-c
    , rowSpan: 1, colSpan: 1 }, + { value:
    9-d
    , rowSpan: 1, colSpan: 1 }, + { value: 10, rowSpan: 1, colSpan: 1 }, + { value: 11, rowSpan: 1, colSpan: 1 }, + { value: 12, rowSpan: 1, colSpan: 1 }, + { value:
    12-a
    , rowSpan: 1, colSpan: 1 }, + { value:
    12-b
    , rowSpan: 1, colSpan: 1 }, + { value:
    12-c
    , rowSpan: 1, colSpan: 1 }, + { value: 13, rowSpan: 1, colSpan: 1 }, + { value:
    13-a
    , rowSpan: 1, colSpan: 1 }, + { value: 14, rowSpan: 1, colSpan: 1 }, + { value:
    14-a
    , rowSpan: 1, colSpan: 1 }, + { value:
    14-b
    , rowSpan: 1, colSpan: 1 }, + { value:
    14-c
    , rowSpan: 1, colSpan: 1 }, + { value:
    14-d
    , rowSpan: 1, colSpan: 1 }, + { value: 15, rowSpan: 1, colSpan: 1 }, + { value:
    15-a
    , rowSpan: 1, colSpan: 1 }, + { value: 16, rowSpan: 1, colSpan: 1 }, + { value:
    16-a
    , rowSpan: 1, colSpan: 1 }, + { value:
    16-b
    , rowSpan: 1, colSpan: 1 }, + { value:
    16-c
    , rowSpan: 1, colSpan: 1 }, + { value: 17, rowSpan: 1, colSpan: 1 }, + { value:
    17-a
    , rowSpan: 1, colSpan: 1 }, + { value: 18, rowSpan: 1, colSpan: 1 }, + { value:
    18-a
    , rowSpan: 1, colSpan: 1 }, + { value: 19, rowSpan: 1, colSpan: 1 }, + { value:
    19-a
    , rowSpan: 1, colSpan: 1 }, + { value:
    19-b
    , rowSpan: 1, colSpan: 1 }, + { value: 20, rowSpan: 1, colSpan: 1 }, + { value: 21, rowSpan: 1, colSpan: 1 }, + { value:
    21-a
    , rowSpan: 1, colSpan: 1 }, + { value: 22, rowSpan: 1, colSpan: 1 }, + { value:
    22-1
    , rowSpan: 1, colSpan: 1 }, + { value:
    22-2
    , rowSpan: 1, colSpan: 1 }, + { value:
    22-3
    , rowSpan: 1, colSpan: 1 }, + { value:
    22-4
    , rowSpan: 1, colSpan: 1 }, + { value:
    22-5
    , rowSpan: 1, colSpan: 1 }, + { value:
    22-6
    , rowSpan: 1, colSpan: 1 }, + { value:
    22-7
    , rowSpan: 1, colSpan: 1 }, + { value:
    22-8
    , rowSpan: 1, colSpan: 1 }, + { value:
    22-9
    , rowSpan: 1, colSpan: 1 }, + { value:
    22-10
    , rowSpan: 1, colSpan: 1 }, + { value:
    22-11
    , rowSpan: 1, colSpan: 1 }, + { value:
    22-12
    , rowSpan: 1, colSpan: 1 }, + { value:
    22-13
    , rowSpan: 1, colSpan: 1 }, + { value:
    22-14
    , rowSpan: 1, colSpan: 1 }, + { value:
    22-15
    , rowSpan: 1, colSpan: 1 }, + { value:
    22-16
    , rowSpan: 1, colSpan: 1 }, + { value:
    22-17
    , rowSpan: 1, colSpan: 1 }, + { value:
    22-18
    , rowSpan: 1, colSpan: 1 }, + { value:
    22-19
    , rowSpan: 1, colSpan: 1 }, + { value:
    22-20
    , rowSpan: 1, colSpan: 1 }, + { value: 23, rowSpan: 1, colSpan: 1 }, + { value:
    23-a
    , rowSpan: 1, colSpan: 1 }, + { value:
    23-b
    , rowSpan: 1, colSpan: 1 }, + { value:
    23-c
    , rowSpan: 1, colSpan: 1 }, + { value:
    23-d
    , rowSpan: 1, colSpan: 1 }, + { value:
    23-e
    , rowSpan: 1, colSpan: 1 }, + { value:
    23-f
    , rowSpan: 1, colSpan: 1 }, + { value:
    23-g
    , rowSpan: 1, colSpan: 1 }, + { value:
    23-h
    , rowSpan: 1, colSpan: 1 }, + { value: 24, rowSpan: 1, colSpan: 1 }, + { value:
    24-a
    , rowSpan: 1, colSpan: 1 }, + { value: 25, rowSpan: 1, colSpan: 1 }, + { value:
    25-a
    , rowSpan: 1, colSpan: 1 }, + { value:
    25-b
    , rowSpan: 1, colSpan: 1 }, + { value: 26, rowSpan: 1, colSpan: 1 }, + { value:
    26-a
    , rowSpan: 1, colSpan: 1 }, + { value:
    26-b
    , rowSpan: 1, colSpan: 1 }, + { value:
    26-c
    , rowSpan: 1, colSpan: 1 }, + { value:
    26-d
    , rowSpan: 1, colSpan: 1 }, + { value:
    26-e
    , rowSpan: 1, colSpan: 1 }, + { value:
    26-f
    , rowSpan: 1, colSpan: 1 }, + { value:
    26-g
    , rowSpan: 1, colSpan: 1 }, + { value:
    26-h
    , rowSpan: 1, colSpan: 1 }, + { value:
    26-i
    , rowSpan: 1, colSpan: 1 }, + { value:
    26-j
    , rowSpan: 1, colSpan: 1 }, + { value:
    26-k
    , rowSpan: 1, colSpan: 1 }, + { value:
    26-l
    , rowSpan: 1, colSpan: 1 }, + { value:
    26-m
    , rowSpan: 1, colSpan: 1 }, + { value: 27, rowSpan: 1, colSpan: 1 }, + { value:
    27-a
    , rowSpan: 1, colSpan: 1 }, + { value: 28, rowSpan: 1, colSpan: 1 }, + { value:
    28-a
    , rowSpan: 1, colSpan: 1 }, + { value: 29, rowSpan: 1, colSpan: 1 }, + { value:
    29-a
    , rowSpan: 1, colSpan: 1 }, + { value:
    29-b
    , rowSpan: 1, colSpan: 1 }, + { value: 30, rowSpan: 1, colSpan: 1 }, + { value:
    30-a
    , rowSpan: 1, colSpan: 1 }, + { value:
    30-b
    , rowSpan: 1, colSpan: 1 }, + { value: 31, rowSpan: 1, colSpan: 1 }, + { value:
    31-a
    , rowSpan: 1, colSpan: 1 }, + { value: 32, rowSpan: 1, colSpan: 1 }, + { value:
    32-a
    , rowSpan: 1, colSpan: 1 }, + { value: 33, rowSpan: 1, colSpan: 1 }, + { value:
    33-a
    , rowSpan: 1, colSpan: 1 }, + { value:
    33-b
    , rowSpan: 1, colSpan: 1 }, + { value: 34, rowSpan: 1, colSpan: 1 }, + { value:
    34-a
    , rowSpan: 1, colSpan: 1 }, + { value:
    34-b
    , rowSpan: 1, colSpan: 1 }, + { value: 35, rowSpan: 1, colSpan: 1 }, + { value:
    35-a
    , rowSpan: 1, colSpan: 1 }, + { value: 36, rowSpan: 1, colSpan: 1 }, + { value:
    36-a
    , rowSpan: 1, colSpan: 1 }, + { value: 37, rowSpan: 1, colSpan: 1 }, + { value:
    37-a
    , rowSpan: 1, colSpan: 1 }, + { value:
    37-b
    , rowSpan: 1, colSpan: 1 }, + { value:
    37-c
    , rowSpan: 1, colSpan: 1 }, + { value:
    37-d
    , rowSpan: 1, colSpan: 1 }, + { value:
    37-e
    , rowSpan: 1, colSpan: 1 }, + { value:
    37-f
    , rowSpan: 1, colSpan: 1 }, + { value:
    37-g
    , rowSpan: 1, colSpan: 1 }, + { value: 38, rowSpan: 1, colSpan: 1 }, + { value:
    38-a
    , rowSpan: 1, colSpan: 1 }, + { value:
    38-b
    , rowSpan: 1, colSpan: 1 }, + { value: 39, rowSpan: 1, colSpan: 1 }, + { value: 40, rowSpan: 1, colSpan: 1 }, + { value: 41, rowSpan: 1, colSpan: 1 }, + { value:
    41-a
    , rowSpan: 1, colSpan: 1 }, + { value: 42, rowSpan: 1, colSpan: 1 }, + { value: 43, rowSpan: 1, colSpan: 1 }, + { value:
    43-a
    , rowSpan: 1, colSpan: 1 }, + { value: 44, rowSpan: 1, colSpan: 1 }, + { value: 45, rowSpan: 1, colSpan: 1 }, + { value:
    45-a
    , rowSpan: 1, colSpan: 1 }, + { value:
    45-b
    , rowSpan: 1, colSpan: 1 }, + { value:
    45-c
    , rowSpan: 1, colSpan: 1 }, + { value:
    45-d
    , rowSpan: 1, colSpan: 1 }, + { value:
    45-e
    , rowSpan: 1, colSpan: 1 }, + { value:
    45-f
    , rowSpan: 1, colSpan: 1 }, + { value:
    45-g
    , rowSpan: 1, colSpan: 1 }, + { value:
    45-h
    , rowSpan: 1, colSpan: 1 }, + { value:
    45-i
    , rowSpan: 1, colSpan: 1 }, + { value:
    45-j
    , rowSpan: 1, colSpan: 1 }, + { value:
    45-j-a
    , rowSpan: 1, colSpan: 1 }, + { value: 46, rowSpan: 1, colSpan: 1 }, + { value:
    46-a
    , rowSpan: 1, colSpan: 1 }, + { value:
    46-b
    , rowSpan: 1, colSpan: 1 }, + { value: 47, rowSpan: 1, colSpan: 1 }, + { value:
    47-a
    , rowSpan: 1, colSpan: 1 }, + { value:
    47-b
    , rowSpan: 1, colSpan: 1 }, + { value: 48, rowSpan: 1, colSpan: 1 }, + { value: 49, rowSpan: 1, colSpan: 1 }, + { value: 50, rowSpan: 1, colSpan: 1 }, + { value: 51, rowSpan: 1, colSpan: 1 }, + { value: 52, rowSpan: 1, colSpan: 1 }, + ], + [ + { value: Which hazards are present in the scenario?, rowSpan: 1, colSpan: 1 }, + { value:
    Dam or levee breach?
    , rowSpan: 1, colSpan: 1 }, + { value:
    Non-failure releases from a structure that may result in the inundation of PAR?
    , rowSpan: 1, colSpan: 1 }, + { value:
    Flash flooding (not caused by releases)?
    , rowSpan: 1, colSpan: 1 }, + { value:
    Slow rising riverine flood?
    , rowSpan: 1, colSpan: 1 }, + { value:
    Hurricane?
    , rowSpan: 1, colSpan: 1 }, + { value: Describe the flood severity:, rowSpan: 1, colSpan: 1 }, + { value:
    Is PAR likely to perceive flooding as life threatening?
    , rowSpan: 1, colSpan: 1 }, + { value:
    Will PAR be able to respond to environmental cues?
    , rowSpan: 1, colSpan: 1 }, + { value:
    If a hurricane is the risk driving hazard, is the storm likely to be Category 4 or 5?
    , rowSpan: 1, colSpan: 1 }, + { value:
    If a hurricane is the risk driving hazard, is the storm likely to be Category 3?
    , rowSpan: 1, colSpan: 1 }, + { value: Describe the proximity of the impact area relative to a hazard source:, rowSpan: 1, colSpan: 1 }, + { value:
    Is the impact area within 3 miles of a dam or within 0.25 miles of a levee?
    , rowSpan: 1, colSpan: 1 }, + { value:
    Is the impact area within 0.5 miles of a body of water, or within an area known to the public to be at-risk of flooding?
    , rowSpan: 1, colSpan: 1 }, + { value: Describe arrival time of the flood hazard relative to warning:, rowSpan: 1, colSpan: 1 }, + { value:
    Will the hazard arrive within 2 hours of the warning issuance?
    , rowSpan: 1, colSpan: 1 }, + { value: Which of the following flood threats could affect your community:, rowSpan: 1, colSpan: 1 }, + { value:
    Dam breaches?
    , rowSpan: 1, colSpan: 1 }, + { value:
    Damaging dam releases?
    , rowSpan: 1, colSpan: 1 }, + { value:
    Levee breach or overtopping?
    , rowSpan: 1, colSpan: 1 }, + { value:
    Flash flooding?
    , rowSpan: 1, colSpan: 1 }, + { value:
    Riverine flooding?
    , rowSpan: 1, colSpan: 1 }, + { value:
    Other flood types?
    , rowSpan: 1, colSpan: 1 }, + { value:
    (IF YES) What other flood types?
    , rowSpan: 1, colSpan: 1 }, + { value: Are the boundaries identified for the areas of your community that would be flooded for the full range of potential flood scenarios?, rowSpan: 1, colSpan: 1 }, + { value: Do you have a general emergency plan?, rowSpan: 1, colSpan: 1 }, + { value: Do you have a general warning plan or annex to a general plan?, rowSpan: 1, colSpan: 1 }, + { value: Do you have standard operating procedures for warnings?, rowSpan: 1, colSpan: 1 }, + { value: Do you have a hazard-specific warning plan for flooding including breach scenarios?, rowSpan: 1, colSpan: 1 }, + { value: Do you have a hazard-specific standard operating procedures for flooding including breach scenarios?, rowSpan: 1, colSpan: 1 }, + { value: Is a particular person or position responsible for getting a first alert or warning out to the public?, rowSpan: 1, colSpan: 1 }, + { value:
    (If YES to 8) What is their name and title?
    , rowSpan: 1, colSpan: 1 }, + { value:
    (If YES to 8) Do they have legal authority to do so?
    , rowSpan: 1, colSpan: 1 }, + { value:
    (IF NO to 8) What is the name and title of who does?
    , rowSpan: 1, colSpan: 1 }, + { value:
    Is the responsible person or position written down?
    , rowSpan: 1, colSpan: 1 }, + { value:
    (If YES to 8-d) Where?
    , rowSpan: 1, colSpan: 1 }, + { value: Would responsibilities pass from one person to another if someone were not available to perform their first alert or warning roles?, rowSpan: 1, colSpan: 1 }, + { value:
    (If YES to 9) How would it be done?
    , rowSpan: 1, colSpan: 1 }, + { value:
    (If YES to 9) How would the people involved know how to do it?
    , rowSpan: 1, colSpan: 1 }, + { value:
    (IF YES to 9) Is how to do it written down?
    , rowSpan: 1, colSpan: 1 }, + { value:
    (If YES to 9-c) Where?
    , rowSpan: 1, colSpan: 1 }, + { value: Do you have a staffed contact point that operates 24 hours per day 7 days a week to receive threat information from those who might detect it?, rowSpan: 1, colSpan: 1 }, + // GET LINK TO MATRIX CARD? + { value: Do your plans, procedures, or other written documents classify threat levels into different categories (for example, flood watch and flood warning), and specify different public actions for each level? Here's an example (SHOW MATRIX CARD) of what I mean., rowSpan: 1, colSpan: 1 }, + { value: What would trigger sending a first alert or warning to the public? , rowSpan: 1, colSpan: 1 }, + { value:
    How would you know when the trigger is reached?
    , rowSpan: 1, colSpan: 1 }, + { value:
    Is anything about the trigger written down?
    , rowSpan: 1, colSpan: 1 }, + { value:
    (IF YES to 12-b) Where?
    , rowSpan: 1, colSpan: 1 }, + { value: Would you seek to confirm the flood threat before distributing a first public alert or warning?, rowSpan: 1, colSpan: 1 }, + { value:
    Are there written procedures about threat confirmation?
    , rowSpan: 1, colSpan: 1 }, + { value: Would you communicate with the agency responsible for the dam or levee before distributing a first public alert or warning, for example, so you could ask questions and get answers?, rowSpan: 1, colSpan: 1 }, + { value:
    (If YES to 14) How would it be done?
    , rowSpan: 1, colSpan: 1 }, + { value:
    (If YES to 14) How would you know how to do that?
    , rowSpan: 1, colSpan: 1 }, + { value:
    (If YES to 14) Is how to do it written down?
    , rowSpan: 1, colSpan: 1 }, + { value:
    (If YES to 14-c) Where?
    , rowSpan: 1, colSpan: 1 }, + { value: Are the name(s) and number(s) of the people to talk with in the agency responsible for the dam or levee written down and readily available?, rowSpan: 1, colSpan: 1 }, + { value:
    (If YES to 15) Where?
    , rowSpan: 1, colSpan: 1 }, + { value: Do you have redundant technologies available for communicating with people in the agency responsible for the dam or levee?, rowSpan: 1, colSpan: 1 }, + { value:
    (If YES to 16) What are they?
    , rowSpan: 1, colSpan: 1 }, + { value:
    (If YES to 16) Would any work if the electricity were out?
    , rowSpan: 1, colSpan: 1 }, + { value:
    (If YES to 16) Would any work if the community were damaged?
    , rowSpan: 1, colSpan: 1 }, + { value: Do the people who would issue a first alert or warning routinely communicate with the people responsible for the dam or levee?, rowSpan: 1, colSpan: 1 }, + { value:
    (If YES to 17) How often? (times/year)
    , rowSpan: 1, colSpan: 1 }, + { value: Are the people who would issue a first alert or warning allowed to get that job done in innovative ways if circumstances keep them from doing it according to procedures?, rowSpan: 1, colSpan: 1 }, + { value:
    (if YES to 18) Is their ability to do this part of your written procedures?
    , rowSpan: 1, colSpan: 1 }, + { value: Do you have unique ways to provide first alerts or warnings for events in which impact could occur in an hour or less, for example, send a first alert or warning out without getting clearance from anyone?, rowSpan: 1, colSpan: 1 }, + { value:
    (If YES to 19) How would it be done?
    , rowSpan: 1, colSpan: 1 }, + { value:
    (If YES to 19) Is how to do it written down?
    , rowSpan: 1, colSpan: 1 }, + { value: How many people would likely be involved in deciding and/or approving issuing a first alert of warning? , rowSpan: 1, colSpan: 1 }, + { value: Do the people who have a role in getting a first alert or warning to the public practice doing that job, for example, in drills or exercises?, rowSpan: 1, colSpan: 1 }, + { value:
    (If YES to 21) How often? (times/year)
    , rowSpan: 1, colSpan: 1 }, + { value: Which of the following ways to disseminate alerts and warnings would you use to get the first alert or warning to the public?, rowSpan: 1, colSpan: 1 }, + { value:
    Route alerting
    , rowSpan: 1, colSpan: 1 }, + { value:
    Fixed location loudspeakers & public address systems
    , rowSpan: 1, colSpan: 1 }, + { value:
    Wireless emergency alerts that use the WEA opt-out system
    , rowSpan: 1, colSpan: 1 }, + { value:
    Wireless emergency alerts that use an SMS opt-in system like Everbridge
    , rowSpan: 1, colSpan: 1 }, + { value:
    Radio
    , rowSpan: 1, colSpan: 1 }, + { value:
    Television
    , rowSpan: 1, colSpan: 1 }, + { value:
    NOAA Weather Radio
    , rowSpan: 1, colSpan: 1 }, + { value:
    Tone alert radios dedicated to dam or levee emergencies
    , rowSpan: 1, colSpan: 1 }, + { value:
    Audio sirens and alarms
    , rowSpan: 1, colSpan: 1 }, + { value:
    Broadcast voice sirens
    , rowSpan: 1, colSpan: 1 }, + { value:
    Message signs
    , rowSpan: 1, colSpan: 1 }, + { value:
    Aircraft
    , rowSpan: 1, colSpan: 1 }, + { value:
    Visual alerting
    , rowSpan: 1, colSpan: 1 }, + { value:
    Email to the public
    , rowSpan: 1, colSpan: 1 }, + { value:
    Text messages not including WEA
    , rowSpan: 1, colSpan: 1 }, + { value:
    Social media, e.g., Twitter and Facebook
    , rowSpan: 1, colSpan: 1 }, + { value:
    Website(s)
    , rowSpan: 1, colSpan: 1 }, + { value:
    Reverse auto-dial telephone distribution system
    , rowSpan: 1, colSpan: 1 }, + { value:
    Tdd/Tyy
    , rowSpan: 1, colSpan: 1 }, + { value:
    Other
    , rowSpan: 1, colSpan: 1 }, + { value: The following questions help to gauge the effectiveness of each warning system identified above. (ONLY ASK ABOUT ITEMS SELECTED IN QUESTIONS 22), rowSpan: 1, colSpan: 1 }, + { value:
    How many patrol cars and officers would be dedicated to route alertings?
    , rowSpan: 1, colSpan: 1 }, + { value:
    What percentage of the population has NOAA Weather Radio or dedicated tone alert radios?
    , rowSpan: 1, colSpan: 1 }, + { value:
    Would a significant portion (large percentage or those closest to hazard) of the at risk population be alerted by audio or broadcast sirens or fixed location loudspeakers?
    , rowSpan: 1, colSpan: 1 }, + { value:
    Have you successfully issued warnings or alerts through the WEA system in the past?
    , rowSpan: 1, colSpan: 1 }, + { value:
    How many aircraft would be dedicated to spreading warnings?
    , rowSpan: 1, colSpan: 1 }, + { value:
    What percentage of the public is engaged with your social media activities?
    , rowSpan: 1, colSpan: 1 }, + { value:
    What percentage of the public has signed up their cell phone number in the reverse autodial system or email notification system?
    , rowSpan: 1, colSpan: 1 }, + { value:
    How many calls/hour can the reverse autodial system make?
    , rowSpan: 1, colSpan: 1 }, + { value: If an update to a warning message were not needed, would the original message be repeated more than once?, rowSpan: 1, colSpan: 1 }, + { value:
    (If YES to 24) How frequently would it be repeated?
    , rowSpan: 1, colSpan: 1 }, + { value: Do you have ways to monitoring what other organizations or people in the public might be saying about the threat to each other, for example, over social media?, rowSpan: 1, colSpan: 1 }, + { value:
    (If YES to 25) How would it be done?
    , rowSpan: 1, colSpan: 1 }, + { value:
    (If YES to 25) Would you attempt to correct wrong information?
    , rowSpan: 1, colSpan: 1 }, + { value: Could there be a significant number of people engaged in any of the following activities, in any of the following locations, or in any of the following groups when alerts or warnings are issued, and do you have special ways to provide them with a first alert or warning?, rowSpan: 1, colSpan: 1 }, + { value:
    Boating
    , rowSpan: 1, colSpan: 1 }, + { value:
    Camping
    , rowSpan: 1, colSpan: 1 }, + { value:
    Hiking
    , rowSpan: 1, colSpan: 1 }, + { value:
    Recreational activities near water
    , rowSpan: 1, colSpan: 1 }, + { value:
    Hospitals
    , rowSpan: 1, colSpan: 1 }, + { value:
    Group homes
    , rowSpan: 1, colSpan: 1 }, + { value:
    Prisons
    , rowSpan: 1, colSpan: 1 }, + { value:
    Shopping centers
    , rowSpan: 1, colSpan: 1 }, + { value:
    Schools
    , rowSpan: 1, colSpan: 1 }, + { value:
    Agricultural workers in fields
    , rowSpan: 1, colSpan: 1 }, + { value:
    Transients
    , rowSpan: 1, colSpan: 1 }, + { value:
    Homeless
    , rowSpan: 1, colSpan: 1 }, + { value:
    Unique subcultures, e.g., the Amish
    , rowSpan: 1, colSpan: 1 }, + { value: Do you have a special way to deliver a first alert or warning message to people very close to the dam and/or levee?, rowSpan: 1, colSpan: 1 }, + { value:
    (If YES to 27) How would it be done?
    , rowSpan: 1, colSpan: 1 }, + { value: Do you have a way to wake people up at night when they might be sleeping to provide them with a first alert or warning?, rowSpan: 1, colSpan: 1 }, + { value:
    (If YES to 28) How would it be done?
    , rowSpan: 1, colSpan: 1 }, + { value: Do you have a way to deliver alerts and warnings to people who are hearing-impaired?, rowSpan: 1, colSpan: 1 }, + { value:
    (If YES to 29) How?
    , rowSpan: 1, colSpan: 1 }, + { value:
    (If YES to 29) What has been done to assist the hearing-impaired in obtaining the specialized equipment or technology they need to be able to receive alerts and warnings?
    , rowSpan: 1, colSpan: 1 }, + { value: Do you have a way to deliver alerts and warnings to people who are visually-impaired?, rowSpan: 1, colSpan: 1 }, + { value:
    (If YES to 30) How?
    , rowSpan: 1, colSpan: 1 }, + { value:
    (If YES to 30) What has been done to assist the visually-impaired in obtaining the specialized equipment or technology they need to be able to receive alerts and warnings?
    , rowSpan: 1, colSpan: 1 }, + { value: Do you provide alerts and warnings in foreign languages for people who only speak a foreign language?, rowSpan: 1, colSpan: 1 }, + { value:
    Are you missing any languages that make up a significant portion of the population?
    , rowSpan: 1, colSpan: 1 }, + { value: Do you have the plans and technology in place to alert and warn people if infrastructure were disrupted, for example, from a lack of electricity, damage to streets that might be used for route alerting, or damage to an outdoor siren system?, rowSpan: 1, colSpan: 1 }, + { value:
    (If YES to 32) What are they?
    , rowSpan: 1, colSpan: 1 }, + { value: Do you have example alerts, warnings and/or emergency press releases or templates to use as guides during an event?, rowSpan: 1, colSpan: 1 }, + { value:
    (If YES to 33) What does each of them say?
    , rowSpan: 1, colSpan: 1 }, + { value:
    (If YES to 33) May I have copies of them?
    , rowSpan: 1, colSpan: 1 }, + { value: Have you recently issued any alerts, warnings and/or emergency press releases to the public?, rowSpan: 1, colSpan: 1 }, + { value:
    (If YES to 34) When and for what?
    , rowSpan: 1, colSpan: 1 }, + { value:
    (If YES to 34) May I have copies of them?
    , rowSpan: 1, colSpan: 1 }, + { value: Would you name a source in the public alerts, warnings, and press releases that you issue?, rowSpan: 1, colSpan: 1 }, + { value:
    (If YES to 35) Who would be named including job title and affiliation?
    , rowSpan: 1, colSpan: 1 }, + { value: Would you recommend in alerts, warnings and press releases that the public take specific protective actions, for example, evacuate, move vertically, or check local media?, rowSpan: 1, colSpan: 1 }, + { value:
    (If YES to 36) What specific public actions would be recommended for each flood threat level?
    , rowSpan: 1, colSpan: 1 }, + { value: Would the alerts, warnings and emergency press releases you issue tell the public about any of the following?, rowSpan: 1, colSpan: 1 }, + { value:
    The consequences of the flood and why taking the recommended protective action(s) would reduce them?
    , rowSpan: 1, colSpan: 1 }, + { value:
    The time people should begin and complete taking the recommended protective action?
    , rowSpan: 1, colSpan: 1 }, + { value:
    The boundaries of the areas that would be flooded?
    , rowSpan: 1, colSpan: 1 }, + { value:
    Why people who are safe, but located close to an area being evacuated have no reason to evacuate?
    , rowSpan: 1, colSpan: 1 }, + { value:
    What parents should do about their children who might still be in school?
    , rowSpan: 1, colSpan: 1 }, + { value:
    What to do with pets and animals when taking a protective action?
    , rowSpan: 1, colSpan: 1 }, + { value:
    The weather outside if a flood was happening on a sunny day?
    , rowSpan: 1, colSpan: 1 }, + { value: Would the alerts, warnings and emergency press releases you issue have either of the following characteristics?, rowSpan: 1, colSpan: 1 }, + { value:
    Would they be specific, for example, if people are asked to evacuate by describing the details of evacuation such as the routes they should take, what boundaries they should cross to reach safety, and the time by when they should get there?
    , rowSpan: 1, colSpan: 1 }, + { value:
    Would they be clear, for example, by not using words like probable maximum flood, uncontrolled release, and breach, and instead use words that everyone can understand?
    , rowSpan: 1, colSpan: 1 }, + { value: Would the alerts, warnings and emergency press releases you issue say anything different for people who might be close to where the flooding would begin versus people who are far away?, rowSpan: 1, colSpan: 1 }, + { value: Would the alerts, warnings and emergency press releases you issue be different if impact is imminent, for example, within minutes to an hour?, rowSpan: 1, colSpan: 1 }, + { value: Would you work with other flood threatened political jurisdictions, for example, other counties or cities, to coordinate the content of public alerts, warnings and/or emergency press releases?, rowSpan: 1, colSpan: 1 }, + { value:
    (If YES to 41) How would you do that?
    , rowSpan: 1, colSpan: 1 }, + { value: Do the people who write and issue public alerts, warnings and press releases practice doing so in drills, exercises or in other ways?, rowSpan: 1, colSpan: 1 }, + { value: Do you have a program in place to provide public education to motivate household preparedness among people in your community who live in areas that could flood?, rowSpan: 1, colSpan: 1 }, + { value:
    (If YES to 43) Please describe that public education program and any material that might be part of it?
    , rowSpan: 1, colSpan: 1 }, + { value: Would you say people in your community who live in areas that could flood are adequately prepared?, rowSpan: 1, colSpan: 1 }, + { value: Has your community experienced a flood in the last 20 years?, rowSpan: 1, colSpan: 1 }, + { value:
    (If YES to 45) In what year did it happen?
    , rowSpan: 1, colSpan: 1 }, + { value:
    How severe was it?
    , rowSpan: 1, colSpan: 1 }, + { value:
    Were members of the public asked to evacuate?
    , rowSpan: 1, colSpan: 1 }, + { value:
    (If YES to 45-c) What percentage of the total population that could be at risk to flooding in your community were asked to evacuate?
    , rowSpan: 1, colSpan: 1 }, + { value:
    What percentage of the population asked to evacuate did so?
    , rowSpan: 1, colSpan: 1 }, + { value:
    How many hours did it take to accomplish the evacuation?
    , rowSpan: 1, colSpan: 1 }, + { value:
    Did you encounter any problems in managing the emergency?
    , rowSpan: 1, colSpan: 1 }, + { value:
    (If YES to 45-g) What were those problems?
    , rowSpan: 1, colSpan: 1 }, + { value:
    What have you done to correct for those problems since then?
    , rowSpan: 1, colSpan: 1 }, + { value:
    Have you made other emergency management changes since then that would influence your response to a future emergency?
    , rowSpan: 1, colSpan: 1 }, + { value:
    (If YES to 45-j) What were they?
    , rowSpan: 1, colSpan: 1 }, + { value: Have warnings been issued in your community recently about an impending emergency including floods and other types of hazards that asked people to take some sort of protective action?, rowSpan: 1, colSpan: 1 }, + { value:
    (If YES to 46) How many times?
    , rowSpan: 1, colSpan: 1 }, + { value:
    (If YES to 46) When?
    , rowSpan: 1, colSpan: 1 }, + { value: If a flood event were to occur in your community, what percentage of the people advised to take the following actions would you expect to actually do so?, rowSpan: 1, colSpan: 1 }, + { value:
    Move vertically? ________%
    , rowSpan: 1, colSpan: 1 }, + { value:
    Evacuate out of the flood inundation area? ________%
    , rowSpan: 1, colSpan: 1 }, + { value: What percentage of your at risk population did not graduate from high school? ________%, rowSpan: 1, colSpan: 1 }, + { value: What percentage of your at risk population are unemployed? ________%, rowSpan: 1, colSpan: 1 }, + { value: + What percentage of your at risk population have a median annual before tax household income below the poverty level, which is $33,207 (U.S. Census Bureau, 2026) per year for a family of four? ________%, + rowSpan: 1, + colSpan: 1 + }, + { value: What percentage of your at risk population are homeless? ________%, rowSpan: 1, colSpan: 1 }, + { value: Are there members of your at risk population who live in a neighborhood that is cut off from everyone else in your community for reasons that might include extreme poverty, race, religion, lifestyle, or other factors?, rowSpan: 1, colSpan: 1 }, + ], + [ + // Response column — intentionally blank for all rows (fillable checklist) + { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, + { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, + { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, + { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, + { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, + { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, + { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, + { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, + { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, + { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, + { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, + { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, + { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, { value: "", rowSpan: 1, colSpan: 1 }, + ], + ] + } + alt="Mileti and Sorensen Flood Threat Questionnaire" + colWidths={[10, "auto", "14%"]} +/> + + \ No newline at end of file diff --git a/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/18-appendix-c-excerpt-from-first-alert-or-warning-diffusion-time.mdx b/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/18-appendix-c-excerpt-from-first-alert-or-warning-diffusion-time.mdx new file mode 100644 index 000000000..276044bb9 --- /dev/null +++ b/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/18-appendix-c-excerpt-from-first-alert-or-warning-diffusion-time.mdx @@ -0,0 +1,721 @@ +--- +title: "Appendix C - Excerpt from First Alert or Warning Diffusion Time Estimation for Dam Breaches, Controlled Dam Releases and Levee Breaches or Overtopping" +--- + +import Link from "@docusaurus/Link"; +import addBaseUrl from "@docusaurus/useBaseUrl"; +import Citation from "@site/src/components/Citation"; +import CitationFootnote from "@site/src/components/CitationFootnote"; +import Equation from '@site/src/components/Equation'; +import EquationNoRef from '@site/src/components/EquationNoRef'; +import EquationReference from '@site/src/components/EquationReference'; +import Figure from "@site/src/components/Figure"; +import FigureInline from "@site/src/components/FigureInline"; +import FigReference from "@site/src/components/FigureReference"; +import NavContainer from "@site/src/components/NavContainer"; +import ProcessList from "@site/src/components/ProcessList"; +import TableReference from "@site/src/components/TableReference"; +import TableVertical from "@site/src/components/TableVertical"; +import VersionSelector from "@site/src/components/VersionSelector"; + + + +# Appendix C - Excerpt from First Alert or Warning Diffusion Time Estimation for Dam Breaches, Controlled Dam Releases and Levee Breaches or Overtopping + +The following is excerpted from an undated document produced for the USACE Risk Management Center by John H. Sorensen and Dennis S. Mileti titled +First Alert or Warning Diffusion Time Estimation for Dam Breaches, Controlled Dam Releases and Levee Breaches or Overtopping. The full draft +document is available here. + +## Previous Research on Diffusion Curves + +In this section of this working paper we present a brief overview of previous research on warning diffusion including point estimates of first alert +diffusion curves for discrete events, daytime versus nighttime estimates, and 3 models including the Rogers and Sorensen model, the Lindell model, and +the Klaftt model. We used the author's terminology and definitions in presenting the findings of their research and did not seek to compare variations +in usage of terms. By default, we accepted the researcher's definition of the population studied and sampling frame. This makes comparisons and +normalization of data difficult. For example, some researchers studied the population defined to be at risk, others studied people in areas that +evacuated, some investigated the population targeted with warnings, others the population who received the warnings, and still others people in a +geopolitical area in which an event occurred. + +### Historical Event Estimates for Diffusion Rates + +We were able to locate over two-dozen historical events in which data about first alert diffusion were presented by researchers. First alert diffusion +data was largely not the prime motive for conducting the research in the published record. Hence, the type of available data that exists across +historical event varies widely. These data, the events from which they were collected, and reference to the publication that contains the data are +presented in . How these distributions might have changed given today's technologies and social climate is +an important research question. + +A review of the first alert dissemination channels across events presented in illustrates that history provides wide variation in the +first alert diffusion effectiveness of any one type of alert channel. The same wide variation can be observed, to the extent that data is available, on the +length of time that was needed to provide a first alert to virtually the whole population across the included events. + +Drabek and Stephenson, 1971 , rowSpan: 1, colSpan: 1 }, + { value: <>Perry and Mushkatel, 1986 , rowSpan: 1, colSpan: 1 }, + { value: <>Perry et al., 1981 , rowSpan: 4, colSpan: 1 }, + null, + null, + null, + { value: <>Perry and Greene, 1983 , rowSpan: 2, colSpan: 1 }, + null, + { value: <>Dillman et al., 1983 , rowSpan: 1, colSpan: 1 }, + { value: <>Leik et al., 1981 , rowSpan: 10, colSpan: 1 }, + null, + null, + null, + null, + null, + null, + null, + null, + null, + { value: <>Burton, 1981 , rowSpan: 1, colSpan: 1 }, + { value: <>Perry and Mushkatel, 1986 , rowSpan: 2, colSpan: 1 }, + null, + { value: <>Rogers and Sorensen, 1989 , rowSpan: 2, colSpan: 1 }, + null, + { value: <>Duclos et al., 1989 ; Sorensen, 1992 , rowSpan: 1, colSpan: 1 }, + { value: <>Vogt and Sorensen 1999 , rowSpan: 1, colSpan: 1 }, + { value: <>Mitchell et al., 2005 , rowSpan: 1, colSpan: 1 }, + { value: <>Duclos et al., 1987 , rowSpan: 1, colSpan: 1 }, + { value: <>Sorensen et al., 2009 , rowSpan: 1, colSpan: 1 }, + { value: <>Paul et al., 2003 , rowSpan: 1, colSpan: 1 }, + { value: <>Gruntfest and Benight, 2005 , rowSpan: 1, colSpan: 1 }, + { value: <>Averill et al., 2005 , rowSpan: 1, colSpan: 1 } + ] + ] + } + alt="Source of first alert or warning in historical events (in percent)." + caption="Source of first alert or warning in historical events (in percent)." + colWidths={["auto"]} + widthMode="intrinsic" +/> + +### Nanticoke Diffusion Curve + +A fire that threatened to burn toxic chemicals onsite at the Spencer Metal Processing Plant caused the warning and evacuation at Nanticoke, +Pennsylvania. The accident occurred about 15 minutes after midnight on March 24, 1987. Local officials were somewhat slow in assessing the gravity of +the situation. After consulting the Chemical Transport Engineering Center, which is a part of the Chemical Manufacturers Association, officials +decided to act on the worst-case scenario. The official evacuation began at about 2:20 AM. Records indicate the sirens for the +Susquehanna Nuclear Power Plant were sounded at 2:21 AM and the Emergency Broadcast System broadcasts commenced at 2:30 AM. It is likely that the +public was hearing other sirens from 12:30 AM onwards. The evacuation was a staged effort. The city was divided into quadrants. The quadrant nearest +the plant was the first to evacuate. Officials decided to evacuate the northwest and west quadrants of the city at 2:50 AM. The evacuation of the +remainder of Nanticoke began at 3:42 AM. Thus, we can identify three distinct geographically-determined groups of evacuees. Shortly after the +incident, the Centers for Disease Control (CDC), in the Department of Health and Human Services, Atlanta, Georgia, conducted a telephone survey in +Nanticoke. The general results of this survey along with the methodology are published elsewhere (Duclos, et al., 1989) . + +The CDC survey described ways in which people were warned to evacuate. These methods included sirens, officials going through the streets with +loudspeakers, officials going door-to-door, friends or relatives going to someone's door, telephone calls from friends or relatives, radio, and +television. In fact, these are all common means that are used to warn people in +emergencies (Lindell and Perry, 1987 ; Sorensen and Mileti, 1990 ). +Perhaps the most significant aspect of the warning is that the town of Nanticoke is within the 10-mile emergency planning zone (EPZ) for the +Susquehanna Nuclear Power Plant. As a result, the town is blanketed with coverage by the sirens that would be used to alert the public to a potential +emergency at that plant. This alert system consists of 110 sirens and includes 44 Federal Signal Thunderbolt 1000s, 50 FS STHl0s, and 16 FS 5s. The +sirens are rated at 125, 115, and 105 dB, respectively. On July 30, 1986, a test of the sirens was made at 11:55 AM, and a telephone survey was +conducted to determine how many people heard the sirens. Results indicated that 76.5% of those persons polled heard the +sirens. presents +the CDC survey data regarding how people first learned of the need to evacuate by source over time. It is the best data we have regarding the +diffusion generated by specific warning sources or channels. + +
    + Diffusion curves for Nanticoke first alert (Sorensen, 1992) . + + } +/> + +### Pittsburgh and Confluence Diffusion Curves + +On Saturday, April 11, 1987 at 12:29 PM, a westbound Conrail freight train derailed in Pittsburgh, Pennsylvania. In the process of derailing, the +westbound train sideswiped an eastbound train causing it to derail. Four tank cars containing hazardous materials on the eastbound train were +derailed. Sparks resulting from the accident ignited a fire. Because of the involvement of hazardous materials, Pittsburgh emergency personnel +initiated an evacuation upon arrival at the scene about 20 minutes after the accident. Apparently recognizing signs of potential danger, some local +residents in the immediate adjacent areas had already begun to evacuate. Up to 22,000 people were evacuated as the initial evacuation area was +expanded to accommodate changing weather conditions. + +By 5:50 PM, the affected areas had been declared safe and the initial evacuation order was rescinded. +Emergency officials planned a second precautionary evacuation for 1:00 PM the following day to upright the leaking tank car; however, a close +inspection of the damaged tank car shortly after midnight detected continued deterioration of the tank car. At 1:30 AM, an evacuation order affecting +between 14,000 and 16,000 residents within a half mile of the scene was issued. This second evacuation order was not rescinded until 4:30 PM on +Sunday, April 12, 1987. Approximately 25 people were treated for eye and throat irritation at area hospitals, and three people were hospitalized +during the course of the accident. + +On Wednesday, May 6, 1987 at 4:10 AM, 21 of the 27 “empty” tank cars carrying product residues, including propane, chlorine, caustic soda, carbon +disulfide, methyl chloride, chloroform, and isobutene derailed in Confluence, Pennsylvania. Because tank cars carrying residue can haul up to 3% of +their full load, emergency officials had no way to determine the exact total amount of products remaining in the cars. Upon examination of the train's + manifest, emergency management officials initiated a precautionary evacuation of the 986 residents. A 3-minute non-stop siren blast was sounded, +which primarily alerted the volunteer firemen as residents could not be aware of the specific meaning of this siren-blast; although it could serve as +an alert to those who heard it. + +At approximately 4:30 AM, a door-to-door and portable loudspeaker alert and notification of the emergency began using volunteer firemen and un-trained +volunteers. Public shelters were set up in the area's high school, and local school buses and ambulances provided transportation for those needing it. + The researchers reported that officials indicated the evacuation was completed in 45 minutes. Assistance from area-wide emergency personnel sealed +two leaking propane tankers by 9:48 AM, but the chance of explosion and/or fire during wreckage cleanup prevented return until 6:10 PM. + +Rogers and Sorensen (1989) describe the study methods and data collection. +Using this data, the following curves were plotted for the two events (see ). + +
    + Diffusion curves for Pittsburgh and Confluence (Rogers et al., 1990) . + + } +/> + +### West Helena Diffusion Curve + +The herbicide and pesticide chemical repackaging facility where the accident occurred is located in an industrial park in West Helena, Arkansas. The +industrial park adjoins a railroad track spur and is the site of a number of other chemical and manufacturing industries. The incident began at +approximately 10:00 AM on Thursday, May 8, 1997, when some agricultural chemicals were delivered to the plant. Workers recall that one of the 1,500-lb +bulk containers of azinphos-methyl had a strange, almost rancid, odor when delivered to the plant. The container, double wrapped in disposable heavy +duty plastic, was brought into the plant where, several hours later, it started to emit fumes. As the fumes spread from the container, creating a +smoky haze, plant employees evacuated to the parking lot of the building across the street; and managers conducted a head count to make sure all +employees were out of the building. + +The public was warned by major sources including: media – TV or radio, National Guard or state government officials, and informal sources including +neighbors, friends, co-workers, family members or relatives. The receipt time for these first alerts is shown in . + +
    + Diffusion curve for West Helena first alert (Vogt and Sorensen, 1999) . + + } +/> + +### Mt. St. Helens Ash Fall Diffusion Curve + +Dillman et al. (1983) studied the receipt of information about the volcanic eruption +at Mt. St. Helens in Spokane Washington, which would experience +major ash fall from the eruption. Most people learned of the ash fall hazard through informal or media sources as no official warning was issued. The + diffusion of information, which led to the first awareness of the eruption, is shown in . + +
    + Mt. St. Helens ash fall first alert diffusion curve (Dillman et al., 1983) . + + } +/> + +### Mt. St. Helens Eruption Diffusion Curves + +Perry and Greene (1983) provide detailed warning diffusion information and data for the +communities of Toutle/Silverlake and Woodland in Washington +State for the May 18, 1980 eruption of Mt. St. Helens. + +Most residents in Toutle/Silverlake first became aware of the eruption by physical cues, which included seeing the large mushroom-shaped ash cloud to +the south, a dramatic increase in temperature, the sounds of trees and automobile windshields cracking from the heat, and Silverlake experienced +slight ash fall about 1.5 hours after the initial eruption. The most significant threat to residents in these communities was from mudflows and +flooding in the Toutle River. County deputies alerted most residents by driving pre-designated routes using sirens and public address systems. A +telephone ring down system was used to alert residents in pre-designated high flood hazard areas. The fire department blocked road access to keep +sightseers and other people out of the at-risk area. + +What occurred in Woodland, which is situated along the Columbia River, on the south side of the volcano, was different. Prior to the eruption on May +18th, officials were primarily concerned about the risk of flooding to their community in the event of a volcanic eruption. The concern was based on +the fact that reservoirs could quickly be filled to overflowing in an eruption from volcano-induced mudflows. A great deal of pre-event publicity was +provided to the residents of Woodland about how serious the threat of flooding would be for their community during an eruption, and they could clearly + see the ash cloud when the eruption occurred. In fact, the flooding that occurred the day of the eruption was very minor. + +Toutle is located close to the volcano on the side toward which the blast from the May 18, 1980 eruption was +directed (Lindell and Perry, 2004) . + presents the first alert diffusion curves in the communities of Toutle and Woodland. + +The warning time curve for Toutle rises very steeply because warnings were disseminated by multiple +sources (Lindell et. al., 2002) . The curve for +Woodland is less steep (see Section 5.10 [of full draft First Alert or Warning Diffusion Time Estimation for Dam Breaches, +Controlled Dam Releases and Levee Breaches or Overtopping] for a further discussion of these curves). + +
    + Mt. St. Helens eruption first alert diffusion curves (Perry and Greene, 1983) . + + } +/> + +### Boulder WEA Diffusion + +Between September 11-15, 2013 Colorado's Front Range experienced catastrophic flash flooding that began when record rainfall from a slow moving cold + front stalled over Colorado, colliding with warm humid air from the equator. Boulder received 17.16 inches of rainfall between September 10-15, +2013 (the annual average is 20.7 inches). On September 12, Boulder Creek crested at approximately 5,000 cubic feet per second (cfs). Normally it flows + between 100-300 cfs. The rainfall that the City of Boulder experienced translates to a 1 in 1,000 per year rain event, and a 1 in 100 per year flood +event. Serious damage was sustained to buildings along the creek and the creek path. + +The National Weather Service issued the first notification of a flash flood for Boulder. It was a Wireless Emergency Alert (WEA message) that was +distributed over mobile communication devices to both the city and county and to the public at 6:36 PM on September 11, 2013. The message stated: +“Flash Flood Warning this area until 9:30 PM MDT. Avoid flood areas. Check local media. -NWS." A study of the diffusion of the first WEA message was +conducted (Bean, et al. 2014) , and presents the +Boulder first alert diffusion curve normalized for 100% of the population. + +
    + + shows first alert diffusion curves developed from data for the six case histories described above. Although the general shape of the +diffusion is similar for all events, the speed and acceleration/deceleration of each curve are specific to the event. These curves are not smooth +because they depict reported data from interviewees who tend to anchor their estimates to rounded numbers such as 15 or 30 minutes rather than precise + numbers such as 13 and 29 minutes. + +
    + + \ No newline at end of file diff --git a/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/19-appendix-d-excerpt-from-protective-action-initiation-time-estimation.mdx b/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/19-appendix-d-excerpt-from-protective-action-initiation-time-estimation.mdx new file mode 100644 index 000000000..fd687a864 --- /dev/null +++ b/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/19-appendix-d-excerpt-from-protective-action-initiation-time-estimation.mdx @@ -0,0 +1,154 @@ +--- +title: "Appendix D - Excerpt from Protective Action Initiation Time Estimation for Dam Breaches, Controlled Dam Releases and Levee Breaches or Overtopping" +--- + +import Link from "@docusaurus/Link"; +import addBaseUrl from "@docusaurus/useBaseUrl"; +import Citation from "@site/src/components/Citation"; +import CitationFootnote from "@site/src/components/CitationFootnote"; +import Equation from '@site/src/components/Equation'; +import EquationNoRef from '@site/src/components/EquationNoRef'; +import EquationReference from '@site/src/components/EquationReference'; +import Figure from "@site/src/components/Figure"; +import FigureInline from "@site/src/components/FigureInline"; +import FigReference from "@site/src/components/FigureReference"; +import NavContainer from "@site/src/components/NavContainer"; +import ProcessList from "@site/src/components/ProcessList"; +import TableReference from "@site/src/components/TableReference"; +import TableVertical from "@site/src/components/TableVertical"; +import VersionSelector from "@site/src/components/VersionSelector"; + + + +# Appendix D - Excerpt from Protective Action Initiation Time Estimation for Dam Breaches, Controlled Dam Releases and Levee Breaches or Overtopping + +The following is excerpted from an undated document produced for the USACE Risk Management Center by John H. Sorensen and Dennis S. Mileti titled +Protective Action Initiation Time Estimation for Dam Breaches, Controlled Dam Releases and Levee Breaches or Overtopping, pp. 21-26. + +## Point Estimates and Curves for Discrete Events + +### Pittsburgh and Confluence Mobilization (PAI) Curves + +On Saturday, April 11, 1987 at 12:29 PM, a westbound Conrail freight train derailed in Pittsburgh, Pennsylvania. In the process of derailing, the +westbound train sideswiped an eastbound train causing it to derail. Four tank cars containing hazardous materials on the eastbound train were +derailed. Sparks resulting from the accident ignited a fire. Because of the involvement of hazardous materials, Pittsburgh emergency personnel +initiated an evacuation upon arrival at the scene about 20 minutes after the accident. Apparently recognizing signs of potential danger, some local +residents in the immediate adjacent areas had already begun to evacuate. Up to 22,000 people were evacuated as the initial evacuation area was +expanded to accommodate changing weather conditions. + +By 5:50 PM, the affected areas had been declared safe and the initial evacuation order was rescinded. +Emergency officials planned a second precautionary evacuation for 1:00 PM the following day to upright the leaking tank car; however, a close +inspection of the damaged tank car shortly after midnight detected continued deterioration of the tank car. At 1:30 AM, an evacuation order affecting +between 14,000 and 16,000 residents within a half mile of the scene was issued. This second evacuation order was not rescinded until 4:30 PM on +Sunday, April 12, 1987. Approximately 25 people were treated for eye and throat irritation at area hospitals, and three people were hospitalized +during the course of the accident. + +On Wednesday, May 6, 1987 at 4:10 AM, 21 of the 27 “empty” tank cars carrying product residues, including propane, chlorine, caustic soda, carbon +disulfide, methyl chloride, chloroform, and isobutene derailed in Confluence, Pennsylvania. Because tank cars carrying residue can haul up to 3% of +their full load, emergency officials had no way to determine the exact total amount of products remaining in the cars. Upon examination of the train's + manifest, emergency management officials initiated a precautionary evacuation of the 986 residents. A 3-minute non-stop siren blast was sounded, +which primarily alerted the volunteer firemen as residents could not be aware of the specific meaning of this siren-blast; although it could serve as +an alert to those who heard it. + +At approximately 4:30 AM, a door-to-door and portable loudspeaker alert and notification of the emergency began using volunteer firemen and un-trained +volunteers. Public shelters were set up in the area's high school, and local school buses and ambulances provided transportation for those needing it. + The researchers reported that officials indicated the evacuation was completed in 45 minutes. Assistance from area-wide emergency personnel sealed +two leaking propane tankers by 9:48 AM, but the chance of explosion and/or fire during wreckage cleanup prevented return until 6:10 PM. + +Rogers and Sorensen (1989) describe the study methods and data collection. +Using this data, the following curves were plotted for the two events (see ). + +
    + +### Nanticoke Mobilization (PAI) Curve + +A fire that threatened to burn toxic chemicals onsite at the Spencer Metal Processing Plant caused the warning and evacuation at Nanticoke, +Pennsylvania. The accident occurred about 15 minutes after midnight on March 24, 1987. Local officials were somewhat slow in assessing the gravity of +the situation. After consulting the Chemical Transport Engineering Center, which is a part of the Chemical Manufacturers Association, officials +decided to act on the worst-case scenario. The official evacuation began at about 2:20 AM. Records indicate the sirens for the +Susquehanna Nuclear Power Plant were sounded at 2:21 AM and the Emergency Broadcast System broadcasts commenced at 2:30 AM. It is likely that the +public was hearing other sirens from 12:30 AM onwards. The evacuation was a staged effort. The city was divided into quadrants. The quadrant nearest +the plant was the first to evacuate. Officials decided to evacuate the northwest and west quadrants of the city at 2:50 AM. The evacuation of the +remainder of Nanticoke began at 3:42 AM. Thus, we can identify three distinct geographically-determined groups of evacuees. Shortly after the +incident, the Centers for Disease Control (CDC), in the Department of Health and Human Services, Atlanta, Georgia, conducted a telephone survey in +Nanticoke. The general results of this survey along with the methodology are published elsewhere (Duclos, et al., 1989) . + + illustrates the warning, mobilization (PAI), and +clearance time curves for the Nanticoke chemical evacuation. + +
    + Mobilization (PAI) curve in the Nanticoke hazardous material accident (Sorensen, 1992) . + + } +/> + +### Hurricane Floyd Mobilization (PAI) Curves + +As reported from the National Hurricane Center, Floyd developed from a tropical wave off the coast of Africa on September 2, 1999. Floyd became a +tropical storm on September 8, 1999 about 850 miles east of the Lesser Antilles and continued to move westward, becoming a hurricane about 240 miles +northeast of the northern Leeward Islands. The westward movement changed to north-westward, temporarily halting its intensification trend. However, +Floyd turned back to the west and strengthened into a major hurricane, intensifying to a Category 4 hurricane with 155 mile per hour winds. On +September 13, Floyd ravaged portions of the central and northwest Bahamas heading for the U.S. Floyd continued to move along the Florida coastline, +causing mass evacuations in Florida, Georgia, South Carolina, and North Carolina. Floyd eventually turned north westward and slowly weakened making +landfall on September 16, 1999 near Cape Fear, North Carolina as a Category 2 hurricane. Hurricane Floyd moved over the eastern part of North Carolina + and accelerated up the coast where it weakened to a tropical storm before moving into New England. Floyd lost its tropical storm characteristics by +September 17, 1999. + + is a sample of the "cumulative response curves" derived for each of the 11 areas. The vertical axis indicates the percentage of total +evacuees from a location who had departed their homes by various times. The four curves show the progression of the evacuation commencing earlier to +the south and gradually moving northward as the forecast track of the storm and warning areas moved northward. The curves are typical of "two-day" +response curves – i.e., evacuations that take place over a period longer than 24 hours. The evacuation begins early on the first day, levels off at +evening of the first day, then resumes the following day. Little evacuation began prior to evacuation notices being issued by officials. + +Evacuation slows down considerably at night. These results were similar those in a survey conducted by +Dow and Cutter (2002) who found that the +majority of residents, 61%, left on Tuesday between 6:00 AM and 9:00 PM followed by a second large group of 31% during the daylight hours of Wednesday. +Hurricane Floyd made landfall in North Carolina early in the morning on Thursday, September 16. + +
    + +### Hurricane Fran Mobilization (PAI) Curves + +Hurricane Fran moved across the Atlantic during the peak of the 1996 hurricane season. It made landfall on the North Carolina coast as a Category 3 +hurricane on the Saffir/Simpson scale, resulting in significant storm surge flooding on the North Carolina coast, widespread wind damage over North +Carolina and Virginia, and extensive flooding from the Carolinas to Pennsylvania. U. S. damages from the storm are estimated at $3.2 billion. Storm +surge on the North Carolina coast destroyed or seriously damaged numerous beachfront houses. Widespread wind damage to trees and roofs, as well as +downed power lines, occurred as Fran moved inland over North Carolina and Virginia. Extensive flooding was responsible for additional damage in the +Carolinas, Virginia, West Virginia, Maryland, Ohio and Pennsylvania. Thirty-four deaths, with 21 in North Carolina alone, are attributed to +Hurricane Fran's fury. Nearly a half-million tourists and residents were ordered to evacuate the coast in North and South Carolina. + +The results of a survey conducted for the U.S. Army Corps of Engineers following Fran asked what day and time they left their homes to go someplace safer are +depicted in the graph in , which shows cumulative evacuation over time – that is, of all evacuees, the percentage who had left by various +times. There was little direct response to the hurricane watch, which was posted through South Carolina on the evening of September 3rd. The early +evacuation began midmorning of the following day, probably due to the Governor's request to relocate. The change of the evacuation notice from +voluntary relocation to mandatory evacuation appears to have reinforced the behavior already underway but did not clearly prompt additional response +at that time. The evacuation paused on the evening of September 4th and, by nightfall, slightly more than 40% of the eventual evacuees had left. On +the morning of September 5th, the evacuation resumed at a fast rate and slowed as the time of landfall approached. + +
    + + \ No newline at end of file diff --git a/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/20-appendix-e-structures-from-the-nsi-database.mdx b/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/20-appendix-e-structures-from-the-nsi-database.mdx new file mode 100644 index 000000000..57411d7cf --- /dev/null +++ b/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/20-appendix-e-structures-from-the-nsi-database.mdx @@ -0,0 +1,451 @@ +--- +title: "Appendix E - Structures from the NSI Database" +--- + +import Link from "@docusaurus/Link"; +import addBaseUrl from "@docusaurus/useBaseUrl"; +import Citation from "@site/src/components/Citation"; +import CitationFootnote from "@site/src/components/CitationFootnote"; +import Equation from '@site/src/components/Equation'; +import EquationNoRef from '@site/src/components/EquationNoRef'; +import EquationReference from '@site/src/components/EquationReference'; +import Figure from "@site/src/components/Figure"; +import FigureInline from "@site/src/components/FigureInline"; +import FigReference from "@site/src/components/FigureReference"; +import NavContainer from "@site/src/components/NavContainer"; +import ProcessList from "@site/src/components/ProcessList"; +import TableReference from "@site/src/components/TableReference"; +import TableVertical from "@site/src/components/TableVertical"; +import VersionSelector from "@site/src/components/VersionSelector"; + + + +# Appendix E - Structures from the NSI Database + +All National Structure Inventory (NSI) technical documentation and references are available +from the U.S. Army Corps of Engineer (USACE) Hydrologic Engineering +Center (HEC) NSI Technical References webpage . + +Release Notes for the NSI 2026 update +document the major changes from the NSI 2022 base dataset. + +## Purpose + +The NSI is a collection of point-based structure inventories used to support natural and technological hazard consequence analysis. +The NSI provides consistent structure locations and attribution, including occupancy type, square footage, foundation characteristics, population estimates, and +economic value estimates. Flood risk analysis is the primary use case, but the data structure also supports consequence analysis for other natural and man-made hazards. + +The 2026 base dataset is a nationally-consistent modeled +inventory. It is intended to provide a practical starting point for consequence analysis where more detailed local inventories are unavailable, too costly to produce, +or infeasible within study time constraints. + +## Background + +The NSI base layer was created and is maintained by USACE. It was originally developed to simplify +geospatial preprocessing for consequence modeling, but it has since been used in a variety of USACE, Federal Emergency Management Agency (FEMA), and interagency applications. + +The NSI includes point locations for structures and a standardized set of attributes required by hazard consequence models. These attributes are exposed through +downloadable datasets and a RESTful API. The standardized schema allows analysts and software tools to work with inventories from different locations and sources +using a common set of fields. + +## Accessing the NSI + +Data from the NSI can not only locate structures, but also populate structures with the attributes included +in a structure inventory. The NSI dataset is separate from the LifeSim program but can +be imported directly in LifeSim as +a sole source or to +supplement a user-defined inventory. + +The NSI is available in GeoPackage, GeoParquet, and GeoJSON formats. State-level GeoPackage and GeoParquet files can be downloaded from +the NSI Download Tool. GeoJSON +files can be requested for individual counties or user-specified bounding boxes through the NSI API. + +## Data + +### Attribute Fields + +The NSI API uses a standardized set of public fields to describe each structure record. These fields support common consequence modeling workflows, +including structure damage estimation, life safety analysis, population exposure, and economic loss estimation. + +Datasets added to the NSI must conform to the required schema. When values are not directly observed, analysts are responsible for providing +reasonable estimates and documenting the assumptions used to populate those fields. At present, the publicly available NSI Base layer is maintained +by the NSI development team. Future upload functionality is expected to allow additional inventories to be added using the same +schema. lists the public fields currently exposed in the NSI Base schema. + +Private fields restricted to Federal users and mission partners may be found at +the NSI Technical References webpage. + + + Description of public fields included in the NSI database (USACE HEC, 2026) . + + } + colWidths={[17, "auto"]} +/> + + demonstrates the typical associated NSI fields ("Import Attributes") used to populate the +LifeSim *Import From Point Shapefile* Required Attributes. Fields not imported into LifeSim are utilized in pre-processing and refinement +of the structure inventory, providing extra information for diagnostic purposes. + +
    + +### Occupancy Types + +Source categories are mapped to NSI occupancy types, which are broadly consistent with FEMA Hazus occupancy classifications and USACE consequence +modeling needs. Residential occupancy types are further refined during processing based on estimated housing units, number of stories, and basement +status. For example, a single-family residential structure is assigned a RES1 subtype that reflects stories and basement condition. + +Content values are estimated by multiplying depreciated structure value by an occupancy-specific content-to-structure value ratio. +These ratios are shown . Applying the ratio to depreciated structure value implicitly +assumes a similar degree of depreciation for contents. + +The content-to-structure value ratios are based on averages from studies that include expert elicitation, survey data, and claims data. Ratios +tend to be higher for occupancy types with specialized equipment or relatively low structure costs. For RES1 structures, the NSI uses a ratio of 0.5. +This differs from the 1.0 ratio assumed +in USACE Economic Guidance +Memorandum (EGM) 04-01. Users +applying EGM damage functions calibrated to structure value should use the EGM ratio. +For most other applications, the NSI ratio is intended to better approximate typical content value. + +RESIDENTIAL, rowSpan: 1, colSpan: 3 }, + { value: "RES1-1SNB", rowSpan: 1, colSpan: 1 }, + { value: "RES1-1SWB", rowSpan: 1, colSpan: 1 }, + { value: "RES1-2SNB", rowSpan: 1, colSpan: 1 }, + { value: "RES1-2SWB", rowSpan: 1, colSpan: 1 }, + { value: "RES1-3SNB", rowSpan: 1, colSpan: 1 }, + { value: "RES1-3SWB", rowSpan: 1, colSpan: 1 }, + { value: "RES1-SLNB", rowSpan: 1, colSpan: 1 }, + { value: "RES1-SLWB", rowSpan: 1, colSpan: 1 }, + { value: "RES2", rowSpan: 1, colSpan: 1 }, + { value: "RES3A", rowSpan: 1, colSpan: 1 }, + { value: "RES3B", rowSpan: 1, colSpan: 1 }, + { value: "RES3C", rowSpan: 1, colSpan: 1 }, + { value: "RES3D", rowSpan: 1, colSpan: 1 }, + { value: "RES3E", rowSpan: 1, colSpan: 1 }, + { value: "RES3F", rowSpan: 1, colSpan: 1 }, + { value: "RES4", rowSpan: 1, colSpan: 1 }, + { value: "RES5", rowSpan: 1, colSpan: 1 }, + { value: "RES6", rowSpan: 1, colSpan: 1 }, + { value: COMMERCIAL, rowSpan: 1, colSpan: 3 }, + { value: "AGR1", rowSpan: 1, colSpan: 1 }, + { value: "COM1", rowSpan: 1, colSpan: 1 }, + { value: "COM2", rowSpan: 1, colSpan: 1 }, + { value: "COM3", rowSpan: 1, colSpan: 1 }, + { value: "COM4", rowSpan: 1, colSpan: 1 }, + { value: "COM5", rowSpan: 1, colSpan: 1 }, + { value: "COM6", rowSpan: 1, colSpan: 1 }, + { value: "COM7", rowSpan: 1, colSpan: 1 }, + { value: "COM8", rowSpan: 1, colSpan: 1 }, + { value: "COM9", rowSpan: 1, colSpan: 1 }, + { value: "COM10", rowSpan: 1, colSpan: 1 }, + { value: INDUSTRIAL, rowSpan: 1, colSpan: 3 }, + { value: "IND1", rowSpan: 1, colSpan: 1 }, + { value: "IND2", rowSpan: 1, colSpan: 1 }, + { value: "IND3", rowSpan: 1, colSpan: 1 }, + { value: "IND4", rowSpan: 1, colSpan: 1 }, + { value: "IND5", rowSpan: 1, colSpan: 1 }, + { value: "IND6", rowSpan: 1, colSpan: 1 }, + { value: PUBLIC, rowSpan: 1, colSpan: 3 }, + { value: "EDU1", rowSpan: 1, colSpan: 1 }, + { value: "EDU2", rowSpan: 1, colSpan: 1 }, + { value: "GOV1", rowSpan: 1, colSpan: 1 }, + { value: "GOV2", rowSpan: 1, colSpan: 1 }, + { value: "REL1", rowSpan: 1, colSpan: 1 } + ], + [ + null, + { value: "Single-Family Dwelling, 1-Story, No Basement", rowSpan: 1, colSpan: 1 }, + { value: "Single-Family Dwelling, 1-Story, w/ Basement", rowSpan: 1, colSpan: 1 }, + { value: "Single-Family Dwelling, 2-Story, No Basement", rowSpan: 1, colSpan: 1 }, + { value: "Single-Family Dwelling, 2-Story, w/ Basement", rowSpan: 1, colSpan: 1 }, + { value: "Single-Family Dwelling, 3-Story, No Basement", rowSpan: 1, colSpan: 1 }, + { value: "Single-Family Dwelling, 3-Story, w/ Basement", rowSpan: 1, colSpan: 1 }, + { value: "Single-Family Dwelling, Split-Level, No Basement", rowSpan: 1, colSpan: 1 }, + { value: "Single-Family Dwelling, Split-Level, w/ Basement", rowSpan: 1, colSpan: 1 }, + { value: "Manufactured Home", rowSpan: 1, colSpan: 1 }, + { value: "Multi-Family Dwelling, 2 Units", rowSpan: 1, colSpan: 1 }, + { value: "Multi-Family Dwelling, 3 to 4 Units", rowSpan: 1, colSpan: 1 }, + { value: "Multi-Family Dwelling, 5 to 9 Units", rowSpan: 1, colSpan: 1 }, + { value: "Multi-Family Dwelling, 10 to 19 Units", rowSpan: 1, colSpan: 1 }, + { value: "Multi-Family Dwelling, 20 to 49 Units", rowSpan: 1, colSpan: 1 }, + { value: "Multi-Family Dwelling, 50+ Units", rowSpan: 1, colSpan: 1 }, + { value: "Temporary Lodging", rowSpan: 1, colSpan: 1 }, + { value: "Institutional Dormitory", rowSpan: 1, colSpan: 1 }, + { value: "Nursing Home", rowSpan: 1, colSpan: 1 }, + null, + { value: "Agriculture", rowSpan: 1, colSpan: 1 }, + { value: "Retail Trade", rowSpan: 1, colSpan: 1 }, + { value: "Wholesale Trade", rowSpan: 1, colSpan: 1 }, + { value: "Personal and Repair Services", rowSpan: 1, colSpan: 1 }, + { value: "Business/Professional/Technical Services", rowSpan: 1, colSpan: 1 }, + { value: "Banks", rowSpan: 1, colSpan: 1 }, + { value: "Hospital", rowSpan: 1, colSpan: 1 }, + { value: "Medical Office/Clinic", rowSpan: 1, colSpan: 1 }, + { value: "Entertainment & Recreation", rowSpan: 1, colSpan: 1 }, + { value: "Theaters", rowSpan: 1, colSpan: 1 }, + { value: "Parking", rowSpan: 1, colSpan: 1 }, + null, + { value: "Heavy Industrial", rowSpan: 1, colSpan: 1 }, + { value: "Light Industrial", rowSpan: 1, colSpan: 1 }, + { value: "Food/Drugs/Chemicals", rowSpan: 1, colSpan: 1 }, + { value: "Metal/Minerals Processing", rowSpan: 1, colSpan: 1 }, + { value: "High Technology", rowSpan: 1, colSpan: 1 }, + { value: "Construction Facilities and Offices", rowSpan: 1, colSpan: 1 }, + null, + { value: "Schools/Libraries", rowSpan: 1, colSpan: 1 }, + { value: "Colleges/Universities", rowSpan: 1, colSpan: 1 }, + { value: "General Government Services", rowSpan: 1, colSpan: 1 }, + { value: "Emergency Response", rowSpan: 1, colSpan: 1 }, + { value: "Church/Non-Profit Organizations", rowSpan: 1, colSpan: 1 } + ], + [ + null, + { value: "0.5", rowSpan: 1, colSpan: 1 }, + { value: "0.5", rowSpan: 1, colSpan: 1 }, + { value: "0.5", rowSpan: 1, colSpan: 1 }, + { value: "0.5", rowSpan: 1, colSpan: 1 }, + { value: "0.5", rowSpan: 1, colSpan: 1 }, + { value: "0.5", rowSpan: 1, colSpan: 1 }, + { value: "0.5", rowSpan: 1, colSpan: 1 }, + { value: "0.5", rowSpan: 1, colSpan: 1 }, + { value: "1.0", rowSpan: 1, colSpan: 1 }, + { value: "0.35", rowSpan: 1, colSpan: 1 }, + { value: "0.35", rowSpan: 1, colSpan: 1 }, + { value: "0.35", rowSpan: 1, colSpan: 1 }, + { value: "0.35", rowSpan: 1, colSpan: 1 }, + { value: "0.35", rowSpan: 1, colSpan: 1 }, + { value: "0.35", rowSpan: 1, colSpan: 1 }, + { value: "0.45", rowSpan: 1, colSpan: 1 }, + { value: "0.75", rowSpan: 1, colSpan: 1 }, + { value: "0.95", rowSpan: 1, colSpan: 1 }, + null, + { value: "1.45", rowSpan: 1, colSpan: 1 }, + { value: "1.25", rowSpan: 1, colSpan: 1 }, + { value: "1.4", rowSpan: 1, colSpan: 1 }, + { value: "1.5", rowSpan: 1, colSpan: 1 }, + { value: "0.55", rowSpan: 1, colSpan: 1 }, + { value: "0.6", rowSpan: 1, colSpan: 1 }, + { value: "1.55", rowSpan: 1, colSpan: 1 }, + { value: "1.45", rowSpan: 1, colSpan: 1 }, + { value: "1.15", rowSpan: 1, colSpan: 1 }, + { value: "1.0", rowSpan: 1, colSpan: 1 }, + { value: "0.25", rowSpan: 1, colSpan: 1 }, + null, + { value: "1.7", rowSpan: 1, colSpan: 1 }, + { value: "1.7", rowSpan: 1, colSpan: 1 }, + { value: "1.7", rowSpan: 1, colSpan: 1 }, + { value: "1.7", rowSpan: 1, colSpan: 1 }, + { value: "1.7", rowSpan: 1, colSpan: 1 }, + { value: "1.45", rowSpan: 1, colSpan: 1 }, + null, + { value: "0.65", rowSpan: 1, colSpan: 1 }, + { value: "0.95", rowSpan: 1, colSpan: 1 }, + { value: "0.7", rowSpan: 1, colSpan: 1 }, + { value: "1.15", rowSpan: 1, colSpan: 1 }, + { value: "0.65", rowSpan: 1, colSpan: 1 } + ], + [ + null, + { value: "Family home", rowSpan: 1, colSpan: 1 }, + { value: "Family home", rowSpan: 1, colSpan: 1 }, + { value: "Family home", rowSpan: 1, colSpan: 1 }, + { value: "Family home", rowSpan: 1, colSpan: 1 }, + { value: "Family home", rowSpan: 1, colSpan: 1 }, + { value: "Family home", rowSpan: 1, colSpan: 1 }, + { value: "Family home", rowSpan: 1, colSpan: 1 }, + { value: "Family home", rowSpan: 1, colSpan: 1 }, + { value: "Mobile home, trailer", rowSpan: 1, colSpan: 1 }, + { value: "Duplex, home with on-site rental", rowSpan: 1, colSpan: 1 }, + { value: "Apartments, condominiums", rowSpan: 1, colSpan: 1 }, + { value: "Apartments, condominiums", rowSpan: 1, colSpan: 1 }, + { value: "Apartments, condominiums", rowSpan: 1, colSpan: 1 }, + { value: "Apartments, condominiums", rowSpan: 1, colSpan: 1 }, + { value: "Apartments, condominiums", rowSpan: 1, colSpan: 1 }, + { value: "Hotel, motel, hostel", rowSpan: 1, colSpan: 1 }, + { value: "Prison, school, college dorm", rowSpan: 1, colSpan: 1 }, + { value: "Elder care facilities with staff (not senior living)", rowSpan: 1, colSpan: 1 }, + null, + { value: "Ag product and livestock storage, offices, raw material sorting and packaging", rowSpan: 1, colSpan: 1 }, + { value: "Department store, strip mall, stores, shops, malls", rowSpan: 1, colSpan: 1 }, + { value: "Warehouse store, distribution centers", rowSpan: 1, colSpan: 1 }, + { value: "Gas and service stations, hair salon", rowSpan: 1, colSpan: 1 }, + { value: "Office buildings, shared workspaces", rowSpan: 1, colSpan: 1 }, + { value: "Financial services", rowSpan: 1, colSpan: 1 }, + { value: "Emergency rooms, triage, surgery (inpatient)", rowSpan: 1, colSpan: 1 }, + { value: "Dentist, general practitioner (outpatient)", rowSpan: 1, colSpan: 1 }, + { value: "Restaurants", rowSpan: 1, colSpan: 1 }, + { value: "Movie theatre, performance stages", rowSpan: 1, colSpan: 1 }, + { value: "Parking lots, parking garages (not dedicated to another building)", rowSpan: 1, colSpan: 1 }, + null, + { value: "Factory", rowSpan: 1, colSpan: 1 }, + { value: "Warehouse", rowSpan: 1, colSpan: 1 }, + { value: "Oil refinery, food processing plants", rowSpan: 1, colSpan: 1 }, + { value: "Mining, manufacture", rowSpan: 1, colSpan: 1 }, + { value: "Research and development labs, server farms", rowSpan: 1, colSpan: 1 }, + { value: "Buildings under construction, construction material yards (e.g., lumber, gravel, steel), contractor offices", rowSpan: 1, colSpan: 1 }, + null, + { value: "Grade school, high school, pre-school, administrative offices", rowSpan: 1, colSpan: 1 }, + { value: "Classrooms, dining, administration (non-living quarters)", rowSpan: 1, colSpan: 1 }, + { value: "City, state, Federal government offices, utility maintenance buildings", rowSpan: 1, colSpan: 1 }, + { value: "Police station, fire station, emergency operations centers, critical function offices", rowSpan: 1, colSpan: 1 }, + { value: "Mosque, Elks Lodge, union hall, Grange (public meeting venue, sporadic use)", rowSpan: 1, colSpan: 1 } + ] + ] + } + alt="Occupancy Types" + caption={ + <> + Hazus specific occupancy types (FEMA, 2025) and associated NSI content values and examples (USACE HEC, 2026) . + + } + colWidths={["13%", "33%", "13%", "auto"]} +/> + +Some noted exclusions from this list include transient facilities like campgrounds, homeless encampments, outdoor markets, stadiums, and arenas. +Another example would be large tourist destinations – such as cruise ships in Alaska during the summer – where the population significantly increases +during this time but is not accounted for in the census data. If these or other unique facilities are in the floodplain and expected to be populated, +the user can create a unique +occupancy type in LifeSim. + +### Structure Values + +The NSI provides both full, non-depreciated, replacement value and depreciated replacement value. These values represent the estimated cost to +rebuild the structure and may differ significantly from market value. NSI values exclude land value and do not account for market conditions such +as demand or location desirability. + +USACE analyses typically use depreciated replacement values, while FEMA Hazus applications often use full replacement values. + + \ No newline at end of file diff --git a/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/21-appendix-f-engineered-construction-structural-stability.mdx b/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/21-appendix-f-engineered-construction-structural-stability.mdx new file mode 100644 index 000000000..a7d6d4d81 --- /dev/null +++ b/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/21-appendix-f-engineered-construction-structural-stability.mdx @@ -0,0 +1,353 @@ +--- +title: "Appendix F - Engineered Construction Structural Stability" +--- + +import Link from "@docusaurus/Link"; +import addBaseUrl from "@docusaurus/useBaseUrl"; +import Citation from "@site/src/components/Citation"; +import CitationFootnote from "@site/src/components/CitationFootnote"; +import Equation from '@site/src/components/Equation'; +import EquationNoRef from '@site/src/components/EquationNoRef'; +import EquationReference from '@site/src/components/EquationReference'; +import Figure from "@site/src/components/Figure"; +import FigureInline from "@site/src/components/FigureInline"; +import FigReference from "@site/src/components/FigureReference"; +import NavContainer from "@site/src/components/NavContainer"; +import ProcessList from "@site/src/components/ProcessList"; +import TableReference from "@site/src/components/TableReference"; +import TableVertical from "@site/src/components/TableVertical"; +import VersionSelector from "@site/src/components/VersionSelector"; + + + +# Appendix F - Engineered Construction Structural Stability + +## Engineered + +The only literature available for engineered construction structural stability is from USACE (1985) ; however, +methods used to determine the USACE stability thresholds cannot be found. Since additional relevant studies could not be identified, a uniform distribution between +the Clausen and Clark most likely threshold and an upper bound of 10 meters squared per second (m2/s) is used. The most likely Clausen and +Clark threshold is used as a lower bound because it is assumed that a low quality or deteriorating reinforced concrete or engineered structure could +have a lower stability threshold than a good quality concrete structure. The upper bound was chosen because it is assumed that quality engineered +structures will have a significantly higher stability threshold than any of the other construction types. + +The default stability criteria for engineered construction is shown in . + +
    + +## Wood-Anchored + +Becker et al. (2011) built a theoretical model to determine the response of typical +Canadian wood-frame homes to an array of 2,500 +flood condition combinations. They evaluated 3 failure mechanisms including fill, collapse, and float both individually and in combination. Each +failure mechanism was evaluated by analyzing the load conditions at the structure and the resistance conditions of the structure. Structural +resistance was determined using the dimensions of the structure along with the strength of individual building components, and each structure was +assumed to be anchored. This model applicably “describes whether a typical wood-frame building will be safe for occupants or whether it will fail…” + +The study resulted in functions for two scenarios – the best and worst case building response. The worst case scenario is representative of structures +with high external loads and low structural resistance whereas the best case scenario is representative of structures with low external loads and +high structural resistance. Becker et al.'s best and worst case combination functions are used for the upper and lower uncertainty bounds for the +default wood-anchored stability criteria. The horizontal drag force working against the structure is calculated as: + + + + + +and the frictional force providing resistance is calculated as: + + + +where + +> _D_ = depth of water above the foundation.
    +> _ns_ = the number of stories.
    +> _hs_ = the height of the story.
    +> _pd_ = the hydrodynamic pressure.
    +> _L_ = the length of the home.
    +> _μ_ = the coefficient of friction.
    +> _W_ = the weight of the house.
    +> _FB_ = the buoyant force. + +Gallegos et al. (2012) looked at 3 levels of damage: inundation, structural failure, and washout. +They analyzed 10 existing +structural damage models coupled with a hydraulic flood model to determine which structural damage models were best at predicting structural failure +and washout. Their work was based on the 1963 Baldwin Hills dam breach in Los Angeles, and while it's unclear if the homes in this area were buoyant +or anchored, Gallegos et al. recognize that each model they analyzed implemented different building standards, modeling methods, etc. and propose +their findings be used as a tool to characterize uncertainty. + +Through calibration, they determined that 9.5 meters cubed per second squared (m3/s2) was the force threshold that maximized the +predictive skill of determining washout and noted that their threshold is similar to other published thresholds such +as McBean et al. (1988) and USACE (1985) . McBean et al. focused mainly +on depth-damage functions but +determined 9 m3/s2 as an appropriate general threshold for stability. It is unclear if the structures in their study were +anchored or buoyant, and they also do not appear to differentiate between construction types. For those reasons, Gallegos et al.'s threshold was +assumed to be more appropriate given the level of detail provided and was used as the most likely threshold for the wood-anchored stability criteria. + +The Gallegos function and the Becker worst function meet and overlap when depths are below 1 meter and velocities are between 3 m/s and 4 m/s. For any + depth and velocity sampled beyond where the two functions overlap, the Gallegos function will be implemented to essentially capture the lowest +possible threshold. + +The default stability criteria for wood-anchored construction is shown in . + +
    + +## Manufactured + +The Hazus Multi-hazard tool implements manufactured stability criteria based on information provided by FEMA (1985). As stated in the manual, “it is +assumed that drag forces exceed manufactured housing design capacity around 13 pounds per linear foot of home length and it is possible to determine +the relationship between depth and velocity for this threshold level of drag force. This results in a simpler velocity-damage function for MH +(manufactured housing) than for the other material types; for a given depth, if the velocity equals or exceeds the collapse velocity, the structure is +assumed to collapse.” + +No other research was identified that proposes stability criteria for manufactured housing; however, FEMA provided a second edition of the +aforementioned 1985 document in 2009. While the 2009 document does not provide updated stability criteria, it does suggest that structural resistance +guidelines implemented by the U.S. Department of Housing and Urban Development (HUD) in 1994 have improved manufactured housing performance in wind +and flood events since. As a result, it is assumed that the manufactured housing stability threshold would be higher post-1994 and more consistent +with wood-buoyant homes. + +To account for the uncertainty, the default manufactured housing criteria in LifeSim 2.0 and later is set to a uniform distribution between the Manufactured +stability criteria provided in the Hazus manual and the timber-steel criteria provided by Dale (2004) for wood-buoyant +structures. The timber-steel threshold provided by Dale is the lowest threshold for the other construction types in the sections to follow and +represents the next threshold up from manufactured housing. It is used as the upper bound because while manufactured housing stability is assumed to +have improved, it is unclear by how much. + +Furthermore, it is assumed that manufactured housing will generally be built with lighter materials easier for transport than some of the heavier, +site-built wood-buoyant homes. The manufactured housing and timber-steel thresholds cross when velocities are less than 1 meter and depths are between +2 and 3 meters. For any depth and velocity sampled beyond where the two functions overlap, the timber-steel threshold is implemented to essentially +capture the lowest possible threshold. + +The default stability criteria for manufactured construction is shown in . + +
    + +## Masonry + +Clausen and Clark (1990) provide the most comprehensive look at masonry stability with their study based on the Dale Dyke dam failure that took place +in the UK in 1864. They present a stability threshold that was determined using calculated flood conditions and structural damage data collected and +published by Samuel Harrison (1864) post-flood. Clausen and Clark looked at 3 damage categories including: inundation, +partial damage, and total destruction. Based on their work, neither partial nor total damage of masonry structures can occur at velocities below 2 +m/s, and total destruction occurs when the depth times velocity is greater than 7 meters squared per second (m2/s). + +Clausen and Clark's threshold is applied directly in RESCDAM. USACE also provides masonry stability criteria, but no justifying methodology can be +found in the literature. Since additional methods are not presented, and Clausen and Clark's threshold for masonry structures is higher than the various + thresholds presented for wood-framed structures, a lower and upper bound of uncertainty for a triangular distribution is assumed. For the lower +bound, a threshold of 6 m2/s is used which is slightly lower than the Becker Best threshold, and for the upper bound, a threshold of 8 +m2/s is used. It is assumed that with modern building standards and technologies it is unlikely that a masonry structure would have lower +stability than a well-built wood structure unless it is an older building. However, it is likely that modern building practices have improved the +stability threshold since the 1800s, so an upper bound was established to match this assumption. + +The default stability criteria for masonry construction is shown in . + +
    + +## Wood-Buoyant + +Black (1975) was the first to publish proposed methodology for determining the stability criteria for wood-buoyant structures. + He considered buoyancy, hydrostatic pressure, and dynamic pressure to determine the external loads required to move a structure and provided the +corresponding depth and velocity functions at which a structure would fail if exceeded. The buoyant, hydrostatic, and dynamic forces were combined +into to analyze the velocities that would lead to movement of the houses: + + + +where + +> _V_ = average water velocity (m/s).
    +> _f_ = the coefficient of friction.
    +> _Rb_ = the buoyancy ratio.
    +> _Wh_ = the total house weight (kg).
    +> _d_ = the submergence depth (m).
    +> _L_ = the length of exposure (m).
    +> 1.03 = the combined constant of the unit weight of water (kgs/m3) and the acceleration of gravity (9.8 m/s2). + +The standard house size used for Black's analysis was 7.3 meters wide by 9.75 meters long for a total of 71.18 square meters on the first floor. He +assumed that when the buoyant force was equal to the weight of the structure that the structure would float and when the force exerted on the house +was equal to the frictional force preventing movement then the structure would fail. His study was not empirically based but performed well in a later +study by Gallegos et al. (2012) . Black established functions for 1 story, 1.5 story, and 2 story homes evaluating each with drywall +and plaster wall and then also evaluating the 1.5 story drywall with a brick veneer. The lightest structure he evaluated was the 1 story with drywall +(7,121 kgs) and the heaviest he evaluated was the 1.5 story with drywall and a brick veneer (25,442 kgs). + +Sangrey et al. (1975) later expanded Black's research using a case study of 155 random structures from the Chemung River floodplain +impacted by the 1972 flood from Tropical Storm Agnes. They collected data on collapsed homes from the flood using aerial photos and ground survey. +Sangrey et al. changed the hydraulic coefficient used by Black from 1 to 2 and determined that the damage criteria proposed by Black was too +conservative. As a result, they proposed new criteria based on a dimensionless force parameter and a corresponding normal force/buoyancy parameter. + +Dale et al. (2004) then used the work of Black and Sangrey et al. to adapt the Black functions to heavier and larger Australian construction. + For example, the lightest structure in Dale et al.'s study was a timber clad, steel-roofed structure weighing nearly 19,000 kilograms. Dale et al. +noted that Sangrey et al. changed the hydraulic coefficient from 1 to 2 because “Black applied the Bernoulli equation (incorrectly) in calculating a +pressure rather than a drag force. The Bernoulli equation does not allow for a drag coefficient and the horizontal forces therefore differ by a factor + of two.” Dale et al. then moved forward with using a drag coefficient of 2 as well and evaluated 3 different types of structures: brick veneer +walls, fiber cement cladding, and timber cladding. + +The equation used for horizontal force on a structure due to flowing water is: + + + +where + +> _CD_ = the drag coefficient.
    +> _FH_ = the horizontal force.
    +> _ρ_ = the water density.
    +> _v_ = the velocity.
    +> _b_ = the width of the house.
    +> _d_ = the depth of water above the foundation. + +While Dale et al.'s study was not empirically based, it also performed well later in Gallegos et al.'s study. Of the three studies, the functions +provided by Dale et al. are the most representative of larger, modern construction for wood-buoyant structures. As such, Dale et al.'s functions are +used for the wood-buoyant LifeSim 2.0 defaults. Two default settings are presented depending on the availability of data in the structure inventory to + determine if a structure is light or heavy based on weight. + +Whether a structure is light or heavy can be determined by looking at building composition. For instance, a home built with drywall will be lighter +than a home built with plaster, and a home built with brick siding will be heavier than a home built with wood siding. Factors that can impact the +weight of a home include, but are not limited to: + +- Siding material +- Number of stories +- Roofing material +- Square footage + +For reference, the lightest structure analyzed by Dale et al. used timber cladding and a steel roof and weighed around 19,000 kilograms at around +192.7 square meters. According to Dale et al., fiber cement cladding weighs around 3.3 times more per cubic meter than timber cladding, brick cladding + weighs around 4.2 times more per cubic meter than timber cladding, and a tile roof weighs around 8.3 times more per square meter than a steel roof. + +When data are available to indicate the weight of a structure, two default criteria with a triangular distribution are available – a light threshold +and a heavy threshold. The uncertainty bounds for both most likely thresholds are the same. The Dale et al. lightest (timber – steel) function is the +lower bound, and the heaviest (brick – tile) threshold is the upper bound. + +These bounds allow for the full range of the four thresholds provided by Dale et al. to be sampled with more values tending toward the most likely +function selected. For structures that would be considered light in weight, the Dale et al. timber – tile function is used as the most likely +threshold. For structures that would be considered heavy in weight, the Dale et al. brick - steel function is used as the most likely threshold. + +If there is insufficient data available to provide an indication if the structures are heavy or light, then the default stability criteria is a +uniform distribution between Dale et al.'s lightest threshold (timber – steel) and heaviest threshold (brick – tile). + +The default stability criteria for wood-buoyant construction is shown in . + +
    + +If data are available to provide an indication of the structure's weight, then the following criteria are used to determine which most likely function + to select: + +- If the weight of the structure is less than 33,623 kilograms (kgs), then use the light threshold. +- If the weight of the structure is greater than or equal to 33,623 kilograms (kgs), then use the heavy threshold. + +This weight criteria are based on the estimated average weight between the timber-tile (light most likely structure) and brick-steel (heavy most +likely structure). These weights were estimated using the floor plan and roofing and siding measurements and weights provided by Dale et al. An +estimated weight was calculated for the siding and roofing of each structure type. Then using the provided weight of 19,000 kilograms for the lightest + structure, the estimated roofing and siding weight for that structure type was subtracted to determine an estimated weight of all remaining building +components that are not roofing or siding. The remaining weight was used as a constant for all structure types. + + provides the estimated weight for each structure +type. + + + Estimated weights (kgs) for Dale et al. structures . + + } + colWidths={[10, 10, 10]} + widthMode="intrinsic" +/> + + and show the default stability criteria for light and +heavy wood-buoyant construction, respectively. + +
    +
    +
    +
    + +USACE (1985) proposed functions for wood framed structures, but due to a lack of justifying methodology, it is unclear if the +functions are for wood-anchored or wood-buoyant structures. However, the USACE wood framed criteria are comparable to other attached structure +criteria, and it is assumed that in Gallegos et al. (2012) , they represent attached structures. + + \ No newline at end of file diff --git a/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/22-appendix-g-research-on-vehicle-stability-and-driver-behavior.mdx b/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/22-appendix-g-research-on-vehicle-stability-and-driver-behavior.mdx new file mode 100644 index 000000000..7975224fb --- /dev/null +++ b/docs/desktop-applications/lifesim/technical-reference-manual/v1.0/22-appendix-g-research-on-vehicle-stability-and-driver-behavior.mdx @@ -0,0 +1,267 @@ +--- +title: "Appendix G - Research on Vehicle Stability and Driver Behavior" +--- + +import Link from "@docusaurus/Link"; +import addBaseUrl from "@docusaurus/useBaseUrl"; +import Citation from "@site/src/components/Citation"; +import CitationFootnote from "@site/src/components/CitationFootnote"; +import Equation from '@site/src/components/Equation'; +import EquationNoRef from '@site/src/components/EquationNoRef'; +import EquationReference from '@site/src/components/EquationReference'; +import Figure from "@site/src/components/Figure"; +import FigureInline from "@site/src/components/FigureInline"; +import FigReference from "@site/src/components/FigureReference"; +import NavContainer from "@site/src/components/NavContainer"; +import ProcessList from "@site/src/components/ProcessList"; +import TableReference from "@site/src/components/TableReference"; +import TableVertical from "@site/src/components/TableVertical"; +import VersionSelector from "@site/src/components/VersionSelector"; + + + +# Appendix G - Research on Vehicle Stability and Driver Behavior + +## Recent Vehicular Stability Studies + +A study by the University of New South Wales for the State Emergency Services +Department (Smith, Modra et al. 2017) summarized most of the +available research on vehicular stability in flowing water. In addition, they added new research on two prototype vehicle stability limit tests where +most of the previous work had been scale models. This report represents the state of the art in vehicle stability +research. shows a +summary of most available stability threshold data in one chart. + +
    + Results of Several Scale Model Tests of Vehicle Stability: + Bonham and Hattersley (1967) , + Gordon and Stone (1973) , + Keller and Mitsch (1993) , + Shu, Xia et al. (2011) , + Xia, Teo et al. (2011) , + Falconer and Xia (2013) , + Toda, Ishigaki et al. (2013) . + + } +/> + +In the study, a small passenger car and a four-wheel drive sport utility vehicle (4WD SUV) were placed in a large pool and pulled sideways until +they moved. There was no velocity in the water, but it was inferred based on the force required to move the vehicle from rest. The static coefficient +of friction was measured at 0.78 for both vehicles for the tires against wet concrete. This is larger than the assumed coefficient in flood conditions + for a moving car (0.30). The lower 0.30 is cited by multiple sources as a reasonable, conservative assumption. Many environmental and conditional +factors impact this coefficient including the tires, supporting material (asphalt, gravel, concrete, etc.), and temperature. The vehicle loses +stability when the friction force equals the hydrodynamic force applied by the flowing water. + + + +Parsing all of the available data and new results, the study developed stability thresholds called *Flood Hazard Vulnerability Curves* and shown in +. The thresholds are intended to be conservative and used for roadway design such that if cars enter the flooded roadway they will not be +swept away. These limits represent a reasonable lower bound of vehicle stability for LifeSim purposes. + +In , the H1-H2 threshold curve represents the lower limit for small vehicles and H2-H3 the lower limit for taller vehicles. + +Arrighi et al. explore the incipient motion of vehicles with three-dimensional (3D) numerical modeling of flow and accurate vehicle weight and +dimensions (Arrighi, Alcerrecha-Huerta et al., 2015 and Arrighi, Huybrechts et al., 2016 ). They +introduce a Shield's type, mobility parameter and show its +dependence on the Froude number using results of other model tests. The 3D modeling reinforced the importance of the coefficient of friction to hold +the vehicle in place. It also showed dependence on the Froude number of the lift and drag coefficients of the vehicle. This research has not been +incorporated into LifeSim. For further detail, refer to the journal articles. + +
    + Flood hazard vulnerability curves (Smith et al. 2017) . + + } +/> + +## Recent Driver Behavior Studies + +The following describes the body of research and logic used to construct the *willingness to enter flooded roads* curves in LifeSim. It relies +primarily on four studies of driver behavior when confronted with flooded roads: +Gissing et al. (2016) , Drobot et al. (2007) , +Pearson and Hamilton (2014) , and Hamilton et al. (2016) . +How the resulting data and +probability curves were incorporated into LifeSim is summarized in +Section Evacuation Parameters Defined by Alternative. + +Some of the research suggests factors that can increase a person's likelihood to enter flooded roads include: + +- Gender: Male (especially at lower depths) +- Age: 18-35 years old +- Prior experience with floods and driving in floods +- Perception of societal norms (are people generally okay with driving in floods?) +- Risk-taking attitude +- Poor reception to flood warnings +- Lack of warning information / signage +- Feeling of control of the circumstances +- Low velocities (perception of flood water flow velocity) +- Lack of females or dependent passengers in the vehicle + +Gissing and Haynes (Gissing, et al., 2016) conducted the only known research +to observe driver behavior at a flooded road. The road was flooded about +10-30 centimeters (cm) and moving “slowly.” They observed 154 drivers and noted gender, relative age, and vehicle type as they were able but not in +all cases. Some drivers were influenced by the actions of other drivers either to enter or turn around. Four-wheel drive (4WD) vehicles were more +willing to enter a flooded roadway than smaller vehicles. Males were also more likely than females to drive into the water. + +Overall, 84% of the drivers entered the flooded road. Segregating the data into high-clearance, low-clearance and unknown (92%, 71%, and 82% entering, +respectively), trends emerge that people in larger vehicles are more willing to enter a flooded road. + +Drobot, Benight, and Gruntfest (Drobot et al., 2007) surveyed about 900 people by mail in Denver, Colorado and Austin, Texas. They +asked people to report their answers on a 4-point scale from “strongly agree” to “strongly disagree.” Three questions were posed after the following +scenario was presented: + +> _You are driving a mid-sized car immediately after a severe thunderstorm in your city. Ahead of you approximately 18" (46cm) of water covers the road and vehicles ahead are stopped._ +> +> 1. _If traffic started to move, I would attempt to cross the water._ +> 2. _Regardless of my vehicle, if water were covering most of the tires on the truck in front of me, I would attempt to drive through the water._ +> 3. _If I were driving an SUV, truck or 4WD instead of a car, I would attempt to drive through the water._ + +Based on answers to the 3 questions, drivers were categorized as willing to drive through flooded roads or not. Overall, 40% of respondents in Denver +indicated they would enter the flooded road, while 8% of respondents in Austin would. + +Important factors in determining whether respondents will drive into flooded roads include: whether or not they take flash flood warnings seriously, +their age, their knowledge of the danger of flash floods and vehicles, and in Denver, previous experience with floods. Gender did not have a +statistically significant trend. + +These two points were deemed to be low estimates based on these factors: + +- They were told that cars ahead had stopped, which is liable to bias the drivers to follow suit. If you see someone pass through, you are more likely +to follow. +- The depth of flooding was given by the survey. Anecdotal evidence suggests that people are not a good judge of hazardous conditions, especially if +the water is cloudy or has significant velocity. +- Results indicate that if people were in a high clearance vehicle instead of the “mid-sized car,” they would be more likely to enter the road. + +In another study (Pearson and Hamilton, 2014 and Hamilton et al., 2016 ), a +scenario prompt was adopted +from Drobot, et al, 2007 : + +> _You are driving in a mid-size car immediately after a thunderstorm. You approach a section of the road that is completely covered in 20 cm (or 60 cm) of water._ + +For the 20 cm scenario, a mean of 3.6 indicated on average, 43% of people would enter the flooded road. For 60 cm, the mean was 1.79 or 13%. This assumes +the range is 0 to 100% for responses 1 to 7, respectively. + +It is generally not appropriate to calculate a mean of Likert scale responses or to convert that mean to a representative percentage of respondents. A +scale of subjective responses (“strongly agree” to “strongly disagree”) is not likely to be accurately represented by a continuous number line. +Unfortunately, as seen from this discussion, very little information on this subject was available, so the points were developed and added to the plots +to help inform the final curve development. However, they should be considered in their proper context. + +These seven points represent the best data available. Unfortunately, they do not provide enough data to fit a curve. +In and , +these points and their uncertainty bands are plotted with data pulled from the vehicle stability +analysis (Chapter Road Networks, Destinations, and Evacuation Parameters). The gray +curves represent the +spread of data on vehicle stability at certain velocities. The y-axis then represents the % of vehicles in the dataset that would maintain stability +encompassing variations in vehicle height, weight, cargo, road conditions, tire conditions, etc. The best estimate of vehicle stability represents +where 50% of vehicles are stable while the upper and lower stability thresholds represent 0% and 100% of vehicles, respectively. + +Since most data points are for cars, the low clearance curve was drawn first. Most confidence was given to the cars observed in Gissing et al because +it was actual behavior and not self-reported, expected behavior. A 10% range was added to the Drobot et al. points to account for the scenario +description where cars have stopped in front of you, which has been shown to impact the decision to enter. + +The curve was then generally fit through the points following a normal distribution curve. The high clearance vehicle curve adopted the standard +deviation (slope) of the low clearance curve and then drawn through the one point belonging to it. It is slightly deeper than all the car points but +also considered anecdotal evidence from video and reports of vehicles entering flooded roads. + +
    + +
    + +Each curve is defined by a mean, standard deviation, and puddle depth which all vehicles will drive through, as shown +in . + + + +Many factors contribute to the decision-making process when a driver approaches a flooded road. Most of those factors are not knowable and pertain to +the particular circumstances and perception of the driver. + +Specifically, is the driver: + +- Willing to risk their life to reach a family member? +- Accurately able to judge the conditions and the stability of their own vehicle? +- Risk averse? + +In place of this complex set of factors, we can model depth and velocity of the water. In literature, the hazard has been represented almost +exclusively with depth only, and anecdotally, it seems people are a better judge of depth than velocity. Considering all the research and limitations +of modeling, the decision criteria in LifeSim will be a function of depth only. + +Several other distributions were considered to define the willingness curves including Uniform, Gamma, Gumbel, Pearson Type 3, and a modified normal. +Some of these offered advantages over the selected truncated normal distribution, but none represented the data adequately while also being easy to +understand by most users. The uniform distribution would only require a minimum and maximum depth, making it easy to comprehend but poorly +representing both a central tendency of most people and the possibility of more extreme behavior. In fact, it is likely that more extreme risk-taking +behavior will account for a significant amount of the life loss on roads. A problem with the normal distribution is that negative depths are possible. + Adding a puddle depth, below which the normal distribution is ignored, solves this problem while also being an easy to understand minimum. + +A cursory review of the proposed default curves shows a couple noteworthy points. For low clearance vehicles, 100% will enter 2.5 inches (6 cm) of +water regardless of velocity, 58% will enter 1 foot (30 cm), 9% will enter 2 feet (61 cm), and none will enter more than 3 feet (91 cm). For high +clearance vehicles, 100% will enter 4 inches (10 cm) of water regardless of velocity, 86% will enter 1 foot (30 cm), 33% will enter 2 feet (61 cm), +and none will enter more than 3.5 feet (107 cm). A comparison to the stability curves – representing behavior with perfect knowledge of the risk – +reveals that all vehicles will avoid deep, slow water that would not cause them to lose stability but may have induced floating or water inside the +vehicle. Conversely, vehicles will be subjected to low depth, high velocity flows which have been shown to destabilize vehicles. These people will +then be subject to the high hazard fatality curve. + +The previous threshold was 2 feet for all vehicles. By making these changes, we are recognizing the complexity and uncertainty of the decision-making +process and the difference between high and low clearance vehicles. The method does not allow for decisions based on perception of the velocity of the + water which is a significant limitation but was not supported by the available data. The changes result in less vehicles entering a road flooded at 2 + feet of depth, but also allow some to enter deeper water, and some to turn around at lower depths. While the previous 2-foot threshold had no +research supporting it, the new threshold is supported as described above. + + \ No newline at end of file diff --git a/docs/desktop-applications/lifesim/users-guide/v1.0/01-preface.mdx b/docs/desktop-applications/lifesim/users-guide/v1.0/01-preface.mdx index 209c3be4e..bacc7ef9a 100644 --- a/docs/desktop-applications/lifesim/users-guide/v1.0/01-preface.mdx +++ b/docs/desktop-applications/lifesim/users-guide/v1.0/01-preface.mdx @@ -2,11 +2,11 @@ title: "Preface" --- -import NavContainer from "@site/src/components/NavContainer"; -import VersionSelector from "@site/src/components/VersionSelector"; import Link from "@docusaurus/Link"; import addBaseUrl from "@docusaurus/useBaseUrl"; import CitationFootnote from "@site/src/components/CitationFootnote"; +import NavContainer from "@site/src/components/NavContainer"; +import VersionSelector from "@site/src/components/VersionSelector"; LifeSim Technical Reference Manual - Chapter: Structure Inventory and Associated Properties provides the definitions for the attributes required for importing a structure inventory from a shapefile. #### To create a structure inventory from a point shapefile: @@ -440,10 +441,10 @@ selected/created rules, for missed structures will not have a stability criteria ## Import from National Structure Inventory (NSI) The National Structure Inventory (NSI) for an area, will contain information on structure occupancy types, population, structure values, foundation -height, build type, and other information. The NSI is currently only available to U.S. Army Corps of Engineer (USACE) users. The NSI is a database of +height, build type, and other information. The NSI is a database of structure locations and attributes and was developed using information from the HAZUS database and other sources including the Longitudinal Employer-Household Dynamics database. Technical documentation -is available from USACE HEC. +is available from USACE HEC. #### To create a structure inventory from the NSI: @@ -759,7 +760,7 @@ story tall with no basement). Damage categories represent a hig Consequence Assessment Model (ECAM) process to determine population and capital impacted for each event. In other words, damage categories represent a grouping of occupancy types. By default, a LifeSim study is pre-loaded with default damage categories and occupancy types. Default damage categories are residential, commercial, industrial, and public. Default occupancy types follow the naming convention developed for HAZUS (FEMA 2019) and are -listed in the *LifeSim Version 2.0 Technical Reference Manual, Appendix D*. +listed in the LifeSim Technical Reference Manual - Appendix E. Users can modify default occupancy types or create and define new occupancy types with unique depth-damage functions and uncertainty parameters. However, entered data is applied to all the structures assigned to a created or modified occupancy type. Several occupancy types can be assigned to a @@ -1154,7 +1155,8 @@ occupancy type. After completing the economic depth-damage functions for the new occupancy type, select the Evacuation Parameters tab (). This tab contains evacuation parameters set for all structures assigned to the selected occupancy type. - Review the LifeSim Technical Reference Manual for more information regarding the evacuation parameters + Review the LifeSim Technical Reference Manual for more + information regarding the evacuation parameters defined by the structure occupancy type.

    @@ -1259,8 +1261,9 @@ occupancy type.

    NOTE: in LifeSim Version 1.0, submergence criteria were divided into three zones: chance, compromise, and safe. However, in LifeSim Version 2.0, the - original three zones were replaced with two new zones: low and high hazard. The LifeSim Version 2.0 Technical Reference Manual, Chapter 9, Section - 9.2 provides a detailed explanation regarding the development of the two new zones. LifeSim Version 2.0 and later characterizes + original three zones were replaced with two new zones: low and high hazard. + The LifeSim Technical Reference Manual - Section: Development of Fatality Rate Functions provides + a detailed explanation regarding the development of the two new zones. LifeSim Version 2.0 and later characterizes the high hazard or low hazard conditions as described below:

    @@ -1291,7 +1294,7 @@ occupancy type. title: ( <> The threshold of submergence is an uncertain parameter sampled uniquely for each structure. Review - the LifeSim Technical Reference Manual for more + the LifeSim Technical Reference Manual - Section: Submergence Criteria for more information regarding the submergence criteria. To enter the submergence criteria for the High Hazard Zone for the new occupancy type, select the Submergence Criteria tab () and set the uncertainty in the threshold of submergence from the Uncertainty Type dropdown menu. The user can diff --git a/docs/desktop-applications/lifesim/users-guide/v1.0/08-road-network-data.mdx b/docs/desktop-applications/lifesim/users-guide/v1.0/08-road-network-data.mdx index c400ab951..a303e87e8 100644 --- a/docs/desktop-applications/lifesim/users-guide/v1.0/08-road-network-data.mdx +++ b/docs/desktop-applications/lifesim/users-guide/v1.0/08-road-network-data.mdx @@ -40,7 +40,9 @@ links are set up correctly. instead of on the road. [Appendix C](./19-appendix-editing-road-network-data-for-use-in-lifesim.mdx) is designed to help users -prepare and edit road networks for use in LifeSim. The *LifeSim Version 2.0 Technical Reference Manual, Chapter 6* describes the computational input +prepare and edit road networks for use in LifeSim. +The LifeSim Technical Reference Manual - Chapter: Road Networks, Destinations, and Evacuation Parameters describes +the computational input parameters required for the traffic simulation model used to determine the speed of vehicles at each time step. There are two ways to add road network data to a LifeSim study and only one format is supported (polygon shapefiles) to be utilized in LifeSim simulations. diff --git a/docs/desktop-applications/lifesim/users-guide/v1.0/10-agricultural-data.mdx b/docs/desktop-applications/lifesim/users-guide/v1.0/10-agricultural-data.mdx index e578e5eae..46088467b 100644 --- a/docs/desktop-applications/lifesim/users-guide/v1.0/10-agricultural-data.mdx +++ b/docs/desktop-applications/lifesim/users-guide/v1.0/10-agricultural-data.mdx @@ -27,8 +27,9 @@ import VersionSelector from "@site/src/components/VersionSelector"; damage to existing crops and interruptions to the planting, growing, and harvesting of crops due to flooding in agricultural areas. Agricultural data is not typically used in a consequence assessment; however, it may assist the user in understanding the amount and type of agriculture in the floodplain and potential flood impacts to it. To compute agricultural damages, hydraulic data (including duration and event arrival), agricultural -data, crop budgets, crop values, and crop duration-damage relationships are required. Review *LifeSim Version 2.0 Technical Reference Manual, -Chapter 7* for more information regarding the agricultural inventory and the computational procedures used to calculate agricultural flood damages. +data, crop budgets, crop values, and crop duration-damage relationships are required. +Review the LifeSim Technical Reference Manual - Chapter: Agricultural Inventory for +more information regarding the agricultural inventory and the computational procedures used to calculate agricultural flood damages. ## Import Agricultural Data @@ -511,8 +512,8 @@ Crop Functions ). The Substitute Crop option allows users to identify a secondary crop which LifeSim will use during the agricultural flood damages calculation if flooding is determined to limit the ability to plant the primary crop. - Review the LifeSim - Version 2.0 Technical Reference Manual, Chapter 7, for more information regarding the computational procedures used to + Review the LifeSim Technical Reference Manual - Chapter: Agricultural Inventory for + more information regarding the computational procedures used to calculate agricultural flood damages.

    diff --git a/docs/desktop-applications/lifesim/users-guide/v1.0/11-ecam-data.mdx b/docs/desktop-applications/lifesim/users-guide/v1.0/11-ecam-data.mdx index 7c6902002..a58ab8fe1 100644 --- a/docs/desktop-applications/lifesim/users-guide/v1.0/11-ecam-data.mdx +++ b/docs/desktop-applications/lifesim/users-guide/v1.0/11-ecam-data.mdx @@ -37,7 +37,8 @@ and their contents. To convert these to ratios, a total supply of available labo Because ECAM runs each county independently, values for labor and capital must be provided for each county in the study area. The total labor and capital must represent the total for the whole county, not the portion of the county in the study area. Available capital is entered as the total value of commercial, industrial and public structures. Labor should be entered as the total under 65 years of age population at all structures at 2AM. -For more detail on computing indirect damages with ECAM, please refer to the *LifeSim Version 2.0 Technical Reference Manual, Chapter 8*. +For more detail on computing indirect damages with ECAM, please refer to +the LifeSim Technical Reference Manual - Chapter: Indirect Damages with ECAM. ## Import ECAM Data diff --git a/docs/desktop-applications/lifesim/users-guide/v1.0/12-alternatives.mdx b/docs/desktop-applications/lifesim/users-guide/v1.0/12-alternatives.mdx index 1dbac4040..fdc3eac06 100644 --- a/docs/desktop-applications/lifesim/users-guide/v1.0/12-alternatives.mdx +++ b/docs/desktop-applications/lifesim/users-guide/v1.0/12-alternatives.mdx @@ -435,7 +435,8 @@ can adjust the parameters by modifying the default values. *Depth Driven Willingness to Enter Flooded Road* right panel: users can define probability density functions for low clearance (cars) and high clearance (trucks) vehicles willingness to enter (ford) flooded roads. During the evacuation simulation, vehicles encountering a flooded road will either attempt to ford the road or will attempt to turn around depending on the defined willingness to enter -functions. The *LifeSim Version 2.0 Technical Reference Manual, Chapter 6* provides extensive detail regarding evacuation parameters and depth driven +functions. The LifeSim Technical Reference Manual - Chapter: Road Networks, Destinations, and Evacuation Parameters provides +extensive detail regarding evacuation parameters and depth driven willingness to enter flooded roads. Life Loss Probability tab () allows the user to adjust the default fatality rate curves that are used to define probability of life loss for the high and low hazard zones. In LifeSim Version 1.0, default fatality rate curves were developed for three zones: chance, compromised, and safe. However, in LifeSim Version 2.0, the original three zones were replaced with two new zones: -low and high hazard. The *LifeSim Version 2.0 Technical Reference Manual, Chapter 9, Section 9.2* provides a detailed explanation regarding the +low and high hazard. The LifeSim Technical Reference Manual - Section: Development of Fatality Rate Functions provides +a detailed explanation regarding the development of the two new zones and the fatality rate functions for the new zones. LifeSim Version 2.0 characterizes each agent as either being in high hazard or low hazard conditions as described in . @@ -714,8 +716,9 @@ To modify the default fatality rate curves: The Create New Alternative dialog box () Stability Criteria tab () allows users to adjust the default stability criteria for three groups: human stability, and low and high -clearance vehicles. The user can adjust the default stability criteria thresholds (depth, velocity, and functional) for the three groups. The *LifeSim -Version 2.0 Technical Reference Manual* provides more information on the human and vehicle stability criteria. +clearance vehicles. The user can adjust the default stability criteria thresholds (depth, velocity, and functional) for the three groups. +The LifeSim Technical Reference Manual provides more information +on the human and vehicle stability criteria.
    ) is where the structure inventory is defined for the leveed area. A structure inventory represents geospatial locations that contain damageable elements, typically a structure such as a home. Structure inventories are required by LifeSim to estimate direct economic damage for a flood event and initial population distribution. For more information on the required attributes -for a structure and how they are used in LifeSim refer to the LifeSim Technical Reference Manual Chapter 4 (USACE 2020). The required steps -to complete the structure inventory tab are: +for a structure and how they are used in LifeSim, refer to +the LifeSim Technical Reference Manual - Chapter: Structure Inventory and Associated Properties. The +required steps to complete the structure inventory tab are: If the index factor is greater than 1, the calculated population change is distributed to structures using a weighting scheme defined by each structure’s occupancy type. The weights allow population to be distributed in a more realistic manner. The weights used to distribute population can - be found in Table 4-7 of the LifeSim Technical Reference Manual (USACE 2020). If the index factor is less than + be found + in Table 8 of the LifeSim Technical Reference Manual. If the index factor is less than 1 then the calculated population change is removed from the structure inventory by removing one-at-a-time from the most populated structures first.

    @@ -1086,7 +1088,8 @@ and/or the local Emergency Management Agency office for their input. Those param The screener selects a qualitative description from a dropdown list for each parameter. The LST assigns a corresponding quantitative relationship to each description and uses that quantitative relationship in the evacuation simulation within LifeSim. More information on the warning and evacuation -timeline and how it is simulated in LifeSim can be found in the LifeSim 2.0 Technical Reference Manual (USACE 2020). +timeline and how it is simulated in LifeSim can be found in +the LifeSim Technical Reference Manual. To complete the emergency preparedness questions in the LifeSim Compute tab, do the following for each question: @@ -1427,8 +1430,9 @@ default First Alert Diffusion functions (Fast, Moderate, Slow). Once an individual, or evacuating group, has received the first alert they are going to take some time before taking protective action and attempting to evacuate the area. Some actions taken prior to taking protective action include verifying the threat, collecting personal belongings, contacting -family and friends, etc. For more information on protective action initiation functions and how they are used in LifeSim, refer to the LifeSim 2.0 -Technical Reference Manual (2020) and Mileti and Sorensen (2017c). The LST 2.0 uses a combination of Evacuation Planning and Community +family and friends, etc. For more information on protective action initiation functions and how they are used in LifeSim, refer to +the LifeSim Technical Reference Manual - Section: Protective Action Initiation Delay and Mileti +and Sorensen (2017c). The LST 2.0 uses a combination of Evacuation Planning and Community Risk Perception to select a protective action initiation function as follows: Evacuation Planning: diff --git a/docx_converter/main.py b/docx_converter/main.py index 5a45af236..7d77eeb83 100644 --- a/docx_converter/main.py +++ b/docx_converter/main.py @@ -23,7 +23,7 @@ # This path will have figure filenames appended (e.g., "/figures/path/to/figure-1.png"). # Must use forward slashes "/" and match the final location in static/figures/. # Example: "figures/desktop-applications/your-software/users-guide/v1.0" -FIGSRC = r"figures/desktop-applications/lifesim/applications-guide/v1.0" +FIGSRC = r"figures/desktop-applications/lifesim/technical-reference-manual/v1.0" # ---- Navigation Component Configuration ---- # These variables configure the NavContainer component shown at the top of each MDX page. @@ -31,9 +31,9 @@ # NAVTITLE: The display text shown in the navigation link (e.g., "User's Guide") # NAVDOC: Document identifier used to fetch available versions from versionList.json # (e.g., "desktop-applications/your-software/users-guide") -NAVLINK = r"/desktop-applications/lifesim/applications-guide" -NAVTITLE = "Applications Guide" -NAVDOC = r"desktop-applications/lifesim/applications-guide" +NAVLINK = r"/desktop-applications/lifesim" +NAVTITLE = "LifeSim" +NAVDOC = r"desktop-applications/lifesim/technical-reference-manual" # ---- File Path Configuration ---- # Set these paths for both development and production environments. @@ -41,30 +41,30 @@ if environment == "production": # PRODUCTION ENVIRONMENT - outputs directly to final locations # DOCX_PATH: Full path to the source Word document - DOCX_PATH = r"C:\Karen\Repositories\RMC-Software-Documentation\static\source-documents\desktop-applications\lifesim\applications-guide\v1.0\LifeSim_Applications_Guide_Aug2024_kwm_ForConversion.docx" + DOCX_PATH = r"C:\Karen\Repositories\RMC-Software-Documentation\static\source-documents\desktop-applications\lifesim\technical-reference-manual\v1.0\LifeSim_Technical_Reference_Manual_kwm_forWebsiteFormat.docx" # BIB_PATH: Full path to the bib.json bibliography file - BIB_PATH = r"C:\Karen\Repositories\RMC-Software-Documentation\static\bibliographies\desktop-applications\lifesim\applications-guide\v1.0\bib.json" + BIB_PATH = r"C:\Karen\Repositories\RMC-Software-Documentation\static\bibliographies\desktop-applications\lifesim\technical-reference-manual\v1.0\bib.json" # FIGURES_DIR: Directory where extracted figures will be saved - FIGURES_DIR = r"C:\Karen\Repositories\RMC-Software-Documentation\static\figures\desktop-applications\lifesim\applications-guide\v1.0" + FIGURES_DIR = r"C:\Karen\Repositories\RMC-Software-Documentation\static\figures\desktop-applications\lifesim\technical-reference-manual\v1.0" # MDX_DIR: Directory where generated MDX files will be saved - MDX_DIR = r"C:\Karen\Repositories\RMC-Software-Documentation\docs\desktop-applications\lifesim\applications-guide\v1.0" + MDX_DIR = r"C:\Karen\Repositories\RMC-Software-Documentation\docs\desktop-applications\lifesim\technical-reference-manual\v1.0" else: # DEVELOPMENT ENVIRONMENT - outputs to temporary location for testing # DOCX_PATH: Full path to the source Word document (typically same as production) - DOCX_PATH = r"C:\Karen\Repositories\RMC-Software-Documentation\static\source-documents\desktop-applications\lifesim\applications-guide\v1.0\LifeSim_Applications_Guide_Aug2024_kwm_ForConversion.docx" + DOCX_PATH = r"C:\Karen\Repositories\RMC-Software-Documentation\static\source-documents\desktop-applications\lifesim\technical-reference-manual\v1.0\LifeSim_Technical_Reference_Manual_kwm_forWebsiteFormat.docx" # BIB_PATH: Full path to the bib.json bibliography file (typically same as production) - BIB_PATH = r"C:\Karen\Repositories\RMC-Software-Documentation\static\bibliographies\desktop-applications\lifesim\applications-guide\v1.0\bib.json" + BIB_PATH = r"C:\Karen\Repositories\RMC-Software-Documentation\static\bibliographies\desktop-applications\lifesim\technical-reference-manual\v1.0\bib.json" # FIGURES_DIR: Temporary directory for testing extracted figures - FIGURES_DIR = r"C:\ExampleFolder\Example_Project_1\Figures" + FIGURES_DIR = r"C:\ExampleFolder\Example_Project_2\Figures" # MDX_DIR: Temporary directory for testing generated MDX files - MDX_DIR = r"C:\ExampleFolder\Example_Project_1\MDX" + MDX_DIR = r"C:\ExampleFolder\Example_Project_2\MDX" # ---- Constants ---- DOCX_PATH = DOCX_PATH diff --git a/src/docConfig.js b/src/docConfig.js index 6adc1a3d5..e5d3ace83 100644 --- a/src/docConfig.js +++ b/src/docConfig.js @@ -37,25 +37,25 @@ const docs = [ category: 'desktop-applications', software: 'lifesim', doc_location: 'desktop-applications/lifesim/users-guide', - doc_name: 'LifeSim Users Guide', + doc_name: "LifeSim User's Guide", active: true, draft: false, }, { category: 'desktop-applications', software: 'lifesim', - doc_location: 'desktop-applications/lifesim/validation-studies', - doc_name: 'LifeSim Validation Studies', + doc_location: 'desktop-applications/lifesim/technical-reference-manual', + doc_name: 'LifeSim Technical Reference Manual', active: true, draft: false, }, { category: 'desktop-applications', software: 'lifesim', - doc_name: 'LifeSim Technical Reference Manual', + doc_location: 'desktop-applications/lifesim/validation-studies', + doc_name: 'LifeSim Validation Studies', active: true, draft: false, - downloadUrl: '/source-documents/desktop-applications/lifesim/technical-reference-manual/LifeSim-Technical-Reference-Manual.pdf', }, { category: 'desktop-applications', diff --git a/src/theme/Layout/buildNavLinks.js b/src/theme/Layout/buildNavLinks.js index d60fb93b9..3c3594a61 100644 --- a/src/theme/Layout/buildNavLinks.js +++ b/src/theme/Layout/buildNavLinks.js @@ -42,15 +42,15 @@ export default function buildNavLinks(useBaseUrl, latestVersions = {}) { const lifeSimUserGuideHref = useBaseUrl( `/docs/desktop-applications/lifesim/users-guide/${latestVersions['desktop-applications/lifesim/users-guide'] || 'v1.0'}/preface`, ); + const lifeSimTechRefHref = useBaseUrl( + `/docs/desktop-applications/lifesim/technical-reference-manual/${latestVersions['desktop-applications/lifesim/technical-reference-manual'] || 'v1.0'}/preface`, + ); const lifeSimValStudiesHref = useBaseUrl( `/docs/desktop-applications/lifesim/validation-studies/${latestVersions['desktop-applications/lifesim/validation-studies'] || 'v1.0'}/preface`, ); const lifeSimAppGuideHref = useBaseUrl( `/docs/desktop-applications/lifesim/applications-guide/${latestVersions['desktop-applications/lifesim/applications-guide'] || 'v1.0'}/preface`, ); - const lifeSimTechRefPdfHref = useBaseUrl( - '/source-documents/desktop-applications/lifesim/technical-reference-manual/LifeSim-Technical-Reference-Manual.pdf', - ); /* -------------------------------------------------------------------------------------------------------------------------------------------------------------- */ @@ -202,12 +202,12 @@ export default function buildNavLinks(useBaseUrl, latestVersions = {}) { href: lifeSimHref, children: [ { id: 'lifesim-users-guide', text: "LifeSim User's Guide", href: lifeSimUserGuideHref }, + { id: 'lifesim-tech-ref', text: 'LifeSim Technical Reference Manual', href: lifeSimTechRefHref }, { id: 'lifesim-validation-studies', text: 'LifeSim Validation Studies', href: lifeSimValStudiesHref, }, - { id: 'lifesim-tech-ref-pdf', text: 'LifeSim Technical Reference Manual (PDF)', href: lifeSimTechRefPdfHref, target: '_blank', rel: 'noopener noreferrer' }, /* { id: 'lifesim-applications-guide', text: 'LifeSim Applications Guide', diff --git a/static/bibliographies/desktop-applications/lifesim/technical-reference-manual/v1.0/bib.json b/static/bibliographies/desktop-applications/lifesim/technical-reference-manual/v1.0/bib.json new file mode 100644 index 000000000..3c9789174 --- /dev/null +++ b/static/bibliographies/desktop-applications/lifesim/technical-reference-manual/v1.0/bib.json @@ -0,0 +1,1306 @@ +[ + { + "citationKey": "Aboelata2011", + "entryType": "presentation", + "author": ["M. A. Aboelata"], + "year": 2011, + "title": "Recent Advances in Life-Loss and Flood Damage Estimation for Dam and Levee Failures" + }, + { + "citationKey": "AboelataBowlesChen2004", + "entryType": "inproceedings", + "author": ["M. A. Aboelata", "D. S. Bowles", "A. Chen"], + "year": 2004, + "title": "Transportation Model for Evacuation in Estimating Dam Failure Life Loss", + "booktitle": "Proceedings of the Australian Committee on Large Dams Conference", + "address": "Melbourne, Victoria, Australia", + "month": "November" + }, + { + "citationKey": "AboelataBowlesMcClelland2003", + "entryType": "inproceedings", + "author": ["M. A. Aboelata", "D. S. Bowles", "D. M. McClelland"], + "year": 2003, + "title": "A Model for Estimating Dam Failure Life Loss", + "booktitle": "Proceedings of the Australian Committee on Large Dams Risk Workshop", + "address": "Launceston, Tasmania, Australia", + "month": "October" + }, + { + "citationKey": "AboelataBowles2005", + "entryType": "report", + "author": ["M. A. Aboelata", "D. S. Bowles"], + "year": 2005, + "title": "LIFESim: A Model for Estimating Dam Failure Life Loss", + "institution": "Institute for Water Resources, U.S. Army Corps of Engineers and Australian National Committee on Large Dams by Institute for Dam Safety Risk Management, Utah State University", + "address": "Logan, UT" + }, + { + "citationKey": "AboelataBowles2006", + "entryType": "report", + "author": ["M. A. Aboelata", "D. S. Bowles"], + "year": 2006, + "title": "Evacuation and Life-Loss Estimation Model for Natural and Dam Break Floods", + "institution": "Proceedings of the U.S. Society on Dam Conference", + "address": "San Antonio, TX" + }, + { + "citationKey": "AboelataBowles2008", + "entryType": "report", + "author": ["M. A. Aboelata", "D. S. Bowles"], + "year": 2008, + "title": "LIFESim: A Tool for Estimating and Reducing Life-Loss Resulting from Dam and Levee Failures" + }, + { + "citationKey": "Arrighi2015", + "entryType": "inproceedings", + "author": ["C. Arrighi", "J. C. Alcerrecha-Huerta", "H. Oumeraci", "F. Castelli"], + "year": 2015, + "title": "Dynamics of Vehicle Debris During a Flood: Incipient Motion Conditions And Numerical Experiments", + "booktitle": "36th IAHR World Congress", + "address": "The Hague, The Netherlands" + }, + { + "citationKey": "Arrighi2016", + "entryType": "article", + "author": ["C. Arrighi", "N. Huybrechts", "A. Ouahsine", "P. Chassé", "H. Oumeraci", "F. Castelli"], + "year": 2016, + "title": "Vehicles instability criteria for flood risk assessment of a street network", + "journal": "Proceedings of the International Association of Hydrological Sciences", + "volume": "373", + "pages": "143-146" + }, + { + "citationKey": "Arrighi2017", + "entryType": "article", + "author": ["C. Arrighi", "H. Oumeraci", "F. Castelli"], + "year": 2017, + "title": "Hydrodynamics of pedestrians' instability in floodwaters", + "journal": "Hydrology and Earth System Sciences", + "volume": "21", + "pages": "515-531", + "doi": "10.5194/hess-21-515-2017" + }, + { + "citationKey": "Lindell2005", + "entryType": "article", + "author": ["M.K. Lindell", "J.C. Lu", "C.S. Prater"], + "year": 2005, + "title": "Household Decision Making and Evacuation in Response to Hurricane Lili", + "journal": "Natural Hazards Review", + "volume": "6", + "pages": "171-179", + "doi": "10.1061/(ASCE)1527-6988(2005)6:4(171)" + }, + { + "citationKey": "Becker2011", + "entryType": "article", + "author": ["A. B. Becker", "W. M. Johnstone", "B. J. Lence"], + "year": 2011, + "title": "Wood frame building response to rapid-onset flooding", + "journal": "Natural Hazards Review", + "volume": "12", + "pages": "85-95" + }, + { + "citationKey": "Black1975", + "entryType": "report", + "author": ["R. D. Black"], + "year": 1975, + "title": "Flood Proofing Rural Residences. A Project Agnes Report prepared for U.S. Department of Commerce", + "institution": "New York State College of Agriculture and Life Sciences", + "note": "Prepared for Economic Development Administration, Washington, DC Office of Technical Assistance" + }, + { + "citationKey": "BonhamHattersley1967", + "entryType": "report", + "author": ["A. J. Bonham", "R. T. Hattersley"], + "year": 1967, + "title": "Low Level Causeways", + "institution": "University of New South Wales", + "address": "Australia" + }, + { + "citationKey": "CH2MHill1974", + "entryType": "report", + "author": ["CH2MHill"], + "year": 1974, + "title": "Potential Flood Damages, Willamette River System", + "institution": "U.S. Army Corps of Engineers", + "address": "Portland, OR" + }, + { + "citationKey": "Chanson2014", + "entryType": "unpublished", + "author": ["H. Chanson", "R. Brown"], + "year": 2014, + "title": "New criterion for the stability of a human body in floodwaters. Discussion", + "note": "Unpublished" + }, + { + "citationKey": "ClausenClark1990", + "entryType": "inproceedings", + "author": ["L. Clausen", "P. Clark"], + "year": 1990, + "title": "The development of criteria for predicting dambreak flood damages using modeling of historical dam failures", + "booktitle": "Proceedings of the International Conference on River Flood Hydraulics", + "editor": "W. White", + "publisher": "Wiley", + "address": "Chichester, U.K.", + "pages": "369-380" + }, + { + "citationKey": "Dale2004", + "entryType": "inproceedings", + "author": ["K. Dale", "M. Edwards", "M. Middelmann", "C. Zoppou"], + "year": 2004, + "title": "Structural flood vulnerability and the Australianisation of Black's curves", + "booktitle": "Proceedings of the Risk Conference", + "publisher": "Risk Engineering Society", + "address": "Barton, Australia" + }, + { + "citationKey": "DHI2019", + "entryType": "manual", + "author": ["DHI"], + "year": 2019, + "title": "Mike 21 Software", + "url": "http://www.mikepoweredbydhi.com/products" + }, + { + "citationKey": "Drobot2007", + "entryType": "article", + "author": ["S. Drobot", "C. Benight", "E. Gruntfest"], + "year": 2007, + "title": "Risk factors for driving into flooded roads", + "journal": "Environmental Hazards", + "volume": "7", + "number": "3", + "pages": "227-234" + }, + { + "citationKey": "ESRI2006", + "entryType": "book", + "author": ["ESRI Press"], + "year": 2006, + "title": "A to Z GIS", + "publisher": "ESRI Press", + "address": "Redlands, CA" + }, + { + "citationKey": "FalconerXia2013", + "entryType": "report", + "author": ["R. A. Falconer", "J. Xia"], + "year": 2013, + "title": "People & Vehicle Stability in Floods", + "address": "Cardiff" + }, + { + "citationKey": "FHWA2006", + "entryType": "report", + "author": ["Federal Highway Administration (FHWA)"], + "year": 2006, + "title": "Empirical Studies on Traffic Flow in Inclement Weather", + "institution": "FHWA", + "address": "Washington, DC", + "number": "FHWA-HOP-07-073" + }, + { + "citationKey": "Fell2003", + "entryType": "article", + "author": ["R. Fell", "C. F. Wan", "J. Cyganiewicz", "M. Foster"], + "year": 2003, + "title": "Time for Development of Internal Erosion and Piping in Embankment Dams", + "journal": "Journal of Geotechnical and Geoenvironmental Engineering", + "volume": "129", + "number": "4", + "pages": "307-314" + }, + { + "citationKey": "FEMA2019", + "entryType": "report", + "author": ["FEMA"], + "year": 2019, + "title": "Summary of Databases in Hazus", + "institution": "FEMA", + "address": "Washington, DC" + }, + { + "citationKey": "FEMA2012", + "entryType": "manual", + "author": ["FEMA"], + "year": 2012, + "title": "Multi-Hazard Loss Estimation Methodology: Earthquake Model. HAZUS-MH 2.1 User Manual", + "institution": "FEMA", + "address": "Washington, DC" + }, + { + "citationKey": "FEMA2020", + "entryType": "manual", + "author": ["Department of Homeland Security"], + "year": 2020, + "title": "Multi-Hazard Loss Estimation Methodology: Earthquake Model. HAZUS-MH 2.1 Technical Manual", + "institution": "Federal Emergency Management Agency (FEMA)", + "address": "Washington, DC" + }, + { + "citationKey": "FEMA2009", + "entryType": "report", + "author": ["FEMA"], + "year": 2009, + "title": "Protecting Manufactured Homes from Floods and Other Hazards: A Multi-Hazard Foundation and Installation Guide", + "number": "FEMA P-85", + "edition": "Second Edition", + "institution": "FEMA", + "address": "Washington, DC" + }, + { + "citationKey": "FLO2022", + "entryType": "manual", + "author": ["FLO-2D Software, Inc."], + "year": 2022, + "title": "FLO-2D Documentation", + "address": "Nutrioso, AZ", + "url": "https://documentation.flo-2d.com/" + }, + { + "citationKey": "Gallegos2012", + "entryType": "article", + "author": ["H. A. Gallegos", "J. E. Schubert", "B. F. Sanders"], + "year": 2012, + "title": "Structural Damage Prediction in a High-Velocity Urban Dam-Break Flood: Field-Scale Assessment of Predictive Skill", + "journal": "Journal of Engineering Mechanics", + "volume": "138", + "number": "10", + "pages": "1249-1262", + "doi": "10.1061/(ASCE)EM.1943-7889.0000427" + }, + { + "citationKey": "Gissing2016", + "entryType": "article", + "author": ["A. Gissing", "K. Haynes", "L. Coates", "C. Keys"], + "year": 2016, + "title": "Motorist Behavior During the 2015 Shoalhaven Floods", + "journal": "Australian Journal of Emergency Management", + "volume": "31", + "number": "2", + "pages": "25-30" + }, + { + "citationKey": "Risher2017", + "entryType": "report", + "author": ["P. Risher", "C. Ackerman", "J. Morrill-Winter", "W. Fields", "J. Needham"], + "year": 2017, + "title": "Levee Breach Consequence Model Validated by Case Study in Joso, Japan", + "institution": "Association of State Dam Safety Officials (ASDSO)" + }, + { + "citationKey": "Risher2016", + "entryType": "report", + "author": ["P. Risher", "S. Gibson"], + "year": 2016, + "title": "Applying Mechanistic Dam Breach Models to Historic Levee Breaches", + "volume": "7", + "journal": "E3S Web of Conferences", + "doi": "10.1051/e3sconf/20160703002" + }, + { + "citationKey": "NSI", + "entryType": "database", + "author": ["U.S. Army Corps of Engineers"], + "title": "National Structure Inventory Database", + "note": "Currently only USACE employees have access", + "url": "https://nsi.sec.usace.army.mil/downloads/" + }, + { + "citationKey": "NSItechdoc2026", + "entryType": "database", + "author": ["Hydrologic Engineering Center"], + "title": "National Structure Inventory (NSI) Technical References", + "year": 2026, + "institution": "U.S. Army Corps of Engineers", + "url": "https://www.hec.usace.army.mil/confluence/nsi/technicalreferences/latest" + }, + { + "citationKey": "FEMA2025", + "entryType": "report", + "author": ["Federal Emergency Management Agency"], + "year": 2025, + "title": "Hazus Inventory Technical Manual: Hazus 7.0", + "institution": "U.S. Department of Homeland Security", + "url": "https://www.fema.gov/sites/default/files/documents/fema_rsl_hazus-7-invtm_06272025_1.pdf" + }, + { + "citationKey": "GordonStone1973", + "entryType": "report", + "author": ["A. D. Gordon", "P. B. Stone"], + "year": 1973, + "title": "Car Stability on Road Causeways", + "institution": "University of New South Wales, Water Research Laboratory" + }, + { + "citationKey": "Hamilton2016", + "entryType": "article", + "author": ["K. Hamilton", "A. E. Peden", "M. Pearson", "M. S. Hagger"], + "year": 2016, + "title": "Stop there's water on the road! Identifying key beliefs guiding people's willingness to drive through flooded waterways", + "journal": "Safety Science", + "volume": "89", + "pages": "308-314" + }, + { + "citationKey": "Harrison1864", + "entryType": "book", + "author": ["S. Harrison"], + "year": 1864, + "title": "A Complete History of the Great Flood at Sheffield on March 11 and 12, 1864" + }, + { + "citationKey": "Healthline2018", + "entryType": "webpage", + "author": ["Healthline"], + "year": 2018, + "title": "Does Your Jogging Speed Feel Right?", + "url": "https://www.healthline.com/health/average-jogging-speed#the-takeaway" + }, + { + "citationKey": "IMPLAN2019", + "entryType": "webpage", + "author": ["IMPLAN Group LLC"], + "year": 2019, + "url": "http://www.implan.com/index.php?option=com_content&view=article&id=153&Itemid=1702" + }, + { + "citationKey": "JonkmanPenningRowsell2008", + "entryType": "article", + "author": ["S. N. Jonkman", "E. Penning-Rowsell"], + "year": 2008, + "title": "Human Instability in Flood Flows", + "journal": "JAWRA Journal of the American Water Resources Association", + "volume": "44", + "pages": "1208-1218", + "doi": "10.1111/j.1752-1688.2008.00217.x" + }, + { + "citationKey": "JonkmanVrijling2008", + "entryType": "article", + "author": ["S. N. Jonkman", "J. K. Vrijling"], + "year": 2008, + "title": "Loss of life due to floods", + "journal": "Journal of Flood Risk Management", + "volume": "1", + "number": "1", + "pages": "43-56" + }, + { + "citationKey": "Jonkman2009", + "entryType": "article", + "author": ["S. N. Jonkman", "B. Maaskant", "E. Boyd", "M. L. Levitan"], + "year": 2009, + "title": "Loss of life caused by the flooding of New Orleans after Hurricane Katrina: analysis of the relationship between flood characteristics and mortality", + "journal": "Risk Analysis", + "volume": "29", + "number": "5" + }, + { + "citationKey": "Jonkman2018", + "entryType": "article", + "author": ["S. N. Jonkman", "M. Godfroy", "A. Sebastian", "B. Kolen"], + "year": 2018, + "title": "Brief communication: Loss of life due to Hurricane Harvey", + "institution": "Copernicus Publications on behalf of the European Geosciences Union" + }, + { + "citationKey": "KellerMitsch1993", + "entryType": "inproceedings", + "author": ["R. J. Keller", "B. F. Mitsch"], + "year": 1993, + "title": "Stability of Cars and Children in Flooded Streets", + "booktitle": "International Symposium on Urban Stormwater Management", + "address": "Sydney, NSW", + "publisher": "Institution of Engineers, Australia" + }, + { + "citationKey": "Lehman2013", + "entryType": "inproceedings", + "author": ["W. Lehman"], + "year": 2013, + "title": "Using HEC-FIA to Identify the Consequences of Flood Events", + "booktitle": "6th International Conference on Flood Management", + "address": "Sao Paulo, Brazil" + }, + { + "citationKey": "Lindell2013", + "entryType": "report", + "author": ["M. K. Lindell"], + "year": 2013, + "title": "Evacuation Planning, Analysis, and Management", + "booktitle": "Handbook of Emergency Response: A Human Factors and Systems Engineering Approach", + "editor": ["A. B. Bariru", "L. Racz"], + "url": "https://www.researchgate.net/publication/284091989_Evacuation_planning_analysis_and_management" + }, + { + "citationKey": "Mahmassani2009", + "entryType": "report", + "author": ["H. S. Mahmassani", "J. Dong", "J. Kim", "R. B. Chen"], + "year": 2009, + "title": "Incorporating Weather Impacts in Traffic Estimation and Prediction Systems", + "institution": "U.S. Department of Transportation", + "address": "Washington, D.C.", + "month": "September" + }, + { + "citationKey": "MartinezGomariz2016", + "entryType": "article", + "author": ["E. Martínez-Gomariz", "M. Gómez", "B. Russo"], + "year": 2016, + "title": "Stability of people exposed to water flows", + "journal": "Ingenieria del Agua", + "volume": "20", + "pages": "43", + "doi": "10.4995/ia.2016.4231" + }, + { + "citationKey": "OSM", + "entryType": "webpage", + "author": ["OpenStreetMap (OSM) Foundation"], + "title": "© OpenStreetMap", + "url": "https://www.openstreetmap.org/copyright" + }, + { + "citationKey": "McBean1988", + "entryType": "article", + "author": ["E. A. McBean", "J. Gorrie", "M. Fortin", "J. Ding", "R. Moulton"], + "year": 1988, + "title": "Adjustment factors for flood damage curves", + "journal": "Journal of Water Resources Planning and Management", + "volume": "114", + "number": "6", + "pages": "635-646" + }, + { + "citationKey": "McClellandBowles2000", + "entryType": "inproceedings", + "author": ["D. M. McClelland", "D. S. Bowles"], + "year": 2000, + "title": "Estimating Life Loss for Dam Safety and Risk Assessment: Lessons from Case Histories", + "booktitle": "Proceedings of the 2000 Annual USCOLD Conference", + "publisher": "U.S. Society on Dams", + "address": "Denver, CO" + }, + { + "citationKey": "McClellandBowles2002a", + "entryType": "report", + "author": ["D. M. McClelland", "D. S. Bowles"], + "year": 2002, + "title": "Estimating Life Loss for Dam Safety Risk Assessment: A Review and New Approach", + "number": "02R-3", + "institution": "Prepared for Institute for Water Resources, U.S. Army Corps of Engineers by Institute for Dam Safety Risk Management, Utah State University", + "address": "Logan, Utah" + }, + { + "citationKey": "McClellandBowles2002b", + "entryType": "report", + "author": ["D. M. McClelland", "D. S. Bowles"], + "year": 2002, + "title": "Estimating Life Loss for Dam Safety Risk Assessment - A Review and New Approach", + "institution": "U.S. Army Corps of Engineers, Institute for Dam Safety Risk Management", + "address": "Logan, Utah" + }, + { + "citationKey": "Milanesi2015", + "entryType": "article", + "author": ["L. Milanesi", "M. Pilotti", "R. Ranzi"], + "year": 2015, + "title": "A conceptual model of people's vulnerability to floods", + "journal": "Water Resources Research", + "volume": "51", + "pages": "182-197", + "doi": "10.1002/2014WR016172" + }, + { + "citationKey": "MiletiSorensen2015", + "entryType": "report", + "author": ["D. S. Mileti", "J. H. Sorensen"], + "year": 2015, + "title": "A Guide to Public Alerts and Warnings for Dam and Levee Emergencies", + "institution": "U.S. Army Corps of Engineers Risk Management Center", + "address": "Davis, CA", + "month": "June" + }, + { + "citationKey": "MiletiSorensen2017a", + "entryType": "report", + "author": ["D. S. Mileti", "J. H. Sorensen"], + "year": 2017, + "title": "First Alert and/or Warning Issuance Time Estimation for Dam Breaches, Controlled Dam Releases, and Levee Breaches or Overtopping", + "institution": "U.S. Army Corps of Engineers Risk Management Center", + "address": "Davis, CA" + }, + { + "citationKey": "MiletiSorensen2017b", + "entryType": "report", + "author": ["D. S. Mileti", "J. H. Sorensen"], + "year": 2017, + "title": "First Alert or Warning Diffusion Time Estimation for Dam Breaches, Controlled Dam Releases and Levee Breaches or Overtopping", + "institution": "U.S. Army Corps of Engineers Risk Management Center", + "address": "Davis, CA" + }, + { + "citationKey": "MiletiSorensen2017c", + "entryType": "report", + "author": ["D. S. Mileti", "J. H. Sorensen"], + "year": 2017, + "title": "Protective Action Initiation Time Estimation for Dam Breaches, Controlled Dam Releases, and Levee Breaches or Overtopping", + "institution": "U.S. Army Corps of Engineers Risk Management Center", + "address": "Davis, CA" + }, + { + "citationKey": "Morris2018", + "entryType": "article", + "author": ["M. Morris", "M. West", "M. Hassan"], + "year": 2018, + "title": "A Guide to Breach Prediction", + "journal": "Dams and Reservoirs", + "volume": "28", + "number": "4", + "pages": "150-152" + }, + { + "citationKey": "Needham2016", + "entryType": "inproceedings", + "author": ["J. Needham", "W. Fields", "W. Lehman"], + "year": 2016, + "title": "The U.S. Army Corps of Engineers Scalable Approach to Estimating Loss of Life from Flooding", + "booktitle": "E3S Web of Conferences 7, 06003, FLOODrisk 2016 – 3rd European Conference on Flood Risk Management" + }, + { + "citationKey": "Needham2020", + "entryType": "inproceedings", + "author": ["J. Needham", "J. Morrill-Winter", "B. Beam", "S. Owen", "W. Fields"], + "year": 2020, + "title": "Validating LifeSim 2.0: Lessons Learned from Application on Historic Events", + "booktitle": "2020 USSD Annual Conference", + "address": "Denver, CO" + }, + { + "citationKey": "NeedhamSeda", + "entryType": "unpublished", + "author": ["J. T. Needham", "Y. Seda-Sanabria"], + "title": "Consequence Estimation for Critical Infrastructure Risk Management", + "note": "Unpublished; received from author" + }, + { + "citationKey": "NEITE", + "entryType": "report", + "author": ["New England Section Institute of Transportation Engineers Technical Committee (NEITE)"], + "title": "Evaluation of Average Effective Vehicle Length in Queue" + }, + { + "citationKey": "HECRAS2024", + "entryType": "manual", + "author": ["Hydrologic Engineering Center"], + "year": 2024, + "title": "HEC-RAS User’s Manual, Version 6.6", + "institution": "U.S. Army Corps of Engineers", + "address": "Davis, CA", + "url": "https://www.hec.usace.army.mil/confluence/rasdocs/rasum/6.6" + }, + { + "citationKey": "PearsonHamilton2014", + "entryType": "article", + "author": ["M. Pearson", "K. Hamilton"], + "year": 2014, + "title": "Investigating driver willingness to drive through flooded waterways", + "journal": "Accident Analysis & Prevention", + "volume": "72", + "pages": "382-390" + }, + { + "citationKey": "RESCDAM2000", + "entryType": "report", + "author": ["RESCDAM"], + "year": 2000, + "title": "The Use of Physical Models in Dam Break Flood Analysis", + "institution": "Helsinki University of Technology", + "address": "Helsinki, Finland" + }, + { + "citationKey": "Wu2013", + "entryType": "report", + "author": ["W. Wu"], + "year": 2013, + "title": "Simplified physically based model of earthen embankment breaching.", + "institution": "Journal of Hydraulic Engineering", + "volume": "139", + "issue": "8", + "pages": "837-851", + "url": "https://doi.org/10.1061/(ASCE)HY.1943-7900.0000741" + }, + { + "citationKey": "Robbins2012", + "entryType": "inproceedings", + "author": ["B. Robbins", "J. L. Wibowo"], + "year": 2012, + "title": "Field Jet Erosion Tests of Treated Clay Levee Embankments", + "booktitle": "ICSE6", + "address": "Paris, France" + }, + { + "citationKey": "RogersSorensen1991", + "entryType": "inproceedings", + "author": ["G. O. Rogers", "J. H. Sorensen"], + "year": 1991, + "title": "Diffusion of emergency warning: comparing empirical and simulation results", + "booktitle": "Risk Analysis", + "editor": "C. Zervos" + }, + { + "citationKey": "Russo2013", + "entryType": "article", + "author": ["B. Russo", "M. Gómez", "F. Macchione"], + "year": 2013, + "title": "Pedestrian hazard criteria for flooded urban areas", + "journal": "Natural Hazards", + "volume": "69", + "pages": "251-265", + "doi": "10.1007/s11069-013-0702-2" + }, + { + "citationKey": "Sangrey1975", + "entryType": "report", + "author": ["D. A. Sangrey", "P. J. Murphy", "J. L. Nieber"], + "year": 1975, + "title": "Evaluating the Impact of Structurally Interrupted Flood Plain Flows", + "institution": "Cornell University", + "note": "Prepared for Office of Water Research and Technology. Distributed by NTIS. PB-247 552" + }, + { + "citationKey": "Shand2011", + "entryType": "inproceedings", + "author": ["T. D. Shand", "G. P. Smith", "R. J. Cox", "M. Blacka"], + "year": 2011, + "title": "Development of Appropriate Criteria for the Safety and Stability of Persons and Vehicles in Floods", + "booktitle": "Proceedings of the 34th World Congress of the International Association for Hydro-Environment Research and Engineering: 33rd Hydrology and Water Resources Symposium and 10th Conference on Hydraulics in Water Engineering", + "address": "Brisbane, Australia" + }, + { + "citationKey": "Shu2011", + "entryType": "article", + "author": ["C. Shu", "J. Xia", "R. A. Falconer", "B. Lin"], + "year": 2011, + "title": "Incipient velocity for partially submerged vehicles in floodwaters", + "journal": "Journal of Hydraulic Research", + "volume": "49", + "number": "6", + "pages": "709-717" + }, + { + "citationKey": "Smith2017", + "entryType": "report", + "author": ["G. P. Smith", "B. D. Modra", "T. A. Tucker", "R. J. Cox"], + "year": 2017, + "title": "Vehicle Stability Testing for Flood Flows", + "institution": "University of New South Wales, Water Research Laboratory" + }, + { + "citationKey": "SorensenMileti2014", + "entryType": "report", + "author": ["J. Sorensen", "D. Mileti"], + "year": 2014, + "title": "First Alert and/or Warning Issuance Time Estimation for Dam Breaches, Controlled Dam Releases, and Levee Breaches or Overtopping", + "institution": "U.S. Army Corps of Engineers, Institute for Water Resources, Risk Management Center", + "address": "Davis, CA", + "note": "Draft paper" + }, + { + "citationKey": "Sorensen2018", + "entryType": "report", + "author": ["J. Sorensen", "D. Mileti", "et al."], + "year": 2018, + "title": "Warning Issuance, Diffusion and Public Protective Action Initiation During the February 2017 Oroville Dam Event", + "institution": "U.S. Army Corps of Engineers, Risk Management Center", + "address": "Davis, CA" + }, + { + "citationKey": "Stedge2006", + "entryType": "report", + "author": ["G. Stedge", "M. Landry", "M. Aboelata"], + "year": 2006, + "title": "Estimating Loss of Life from Hurricane-Related Flooding in the Greater New Orleans Area, Loss-of-Life Modeling Report", + "institution": "Abt Associates", + "address": "Bethesda, MD", + "note": "Prepared for Paul Scodari, U.S. Army Corps of Engineers, Institute for Water Resources" + }, + { + "citationKey": "Toda2013", + "entryType": "inproceedings", + "author": ["K. Toda", "T. Ishigaki", "T. Ozaki"], + "year": 2013, + "title": "Experiment Study on Floating Car in Flooding", + "booktitle": "ICFR", + "address": "Exeter" + }, + { + "citationKey": "TRB2016", + "entryType": "book", + "author": ["Transportation Research Board (TRB)"], + "year": 2016, + "title": "Highway Capacity Manual. 6th Edition: A Guide for Multimodal Mobility Analysis", + "publisher": "Transportation Research Board", + "address": "Washington, DC" + }, + { + "citationKey": "RMC2021", + "entryType": "manual", + "author": ["Risk Management Center"], + "year": 2021, + "title": "LifeSim User's Guide", + "institution": "U.S. Army Corps of Engineers", + "address": "Davis, CA" + }, + { + "citationKey": "USACE1985", + "entryType": "report", + "author": ["U.S. Army Corps of Engineers"], + "year": 1985, + "title": "Business Depth-Damage Analysis Procedures", + "number": "85-R-5", + "institution": "Institute for Water Resources, USACE", + "address": "Alexandria, VA" + }, + { + "citationKey": "Baker1987", + "entryType": "report", + "author": ["E. J. Baker"], + "year": 1987, + "title": "Warning and Evacuation in Hurricanes Elena and Kate", + "institution": "Department of Geography, Florida State University", + "address": "Tallahassee, FL" + }, + { + "citationKey": "USACE1996", + "entryType": "manual", + "author": ["U.S. Army Corps of Engineers"], + "year": 1996, + "title": "Risk-Based Analysis for Flood Damage Reduction Studies", + "number": "EM 1110-2-1619", + "institution": "USACE", + "address": "Washington, D.C.", + "url": "https://www.publications.usace.army.mil/Portals/76/Publications/EngineerManuals/EM_1110-2-1619.pdf" + }, + { + "citationKey": "USACE2003", + "entryType": "report", + "author": ["U.S. Army Corps of Engineers"], + "year": 2003, + "title": "EGM 04-01: Generic Depth-Damage Relationships for Residential Structures with Basements", + "institution": "USACE", + "address": "Washington, D.C." + }, + { + "citationKey": "USACE2006", + "entryType": "report", + "author": ["U.S. Army Corps of Engineers"], + "year": 2006, + "title": "Depth-Damage Relationships for Structures, Contents, and Vehicles and Content-To-Structure Value Ratios (CSVR) in Support of the Donaldsonville to the Gulf, Louisiana, Feasibility Study", + "institution": "USACE New Orleans District", + "address": "New Orleans, Louisiana", + "url": "https://www.mvn.usace.army.mil/Portals/56/docs/PD/Donaldsv-Gulf.pdf" + }, + { + "citationKey": "USACE2014", + "entryType": "manual", + "author": ["U.S. Army Corps of Engineers"], + "year": 2014, + "title": "Safety of Dams – Policy and Procedures", + "number": "ER 1110-2-1156", + "institution": "USACE", + "address": "Washington, D.C.", + "url": "https://www.publications.usace.army.mil/Portals/76/Publications/EngineerRegulations/ER_1110-2-1156.pdf" + }, + { + "citationKey": "USACE2015a", + "entryType": "manual", + "author": ["U.S. Army Corps of Engineers"], + "year": 2015, + "title": "HEC-FIA Flood Impact Analysis User's Manual", + "institution": "Institute for Water Resources, USACE", + "address": "Davis, CA" + }, + { + "citationKey": "USACE2015b", + "entryType": "newsletter", + "author": ["U.S. Army Corps of Engineers"], + "year": 2015, + "title": "Advances in Hydrologic Engineering Newsletter, Spring 2015", + "institution": "Institute for Water Resources, USACE", + "address": "Davis, CA" + }, + { + "citationKey": "USACE2016", + "entryType": "manual", + "author": ["U.S. Army Corps of Engineers"], + "year": 2016, + "title": "HEC-FDA Flood Damage Reduction Analysis", + "institution": "Institute for Water Resources, USACE", + "address": "Davis, CA" + }, + { + "citationKey": "USACE2017", + "entryType": "manual", + "author": ["U.S. Army Corps of Engineers"], + "year": 2017, + "title": "Risk Assessment for Flood Risk Management Studies", + "number": "ER 1110-2-101", + "institution": "USACE", + "address": "Washington, D.C.", + "url": "https://www.publications.usace.army.mil/Portals/76/Publications/EngineerRegulations/ER_1105-2-101.pdf" + }, + { + "citationKey": "USACE2026HECFIA", + "entryType": "manual", + "author": ["U.S. Army Corps of Engineers"], + "year": 2026, + "title": "HEC-FIA Flood Impact Analysis Technical Reference Manual", + "institution": "Institute for Water Resources, USACE", + "address": "Davis, CA" + }, + { + "citationKey": "USCensus2019", + "entryType": "webpage", + "author": ["U.S. Department of Commerce, Census Bureau, Center for Economic Studies"], + "year": 2019, + "url": "https://www.census.gov/programs-surveys/ces.html", + "address": "Washington, D.C." + }, + { + "citationKey": "Census2017", + "entryType": "webpage", + "author": ["American Community Survey, ACS 5-Year Estimates Subject Tables, Table S1810"], + "institution": "U.S. Census Bureau", + "title": "DISABILITY CHARACTERISTICS", + "year": 2017, + "url": "https://data.census.gov/table/ACSST5Y2017.S1810?q=ambulatory+difficulty" + }, + { + "citationKey": "Census2026", + "entryType": "webpage", + "institution": "U.S. Census Bureau", + "title": "Poverty Thresholds for 2025 by Size of Family and Number of Related Children Under 18 Years (in dollars)", + "year": 2026, + "url": "https://www.census.gov/data/tables/time-series/demo/income-poverty/historical-poverty-thresholds.html", + "address": "Washington, D.C." + }, + { + "citationKey": "USDHHS2008", + "entryType": "report", + "author": ["U.S. Department of Health and Human Services"], + "year": 2008, + "title": "2008 Physical Activity Guidelines for Americans", + "institution": "U.S. Department of Health and Human Services", + "address": "Washington, D.C.", + "url": "https://health.gov/sites/default/files/2019-09/paguide.pdf" + }, + { + "citationKey": "Brault2008", + "entryType": "report", + "author": ["M. Brault"], + "year": 2008, + "title": "Disability Status and the Characteristics of People in Group Quarters: A Brief Analysis of Disability Prevalence Among the Civilian Noninstitutionalized and Total Populations in the American Community Survey ", + "institution": "U.S. Census Bureau", + "url": "https://www.census.gov/content/dam/Census/library/working-papers/2008/demo/gq-disability.pdf" + }, + { + "citationKey": "LODES", + "entryType": "report", + "year": 2017, + "title": "LEHD Origin-Destination Employment Statistics (LODES) Dataset Structure Format Version 7.3", + "institution": "U.S. Census Bureau", + "url": "https://lehd.ces.census.gov/data/lodes/LODES7/LODESTechDoc7.3.pdf" + }, + { + "citationKey": "Xia", + "entryType": "unpublished", + "author": ["J. Xia", "R. Falconer", "X. Xiao", "Y. Wang"], + "title": "New Criterion for the Stability of a Human Body in Floodwaters", + "note": "Unpublished" + }, + { + "citationKey": "Xia2011", + "entryType": "article", + "author": ["J. Xia", "F. Y. Teo", "B. Lin", "R. A. Falconer"], + "year": 2011, + "title": "Formula of Incipient Velocity for Flooded Vehicles", + "journal": "Natural Hazards", + "volume": "58", + "number": "1", + "pages": "1-14" + }, + { + "citationKey": "AverillEtAl2005", + "entryType": "incollection", + "author": ["J. Averill", "D. Mileti", "R. Peacock", "E. Kuligowski", "N. Groner", "G. Proulx", "P. Reneke", "H. Nelson"], + "year": 2005, + "title": "Appendix C: Causal Modelling", + "booktitle": "Occupant Behavior, Egress, and Emergency Communications: Federal Building and Fire Safety Investigation of the World Trade Center Disaster (NIST NCSTAR 1-7)", + "chapterTitle": "Predicting Evacuation Delay in the World Trade Center", + "institution": "U.S. Department of Commerce, National Institute of Standards and Technology", + "address": "Washington, D.C.", + "pages": "217-228" + }, + { + "citationKey": "BeanEtAl2014", + "entryType": "report", + "author": ["Hamilton Bean", "Brooke Liu", "Stephanie Madden", "Dennis Mileti", "Michele Wood"], + "year": 2014, + "title": "Comprehensive Testing of Imminent Threat Public Messages For Mobile Devices", + "institution": "National Consortium For The Study Of Terrorism And Responses To Terrorism, University of Maryland", + "address": "College Park, MD" + }, + { + "citationKey": "Burton1981", + "entryType": "report", + "author": ["I. Burton"], + "year": 1981, + "title": "The Mississauga Evacuation: Final Report", + "institution": "Institute of Environmental Studies, University of Toronto", + "address": "Toronto, ON" + }, + { + "citationKey": "BLS2014", + "entryType": "report", + "author": ["Bureau of Labor Statistics"], + "year": 2014, + "title": "American Time Use Survey Summary", + "institution": "Bureau of Labor Statistics", + "address": "Washington, DC" + }, + { + "citationKey": "DillmanEtAl1983", + "entryType": "incollection", + "author": ["D. Dillman", "M. Schwalbe", "J. Short, Jr."], + "year": 1983, + "title": "Communication Behavior and Social Impacts Following the May 18, 1980 Eruption of Mount St. Helens", + "booktitle": "Mt. St. Helens: Three Years Later", + "editor": ["S. Keller"], + "institution": "Washington State University", + "address": "Pullman, WA", + "pages": "173-179" + }, + { + "citationKey": "DrabekStephenson1971", + "entryType": "article", + "author": ["T. Drabek", "J. Stephenson, III"], + "year": 1971, + "title": "When Disaster Strikes", + "journal": "Journal of Applied Social Psychology", + "volume": "1", + "number": "2", + "pages": "187-203" + }, + { + "citationKey": "Drabek1996", + "entryType": "report", + "author": ["T. E. Drabek"], + "year": 1996, + "title": "Disaster evacuation behavior: Tourists and other transients", + "institution": "Natural Hazards Research and Applications Information Center, University of Colorado", + "address": "Boulder, CO" + }, + { + "citationKey": "DuclosEtAl1987", + "entryType": "article", + "author": ["P. Duclos", "L. Sanderson", "F. E. Thompson", "B. Brackin", "S. Binder"], + "year": 1987, + "title": "Community Evacuation Following a Chlorine Release, Mississippi", + "journal": "Disasters", + "volume": "11", + "number": "4", + "pages": "286-289" + }, + { + "citationKey": "DuclosEtAl1989", + "entryType": "article", + "author": ["P. Duclos", "S. Binder", "R. Riester"], + "year": 1989, + "title": "Community Evacuation Following the Spencer Metal Processing Plant Fire, Nanticoke, Pennsylvania", + "journal": "Journal of Hazardous Materials", + "volume": "22", + "pages": "1-11" + }, + { + "citationKey": "GreeneEtAl1981", + "entryType": "article", + "author": ["M. R. Greene", "R. W. Perry", "M. K. Lindell"], + "year": 1981, + "title": "The March 1980 eruptions of Mt. St. Helens: Citizen information and threat perception", + "journal": "Disasters", + "volume": "5", + "pages": "49-66" + }, + { + "citationKey": "GruntfestBenight2005", + "entryType": "report", + "author": ["E. Gruntfest", "C. Benight"], + "year": 2005, + "title": "Toward Improved Warning for Short Fused Weather Events", + "note": "NSF Progress Report", + "institution": "University of Colorado", + "address": "Colorado Springs, CO" + }, + { + "citationKey": "HellriegelKlafft2014", + "entryType": "inproceedings", + "author": ["J. Hellriegel", "M. Klafft"], + "year": 2014, + "title": "A Tool for the Simulation of Alert Message Propagation in the General Population", + "booktitle": "Proceedings of the 11th International ISCRAM Conference", + "editor": ["S. R. Hilts", "M. S. Pfaff", "L. Plotnick", "P. C. Shih"], + "address": "University Park, PA", + "month": "May" + }, + { + "citationKey": "Klafft2013", + "entryType": "inproceedings", + "author": ["M. Klafft"], + "year": 2013, + "title": "Diffusion of emergency warnings via multi-channel communication systems: an empirical analysis", + "booktitle": "2013 IEEE Eleventh International Symposium on Autonomous Decentralized Systems (ISADS)", + "address": "Mexico City", + "note": "6-8 March 2013" + }, + { + "citationKey": "LaveMarch1975", + "entryType": "book", + "author": ["C. Lave", "J. March"], + "year": 1975, + "title": "An Introduction to Models in the Social Sciences", + "publisher": "Harper and Row", + "address": "New York, NY" + }, + { + "citationKey": "LeikEtAl1981", + "entryType": "report", + "author": ["R. Leik", "M. Carter", "J. Clark"], + "year": 1981, + "title": "Community Response to Natural Hazard Warnings: Final Report", + "institution": "University of Minnesota", + "address": "Minneapolis, MN" + }, + { + "citationKey": "LindellPerry1987", + "entryType": "article", + "author": ["M. K. Lindell", "R. W. Perry"], + "year": 1987, + "title": "Warning mechanisms in emergency response systems", + "journal": "International Journal of Mass Emergencies and Disasters", + "volume": "5", + "number": "2", + "pages": "137-153" + }, + { + "citationKey": "LindellPerry1992", + "entryType": "book", + "author": ["M. K. Lindell", "R. W. Perry"], + "year": 1992, + "title": "Behavioral Foundations of Community Emergency Planning", + "publisher": "Hemisphere Press", + "address": "Washington, DC" + }, + { + "citationKey": "LindellEtAl2002", + "entryType": "report", + "author": ["M. K. Lindell", "C. W. Prater", "R. W. Perry", "J. Y. Wu"], + "year": 2002, + "title": "EMBLEM: An Empirically-Based Large Scale Evacuation Time Estimate Model", + "institution": "Texas A&M University Hazard Reduction & Recovery Center", + "address": "College Station, TX" + }, + { + "citationKey": "LindellPerry2004", + "entryType": "book", + "author": ["M. Lindell", "R. Perry"], + "year": 2004, + "title": "Risk Communication in Multiethnic Communities", + "publisher": "Sage Publications, Inc.", + "address": "Thousand Oaks, CA" + }, + { + "citationKey": "MitchellEtAl2005", + "entryType": "report", + "author": ["J. T. Mitchell", "A. S. Edmonds", "S. L. Cutter", "M. Schmidtlein", "R. McCarn", "M. E. Hodgson"], + "year": 2005, + "title": "Evacuation Behavior in Response to the Graniteville, South Carolina, Chlorine Spill", + "note": "Quick Response Research Report 178", + "institution": "Natural Hazards Center, University of Colorado", + "address": "Boulder, CO" + }, + { + "citationKey": "PaulEtAl2003", + "entryType": "report", + "author": ["Bimal Kanti Paul", "Vicki Tinnon Brock", "Shane Csiki", "Lori Emerson"], + "year": 2003, + "title": "Public Response to Tornado Warnings: A Comparative Study of the May 4, 2003, Tornados in Kansas, Missouri, and Tennessee", + "note": "Quick Response Report #165", + "institution": "Natural Hazards Research and Applications Information Center, University of Colorado" + }, + { + "citationKey": "PerryGreene1983", + "entryType": "book", + "author": ["R. Perry", "J. Greene"], + "year": 1983, + "title": "Citizen Response to Volcanic Eruptions: The Case of Mt. St. Helens", + "publisher": "Irvington Publishers", + "address": "New York, NY" + }, + { + "citationKey": "PerryEtAl1981", + "entryType": "book", + "author": ["R. Perry", "M. Lindell", "M. Greene"], + "year": 1981, + "title": "Evacuation Planning in Emergency Management", + "publisher": "Lexington Books", + "address": "Lexington, MA" + }, + { + "citationKey": "PerryMushkatel1986", + "entryType": "book", + "author": ["R. Perry", "A. Mushkatel"], + "year": 1986, + "title": "Minority Citizens in Disaster", + "publisher": "University of Georgia Press", + "address": "Athens, GA" + }, + { + "citationKey": "RogersNehnevajsa1987", + "entryType": "incollection", + "author": ["G. O. Rogers", "J. Nehnevajsa"], + "year": 1987, + "title": "Warning human populations of technological hazards", + "booktitle": "Radiological accidents: Perspectives and emergency", + "editor": ["C. Chester", "S. K. Gant"], + "institution": "American Nuclear Society", + "address": "Washington, D.C.", + "pages": "357-362" + }, + { + "citationKey": "RogersSorensen1988", + "entryType": "article", + "author": ["G. Rogers", "J. Sorensen"], + "year": 1988, + "title": "Diffusion of Emergency Warnings", + "journal": "Environmental Professional", + "volume": "10", + "pages": "281-294" + }, + { + "citationKey": "RogersSorensen1989", + "entryType": "article", + "author": ["G. O. Rogers", "J. H. Sorensen"], + "year": 1989, + "title": "Public Warning and Response in Two Hazardous Materials Accidents", + "journal": "Journal of Hazardous Materials", + "volume": "22", + "number": "1", + "pages": "57-74" + }, + { + "citationKey": "RogersSorensen1991", + "entryType": "article", + "author": ["G. O. Rogers", "J. H. Sorensen"], + "year": 1991, + "title": "Diffusion of Emergency Warning: Comparing Empirical and Simulation Results", + "journal": "Risk Analysis", + "volume": "11", + "pages": "117-134" + }, + { + "citationKey": "RogersEtAl1990", + "entryType": "report", + "author": ["G. Rogers", "A. Watson", "J. Sorensen", "R. Sharp", "S. Carnes"], + "year": 1990, + "title": "Evaluating Protective Actions for Chemical Agent Emergencies", + "institution": "Oak Ridge National Laboratory", + "note": "ORNL-6615" + }, + { + "citationKey": "Sorensen1992", + "entryType": "report", + "author": ["J. Sorensen"], + "year": 1992, + "title": "Assessment of the Need for Dual Indoor/Outdoor Warning Systems and Enhanced Tone Alert Technologies In the CSEPP", + "institution": "Oak Ridge National Laboratory", + "address": "Oak Ridge, TN", + "note": "ORNL/TM-12095" + }, + { + "citationKey": "SorensenMileti1989", + "entryType": "article", + "author": ["J. Sorensen", "D. Mileti"], + "year": 1989, + "title": "Warning Systems for Nuclear Power Plant Emergencies", + "journal": "Nuclear Safety", + "volume": "30", + "number": "3", + "pages": "358-370" + }, + { + "citationKey": "SorensenMileti1990", + "entryType": "incollection", + "author": ["J. Sorensen", "D. Mileti"], + "year": 1990, + "title": "Risk Communication For Emergencies", + "booktitle": "Communicating Risks to the Public: International Perspectives", + "editor": ["R. Kasperson", "P. Stallen"], + "publisher": "Kluwer Academic Publishers", + "pages": "369-394" + }, + { + "citationKey": "SorensenEtAl2009", + "entryType": "report", + "author": ["J. Sorensen", "B. Vogt", "A. Smith"], + "year": 2009, + "title": "Results of an Investigation of the Effectiveness of Using Reverse Telephone Emergency Warning Systems in the October 2007 San Diego Wildfires", + "institution": "Oak Ridge National Laboratory", + "note": "ORNL/TM-2009/154, June" + }, + { + "citationKey": "USNRCFEMA2011", + "entryType": "report", + "author": ["U.S. Nuclear Regulatory Commission", "Federal Emergency Management Agency"], + "year": 2011, + "title": "Criteria for Preparation and Evaluation of Radiological Emergency Response Plans and Preparedness in Support of Nuclear Power Plants", + "note": "NUREG-0654/FEMA-REP-1, Rev.1, Supplement 4: Criteria for National Preparedness Initiative Integration, Exercise Enhancement, and Backup Alert and Notification Systems" + }, + { + "citationKey": "VogtSorensen1999", + "entryType": "report", + "author": ["B. Vogt", "J. Sorensen"], + "year": 1999, + "title": "Description of Survey Data Regarding The Chemical Repackaging Plant Accident, West Helena, Arkansas", + "institution": "Oak Ridge National Laboratory", + "note": "ORNL/TM-13722" + }, + { + "citationKey": "DowCutter2002", + "entryType": "article", + "author": ["K. Dow", "S. L. Cutter"], + "year": 2002, + "title": "Emerging Hurricane Evacuation Issues: Hurricane Floyd and South Carolina", + "journal": "Natural Hazards Review", + "volume": "3", + "number": "1", + "pages": "12-18", + "doi": "10.1061/(ASCE)1527-6988(2002)3:1(12)" + }, + { + "citationKey": "NRC1986", + "entryType": "legalcase", + "author": [], + "year": 1986, + "title": "23 NRC 294: Atomic Safety and Licensing Board in the Matter of Carolina Power and Light Company", + "institution": "Nuclear Regulatory Commission", + "note": "NRC Docket No. 50-400-0L" + } +] \ No newline at end of file diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/break-segment.gif b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/break-segment.gif new file mode 100644 index 000000000..b709b9348 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/break-segment.gif differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure1.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure1.png new file mode 100644 index 000000000..4a8bf16d5 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure1.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure10.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure10.png new file mode 100644 index 000000000..4bea880eb Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure10.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure11.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure11.png new file mode 100644 index 000000000..1388194ce Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure11.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure12.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure12.png new file mode 100644 index 000000000..859cfdc30 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure12.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure13.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure13.png new file mode 100644 index 000000000..fa18eb0f3 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure13.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure14.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure14.png new file mode 100644 index 000000000..1f70f627c Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure14.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure15.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure15.png new file mode 100644 index 000000000..9792a203a Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure15.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure16.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure16.png new file mode 100644 index 000000000..23e637aa6 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure16.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure17.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure17.png new file mode 100644 index 000000000..d54407de5 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure17.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure18.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure18.png new file mode 100644 index 000000000..ee7688204 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure18.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure19.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure19.png new file mode 100644 index 000000000..2adb0fcda Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure19.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure2.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure2.png new file mode 100644 index 000000000..75c696b45 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure2.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure20.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure20.png new file mode 100644 index 000000000..1ab8e6dee Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure20.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure21.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure21.png new file mode 100644 index 000000000..c3c648364 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure21.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure22.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure22.png new file mode 100644 index 000000000..9a1df42d2 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure22.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure23.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure23.png new file mode 100644 index 000000000..dfa0e6ece Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure23.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure24.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure24.png new file mode 100644 index 000000000..551b2286d Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure24.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure25.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure25.png new file mode 100644 index 000000000..de77ea0a1 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure25.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure26.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure26.png new file mode 100644 index 000000000..c03fd883c Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure26.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure27.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure27.png new file mode 100644 index 000000000..07bbfa2ac Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure27.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure28.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure28.png new file mode 100644 index 000000000..096473cb6 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure28.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure29.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure29.png new file mode 100644 index 000000000..1950b0d60 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure29.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure3.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure3.png new file mode 100644 index 000000000..8b11120cf Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure3.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure30.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure30.png new file mode 100644 index 000000000..99301d8d0 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure30.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure31.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure31.png new file mode 100644 index 000000000..1f0316449 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure31.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure32.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure32.png new file mode 100644 index 000000000..377f8f3a8 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure32.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure33.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure33.png new file mode 100644 index 000000000..d16ed2ecd Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure33.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure34.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure34.png new file mode 100644 index 000000000..065487ffe Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure34.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure35.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure35.png new file mode 100644 index 000000000..62c7b6c7a Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure35.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure36.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure36.png new file mode 100644 index 000000000..3c84309f4 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure36.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure37.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure37.png new file mode 100644 index 000000000..412ba12f3 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure37.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure38.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure38.png new file mode 100644 index 000000000..e573ff3f9 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure38.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure39.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure39.png new file mode 100644 index 000000000..2a9dae19b Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure39.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure4.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure4.png new file mode 100644 index 000000000..3a52ffe99 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure4.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure40.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure40.png new file mode 100644 index 000000000..a34beb6f3 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure40.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure41.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure41.png new file mode 100644 index 000000000..1f1264bff Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure41.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure42.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure42.png new file mode 100644 index 000000000..4e1618d35 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure42.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure43.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure43.png new file mode 100644 index 000000000..5d8012c93 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure43.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure44.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure44.png new file mode 100644 index 000000000..9c5ba664f Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure44.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure45.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure45.png new file mode 100644 index 000000000..0c0347b80 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure45.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure46.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure46.png new file mode 100644 index 000000000..ad8dc8fdf Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure46.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure47.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure47.png new file mode 100644 index 000000000..ca915005e Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure47.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure48.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure48.png new file mode 100644 index 000000000..b1ad072e6 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure48.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure49.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure49.png new file mode 100644 index 000000000..081965c09 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure49.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure5.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure5.png new file mode 100644 index 000000000..7f010af29 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure5.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure50.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure50.png new file mode 100644 index 000000000..69a1efad3 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure50.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure51.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure51.png new file mode 100644 index 000000000..3de3b7d92 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure51.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure52.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure52.png new file mode 100644 index 000000000..85d77b3f6 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure52.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure53.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure53.png new file mode 100644 index 000000000..9afb7c52d Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure53.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure54.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure54.png new file mode 100644 index 000000000..396cfffbc Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure54.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure55.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure55.png new file mode 100644 index 000000000..e8d9c57cf Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure55.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure56.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure56.png new file mode 100644 index 000000000..3c19bfbb9 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure56.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure57.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure57.png new file mode 100644 index 000000000..67a03acc7 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure57.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure58.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure58.png new file mode 100644 index 000000000..1e05509f4 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure58.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure59.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure59.png new file mode 100644 index 000000000..e7e514314 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure59.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure6.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure6.png new file mode 100644 index 000000000..c836bd239 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure6.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure60.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure60.png new file mode 100644 index 000000000..ac9cddce8 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure60.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure61.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure61.png new file mode 100644 index 000000000..2d0295fd4 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure61.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure62.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure62.png new file mode 100644 index 000000000..c35ebd7e7 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure62.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure63.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure63.png new file mode 100644 index 000000000..352225ee1 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure63.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure64.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure64.png new file mode 100644 index 000000000..e37219213 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure64.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure65.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure65.png new file mode 100644 index 000000000..0768d52c0 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure65.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure66.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure66.png new file mode 100644 index 000000000..5fa5f370e Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure66.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure67.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure67.png new file mode 100644 index 000000000..5b15972a1 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure67.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure68.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure68.png new file mode 100644 index 000000000..d2c685b5b Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure68.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure69.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure69.png new file mode 100644 index 000000000..1d8144c36 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure69.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure7.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure7.png new file mode 100644 index 000000000..c9921696e Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure7.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure70.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure70.png new file mode 100644 index 000000000..f76f220af Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure70.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure71.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure71.png new file mode 100644 index 000000000..a2fe26577 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure71.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure72.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure72.png new file mode 100644 index 000000000..d8ec9969d Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure72.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure73.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure73.png new file mode 100644 index 000000000..778b62b19 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure73.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure74.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure74.png new file mode 100644 index 000000000..90b25f283 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure74.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure75.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure75.png new file mode 100644 index 000000000..2f2cbf5fc Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure75.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure76.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure76.png new file mode 100644 index 000000000..de462773d Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure76.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure77.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure77.png new file mode 100644 index 000000000..199b20ecf Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure77.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure78.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure78.png new file mode 100644 index 000000000..445c58b45 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure78.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure79.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure79.png new file mode 100644 index 000000000..7c8b02955 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure79.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure8.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure8.png new file mode 100644 index 000000000..ced7b3d54 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure8.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure80.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure80.png new file mode 100644 index 000000000..06297efe9 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure80.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure81.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure81.png new file mode 100644 index 000000000..6bb7c46cb Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure81.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure82.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure82.png new file mode 100644 index 000000000..afb47dae1 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure82.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure83.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure83.png new file mode 100644 index 000000000..fa79c8a04 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure83.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure84.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure84.png new file mode 100644 index 000000000..484284dcd Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure84.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure85.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure85.png new file mode 100644 index 000000000..b2fd30e5c Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure85.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure86.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure86.png new file mode 100644 index 000000000..cd340f674 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure86.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure87.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure87.png new file mode 100644 index 000000000..956fb3150 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure87.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure9.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure9.png new file mode 100644 index 000000000..a2f3c9b91 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/figure9.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/hydraulic-import.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/hydraulic-import.png new file mode 100644 index 000000000..b018e4377 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/hydraulic-import.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/newfig-nsi2026.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/newfig-nsi2026.png new file mode 100644 index 000000000..992659962 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/figures/newfig-nsi2026.png differ diff --git a/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/inline-images/inline-occ-add.png b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/inline-images/inline-occ-add.png new file mode 100644 index 000000000..12c5a1904 Binary files /dev/null and b/static/figures/desktop-applications/lifesim/technical-reference-manual/v1.0/inline-images/inline-occ-add.png differ diff --git a/static/source-documents/desktop-applications/lifesim/technical-reference-manual/LifeSim-Technical-Reference-Manual.pdf b/static/source-documents/desktop-applications/lifesim/technical-reference-manual/LifeSim-Technical-Reference-Manual.pdf deleted file mode 100644 index 7101a759c..000000000 Binary files a/static/source-documents/desktop-applications/lifesim/technical-reference-manual/LifeSim-Technical-Reference-Manual.pdf and /dev/null differ diff --git a/static/source-documents/desktop-applications/lifesim/technical-reference-manual/v1.0/LifeSim_Technical_Reference_Manual_kwm_forWebsiteFormat.docx b/static/source-documents/desktop-applications/lifesim/technical-reference-manual/v1.0/LifeSim_Technical_Reference_Manual_kwm_forWebsiteFormat.docx new file mode 100644 index 000000000..99b65c33e Binary files /dev/null and b/static/source-documents/desktop-applications/lifesim/technical-reference-manual/v1.0/LifeSim_Technical_Reference_Manual_kwm_forWebsiteFormat.docx differ