diff --git a/docs/desktop-applications/lifesim/applications-guide/v1.0/00-document-info.mdx b/docs/desktop-applications/lifesim/applications-guide/v1.0/00-document-info.mdx
new file mode 100644
index 000000000..71eb06a62
--- /dev/null
+++ b/docs/desktop-applications/lifesim/applications-guide/v1.0/00-document-info.mdx
@@ -0,0 +1,28 @@
+---
+title: Document Info
+reportDate: March 2026
+reportType: Computer Program Document
+reportTitle: LifeSim
+reportSubTitle: Applications Guide
+reportAuthors: ['Susie Byrd, Risk Management Center']
+reportAbstract:
+reportAcknowledgments: xx
+reportSubjectTerms:
+responsiblePersonName: xx
+responsiblePersonNumber: ###-###-####
+---
+
+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/applications-guide/v1.0/00-version-history.mdx b/docs/desktop-applications/lifesim/applications-guide/v1.0/00-version-history.mdx
new file mode 100644
index 000000000..628e2985d
--- /dev/null
+++ b/docs/desktop-applications/lifesim/applications-guide/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/applications-guide/v1.0/01-preface.mdx b/docs/desktop-applications/lifesim/applications-guide/v1.0/01-preface.mdx
new file mode 100644
index 000000000..112ddaffb
--- /dev/null
+++ b/docs/desktop-applications/lifesim/applications-guide/v1.0/01-preface.mdx
@@ -0,0 +1,56 @@
+---
+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";
+
+
+
+# Preface
+
+LifeSim is the life loss and direct damage estimation software used by the U.S. Army Corps of Engineers. LifeSim is designed to simulate the entire
+warning and evacuation process for estimating potential life loss and direct economic damages resulting from floods. The following is a description of
+ the major capabilities of LifeSim:
+
+Graphical User Interface
+
+Agent Based Modeling
+
+Evacuation Simulation
+
+Uncertainty
+
+Graphics and Reporting
+
+The user interacts with LifeSim through a graphical user interface (GUI). The interface is designed to make it easy to use the software, while still
+maintaining a high level of efficiency for the user.
+
+LifeSim uses an agent-based approach to track individuals throughout the warning and evacuation process. 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 who are exposed to the hazard and the associated direct damages. By tracking individual people and their movements, LifeSim can help
+identify where people are most at risk of losing their lives, whether it is on roads or in structures.
+
+Three modes of evacuation are included in LifeSim: cars, sports utility vehicles (SUVs), and pedestrians. For vehicular evacuation, a dual regime
+modified Greenshields model (USDOT) in conjunction with spillback enforcement is used for traffic propagation to represent the effects of traffic
+density and road capacity on vehicle speed. Each road is assigned default values for the number of lanes, free flow speed, traffic jam densities, and
+minimum stop-and-go speeds based on the Highway Capacity Manual (HCM) (TRB 2000).
+
+To define the routes people use to evacuate, a road network is provided where each segment of the network contains information such as road category,
+directionality, ground offset (for bridges), and interconnectivity. The road network can be imported from an existing GIS polyline shapefile or from
+OpenStreetMap. OpenStreetMap is a collaborative project to create a free editable map of the world. During each timestep at the user defined interval
+Δt, evacuating groups (PAR evacuating from a structure in a single vehicle) move as far as the model allows until the group reaches a destination
+point, gets caught, or becomes stranded. More information on the evacuation simulation can be found in the (RMC 2021).
+
+LifeSim applies both natural variability and knowledge uncertainty through Monte Carlo analysis. Multiple parameters can be entered with uncertainty
+including those that influence the warning and evacuation timeline. Each iteration in a simulation represents a scenario that could occur given the
+data uncertainties in the model. The results of the analysis provide a distribution of estimated consequences from a given hazard.
+
+
\ No newline at end of file
diff --git a/docs/desktop-applications/lifesim/applications-guide/v1.0/02-introduction.mdx b/docs/desktop-applications/lifesim/applications-guide/v1.0/02-introduction.mdx
new file mode 100644
index 000000000..b1d8dd0e1
--- /dev/null
+++ b/docs/desktop-applications/lifesim/applications-guide/v1.0/02-introduction.mdx
@@ -0,0 +1,75 @@
+---
+title: "Introduction"
+---
+
+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";
+
+
+
+# Introduction
+
+Welcome to the U.S. Army Corps of Engineers LifeSim Applications Guide. LifeSim uses an agent-based methodology for estimating life loss with the
+fundamental intent to simulate population redistribution during an evacuation. Direct life loss, direct economic damages, and direct agriculture
+damages are then determined by the hazard (e.g., flooding). Direct consequences, the primary focus of LifeSim, are those incurred when people,
+structures, or agricultural resources interact with the hazard.
+
+LifeSim is designed to simulate the entire warning and evacuation process for estimating potential life loss and direct economic damages resulting from
+ catastrophic floods (e.g., riverine flooding, coastal flooding, dam breach, and levee breach). LifeSim applies both natural variability and knowledge
+ uncertainty (i.e., naturally occurring change in models’ parameters and outputs and gaps in what can be known by the modelers at the time) through
+Monte Carlo simulation. Many parameters can be entered with uncertainty including those that influence the warning and evacuation timeline (see the ,
+Warning and Evacuation Timeline Section for a more detailed overview). LifeSim is a multifaceted consequence estimation tool that can be utilized for various
+ types of studies and analyses, including dam safety, levee safety, coastal storm risk management, flood risk management, risk communication, and
+more.
+
+## Overview of this Guide
+
+The LifeSim Applications Guide contains written descriptions of seven examples that demonstrate the main features of the LifeSim software. The
+discussions in this manual contain detailed descriptions for the data inputs and analysis of the output for each example. The examples show and
+describe various input and output screens used to enter the data and view the output. The examples are intended as a guide for performing similar
+analyses in LifeSim. The manual is organized as follows:
+
+Summary of LifeSim Inputs, details the required inputs for all LifeSim studies. This section also defines and explains the inputs.
+Finally, some recommended data pre-processing is discussed. Reference back to this section for additional information on Hydraulic Data, emergency
+planning zones, Structure Inventories, Alternatives, and Simulations.
+
+Example 1, Estimating Consequence for Levees and Floodwalls,demonstrates the data required to estimate consequences
+ (life loss and direct economic damages) for a levee or floodwall breach. The example details required inputs, ways to acquire emergency preparedness
+information for populations at risk (PAR) and emergency management agencies (EMAs), how to simulate evacuation, and how to analyze your modeling
+results.
+
+Example 2, Estimating Consequences for Dams, demonstrates the data required to estimate consequences for a dam breach model. The
+example details potential Geospatial Information System (GIS) pre-processing needed for data inputs, editing your structure inventory for accuracy,
+and inputting warning and evacuation data specific to dams.
+
+Example 3, Estimating Consequences for Cascading Dam Breaches, demonstrates various ways to model cascading dam breaches. The example
+ highlights the modeling differences if there is a downstream dam that breaches due to an upstream dam breaching. This example primarily focuses on
+differences in (1) selecting the hazard occurrence time (i.e., the date and time breach or overtopping occurs in the study area) and (2) the
+delineation and parameter selection of the emergency planning zones (i.e., zones in LifeSim that can uniquely sample uncertainty parameters).
+
+Example 4, Estimating Consequences for Coastal Infrastructure,illustrates how LifeSim modeling differs for coastal
+structures (e.g., floodwalls, seawalls, dunes, and levees) compared to riverine infrastructure (e.g., floodwalls and levees), including differences in
+ hydraulic data, warning times, and other consequence nuances specific to coastal infrastructure.
+
+Example 5, Estimating Life Loss in Flood Risk Management Planning, details how to compare life loss across an array of Planning
+alternatives in LifeSim. This example shows how to use typical Planning hydraulic outputs (e.g., eight flow-frequency events typically used in
+Hydrologic Engineering Center’s Flood Damage Reduction Analysis [ HEC-FDA]) in LifeSim to estimate expected annual life loss and how to utilize these
+results in the Planning process.
+
+Example 6, Estimating Direct Economic Damages for Flood Risk Management Planning, focuses solely on generating accurate direct
+economic damages with more uncertainty than the default parameters. The chapter details how to edit and create structure occupancy types, adjust
+stage-damage curve uncertainty, adjust foundation height uncertainty, and adjust structure value uncertainty.
+
+Example 7, Estimating Consequences Using Summary Grids,demonstrates how to estimate life loss and economic damages
+using summary grid output which differs from using Hierarchical Data Format (HDF) files from Hydrologic Engineering Center’s River Analysis System
+(HEC-RAS). This example will be helpful for individuals attempting to estimate consequences for a smaller Planning study, a study that did not utilize
+ unsteady flow in HEC-RAS, or a study with limited output or information from the hydraulic model.
+
+
\ No newline at end of file
diff --git a/docs/desktop-applications/lifesim/applications-guide/v1.0/03-summary-of-lifesim-inputs.mdx b/docs/desktop-applications/lifesim/applications-guide/v1.0/03-summary-of-lifesim-inputs.mdx
new file mode 100644
index 000000000..e85c3d110
--- /dev/null
+++ b/docs/desktop-applications/lifesim/applications-guide/v1.0/03-summary-of-lifesim-inputs.mdx
@@ -0,0 +1,231 @@
+---
+title: "Summary of LifeSim Inputs"
+---
+
+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 TableVertical from "@site/src/components/TableVertical";
+import Figure from "@site/src/components/Figure";
+
+
+
+# Summary of LifeSim Inputs
+
+## Purpose
+
+LifeSim requires an array of inputs in order to calculate life loss and/or economic consequences. This section details the general requirements to run
+ a LifeSim model and some of the recommended pre-processing that should take place outside of LifeSim. The major inputs that require pre-processing
+are the emergency planning zones (EPZ), structure inventory, and the summary output polygon(s) used in the simulations. Inputs required to simulate
+evacuation (i.e., road network and destinations) are discussed in the .
+
+## Hydraulic Data
+
+Each of the applications in this guide details how to import hydraulic data from Hydrologic Engineering Center’s River Analysis System (HEC-RAS),
+including various import sources (e.g., summary grids and Hierarchical Data Format files) from HEC-RAS. There are nuances in selecting the correct
+hazard occurrence time for dams, levees, cascading dam failures, etc. The hazard occurrence time is defined as the point in time in which the hazard
+(e.g., dam breach, levee overtopping) occurs. It is the anchor point for all other time-dependent warning and evacuation parameters within the
+simulation.
+
+It is recommended to reference the Hydraulic Data section for your specific application. There are other hydraulic data sources that can be imported
+into LifeSim that are not discussed in the Applications Guide (e.g. FLO2D). However, they are discussed in the .
+
+## Structure Inventory
+
+To use LifeSim to calculate direct life loss and/or economic damages, a structure inventory must be imported into the study. LifeSim will not simulate
+ if any structure points are located outside of the EPZ.
+
+For LifeSim users located in the U.S., the best available structure inventory data is the most recent version of the National Structure Inventory
+(NSI). The NSI is now public facing and can be leveraged by all U.S. LifeSim users from the . See the for additional information. This dataset
+includes each of the LifeSim required attributes except for Ground Floor Height, Above Ground Floor Height, and Attic Height, which typically use the
+default values shown above. An alternative approach to the base NSI dataset can include various county and state data including local tax assessor,
+parcel, or footprint data that could help inform building location as well as some of the other attributes. Conducting a survey (direct observation or
+ virtually using a tool like Google Earth) within the study area could also inform the structure inventory.
+
+Occasionally, there may be a local dataset (e.g., from a local university, municipality, or some other study unrelated to your own) that has been
+calibrated specifically for the area of interest and surpasses the precision of some of the NSI’s more general assumptions. If a local dataset is
+available, either using GIS software to incorporate the localized data into your inventory or choosing to only use the localized data is often
+preferred.
+
+The NSI was developed using parcel data, building footprints, and several other data sources to create a comprehensive statistical structure
+inventory. LifeSim has the capability of downloading a base NSI inventory based on a provided study area polygon, and other methods for accessing NSI
+data will likely become available in the future. If using an alternative to the NSI, a point structure inventory must be created with the following
+data fields for each structure:
+
+Occupancy Type
+
+Number of Stories
+
+Construction Type
+
+Foundation Height
+
+Population Under 65 (Night)
+
+Population Over 65 (Night)
+
+Population Under 65 (Day)
+
+Population Over 65 (Day)
+
+Structure Value
+
+Content Value
+
+Vehicle Value
+
+The first four fields listed above define the structure types and directly impact the life loss calculations. The occupancy type and construction type
+ fields help to define the structure stability criteria in LifeSim (discussed in more detail in the following sections). Construction type
+specifically denotes outer wall materials such as wood, steel, manufactured, or concrete. The number of stories and foundation height fields help
+define the potential for vertical evacuation and the first-floor elevation of the structure. Population values are required to calculate life loss.
+
+By default, LifeSim uses the 40 occupancy types from HAZUS listed and described below, although they can be customized. The user can also add new
+occupancy types in LifeSim.
+
+
+
+When importing a structure inventory into LifeSim, if structure, content, and/or vehicle values are not readily available, you can check the “Missing”
+ box and enter a default value. In the example below, all structures in the structure inventory have a value of $200,000. If the purpose of the study
+is only to evaluate life loss and not monetary damages, it is appropriate to set these values to $0.
+
+
+
+## Emergency Planning Zones
+
+An EPZ is a geospatial area where the warning and evacuation characteristics are homogeneous; the Emergency Management Agency 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. EPZs also allow LifeSim to have different warning and mobilization parameters for areas that experience different flooding
+characteristics (e.g., breach flows and non-breach flows). Depending on the study’s purpose and level of detail there could be different parameters
+for different areas, communities, or counties. Refer to the for additional information regarding EPZs.
+
+## Alternatives
+
+Each of the applications in this guide include specific details regarding creating alternatives, including selecting imminent hazard identification
+times (i.e., warning times), simulating evacuation, and how many alternatives to include per hydraulic scenario. There are nuances to creating
+alternatives for different types of LifeSim models.
+
+It is recommended to reference the Alternatives section for each application.
+
+## Simulations
+
+There are limited options to select in the Simulations window. However, a key part of LifeSim Simulations is the summary output polygon. A summary
+output polygon is required when creating a simulation. The user may enter multiple summary output polygons in a single simulation. Similar to the
+EPZs, the summary output polygon is a geospatial area and LifeSim will generate results based on the areas in the summary output polygon. The summary
+output polygon can be a shapefile that is not an input for LifeSim. An example of this is using the U.S. Census city boundaries shapefiles to receive
+LifeSim results by city. Another example is simply using the study’s EPZ as the summary output polygon if the results do not need to be specifically
+delineated by area.
+
+(Page is intentionally left blank)
+
+
\ No newline at end of file
diff --git a/docs/desktop-applications/lifesim/applications-guide/v1.0/04-estimating-consequences-for-levees-and-floodwalls.mdx b/docs/desktop-applications/lifesim/applications-guide/v1.0/04-estimating-consequences-for-levees-and-floodwalls.mdx
new file mode 100644
index 000000000..16736a51e
--- /dev/null
+++ b/docs/desktop-applications/lifesim/applications-guide/v1.0/04-estimating-consequences-for-levees-and-floodwalls.mdx
@@ -0,0 +1,1252 @@
+---
+title: "Estimating Consequences for Levees and Floodwalls"
+---
+
+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 Figure from "@site/src/components/Figure";
+import FigureInline from "@site/src/components/FigureInline";
+
+
+
+# Estimating Consequences for Levees and Floodwalls
+
+## Purpose
+
+This example demonstrates the process for estimating consequences for levees or floodwalls in LifeSim. The general process is similar to , but there
+are modeling nuances specific to levees or floodwalls. This chapter focuses on the Cache Creek Levee located in Yolo County, CA. This levee system was
+ originally modeled in 2021 by the U.S. Army Corps of Engineers’ (USACE) Modeling, Mapping and Consequences (MMC) Production Center. This chapter
+includes step-by-step instructions for importing the required data into LifeSim for a levee or floodwall breach model, how to choose appropriate
+warning and evacuation data for a study area, how to simulate evacuation, and how to interpret model results.
+
+## Input Data
+
+The subsequent sections discuss the input data required to calculate direct damages and life loss for a levee or floodwall in LifeSim. The input data
+sections include hydraulic data, emergency planning zones (EPZ), structure inventories, road networks, destinations, creating alternatives, and
+simulating alternatives.
+
+## Hydraulic Data
+
+The Cache Creek Levee utilized output from the Hydrologic Engineering Center’s River Analysis System (HEC-RAS). When using HEC-RAS data in LifeSim,
+the hydraulic data should be in the form of Hierarchical Data Format (HDF) files. HDF files are essentially a file package of depths, velocities, and
+hydraulic timing. Using HDF files allows you to simulate evacuation in LifeSim easily and with greater detail. For most levees/floodwalls, it is
+recommended to simulate evacuation to accurately capture potential life loss in structures and on roads. The HEC-RAS plan HDF file and the
+HEC-RAS terrain HDF file are needed for each hydraulic scenario.
+
+To import the hydraulic data from HEC-RAS, right click on Hydraulic Data in the study pane, and select Import from
+HEC-RAS.
+
+
+
+From the Import from HEC-RAS window, map to the project’s HEC-RAS Plan(s) Directory by clicking on the button with the three dots. The file directory
+selected should contain plan HDF files from HEC-RAS (e.g., p01.hdf). Then, map to the project’s HEC-RAS Terrain File (e.g., terrain.hdf) by clicking
+on the button with three dots. Note, you will also need all terrain Tagged Image Format (TIF) files. Then, you will select the specific HEC-RAS plan
+you want to import by using the dropdown next to HEC-RAS Plan. Once selected, the Name of the hydraulic scenario automatically populates, but the user
+ can alter the Name. Once you have the hydraulic data selected in the Import from HEC-RAS window, you can either select Import from
+RAS or Import from Map.
+
+
+
+### Import HEC-RAS Data – Import from RAS
+
+If you select Import from RAS, select the cross section where the hazard (e.g., overtopping or breach) occurs within the study area.
+The hydraulic engineer should supply you with the project’s breach locations, which correspond to a cross section. After selecting the correct cross
+section, click OK.
+
+
+
+You automatically return to the Import from HEC-RAS window. A representative hydrograph is now shown in the window along with hydraulic timing
+information and corresponding depths at each timestep. Within this window, enter the Hazard Occurrence date and time. The Hazard Occurrence date and
+time should match the time that breach or overtopping (if applicable) begins within the study area. This information can be found in the HEC-RAS model
+ or provided to you by the hydraulic engineer. Press OK; the hydraulic scenario is processed and imported into LifeSim.
+
+
+
+### Import HEC-RAS Data – Import from Map
+
+Alternatively, if you select Import from Map, the RAS Map Data Selector window opens.
+
+
+
+To view a hydrograph along with its hydraulic timing and depths, use the Select Hydrograph Tool in the toolbar (shown below).
+
+
+
+The RAS Map Data Selector map window automatically displays the 2D areas used in the RAS modeling, the cross sections, the hydraulic animation, and a
+base map. The user can change the base map and add data to the map window (e.g., breach locations shapefile, leveed area shapefile, structure
+inventory, etc.) by clicking on the Add Data button (see below).
+
+
+
+For the Cache Creek Levee, adding the breach location shapefile (“LCL” in the layers shown in the figure below) and the leveed area shapefile
+(“POLYGON” in the layers shown in the figure below) to the map window was useful in finding the where the hazard first occurs near the breach
+location.
+
+
+
+Once you find a representative hydrograph for the hydraulic scenario, click OK. The Import from HEC-RAS window is now shown. The new
+window displays hydraulic timing information as well as the same representative hydrograph. Again, the Hazard Occurrence date and time should match
+the time that breach or overtopping (if applicable) begins within the study area. Press OK; the hydraulic scenario will be processed
+and imported into LifeSim.
+
+
+
+Repeat this process for each of the study’s hydraulic scenarios.
+
+## Emergency Planning Zones
+
+As discussed in the , EPZs are polygons that allow LifeSim to have different warning and mobilization parameters for different geographic areas and/or
+ for areas that experience different flooding characteristics. For most levees and floodwalls, the shapefile used for the EPZ should represent the
+estimated leveed area. Otherwise, it is likely that both economic damages and life loss estimates would be inflated due to including consequences that
+ are outside of the leveed area. Presumably you are estimating the risk of a levee or floodwall; therefore, you need to understand where the
+incremental risk (i.e., “levee risk” or the risk associated with the levee) is, which is within the leveed area.
+
+For most levees and floodwalls, the shapefile used for the EPZ should represent the estimated leveed area. The National Levee Database (NLD) is a
+resource that includes most floodwalls and levees within the U.S. (). The NLD shows the leveed area for each project and allows you to download the
+leveed area as a shapefile, which should be used as the EPZ for the entire study.
+
+If the project is not included in the NLD or you are unable to access the NLD, it is recommended to obtain the HEC-RAS model’s 2D mesh area and use
+this shapefile as the EPZ. It’s also recommended to discuss what should be considered the leveed area with your hydraulic engineer and any other team
+members on the study.
+
+### EPZ Warning and Protective Action Parameters
+
+Once you have a representative shapefile for the EPZ, the next step is to assign the Warning and Protective Action Data, including the Warning
+Issuance Delay, Warning Diffusion (First Alert Curves), and Protective Action Initiation (PAI) parameters.
+
+There are a few types of resources to consider when gathering information about the area’s warning and evacuation procedures: (1) any expert opinion
+consequence elicitation conducted in the city or county in question within 5 years of the current analysis, (2) the USACE Levee Screening Tool (LST),
+ and (3) local, county, and/or state Emergency Management Agency (EMA) websites and social media. Reaching out to communities directly, or the
+responsible USACE districts, and asking questions to gauge the need for a more formal consequence elicitation is perfectly acceptable if the data
+available is in question.
+
+If these resources are not available for your project, you should select LifeSim’s preset Unknown parameters for Warning Issuance Delay, Hazard
+Communication Delay, and Protective Action Initiation curves within the EPZ editor.
+
+The subsequent sections discuss the three resources that should be considered when developing your warning and evacuation parameters.
+
+#### Using Existing Consequence Elicitation Data to Inform LifeSim Parameters
+
+Over recent years, many consequence elicitations have been conducted within the U.S. to support risk assessments. The consequence elicitations are
+generally conducted for various high-risk cities and/or counties. When starting a new LifeSim model or risk assessment, check if an elicitation was
+already conducted within your study area. The current consequence elicitation directory is stored on a and is for internal use only. Reaching out to
+the responsible USACE district is a perfectly acceptable way to assess whether or not an elicitation has been or needs to be conducted for your study.
+ If an elicitation was completed, you can likely use most of these same parameters for your LifeSim model. It is recommended to review the elicitation
+ results, including the meeting notes and elicited LifeSim parameters, to ensure the parameters are logical for your levee project. If the elicitation
+ was conducted for a dam, review the notes to ensure that the elicitation could be applied to a levee. There may be instances in which you do not feel
+ confident that the previous elicitation results directly apply to your project, which could cause you to gather other resources to make an informed
+decision.
+
+#### Using the Levee Screening Tool to Inform LifeSim Parameters
+
+The Levee Screening Tool (LST) () can contain helpful information regarding expected emergency action plans, community awareness, and warning systems
+to inform the EPZ’s warning and evacuation data. Within the LST, a levee may have several segments with individual screenings. It is recommended to
+look at the segment with the most screenings, or to identify the screening that was completed most recently; this screening will have the most
+up-to-date information. Generally, all levee units are rescreened as a system, but there can be special instances in which this is not the case.
+
+If you attempt to login to the LST and are unable, there are instructions on the login page to request/create an account.
+
+The figure below shows the screenings for the segments of Cache Creek Levee available in the LST.
+
+
+
+As shown in the figure below, Cache Creek Levee was last screened several years ago in 2015. The user may find that this information is not recent
+enough to use in the LifeSim study. Since the 6 levee segments were all screened at the same, I selected the segment that has the most screenings:
+Willow Slough Bypass – Unit 1, left bank.
+
+
+
+After selecting a levee unit screening, navigate to the Consequences section of the LST.
+
+
+
+This Consequences section of the LST shows key consequences information such as Evacuation Planning, Community Awareness, and Flood Warning
+Effectiveness. Each of these elements can be helpful in determining preset LifeSim curves if the explanations of the scores are detailed, recent, and
+logical. The details for Cache Creek Levee’s Evacuation Effectiveness Information are shown below.
+
+
+
+The Evacuation Planning factor may help determine the Warning Issuance Delay. As shown above, the latest Evacuation Planning information is from 2012
+and 2013. This may not be the most up-to-date information; it is recommended to confirm the information by looking into the Emergency Management
+Agency’s website (see next section for details). If the Evacuation Planning factor was given an Acceptable rating (with quality reasoning) you would
+select an optimistic Warning Issuance Delay curve, such as Well Prepared.
+
+The Community Awareness factor can be used to inform the Protective Action Initiation curve. If the rating is Acceptable and the explanation includes
+information about recent flood events/evacuations, public education campaigns, and flood preparedness as a topic in the media, then an optimistic PAI
+curve could be warranted, such as the Perception: High / Preparedness: High. However, if the rating is Unacceptable and none of the previously stated
+factors are included in the explanation, a more pessimistic PAI curve may be warranted, such as the Perception: Low / Preparedness: Low.
+
+The Flood Warning Effectiveness factor can be used to inform the Warning Diffusion/First Alert curves. If this factor received an Acceptable rating
+and the explanation details several different types of warning channels (e.g., radio, media, reverse 911, and texts), then an optimistic Warning
+Diffusion curve should be used, such as the Moderately Fast or the Fast curves.
+
+If the ratings and explanations could defend a variety of LifeSim parameters, it is recommended performing sensitivity runs using a variety of
+parameters to determine if life loss changes significantly and then seek additional information from the local sponsor and/or the project’s district
+office. The local personnel should be able to provide more information to determine final LifeSim parameters if necessary. Additionally, you can
+provide a variety of results in your study and clearly state the differences between the sets of alternatives and simulations. The variety of
+scenarios provide uncertainty to the life loss estimates, especially if there is some uncertainty regarding some of the warning and evacuation
+parameters. Ensure there is defensible reasoning for each uncertainty parameter.
+
+#### Using Emergency Management Agency Websites to Inform LifeSim Parameters
+
+Looking through the county’s Emergency Management Agency’s (EMA) website or social media provides insight on the area’s emergency procedures, recent
+updates to emergency action plans or hazard mitigation plans (if applicable), and what warning channels are available, which can inform the EPZ’s
+warning and evacuation data.
+
+The Cache Creek Levee is in Yolo County, CA. This section discusses the emergency procedures and resources from Yolo County Emergency Management and
+demonstrates how to use this type of information to select appropriate warning and evacuation parameters. As shown in the screenshot below, Yolo
+County’s website links to Current Emergencies and Incidents (listed in both English and Spanish), Flooding Resources, and the county’s relatively
+recent updates to emergency preparedness and resources.
+
+
+
+As you scroll down this webpage, there are additional links about how to prepare for an emergency, signing up for Yolo Alert, and contact information
+for the Office of Emergency Services. After clicking on the link to sign up for emergency alerts, you are sent to a webpage to sign up for Yolo
+County’s warning system, Everbridge, which is an advanced public warning system.
+
+
+
+While selecting uncertainty parameters for your EPZ, consider if the area experienced flooding recently, especially large flood events that resulted
+in evacuations. This information helps select warning and evacuation data in LifeSim (e.g., heightened community awareness, recent experience writing
+and sending out warnings, etc.). Regardless of the curves you select for your study, defensible reasoning for each warning and evacuation parameter is
+ needed.
+
+### Importing an Emergency Planning Zone
+
+This section discusses importing an EPZ into LifeSim and how to use the information discussed in the previous sections to determine the final
+parameters used in the study. For Cache Creek Levee, the readily available warning and evacuation data, the local EMA website, and recent flood
+warnings and evacuations are heavily relied upon to determine appropriate warning and evacuation parameters.
+
+Once you determine the EPZ shapefile and gather information on the area’s warning and evacuation data, import the EPZ shapefile into LifeSim. Right
+click on Emergency Planning Zones in the study tree and select Import EPZs from Shapefile.
+
+
+
+The Import Emergency Planning Zones window opens. First, map to the EPZ shapefile. You can do this by either utilizing the Emergency Planning Zone
+Polygon Shapefile dropdown, which displays the polygon shapefiles that are currently in your Map Layers, or you can map to the shapefile by clicking
+on the button with the three dots next to dropdown.
+
+
+
+Then, designate one of the shapefile’s fields as the Emergency Planning Zone Name Field. If you are importing a shapefile composed of multiple areas,
+or EPZs (e.g., two counties), the Emergency Planning Zone Name Field needs to have unique values. After selecting the Name Field, select the warning
+and evacuation data for the EPZ(s). For the Cache Creek Levee, the National Levee Database named the leveed area “Sugarfield – Woodland NE”.
+
+As stated previously, information from the Yolo County Office of Emergency Services website is heavily utilized to select warning and evacuation data.
+ To accurately select the Warning Issuance Delay curve to be used in the study, consider if there are message templates, if the county has recently
+(within the past 10 years) sent out an evacuation warning, especially within the leveed area, and if there are trainings or standard operating
+procedures for writing warning messages.
+
+When utilizing only the local emergency management website, some of this information may be difficult to find. It is recommended to do additional
+research about the leveed area and any flooding that may have occurred in this area. For example, after a brief internet search, there multiple
+articles reporting that the Cache Creek Levee was overtopped in 2019. Yolo County Sheriff’s Office released evacuation notices via Twitter (see
+screenshot below) and through Yolo County AlertSense (Everbridge). Yolo County emergency managers have recently sent out warning and evacuation
+messages directly related to a levee safety emergency occurring at Cache Creek Levee.
+
+
+
+Because we don’t fully understand how quickly the warning was sent out relative to when Yolo County was notified of the emergency, the Moderately
+Prepared warning issuance delay curve was selected to allow for more uncertainty in the delay time. The most likely sampled warning issuance delay
+time is 16 minutes (about 21% likelihood), but there is still probability that the delay is longer or shorter (e.g., there is a 12% likelihood that
+the delay is 50 minutes; there is a 15% likelihood the delay is 10 minutes.)
+
+
+
+Next, select First Alert Diffusion curves for the EPZ. This parameter is heavily influenced by the amount of communication channels the county would
+use during a levee safety emergency. As shown in the section above, Yolo County has an opt-in alert system. The website also shows Yolo County uses
+Everbridge, which is a robust mass alert system. Everbridge distributes messages via phone calls, texts, and emails. Additionally, following the 2019
+Cache Creek Levee overtopping, it’s likely that several people signed up for alert messages through AlertSense. It is known that Yolo County utilizes
+social media, radio, and news to distribute a warning message.
+
+Given what we do know about the available communication channels, the warning message would likely be distributed to the relatively small leveed area
+quickly. However, since AlertSense (Everbridge) is an opt-in system, and it is unclear what percentage of the population protected by Cache Creek has
+signed up for this system, it is not recommended to assume the most optimistic First Alert curve. With our baseline understanding of Yolo County’s
+available warning channels, the Moderately Fast First Alert Diffusion curve was selected.
+
+
+
+Finally, select the PAI curve. Recent experiences (within the past decade) with flooding and/or evacuation are reason to assume more optimistic PAI
+curves; conversely, if the community doesn’t have a history of flooding, the selected PAI curves should be more pessimistic. The residents protected
+by Cache Creek Levee experienced flooding due to levee overtopping in 2019. As shown in the evacuation order posted by the Yolo County’s Sheriff
+Office on Twitter, approximately 100 people were asked to evacuate from the Cache Creek leveed area. However, because the effectiveness of the
+evacuation order is unknown, it is recommended to allow for more uncertainty in the PAI curve. The Perception: High / Preparedness: Low PAI curve was
+selected for Cache Creek Levee to both account for the area’s recent experience with flooding and witnessing the potential consequences (Perception:
+High) and uncertainty regarding the population’s readiness to mobilize (Preparedness: Low) since there is limited knowledge on preparedness.
+
+
+
+The user is encouraged to perform additional sensitivity tests on parameters that have significant knowledge uncertainty. In this example, there is
+limited information on the community’s preparedness during a flood emergency. Therefore, the user should run simulations with the Perception: High /
+Preparedness: Low PAI curve as well as the Perception: High / Preparedness: Moderate PAI curve to better understand the model’s sensitivity to the
+selected PAI curve. Then, the user may want to run the Perception: Unknown / Preparedness: Unknown curve as an additional sensitivity test. Regardless
+ of your final model parameters, ensure there is ample justification for the selected warning evacuation parameters and that they accurately represent
+ the impacted areas.
+
+Ensure the warning and evacuation parameter assumptions are clearly documented.
+
+After selecting your uncertainty parameters, enter a name for the EPZ, press OK, and the EPZ is imported into the LifeSim study.
+
+## Structure Inventory
+
+### Importing a Structure Inventory
+
+To import a structure inventory from an existing point shapefile, navigate to the Study pane in your model, right click on Structure
+Inventories, and select Import from Point Shapefile.
+
+
+
+Then, either select the Structure Inventory Shapefile from the dropdown, which is available if the shapefile is in the Map Layers pane of the LifeSim
+model, or map to the shapefile by clicking on the button with the three dots next to the dropdown. Notably, there are several required attributes in
+order for LifeSim to properly calculate economic damages and life loss. The list of required attributes from the Import from Point Shapefile window is
+ shown below.
+
+
+
+Once you match up your shapefile’s attributes (Import Attributes) with the corresponding LifeSim Required Attributes (an example of matched up
+attributes using the NSI is shown in the figure below), click Next at the bottom right. If the shapefile is missing certain
+attributes (e.g., Other Value in the figure below), you can check the “Missing” checkbox and enter a default value. This value will be the same for
+each structure in the inventory.
+
+
+
+Then, match the occupancy types in LifeSim with the occupancy types included in your structure inventory shapefile. If using the NSI, typically the
+occupancy types exactly match the occupancy type names in LifeSim, but the user should scan through the list to ensure everything is matched up
+correctly. If these are mismatched, the depth-damage functions, evacuation parameters, and submergence criteria will not be correct for that structure
+ type, which impacts the accuracy of your economic damages and life loss results.
+
+
+
+After the occupancy types are assigned and reviewed, click Next. The final step for importing the inventory is the Stability Criteria
+ Assignment. LifeSim has default stability criteria assignments for wood unanchored structures (e.g., mobile homes), wood anchored structures, masonry
+ structures, and steel structures. For NSI users, you should use the default stability criteria shown below.
+
+
+
+You can create additional criteria rules by clicking Create Rule. A new rule appears in the Rule List; enter a Rule Name and set the
+logic for the new stability criteria. For example, if you want to adjust the criteria for Wood 2-story structures to use the USACE – Wood 2-story
+stability criteria, select the following information:
+
+
+
+Once all structures have been assigned a stability criterion, click Finish. The structure inventory is then imported into LifeSim.
+
+### Editing the Structure Inventory
+
+After importing a structure inventory into LifeSim, edits to the attribute table and/or structure placement are likely needed. To edit the imported
+structure inventory, right click on the study’s structure inventory and click Show in Map Window.
+
+
+
+Navigate to the Map Layers pane. Right click on the structure inventory (NSI2_CacheCreek below) and select Edit. You can now edit the
+ placement of structure points in the map window and edit structure attributes in the attribute table.
+
+
+
+Once you are done editing the structure inventory, right click on the structure inventory in the Map Layers pane (NSI2_CacheCreek in the figure below)
+ and select Stop Editing.
+
+
+
+A pop-up window then asks if you want to save your changes to the study’s structure inventory file. Select Yes and the changes are
+reflected in the structure inventory both in the Study pane and Map Layers pane.
+
+
+
+## Simulating Evacuation
+
+For most levee/floodwall projects, evacuation is simulated in LifeSim. In addition to the hydraulic data, EPZs, and structure inventory, you need to import
+ (1) a road network and (2) destination points to simulate evacuation in LifeSim. The recommended workflow is to begin with importing a road network
+and then create destination points.
+
+### Road Network
+
+There are two ways to import a road network: (1) download and import a road network from OpenStreetMap (OSM) within LifeSim and (2) import a polyline
+shapefile. Unless you have detailed data from a previous study or from local stakeholders, you will download and import a road network from
+OpenStreetMap.
+
+#### Downloading a Road Network in LifeSim
+
+To download and import a road network, navigate to the Study Pane, right click on Road Networks, and select Import Road
+Network From OpenStreetMap.
+
+
+
+The Import Road Network From OpenStreetMap window opens. The primary data needed to import a road network is a bounding polygon shapefile. The
+bounding polygon determines what roads are downloaded from OpenStreetMap. The easiest bounding polygon to use for import is the shapefile used for the
+ EPZ; additionally, the bounding polygon needs to be in the same projection as the LifeSim study Once you select the polygon, type in a bounding
+polygon buffer (the value represents miles).
+
+As shown below, the Cache Creek EPZ shapefile is being used for import. The Bounding Polygon Buffer is set to 1 mile. The additional mile of road
+network allows for more realistic traffic congestion in the simulation and increases the accuracy of potential evacuation routes. There should be some
+ amount of buffer included on the bounding polygon for import, unless the selected shapefile is already buffered or larger than the leveed area.
+Selecting an appropriate buffer size depends on the size of the study area, inundation extents, the density of the population, and known evacuation
+routes. Do not make the buffer too large as this imports many additional road segments that (1) may not improve the evacuation accuracy and (2) can
+significantly increase simulation run times as depths and velocities on each road segment are calculated (i.e., more road segments lead to longer
+simulation times).
+
+
+
+As shown above, there are several types of road segments included in OpenStreetMap road networks. LifeSim has certain road types automatically
+selected and deselected for import. However, depending on the study area, you may need to include additional road segment types. For example, if the
+study area is primarily rural or farmland, you would want to select tertiary (“The next most important roads in a country’s system”), residential
+(“Roads which serve as an access to housing without function connecting settlements. Often lined with housing”), and track (“Roads for mostly
+agricultural or forestry uses”) for import. For larger or primarily urban study areas, it is recommended to import only the default, or baseline road
+types to reduce simulation run times. Once you have selected or deselected the road segment types that should be included in your road network, select
+ OK, and the road network downloads and imports into the study.
+
+#### Import Road Network from Shapefile
+
+The other method of importing a road network is to use an existing polyline shapefile. Navigate to the study pane, right click on Road
+Networks, and select Import Road Network from Shapefile.
+
+
+
+The Import Road Network window opens. Map to the Road Network Shapefile by either using the dropdown (only polyline shapefiles that are in the map
+window are shown) or by clicking the button with the three dots next to the dropdown. Then, match the CFCC Name Field to the corresponding attribute from
+ the polyline shapefile, which should be an already existing attribute if you are importing a road network from a previous study. Then, match the
+One-Way Field (with an identifier) and the Vertical Offset attribute. These fields are optional but increase the accuracy of the road network. Once
+you match up the field(s) with your shapefile’s attribute(s), select OK and the road network imports.
+
+
+
+#### Editing a Road Network
+
+After importing a road network into LifeSim, edits to the polygon and/or the road network’s attributes are likely needed. OSM provides a base for an
+accurate road network. However, there are aspects to the data that may need to be edited and confirmed. One of the key components of a road network is
+ the “Vertical Offset” field, which is found in the road network attribute table. This field accounts for if a road segment should have some amount of
+ vertical offset relative to the terrain elevation, such as a bridge or highway overpass. The default vertical offset for all road segments in OSM is
+0. Vertical offsets should be confirmed and edited throughout the study area. Focus on areas you can visibly see road segments over waterways (i.e.,
+bridges) and areas where highways are most concentrated (there may be overpasses). To view the attribute table and the Vertical Offset field, right
+click on the imported road network from the Study pane and select Show in Map Window. Navigate to the Map Layers pane, right click on
+ the road network, and select Open Attribute Table.
+
+
+
+
+
+For Cache Creek Levee, there are several highway overpasses in the study’s road network. Many of these overpasses lead to destination points and need
+to have accurate vertical offsets. The highlighted road segments shown below are parts of highways located over a different highway. A vertical offset
+ of 40 feet was given to both segments. Without accounting for the 40 feet of vertical offset within the attribute table, LifeSim may wrongly show
+this overpass as inundated. This could negatively and incorrectly impact evacuation to the south, potentially affecting estimated direct life loss.
+Use best available data to determine accurate vertical offsets (e.g., Google Street View).
+
+
+
+
+
+It is recommended to save the road network edits as you progress. For example, save the road network and the LifeSim study after making a few road
+network edits, then make additional edits to the road network and save again. Several edits to one shapefile can overload LifeSim’s memory and may
+crash the program prior to saving your edits.
+
+### Destination Points
+
+The other key element for simulating evacuation is destination points, which represent where the evacuating population should/will go to reach safety.
+ To import destinations, a point shapefile is needed. You can create the required point shapefile in LifeSim or in another geospatial software (e.g.,
+ArcGIS Pro or QGIS).
+
+#### Creating a Point Shapefile in LifeSim
+
+Locate the toolbar at the top of the map window. Click on the down arrow next to the folder with a plus sign (
+{"\n"}) and select Create
+ New.
+
+
+
+The Create New Vector Features File window opens. Click on the button with three dots to select the file output location.
+
+
+
+A new window opens that allows you to map to your desired file location. Name the shapefile and click Save.
+
+
+
+Select the appropriate Feature Type from the dropdown (Point for a Destinations file) and either use the map projection (recommended) or map to
+another project file. Press OK and your new point shapefile is added to the map window.
+
+
+
+To add features within the point shapefile, navigate to the map pane, right click on the point shapefile you created, and select
+Edit. Navigate to the toolbar at the top of the map window and click the Add New Features button. This now allows
+you to create new points, which represent evacuation destinations.
+
+
+
+It is best to place destination points directly on road segments, so it is recommended to also have your road network in the map window. If the point
+is not placed directly on a road segment, the closest road segment is assumed to be the destination point. When creating destination points, most of
+the points should be on major highways and roadways. The destination points should generally not be shelters or large buildings because there is no
+way to set a limit on how many people can evacuate to each destination point. This would lead to inaccuracies in your evacuation simulation.
+
+In general, attempt to place each of the destination points an equal distance away from the study area. If one destination is significantly closer to
+the study area, LifeSim will direct most of the population to this destination point since it is the closest distance and most likely the quickest
+evacuation route. The group evacuating selects which destination point to evacuate based on the shortest travel time (i.e., accounting for traffic
+congestion), not the shortest travel distance. Depending on the study area and available information, you may want to place some destination points
+closer or farther away from the study area (e.g., If you want more people to evacuate east rather than north, place the destination points to the east
+ closer to the study area than the northern destination points).
+
+For Cache Creek, the study area is most densely populated in the western portion of the leveed area. The flooding source is along the eastern portion
+of the leveed area, so the destination points located to the west are the preferred destination routes, therefore the northern and western destination
+ points are closer to the population center compared to the destination points to the east of the leveed area.
+
+
+
+Once you have placed all your initial destination points in the map window, edit the attribute table to give each feature unique attributes. As you
+place destinations, new rows are automatically created in the point shapefile’s attribute table. The figure below shows that as two new points are
+placed in the map window, two new rows are created. The attribute shown in the attribute table (“Id”) automatically populates as a blank attribute;
+each point needs a unique “Id” value.
+
+
+
+To import a destinations file, at least one of the fields in the attribute table needs to have unique naming (Destinations Naming Identifier). The Id
+field could be used, but it’s recommended to create a new field in the shapefile’s attribute table. To create a new field, click Open Field
+Calculator.
+
+
+
+The Field Calculator window opens. Select Create New Column and type a field title (e.g., Name). Within the Expression box, type “=”
+with some text, which automatically sets the field type to be text rather than an integer (e.g., type “=RoadName”). Then press
+Execute.
+
+
+
+The attribute table should now include a new field with placeholder text. You are now able to edit each attribute’s name.
+
+
+
+For clarity and ease of use, each destination point should be named based on the road it’s placed on.
+
+
+
+Press the Stop Editing Feature Session button (
+{"\n"}) and click
+Yes after the Save Map Edit dialog box pops up.
+
+#### Importing and Editing Destinations File(s)
+
+After creating a point shapefile that represents the study area’s destination points, you can import the shapefile into LifeSim as a destinations
+file. Navigate to the Study pane, right click on Destinations, click Import Destinations from Shapefile.
+
+
+
+The Import Destinations from Point Shapefile window opens. Enter a name for the destinations file. Then, select the point shapefile you want to import.
+ If the shapefile is in the Map Layers pane, it will be available via the dropdown. Otherwise, click on the three dots next to the dropdown to map to
+the destinations shapefile file location.
+
+
+
+Then, select the Destination Identifier Field. For the destinations to import into LifeSim, each destination must have a unique name (i.e., the field
+cannot contain blank attributes and the selected field cannot contain duplicate names). Press OK and the destinations import into the
+ study.
+
+
+
+Once the destinations file is imported, ensure you edit the study’s destination file, not the original shapefile created in the Map Layer pane. Like
+editing the study’s structure inventory, add the newly imported destination file to the map window, right click on the file (in the Map Layers pane),
+and select Edit. You can now add destinations, edit the destination placement, and edit the attribute table. After saving any edits,
+these changes are reflected in the study’s destinations file.
+
+## Creating Alternatives
+
+Once you have all the input data imported in the LifeSim study, you can begin creating alternatives. To create an alternative, navigate to the Study
+pane, right click on Alternatives, and click Create New Alternative.
+
+
+
+To create an alternative for a levee, include all input data required to calculate life loss and simulate evacuation. For most levee studies, this
+includes hydraulic data, a structure inventory, an EPZ, a road network, and destinations. Select the input data through the dropdown menus within the
+Create New Alternative window. In addition to the input data, other warning and evacuation parameters need to be entered for each alternative. Two
+other inputs required to create an alternative are the Imminent Hazard Identification Time and the Hazard Communication Delay. Input values (in hour
+units) for both parameters. If you have multiple EPZs, enter the information for these parameters for each EPZ.
+
+
+
+The example alternative below (LCL_TOL_Min; i.e., a minimal warning scenario for a hazard occurrence at the Levee Control Location during a Top of
+Levee hydraulic loading) shows the selected data inputs required to simulate traffic and calculate life loss for the LCL TOL hydraulic scenario as
+well as the entries for the relative hazard identification time and hazard communication delay. The relative hazard identification time should be
+reflective of the community’s ability to monitor the project, how early the event could be forecasted in advance, and the type of failure mode. For
+example, if the emergency managers would have little time to identify a rapidly developing breach, the relative hazard identification time would be
+close to the time the hazard occurs. The example alternative (LCL_TOL_Min) is representative of a situation in which the breach occurs relatively
+quickly. You can create multiple alternatives for each hydraulic scenario with various warning times if there is uncertainty surrounding the relative
+hazard identification time. This provides a range of possible life loss outcomes.
+
+Additionally, determining the hazard communication delay depends on how quickly the hazard would be communicated from the project personnel to local
+emergency managers. A smaller delay (or no delay) would occur if the local emergency managers were onsite with other project personnel while the
+situation develops. A longer delay would occur if the local emergency managers were unaware of the hazard, there are power and electricity outages,
+and there are no redundant technologies available to maintain communication with project personnel. The project’s emergency action plan provides
+insight regarding the potential hazard communication delay. The hazard communication delay in the example alternative represents a situation in which
+the project personnel are able to contact the local emergency managers relatively quickly, but there is still a slight delay.
+
+
+
+## Creating Simulations
+
+Once you have created alternatives, you need to simulate the alternatives to compute life loss and economic damages results. To create a simulation,
+navigate to the Study Pane, scroll to the bottom, right click on Simulations, and select Create New Simulation.
+
+
+
+The Create New Simulation window will open. From this window, you can simulate at various hazard occurrence times of day to account for interpolating
+population estimates within structures. Additionally, you can specify the number of iterations, select summary polygons for result aggregation, and
+select which alternatives to run.
+
+Below is an example of a simulation for breach location 2 (BL2) alternatives, including a daytime (2pm) and a nighttime (2am) hazard occurrence, that
+simulates each hazard occurrence time with 1,000 iterations. LifeSim simulates the alternatives assuming the hazard occurrence time is at 2am and then
+ again assuming the hazard occurrence time is at 2pm. These times are generally selected because there is no interpolation of daytime and nighttime
+population at these times in the model. If other times are selected, LifeSim will interpolate between the daytime and nighttime population values
+included in the structure inventory.
+
+In the example, only one summary polygon is included, which is the EPZ shapefile. You can include multiple summary polygons if you want to see results
+ by county, city, census tract, arrival time, depth, etc. You can include any shapefile as a summary polygon, but the Summary Name Field must include
+a unique name for each attribute.
+
+
+
+Within the Create New Simulation window, there are an array of options that the user can customize for each simulation. Click on
+Options (located in the top left corner) and select Computation Engine Options.
+
+
+
+The Computation Engine Options window opens, and you can customize (1) the number of threads for the simulation (the higher the number of threads, the
+ faster the simulation runs), (2) whether the simulation generates structure summary results, (3) whether the simulation generates road summary
+results, and (4) whether you want to enforce vehicular spillback. More information about the appropriate times to uncheck these boxes is discussed in
+the LifeSim 2.0 User Manual (See the Simulation – Computation Engine Options section).
+
+
+
+Click Save in the Computation Engine Options window after you make changes. Press OK in the Create New Simulation
+window after selecting the hazard occurrence times, entering the number of iterations, selecting a summary polygon, and checking the alternatives to
+be included in the simulation. The simulation you created is now located under Simulations in the study pane. Right click on the new simulation’s name
+ and select Run Simulation.
+
+
+
+## Understanding and Interpreting Results
+
+After running simulations, you can view your results by result plots, result tables, and result maps. Each way to view results is uniquely beneficial
+in (1) understanding your life loss and economic damage estimates and (2) quality checking your results. It is unlikely that your first simulation
+will be your last simulation—edits to the structure inventory, EPZs, road network and/or destination points may be needed to obtain accurate and
+representative results.
+
+### Result Plots
+
+The first way to view results is by result plots. Right click on the already run simulation and select View Results Plots. The
+Simulation Results Plots window opens. The first tab of the window display is the Box and Whisker – Time of Day. The user can toggle which alternative
+ results are displayed in the whisker plot and what data is shown in the plot (Plot Summary Data By dropdown in the bottom right corner). You can also
+ view results across various summary polygons or summary zones.
+
+This tab is helpful in seeing if the results fall within the expected order of life loss magnitude. As an example (from the figure below), the BL2 TOL
+ breach scenario should result in more life loss than the BL2 75% breach due to the higher water surface elevation and because they use the same data
+inputs and warning time. If the BL2 75% breach resulted in more life loss than the BL2 TOL breach, the alternatives may include the wrong hydraulic
+scenarios, or the user would need to confer with the hydraulic engineer about the issue. Additionally, this tab helps the user understand if life loss
+ is likely to be higher at various times of day (e.g., daytime versus nighttime life loss).
+
+
+
+The next tab is the Box and Whisker – Alternatives. This tab is similar to the Box and Whisker – Time of Day plot in terms of the data displayed, but
+the data is displayed differently. The key difference between the two tabs is you can toggle which Time of Day results are displayed in the Box and
+Whisker – Alternatives tab. You can view just the 02:00 or 14:00 results. In the example below, only the 14:00 results are shown.
+
+
+
+Another key result to analyze and review is the Life Loss on Roads, which is shown in the figure below. Overall, there is little estimated life loss
+on roads within the BL2 results. If the life loss on roads makes up most of the total life loss, the user should review the road network and
+destinations to ensure the simulated evacuations are logical, that there is not high life loss on particular road segments, and that all the road
+segments are connected properly. For example, ensure most of the life loss on roads is not incorrectly occurring on a single bridge that should have a
+ vertical offset.,
+
+
+
+#### Generating and Viewing Detailed Output in Results Plots
+
+The best ways to identify whether there are issues with the evacuation data are to (1) animate the simulated evacuation and observe if there are
+traffic issues of any kind and (2) understand which destinations were utilized the most by evacuees and ensure the most used destinations make sense
+given the study area. To view both the evacuation animation and the cumulation destination arrivals, you’ll need to generate detailed output. To get
+this output, go to the Iterations tab from the Results Plot window, left click on the iteration that you want more detailed information for, such as
+animating evacuation, and click Generate Detailed Output in the bottom right corner.
+
+As you can see in the example below, I selected an iteration that has the highest life loss on roads to better understand potential evacuation issues.
+ If there are several iterations with high life loss on roads, it may be best to select an iteration that is representative of the average life loss
+on roads. Sometimes high life loss on roads in some iterations is solely due to a timing issue rather than a traffic issue; the highest life loss on
+roads results may occur when there is little warning and many people are on the road minutes prior of the floodwaters arriving.
+
+
+
+Within the Results Plots window, go to the Detailed Output Results to see additional information specific to the iteration you generated detailed
+output for. Within this tab, there are three sub-tabs (Time Evacuating Histogram, Cumulative Evacuation Outflow, and Cumulative Destination Arrivals).
+ Each iteration you create detailed output for is included as an option for viewing on the left side of the tab. The first sub-tab you can view is the
+ Time Evacuating Histogram, which shows you how long it takes for people to evacuate safely to a destination point. This histogram can be very
+informative, especially if you think traffic would be an issue in your study area. For example, if the study area is very populated and everyone
+evacuates within 5 minutes, this may indicate that your destination points should be placed farther away from the EPZ to allow more realistic traffic
+conditions to occur in the model.
+
+
+
+The second sub-tab is the Cumulative Evacuation Outflow, which shows the relationship between the number of evacuees and the duration of the
+evacuation and compares the number of mobilized individuals to the number of people who reach safety. This provides additional information on how long
+ it generally takes the Population at Risk (PAR) to initiate protective action and when the hazard begins to disrupt evacuation.
+
+
+
+The third and final sub-tab is the Cumulative Destination Arrivals. This shows how many vehicles traveled to each destination point. This plot can be
+very useful when conducting a quality control review of the evacuation results and life loss on roads. As you can see in the example plot below, the
+113-S destination point was overwhelmingly utilized compared to the other destination points. To understand if the destination arrivals are logical,
+you need to understand your study area. Depending on the project, the terrain of the area, the location of the hazard, and the availability of egress
+routes dictates if there are viable destination points in all directions. In many situations, only a couple of directions are likely to offer
+favorable destination points. For Cache Creek Levee, the inundation extents cut off egress routes to the north, east, and west. Therefore, most of the
+ vehicles were expected to evacuate to the south, which is exactly what is shown in the plot.
+
+
+
+#### Animating Evacuation
+
+The other key data available following generating detailed output is Evacuation Animation. To view the animation, right click on the already run
+simulation, select View Results Maps, and the Result Map Selector window opens. Scroll to the alternative that you generated detailed
+ output for, check the box that includes “Evacuation Animation” in the title, and select the corresponding hydraulic scenario (02:00 BL2 TOL scenario
+in this example). Then click Send Selected To Map Window.
+
+
+
+You can then view the evacuation for this specific iteration. You can play and pause the animation by utilizing the button in the middle. You can make
+ the animation speed up or slow down by using the Slower to Faster scroller bar; you can also manually speed up and slow down the animation by using
+the top scroller bar. The animation shows when structures are warned (yellow structures by default), when structures are inundated (red structures),
+when vehicles evacuate (blue cars), and when vehicles are caught (red cars). This is a useful tool for understanding if your road network and
+destinations are set up appropriately. When animating evacuation, you can zoom into specific areas to see if there is significant traffic or
+significant life loss on roads and confirm if the life loss results are valid or if there are potential issues with the road network. Examples of
+potential issues are disconnected road segments, road segments that may be too long and are showing vehicles as caught that are not actually
+inundated, and vertical offsets that have not been appropriately added.
+
+
+
+### Result Maps
+
+Another way to view if life loss on roads appears reasonable is to view various Roads Summary maps. These layers are accessible in the Result Maps
+Selector.
+
+
+
+Select the alternative results you want to add to the map window, adjust the value bins and corresponding symbols as needed (these can also be
+adjusted later in the Map Layer pane) and click Send Selected to Map Window. The Roads Summary polyline shapefile should now be in
+the Map Layers pane. You can see in the map window if there are roads with high average life loss. Additionally, it’s helpful to look through Roads
+Summary attribute table (right click on the shapefile; click Open Attribute Table).
+
+
+
+Within the Roads Summary Attribute table, scroll to the right and find the field titled Life_Loss_Mean. Double click on this field name to sort from
+the lowest life loss to the highest life loss; double click on the field name again to sort from the highest life loss to the lowest life loss (you
+can also right click on the field’s header and select ascending or descending). As shown in the example below, life loss occurs on only five road
+segments for Cache Creek Levee. If the mean life loss for one of these segments was high relative to the total mean life loss, this would indicate
+that there may be a road network connectivity issue or an unwanted traffic build-up. You would then look at the evacuation animation again, focusing
+on those high life loss road segments to identify the potential issue.
+
+
+
+In addition to performing a quality check on the life loss on roads and evacuation data inputs, you should always review the life loss in structures
+results. Common issues or errors that can be caught when looking through the results is (1) a high amount of population within structures that should
+have a relatively small population (e.g., a RES1 structure containing a total population of 25), (2) the structure stability was not linked to the
+correct structure types (e.g., a RES2 structure having an engineered structure stability assignment), (3) a field was not linked properly when importing
+ a structure inventory (e.g., absence of values assigned to vehicles, resulting in all values being populated as $0), or (4) structure points are not
+ placed accurately.
+
+An efficient way of reviewing the life loss in structures results is to look through various results maps. To add these layers to the map window,
+right click on the already run simulation, and select View Results Maps. The Result Map Selector window opens. Select the structure
+summaries from the scenarios you want to add to the Map Layers pane and click Send Selected to Map Window. To conduct a full quality
+check on the structures, add structure summaries for all times of day. If you only analyze the daytime Structure Summary (14:00), you could miss any
+errors occurring with the nighttime population (02:00).
+
+
+
+Once the Structure Summary shapefile(s) have been added to the Map Layers pane, right click on the shapefile, and select Open Attribute
+Table.
+
+
+
+Similar to viewing the Road Summary results, scroll to the Life_Loss_Total_Mean field. Double click on the field name to sort from the lowest to the
+highest life loss; double click on the field name again to sort from the highest to the lowest life loss. Then, confirm that the life loss results
+align with the structure type and that the structure point placement for the structures with relatively high average life loss is accurate.
+
+
+
+Begin confirming the placement of structure points by selecting the first structure while the life loss is sorted from highest to lowest. Right click
+on the row number (3569 in the example below) and select Zoom to Selected.
+
+
+
+LifeSim then zooms to the selected structure, and you can confirm the point placement of the structure with the highest life loss. For Cache Creek
+Levee, the highest life loss occurs in a commercial building as shown in the figure below. The structure placement is in the middle of the building
+footprint, which confirms that the life loss estimate for this structure is valid in terms of its location. This process should be repeated as often
+as necessary to confirm that the life loss estimates in structures are reasonable for the various hydraulic scenarios.
+
+
+
+### Result Tables
+
+The final way to view results is by table. This is most helpful to clearly see results for various alternatives at once and is the easiest way to export
+ results for report writing. To see the results table, right click on the already run simulation and select View Results Table. The
+Results Table window opens.
+
+
+
+There are four tabs that each show results in a different way. The first tab shows average results for each alternative and each time of day that was
+included in the simulation. This table is most useful when reporting out PAR estimates, the number of structures inundated, average structure depth,
+average mobilization rates, and average life loss.
+
+The Iteration Results table shows you the life loss and economic results for each specific iteration of each alternative and time of day. You can also
+ generate detailed output from this tab by right clicking on the row you want to obtain detailed output for and clicking Generate Detailed
+Output.
+
+
+
+The EPZ Results table shows iteration results as well but highlights the parameter sampling results (in hours) in addition to the total life loss
+results. As you scroll through this table, you can see the sampled relative warning issuance time, sampled hazard communication delay, sampled warning
+ issuance delay, sampled warning curve, and sampled mobilization curve for each iteration. This provides insight into which parameters drive life
+loss.
+
+
+
+Finally, the Detailed Output Results table shows detailed output results by evacuation group for specific iterations. This table details if a group
+received warning, if they mobilized, if they mobilized safely, how quickly they mobilized, which life loss probability zone (low hazard or high
+hazard) was used for sampling, what kind of vehicle was used during evacuation, and the various stability thresholds. This provides significant detail
+ surrounding evacuation and the life loss probability zones, which allows the user to understand why life loss occurred (or why there is little life
+loss) for that specific iteration.
+
+
+
+You can export any of the four tabulated tables into various formats by clicking on the Export Table button (see below). After
+clicking on this button, name the file and select the file format. Then click Save.
+
+
+
+
+
+Following any edits made during the quality control check, you need to rerun all simulations. Once you confirm the new life loss and
+economic results, your levee/floodwall LifeSim model is complete.
+
+ (Page is intentionally left blank)
+
+
\ No newline at end of file
diff --git a/docs/desktop-applications/lifesim/applications-guide/v1.0/05-estimating-consequences-for-dams.mdx b/docs/desktop-applications/lifesim/applications-guide/v1.0/05-estimating-consequences-for-dams.mdx
new file mode 100644
index 000000000..cb601d33e
--- /dev/null
+++ b/docs/desktop-applications/lifesim/applications-guide/v1.0/05-estimating-consequences-for-dams.mdx
@@ -0,0 +1,1061 @@
+---
+title: "Estimating Consequences for Dams"
+---
+
+import Link from "@docusaurus/Link";
+import addBaseUrl from "@docusaurus/useBaseUrl";
+import CitationFootnote from "@site/src/components/CitationFootnote";
+import Figure from "@site/src/components/Figure";
+import FigReference from "@site/src/components/FigureReference";
+import NavContainer from "@site/src/components/NavContainer";
+import TableVertical from "@site/src/components/TableVertical";
+import VersionSelector from "@site/src/components/VersionSelector";
+
+
+
+# Estimating Consequences for Dams
+
+## Purpose
+
+This example demonstrates the process for estimating consequences for dam breaches in LifeSim. This chapter focuses on Curwensville Dam located in
+Clearfield County, PA. This was originally modeled by the Modeling, Mapping and Consequences (MMC) Production Center of Expertise of the U.S. Army
+Corps of Engineers (USACE) in 2022. This chapter walks through developing and importing the needed data and how to choose appropriate warning and
+evacuation data for a LifeSim study.
+
+## Data Requirements
+
+To take full advantage of LifeSim capabilities, an unsteady Hydrologic Engineering Center’s River Analysis System (HEC-RAS) dam breach model with a
+range of breach and corresponding non-breach events is required. Non-breach events are needed to identify any areas flooded prior to the breach, which
+ allows you to understand incremental life loss and incremental risk of the dam. Alternatively, the inundation footprint from a breach model time step
+ just before the breach occurs can be used to identify areas flooded prior to the breach, but for this example the non-breach inundation footprint is
+used to identify pre-breach flooding. This example also assumes that both maximum depth grids and inundation boundary polygons for each event have
+been created in the HEC-RAS model directory using RAS Mapper.
+
+The hydraulic events used in the example are shown in the table below.
+
+
+
+LifeSim requires a structure inventory that includes the following characteristics at a minimum, (1) a structure occupancy type, (2) a construction
+type, (3) the number of stories, and (4) the population within the structure. This example uses the USACE National Structure Inventory (NSI) as the
+base dataset for the structure inventory.
+
+## Input Data and Pre-Processing
+
+### Study Area Polygon
+
+The first step in modeling a dam breach in LifeSim is to identify a study area polygon that can be used as a basis for emergency planning zones (EPZ),
+ the structure inventory boundary, and output polygons. There are several ways to do this, but the most common methods include buffering the maximum
+inundation, manually drawing a polygon boundary in GIS software (e.g., ArcGIS Pro or QGIS), or exporting a Geometry Bounding Polygon from RAS Mapper
+within HEC-RAS. The RAS Mapper geometry polygon method does not always produce an acceptable study area when there are complex geometries. When using
+this method, the output must be checked for areas where inundation is not covered and for gaps within the polygon requiring vertex edits. This example
+ uses a method of buffering and then simplifying the maximum inundation polygon in ArcGIS Pro.
+
+Create a map in ArcGIS Pro and use the Add Data button to add the inundation polygon of the maximum breach event. In the
+Geoprocessing tools pane, navigate to Analysis Tools > Pairwise Overlay > Pairwise Buffer. Select the maximum inundation polygon as the Input Features
+ and designate an output shapefile name (it is not recommended to save into the default geodatabase location). The buffer will be set at 1,500 feet.
+This allows for (1) a reasonable number of structure points outside the inundation for use in calibration of the inventory and (2) the case that a
+larger breach event might be added in the future. The Dissolve Type is set to “Dissolve all output features into a single feature”. Reference the
+ArcGIS Pro technical documents for additional information on tool inputs. The tool setup is shown in .
+
+Once the dissolve is complete, the Simplify Polygon tool is used to reduce the complexity and file size of the buffered polygon for a final study
+area, which allows follow-on GIS processes and the LifeSim modeling to run more efficiently. The tool is found by navigating to Cartography Tools >
+Generalization in the default Geoprocessing toolboxes. The output of this tool should be your final study area polygon. The simplification tolerance
+determines how far the new simplified line can move. A larger number will make a simpler polygon. Make sure this number is less than the original
+buffer distance. The inundation boundary can be used as an Input Barrier to ensure than the study area is larger than the inundation. The tool setup
+is shown in .
+
+
+
+Once the simplify polygon tool has been run, the study area is visually checked to look for areas that need to be cleaned up. Several spots had open
+areas near the center of the polygon. Those vertices were removed using the Edit ribbon and the Edit Vertices tool. Vertices can be selected and
+deleted by right clicking on the selected group and using the option to delete the selected vertices. This is shown in
+{"\n"}. There were also several disconnected polygons caused by very small spots of disconnected inundation which
+were deleted from the final study area. The edits were saved. shows some of the vertices that were removed.
+
+
+
+Alternative Methods to Get a Study Area:
+
+Create a new shapefile and draw a polygon around the maximum inundation. This can be accomplished in the LifeSim map viewer or in ArcGIS, QGIS, or
+another GIS software.
+
+Export the Geometry Bounding Polygon from HEC-RAS/RAS-Mapper. Check and edit the polygon for completeness).
+
+### Emergency Planning Zones
+
+EPZs are polygons that allow LifeSim to have different warning and mobilization parameters for different geographic areas and/or for areas that
+experience different flooding characteristics (e.g., breach flows and non-breach flows). Depending on the study’s purpose and level of detail there
+could be different parameters for different communities or counties. For this example, we will focus our geographic areas on the flood characteristics
+ only and assume that parameters influenced by emergency response capability and demographic characteristics can be captured by using the default
+“unknown” curves in LifeSim. Reference the for additional information regarding the software’s default parameters.
+
+In a standard dam breach scenario where no detailed information about the communities is known, there are three primary areas that may have different
+warning and mobilization characteristics: (1) the area upstream of the dam (or the reservoir), (2) the area that experiences flooding downstream of
+the dam prior to (or regardless of) a breach, and (3) the area that is only flooded in the event of a breach. People living near the pool of a
+reservoir would typically be more aware of the flood risk than areas downstream and would have more time to mobilize as the reservoir rises, so their
+perception of risk is higher. Downstream areas subject to flooding prior to a breach (i.e., spillway flow or non-breach flows from dam releases) may
+not necessarily have a higher risk perception, but they would receive flood warnings relative to when spillway flow begins. The non-breach flows rate
+of rise would also be more gradual than a breach, meaning they would have more warning time and a higher likelihood of mobilization than areas only
+flooded in the event of a breach.
+
+To simulate this effect in LifeSim, each unique event with different levels of spillway flow needs a unique EPZ polygon because the areas flooded
+prior to a breach are different—this is why you need corresponding non-breach events for each of your breach events. If an event has no flooding prior
+ to the breach, the EPZ only needs two areas: (1) the area upstream in the reservoir and (2) the area downstream. However, this requires the hydraulic
+ modeling and structure inventory to be adequately calibrated so that no structures are flooded in the corresponding non-breach event (e.g., For the
+Top of Active Storage breach scenario to only have two zones, there should be zero inundated damages during the Top of Active Storage non-breach
+scenario. Otherwise, the EPZ would need to include the 3 zones identified above.).
+
+The first step in creating the two zone EPZ is to make a copy of the Study Area and call it “EPZ_NoDoubleWarning”. This is done by right clicking on
+the layer name, selecting Data menu near the bottom, and clicking on Export Features. Save the file in a folder, not
+ in the default geodatabase. The resulting polygon can be split at the dam to create an “In Pool” polygon feature and a “Downstream” polygon feature.
+On the Edit ribbon, click on the Split tool, select the polygon, and make a split across the polygon at the dam. Save the edits.
+
+
+
+A name field is added so that each polygon can be named appropriately. Right click on the layer name to open the Attribute Table, then select
+Add Field to bring up the Add Field dialog. Set the field name to Name and the Data Type to Text. When finished, hit the
+Save button in the upper right on the Fields ribbon.
+
+
+
+Next, type in the names of each EPZ.
+
+
+
+This results in an EPZ that can be used for any events without flooding prior to a breach (in this example, these events are Top of Active Storage
+Pool, Security Scenario Pool, and Normal High Pool).
+
+To make the EPZ shapefiles for the events with flooding prior to breach, the non-breach polygons must be joined with the “EPZ_NoDoubleWarning” file
+using the Union tool (not the Merge tool, as that will create overlapping polygons in the process). First, make sure the selections are cleared out.
+Navigate to the Union tool in the Geoprocessing toolbox in Analysis Tools > Overlay > Union. Select the “EPZ_NoDoubleWarning” file and the Inundation
+Boundary shapefile of the Maximum High Pool Non-Breach scenario as inputs, and name the output feature “EPZ_MHP_DoubleWarning.shp” (again, do not save
+ in the geodatabase).
+
+
+
+Once the EPZ has been created, it needs to be modified by merging some areas together and ensuring the EPZ names are correct. Open the attribute table
+ and zoom the map close to the dam where all three areas come together. Select Polygons to identify which one should be the
+Non-Breach EPZ and change the name (“NonBreachEPZ” in the figure below).
+
+
+
+The rest of the Downstream area can be changed to the Breach EPZ (“BreachEPZ” in the figure below). Next, the two “InPoolEPZs” can be merged together
+to make a single in-pool polygon (“InPoolEPZ” in the figure below). Hold control to select both and find the Merge tool in the Edit ribbon.
+
+
+
+This will leave a single unnamed feature. Right clicking on that feature and selecting Zoom To will identify this feature as two
+small, disconnected inundation areas. If needed they could be merged as part of the appropriate breach or non-breach area, but in this example, they
+appear to be unrelated to the breach modeling so they can be completely deleted by selecting that row and hitting the Delete button
+near the top middle of the Edit ribbon (or by right clicking the row and selecting delete). Once the edits are saved, this should complete the MHP
+Double Warning EPZ. The same steps, starting with the Union, must be repeated with the Intermediate High Pool (IHP) non-breach area using
+“EPZ_IHP_DoubleWarning” as the Union output file name.
+
+### Simulation Output Polygons
+
+LifeSim has the capability to output results aggregated to multiple polygon shapefiles. At a minimum the EPZ polygons can be selected as output
+polygons, but for comprehensive understanding and reporting of the results additional polygons are needed. For this example, a polygon will be created
+ that has the downstream area broken out by milage zones relative to the dam. The zones are 0 to 3 miles, 3 to 7 miles, 7 to 15 miles, 15 to 60 miles,
+ and over 60 miles. A separate polygon shapefile will be created by selecting and exporting city boundary polygons that are significantly impacted by
+the inundation.
+
+To make the milage reach polygon, start by exporting the “EPZ_NoDoubleWarning” layer as a new shapefile by right clicking on it in the Layers Pane and
+ navigating to Data > Export Features. Save to a folder and name it “Milage_Reaches.shp”. Next, identify a point along the river three miles
+downstream of the dam. This can be done by looking at cross section stations from the RAS geometry, creating points along a river centerline every
+mile, or simply by using the measure a path tool in ArcGIS Pro or Google Earth. For this example, the cross sections were exported from RAS Mapper and
+ included in a Geometry folder in the RAS model data. These are added to the ArcGIS Pro map and labeled with the “River Stat” field. Since the dam is
+at river station 185.7, the downstream polygon needs to be split close to 182.7 (3 miles), 178.7 (7 miles), 170.7 (15 miles) and 125.7 (60 miles).
+There are no cross sections with these exact river station values, but they are close enough to visually estimate a location to split the polygon. The
+ cross sections also provide a guide for splitting the polygons perpendicular to the river inundation. To split the polygon, use the
+Split tool in the Edit ribbon, select the polygon, and draw the split between stations 182.63 and 182.79 to delineate the first reach
+ three miles downstream of the dam.
+
+
+
+Repeat the split at the remaining river stations, then save the edits. Right click on the layer and open the attribute table to assign the correct
+names. A first and important step in naming is to rename the “InPoolEPZ” polygon to just say “InPool”. This will become important later in the study,
+because if both the Milage Reaches and the EPZ shapefiles are used as output polygons, having two areas with the same name could cause double counting
+ of results if Excel pivot tables are used to analyze results. Select each row to identify what the name should be. Do not use only numbers and dashes
+ because most spreadsheets will attempt to convert “3-7” into a date format. Save the edits when complete.
+
+
+
+The second results output polygon set is a city boundary polygon. A comprehensive set of U.S. city boundaries, or Places as they are called on the
+Census.gov website, can be obtained by navigating to the link below and finding the Places 1:500,000 (national) shapefile a little more than halfway
+down the page.
+
+
+
+Once the file is downloaded and unzipped, load it into the ArcGIS Pro map using the Add Data button. Use the Select by Location tool
+in the Map ribbon to select the cities that intersect with the maximum inundation polygon (the MHP Breach in this example). You could intersect it
+with the study area, but since that was buffered, it could result in some cities that would have no consequences.
+
+
+
+Once the selection is complete, right click on the city layer and navigate to Data > Export Features to export the selected features into a new
+shapefile called “City_Boundaries.shp”. This results in 79 individual cities, which is more than we want in our simulation outputs since many of them
+do not have significant impacts and sorting through that many rows of results creates difficulties in interpreting results. Smaller cities farther
+downstream can be removed, as well as cities that are barely touched by the inundation, by selecting individual polygons and using the Delete button
+in the Edit ribbon. Another method of removing cities is to run a test simulation in LifeSim, view the results table, and identify any cities that do
+not have any life loss. The latter was done for this example and based on those results and user judgement the following nine cities were retained for
+ the city boundary results output polygon:
+
+Clearfield, PA
+
+Curwensville, PA
+
+Hyde, PA
+
+Jersey Shore, PA
+
+Lock Haven, PA
+
+Milton, PA
+
+Muncy, PA
+
+Plymptonville, PA
+
+South Renevo, PA
+
+### Structure Inventory
+
+The Curwensville Dam structure inventory is developed using the USACE NSI dataset. Reference the for additional information on the NSI and/or importing
+ structure inventories into LifeSim.
+
+## LifeSim Model Setup
+
+The subsequent sections will discuss setting up a LifeSim model by importing data and setting EPZ parameters and alternatives. The sections will cover
+ hydraulic data import, EPZs, structure inventories, creating alternatives, and simulating alternatives.
+
+### Hydraulic Data
+
+For estimating life safety consequences, LifeSim requires depths, velocities, and arrival times from unsteady hydraulic modeling. The most common
+method of delivering this information into the LifeSim model is through HEC-RAS Hierarchical Data Format (HDF) plan files (Note: Only HEC-RAS versions
+ 5+ produce the HDF files required by LifeSim). For each hydraulic scenario, the user will need the plan file from HEC-RAS and the terrain files (both
+ the HDF and the associated Tagged Image Format (TIF) files) so that LifeSim can calculate depths and arrival times.
+
+Prior to importing data, create a new study by specifying a name and location to save to study data. To import the hydraulic data from HEC-RAS, right
+click on Hydraulic Data in the study pane, and select Import from HEC-RAS.
+
+
+
+From the Import from HEC-RAS window, map to the project’s HEC-RAS Plan(s) Directory by clicking on the button with the three dots. The file directory
+selected should contain plan HDF files from HEC-RAS (e.g., PA00003_Curwensvill.p01.hdf). Select the specific HEC-RAS plan you want to import by using
+the dropdown next to HEC-RAS Plan. Once selected, the Name of the hydraulic scenario will automatically populate, but the user is able to alter the
+Name. If the terrain is inside the HEC-RAS directory Terrain folder it usually auto populates the terrain. If not, map to the project’s HEC-RAS
+Terrain File (HDF) by clicking on the button with three dots. Once you have the hydraulic data mapped and selected in the Import from HEC-RAS window,
+you can either select Import from RAS or Import from Map.
+
+
+
+To specify the timing of the hazard being evaluated, in this case dam breach, the user can either import a hydrograph from a specific cross section or
+ a storage area using the Import from RAS option or select a point on the map to generate a hydrograph using the Import from Map option. This example
+uses the Import from Map option for simplicity. Refer to the for guidance on utilizing the Import from RAS option.
+
+When you select Import from Map, the RAS Map Data Selector window will open.
+
+
+
+To view a hydrograph along with its hydraulic timing and depths, use the Select Hydrograph Tool in the toolbar (shown below).
+
+
+
+The RAS Map Data Selector map window will automatically display the 2D areas used in the RAS modeling, the cross sections, the hydraulic animation,
+and a base map. The user can change the base map and add data to the map window (e.g., breach locations shapefile, leveed area shapefile, structure
+inventory, etc.) by clicking on the Add Data button (see below).
+
+
+
+Zoom into the area just downstream of the dam and move the animation slider bar to get a clear picture of the inundation. Use the Select
+Hydrograph Tool and click in the center channel of the inundation just below the dam to get a hydrograph.
+
+
+
+Once a representative hydrograph for the hydraulic scenario is loaded, click OK and you will return to the Import from HEC-RAS
+window. The window will now display hydraulic timing information as well as the same representative hydrograph. The Hazard Occurrence date and time
+should match the time that breach or overtopping (if applicable) begins within the study area. This information can be found in HEC-RAS or the
+hydraulic engineer will provide this information. For the Curwensville MH Breach, the breach initiation time is 2/3/2099 at 23:00. The red line is the
+ hazard occurrence time, and the first 31 feet of depth represents spillway flow. The hydrograph then increases steeply after the breach. Press
+OK and the hydraulic scenario will be processed and imported into LifeSim.
+
+
+
+The user will repeat this process for each of the study’s hydraulic scenarios. For non-breach scenarios, it is recommended to use the same imminent
+hazard time used for the corresponding breach scenario. LifeSim interpolates population between the 2am and 2pm time values. Therefore, using
+different imminent hazard times for breach and non-breach can cause inconsistencies when calculating incremental consequences by subtracting
+non-breach results from breach results.
+
+### Importing a Structure Inventory
+
+To import a structure inventory from an existing point shapefile, the user will navigate to the Study pane in their model, right click on
+Structure Inventories, and select Import Structures from Shapefile.
+
+
+
+The user will then be able to either select the Structure Inventory Shapefile from the dropdown, which is available if the shapefile is in the Map
+Layers pane of the LifeSim model, or navigate to the shapefile by clicking on the button with the three dots next to the dropdown. Once you match up
+your shapefile’s attributes (Import Attributes) with the corresponding LifeSim Required Attributes (an example of matched up attributes using the NSI
+is shown in the figure below), click Next at the bottom right.
+
+
+
+You will then need to match the occupancy types in LifeSim with the occupancy types included in your structure inventory shapefile. If using NSI 2019
+or NSI 2022, the occupancy types will typically exactly match the occupancy type names in LifeSim, but the user should scan through the list to ensure
+ everything is matched up correctly. If these are mismatched, the depth-damage functions, evacuation parameters, and submergence criteria will not be
+correct for that structure, which would impact the accuracy of your economic damages and life loss. If an occupancy type is missing, the user can add
+occupancy types or edit the existing occupancy types, which is discussed in the next subsection.
+
+
+
+After the occupancy types are assigned and reviewed, click Next. The final step for importing the inventory is the Stability Criteria
+ Assignment. LifeSim has default stability criteria assignments for wood unanchored structures (e.g., mobile homes), wood anchored structures, masonry
+ structures, and steel structures. For NSI users, you should use the default stability criteria.
+
+
+
+Reference the for creating new structure criteria rules. Once all structures have been assigned a stability criterion, click Finish.
+ The inventory will then be imported into LifeSim.
+
+### Emergency Planning Zones
+
+The three EPZ shapefiles created in ArcGIS are each imported to the EPZ section of LifeSim. Within a set of EPZs, each zone must be assigned a curve
+for Warning Issuance Delay, First Alert Diffusion during daytime and nighttime, and Protective Action Initiation (commonly called mobilization).
+
+
+
+When conducting a detailed consequence analysis in LifeSim, the analyst would work with local emergency managers and other subject matter experts to
+determine the most appropriate curves to select for the entire study area or for specific areas with the study area. However, LifeSim contains generic
+ “unknown” curves that represent a maximum amount of uncertainty (relative to the other preset curves) regarding EPZ parameters. The unknown warning
+diffusion and PAI curves are uniform distributions, so given enough iterations the range of results should provide reasonable upper and lower bounds
+of life loss. These unknown parameters are used for most MMC level LifeSim models and are used in this example. Reference the and
+for more information on how to develop Warning and Protective Action parameters for your specific impact areas.
+
+To import an EPZ, right click on Emergency Planning Zones and select Import EPZs From Shapefile.
+
+
+
+In the Import Emergency Planning Zones window, use the three dots on the upper right to browse to the “EPZ_MHP_DoubleWarning.shp” shapefile that was
+created in the prior GIS section. Once selected, fill in the name field with the same name as the shapefile, and in the Emergency Planning Zone Name
+Field dropdown menu select the field “Name” which was added to the shapefile in the GIS section. Before proceeding, confirm that there are now three
+emergency planning zones named BreachEPZ, InPoolEPZ, and NonBreachEPZ.
+
+
+
+Each of the three EPZs are now assigned a Warning Issuance Delay curve, a First Alert Curve, and a PAI curve. Each area will have the same assigned
+curves for each uncertainty parameter.
+
+There is a check box for Simulate Traffic (If Applicable). The “if applicable” statement is here because there is also a checkbox in the Alternative
+window to either simulate traffic or not simulate traffic for each alternative. Regardless of whether this box in the EPZ editor is checked, the
+primary option for simulating evacuation is the one in the Alternative window.
+
+However, if the Alternative specifies that traffic will be simulated, then the checkbox in the EPZ editor becomes applicable and allows the user to
+select specific EPZs in which traffic will be simulated. Traffic can either be simulated in all EPZs or only in certain selected EPZs. For example, in
+ a dam breach with a very long inundation area traffic might only be a concern in areas close to the dam or in a few large cities. EPZ polygons could
+be created specifically for those areas so that the model runs efficiently while still simulating traffic in high-risk areas. Since this is meant to
+be a more base-level analysis, the Alternatives will specify that traffic will not be simulated, so the check box in the EPZ editor is not applicable
+and can be left checked.
+
+#### Warning Issuance Delay
+
+The Warning Issuance Delay is the time it takes from when the emergency managers receive the notification of the imminent hazard to when they issue
+the first evacuation order to the public. The preset “Preparedness Unknown” warning issuance delay curve is used in this analysis. Although the range
+of possible warning issuance delay possibilities is between 0 minutes and 360 minutes, the most likely outcome is warning issuance 30 minutes after
+officials are notified of the flood hazard.
+
+
+
+#### First Alert Diffusion
+
+The preset “Preparedness Unknown” warning diffusion curves were used in this analysis. The curves utilize a uniform distribution, and the warning
+diffusion curves are sampled during each Monte Carlo iteration in LifeSim. The upper bound of the curve reaches 100% diffusion after 100 minutes, and
+the lower bound reaches 100% diffusion after 360 minutes. Note that there is a different diffusion curve for daytime and nighttime.
+
+
+
+
+
+#### Protective Action Initiation
+
+Protective Action Initiation (PAI) is the rate at which PAR takes action after receiving an evacuation order (warning). Unlike the warning diffusion
+curves, the PAI “Preparedness Unknown” curve includes a perception element as well. The perception element describes the PAR as being aware of flood
+risk (Perception = High) or generally unaware that they are at risk of being flooded (Perception = Low). The “Preparedness Unknown, Perception
+Unknown” curve was used in this analysis for all areas.
+
+
+
+Switch the Emergency Planning Zone dropdown to the NonBreachEPZ and make the same selections that were made for the BreachEPZ; repeat for the
+InPoolEPZ, then click OK to close the EPZ editor window. Repeat the Import EPZs from Shapefile process with the
+“EPZ_IHP_DoubleWarning” shapefile and the “EPZ_NoDoubleWarning” shapefile using the same uncertainty parameters for each area in each EPZ.
+
+### Creating Alternatives in LifeSim
+
+Below the EPZ section of the LifeSim study tree are Road Networks, Destinations, Agricultural Data, and ECAM Data. These sections will be skipped for
+this example of a base level study, as they are not utilized on most USACE projects that follow the MMC Standard Operating Procedure (SOP). Therefore,
+ the next step will be to create alternatives.
+
+For this study, each breach event will have two alternatives representing different warning ranges. These ranges are referred to as minimal warning
+and ample warning and they allow the results to be applied to different potential breach scenarios that may have different opportunity ranges for
+observation, development, and warning in relation to the breach initiation. The non-breach events will only have one alternative because only the
+areas impacted by breach flows will have different warning conditions. The table below shows the different warning times used in these alternatives.
+
+:::danger
+This table contains cells that span multiple rows or columns. Manually update the React component to properly format the table.
+:::
+
+
+
+To create the first alternative, right click on Alternatives and select Create New Alternative to bring up the
+alternative window.
+
+
+
+The name for this first alternative will be “MHP_Breach_MinWarn”. Under Input Data Sources, uncheck the box for Simulate Traffic but leave the
+Calculate Life Loss box checked. Fill in the remainder of the Input Data Sources box to match the following figure.
+
+
+
+The lower section of the Alternative Editor allows the user to set different parameters for each EPZ area. For the BreachEPZ, the Imminent Hazard ID
+Time is set to a Uniform Distribution of -2 to 0 (i.e., between 2 hours prior to the hazard and the time of hazard occurrence) which represents the
+MMC SOP minimal warning case. This value is the time that a breach or other hazard would be identified by someone on site. The Hazard Communication
+Delay represents the time it takes for that person to alert local emergency managers or other officials of the hazard and this value is set to a
+uniform distribution between 0.1 and 0.5 hours.
+
+
+
+Note that the green column in the hydrograph represents the potential range of time that a warning could be issued. This not only reflects the two
+uniform distributions just entered, but it also reflects uncertainty on the EPZ parameter for the Warning Issuance Delay. This window also shows other
+ tabs for Evacuation Parameters, Life Loss Probability, Stability Criteria, and Agriculture where additional parameters can be customized, but for a
+standard LifeSim model these can be left at the default values.
+
+Once the BreachEPZ warning values have been entered, use the Emergency Planning Zone dropdown to switch to the InPoolEPZ. For the in-pool area a
+single most likely warning time of -72 hours will be used with no uncertainty. The reason for this is not necessarily that the population in this area
+ will have that much warning, but that the characteristics of the flood caused by a rising reservoir pool are such that we assume the mobilization
+rate will be near the upper end of the PAI curve. The early warning time provides a model outcome reflecting that assumption. Also note that it is on
+a 24-hour increment, which prevents any potential issues in calculating incremental results caused by population interpolation between daytime and
+nighttime. If the warning was on a 12-hour increment, that interpolation could cause a negative incremental PAR result. With a warning that early the
+Hazard Communication delay is insignificant, so it is left at the default value of 0.
+
+
+
+Finally, switch to the NonBreach EPZ and set the same warning (-72 hours) that was used for the in-pool EPZ. A similar assumption of upper-end
+mobilization based on flood characteristics applies here; the non-breach flooding is a result of spillway flow from the dam which will typically be
+forecasted in advance based on rainfall and inflows and it will occur somewhat gradually as the pool rises above the spillway crest or spillway gates
+are incrementally opened. Once this final warning is set, click OK to close the Alternative Editor window.
+
+To create the additional alternatives, an easy method is to right click on the alternative just created and click Copy. This brings
+up a window where the name of the new alternative can be changed. Change the name to “IHP_Breach_MinWarn” to create the next alternative. Right click
+on the new alternative and select Edit. Change the hydraulic event to IH Breach and change the EPZ to the “EPZ_IHP_DoubleWarning”
+file. Set the same hazard ID time and hazard communication delay for breach, non-breach, and in-pool areas to the same as they were on the MHP
+alternative (-2 to 0 hours for breach and -72 hours for non-breach and in-pool).
+
+
+
+Next, copy existing alternatives (e.g., “IHP_Breach_MinWarn”) to create alternatives for “TAS_Breach_MinWarn”, “SS_Breach_MinWarn”, and
+“NH_Breach_MinWarn”. In each alternative, change the hydraulic event to the appropriate breach event (i.e., TAS, SS, or NH) and for each of these
+three alternatives change the EPZ to the “EPZ_NoDoubleWarning” selection. There will be no non-breach zone for these runs because there is no
+out-of-bank flooding prior to the breach.
+
+Once the minimal warning scenarios are complete, make copies of each one and replace the “MinWarn” in the name with “AmpleWarn”.
+
+
+
+The only edit required for each alternative is the Hazard ID time for the breach zone, which is changed to -6 to -2 hours (minimal warning was -2 to 0
+ hours).
+
+
+
+Finally, set up the non-breach alternatives. For this study we will have non-breach alternatives for only the (1) MH Pool, (2) IH Pool, and (3) TAS
+Pool. The TAS event should not have any damages as it should be within control levels, but it needs to be simulated to confirm that and identify any
+inaccuracies in the hydraulics or structure inventory that need to be corrected.
+
+Once all the example alternatives are created it should match the figure below.
+
+
+
+### Creating Simulations
+
+Simulations are created for testing (e.g., “Test_Sim”) and for each grouping of alternatives (e.g., “MH_Sims”, “IH_Sims”, and “TAS_SS_NH_Sims”; TAS,
+SS, and NH alternatives can be run together since they will all use the two zone EPZ). The “TestSim” is created to run the TAS non-breach alternative
+and any other alternatives that might be run for testing (e.g., MHP Minimal Warning as the most structures will be inundated in this scenario). This
+simulation is helpful for calibrating the structure inventory. As discussed earlier, the TAS non-breach test simulation will help you identify any
+structures that are in the river or reservoir. The MHP scenario will help you identify if high life loss structures are accurately placed and/or if
+the structure attributes need updating (e.g., a high-rise apartment building only has one floor in the attribute table, which does not allow the PAR
+to vertically evacuate in the simulation and may be inflating life loss estimates).
+
+The MH and IH alternatives get their own simulations so that the EPZ polygons can be used as a reporting polygon; remember the non-breach EPZ polygons
+ for those events are unique to the MH and IH scenarios. Since the “TestSim” is not for final reporting, the Summary Polygons are less relevent and
+the number of iterations can be lower. Name the simulation “TestSim”, select the 2am and 2pm boxes, set the number of iterations to 100 and use the
+NoDoubleWarning EPZ as the Summary Polygon. Select the TAS_NonBreach alternative (and any other alternative needed to help with calibration) to run.
+
+
+
+Next create the “MH_Sims”, “IH_Sims”, and “TAS_SS_NH_Sims” simulations. For the “MH_Sims”, select 2am and 2pm, and use 1000 iterations (more
+iterations can be used depending on need and simulation times, 1,000 is a recommended minimum). For the Summary Polygons, select the MHP double
+warning EPZ, the Milage Reaches polygon that was created in ArcGIS previously, and the City Boundaries polygon. For Summary Set Name it is important
+to use the same names for each simulation (EPZs, Reaches, and Cities) to facilitate analysis of results in a spreadsheet.
+
+
+
+Once all the example simulations are created, it should match the figure below.
+
+
+
+## Running the TestSim
+
+The first Simulation to be run is the TestSim, as this will assist in calibration of the inventory. In theory, the TAS non-breach scenario should be
+within channel and have no flood damages. If structures are flooded in this scenario, it means those structures would likely be flooded prior to the
+breach in the breach scenario and would not receive any warning within the model.
+
+Right click on the TestSim and select Run Simulation to simulate the TAS non-breach alternative that was selected.
+This simulation may take about 20 minutes or more depending on the computer. Once the simulation is finished, right click on TestSim
+and select View Results Tables.
+
+
+
+The primary output table for the simulation has a row for each Summary area, including totals for the entire summary areas. There are also rows for
+each time of day. In this example 15 structures were inundated in the TAS non-breach event and these need to be checked and modified before running
+the final simulation sets.
+
+
+
+## Editing the Structure Inventory Based on Simulation Results
+
+To edit the structure inventory, right click the study’s structure inventory in the study tree and select Show in Map Window.
+
+
+
+Switch to the Map Layers tab and add a web imagery layer as shown below.
+
+
+
+Switch back to the study tree, right click on TestSim under Simulations and select View Results Maps.
+
+
+
+Check the box next to 14:00 Structure Summary and the rest of the window should populate as follows.
+
+
+
+Click Send Selected to Map Window in the bottom right to add the selection(s) to the map. In the Map Layers pane, select and move the
+ structure inventory so it is at the top of the list. Next, right click on the TAS_NonBreach layer and select Properties. Change the
+Draw Style to Value, select the Attribute Max_Depth, change the number of bins to 1 and the Minimum to 0.001. Next change both the Line Color and Fill
+ Color to yellow and change the size to 5. Next, select the Excluded Values category, and uncheck the boxes next to Line Color and Fill Color. When
+the changes are made hit Apply and then Close in the bottom right.
+
+
+
+These map properties create an effect that highlights any structures that were inundated by more than 0.001 feet in the TAS Non-breach simulation.
+Four of the structures are on or just upstream of the dam itself. Zooming in it is apparent that these are not structure points that should be
+included in the LifeSim model.
+
+
+
+The problem is addressed by editing the structure inventory. Right click on the inventory and select Edit.
+
+
+
+Once edit is selected a new toolbar appears on the right side of the map buttons.
+
+
+
+First the three points on the dam are selected by drawing a box around them.
+
+
+
+Hit the Delete key on your keyboard to delete the structure points. Directly west of these structure, across the lake, a highlighted
+structure point in an empty field can also be selected and deleted. The user can zoom out and scroll downstream to locate the other highlighted points
+ that were damaged in the TAS non-breach, either deleting points if there are no apparent structures nearby without points or moving them to
+structures if possible. It can be helpful to uncheck the structure inventory layer display to help locate the yellow points. Structures can be moved
+by left clicking and holding down the button to drag the points to a new location as demonstrated in the figure below.
+
+
+
+To finish editing, click on the Save button and then click on the Stop Editing button. Note that if saving results
+in an error about the number of records not matching, stop editing and remove the inventory from the map layer list, then add it to the display again from
+ the study tree and verify and re-edit as necessary.
+
+
+
+Editing the structure points impacted in the TAS Non-breach event represents a minimum level of structure inventory calibration that must be
+accomplished to avoid overestimating consequences due to structures not receiving a warning or structures being flooded deeper than they should be.
+There are some cases where a structure point is placed correctly but is still flooded due to either terrain inaccuracies or lack of low flow hydraulic
+ model calibration. In these cases, the user must determine the most efficient and effective resolution which could include steps such as moving
+structures to compensate for the inaccuracies, using a double warning approach to ensure the structures get a warning in the model prior to
+inundation, or performing additional hydraulic model calibration. Some structure points may need to be moved outside of the structure footprint to
+compensate. Common examples of when this may be required are structures on a hillside where the uphill side is at ground level and the downhill side
+is raised on blocks or piers and floating structures attached to riverside docks (there are several examples of the latter along the Columbia River).
+
+Once the TAS non-breach calibration is complete, edit the test simulation to select both the MH Breach Minimal Warning and the TAS Non-Breach
+alternatives, then run the simulation with those two alternatives and the inventory edits just completed. This second test will accomplish two important
+ tasks: (1) it will verify that the TAS Non-breach event does not flood any structures and (2) it will provide the results needed to verify the
+attributes and locations of high consequence structures.
+
+Once the simulation is complete, close the simulation then right click on TestSim and select View Results Tables. It
+ should look like the figure below where the TAS_NonBreach alternative has zero structures inundated.
+
+
+
+Close the table, right click on TestSim again, and select View Results Maps. Check the box next to the MHP Breach
+MinWarn 14:00 Structure Summary and click Send Selected to Map Window in the bottom right of the window. The map window will now
+contain a heat map of the daytime life loss for the MH MinWarn alternative.
+
+
+
+Life loss at individual structures can be checked by right clicking on the selection and opening the attribute table. Scroll the table halfway across
+to the field Life_Loss_Total_Mean, right click on the field name, and select Sort Descending. The first row will now be the structure
+ with the highest mean life loss. Right click on the row number on the left and select Zoom to Selected to zoom to the structure
+area. Repeat the zoom a few more times to zoom to a close view of the structure.
+
+
+
+Now with the structure inventory displayed on top of the results map, right click on the inventory to open the attribute table. Move and organize both
+ attribute windows to they can be seen, and then use the Select tool (white arrow) to select the structure with the high life loss.
+In the structure attribute table, click on the button to Show Selected Rows Only as shown in the figure below.
+
+
+
+In this example, a significant portion of the life loss (22%) is occurring in a building with an occupancy type of EDU1, which is a school. The
+structure can now be investigated to determine whether the attributes and location are correct. The first obvious issues are that (1) the placement is
+ incorrect based on the imagery and (2) the NSI lists the school as a single-story structure, while many schools are multiple stories.
+
+
+
+Scrolling right on the inventory shows that there is a daytime under 65 population of 739, which should be the students and teachers combined. The
+structure can be moved based on the imagery, but to check the other attributes the school must be researched on the internet.
+
+Google Maps and Streetview can typically be used to verify how many stories a building is if street view is available in the area. With a school, the
+school website also often has pictures which can be used to count stories. A Google Maps search for Clearfield Area High School will bring the user to
+ a completely different school location than what is shown in the inventory and in the Mapbox satellite imagery in LifeSim, which poses a unique
+problem.
+
+
+
+It’s helpful to crosscheck the stucture’s location by utilizing an alternate imagery source. LifeSim contains two streaming sources, MapBox and ESRI.
+The figure below shows the same area with Mapbox imagery on the left and ESRI imagery on the right.
+
+
+
+While the ESRI imagery is lower resolution, the school buildings are clearly not there, leading to the possibility that the school has been
+demolished. Additional news article searches verified that a new consolidated school was built and the school location in the structure inventory was
+the old school. The point can be moved to the new school location found in the Google Maps search, however, an inundation check shows that new
+location to be outside of the maximum inundation footprint, so the entire school point can be deleted instead of moved. Right click on the inventory
+layer in LifeSim and select Edit, then select the structure point, right click on it, and click Delete Selected
+Features. If the school was still operating in its original location, the point would be moved to the school structure and the number of
+stories would be changed to 3 stories.
+
+Next look at the structures with the second highest mean life loss value by selecting that row in the MH_Breach_MinWarn attribute table (with the
+descending sort on the Life Loss Total Mean field). Right click on the row to zoom to the structure and it comes up as the Curwensville Area School
+District. Open the structure attribute table and select the structure and it will show two structures on the same point, both EDU1 schools.
+
+
+
+Right click on the inventory layer to edit. First, delete the residential structure points currently on the school or move them to any nearby
+residential structures that are missing points. Move the EDU points to the school (they can stay together because there is a high school and middle
+school in the same complex). Next perform an internet photo search to find pictures of the school to confirm the number of stories (this area did not
+have street view available). Photos show the school to be 2-stories, so change the number of stories.
+
+
+
+Save the edits and stop the editing session.
+
+While further edits will not be detailed in this guide, additional calibration can be performed by scrolling along the inundated areas and looking for
+ visual inventory issues such as misplacement in open fields or points too close to or inside the river itself. Attributes of selected structures can
+be edited by opening the attribute table of the structure inventory. Note that typically in dam breaches life loss is higher in areas closer to the
+dam due to the arrival time, and high consequence structures in both daytime and nighttime results should be checked and validated. The level of
+effort spent in calibrating the inventory depends on the scope and purpose of the study as well as the accuracy of the data used to create the
+structure inventory.
+
+Once all structure edits have been completed, the three non-test simulations can be computed. Once complete, results can be viewed by right clicking
+on the simulations and selecting View Results Plots, Tables, or Maps. The results tables can be
+copied into Microsoft Excel and analyzed using pivot tables and formulas. Results can be displayed and compared by downstream reaches and city
+boundaries; additionally, the IHP and MHP results can be viewed by non-breach and breach EPZs.
+
+(Page is intentionally left blank)
+
+
\ No newline at end of file
diff --git a/docs/desktop-applications/lifesim/applications-guide/v1.0/06-modeling-cascading-dam-breaches-in-lifesim.mdx b/docs/desktop-applications/lifesim/applications-guide/v1.0/06-modeling-cascading-dam-breaches-in-lifesim.mdx
new file mode 100644
index 000000000..97d88dc7b
--- /dev/null
+++ b/docs/desktop-applications/lifesim/applications-guide/v1.0/06-modeling-cascading-dam-breaches-in-lifesim.mdx
@@ -0,0 +1,339 @@
+---
+title: "Modeling Cascading Dam Breaches in LifeSim"
+---
+
+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 TableVertical from "@site/src/components/TableVertical";
+import Figure from "@site/src/components/Figure";
+import TableReference from "@site/src/components/TableReference";
+import FigReference from "@site/src/components/FigureReference";
+
+
+
+# Modeling Cascading Dam Breaches in LifeSim
+
+## Purpose
+
+This chapter demonstrates the process for estimating consequences for a scenario in which multiple dams breach within the same modeling extents. An
+example of this is a dam breaching due to extreme inflow from an upstream dam breach. This chapter focuses on a breach at Oahe Dam, located along the
+Missouri River in South Dakota, and the other dams located downstream that could breach following a breach at Oahe Dam.
+
+There are several dams downstream of Oahe Dam that are at risk of a cascading breach. The modeled cascading breaches (originally modeled by the
+Modeling, Mapping, and Consequences (MMC) Production Center of the U.S. Army Corps of Engineers’ (USACE) in 2022) include three other dams that could
+potentially breach: Big Bend Dam (85 miles downstream of Oahe Dam), Fort Randall Dam (192 miles downstream of Oahe Dam), and Gavins Point Dam (261
+miles downstream of Oahe Dam). Since this example assumes there are three dams that breach following the initial Oahe Dam breach, there are multiple
+ways to model this scenario in LifeSim.
+
+This chapter focuses on two options: (1) warning the entire downstream area relative to the Oahe Dam breach and (2) warning the in-pool area, areas
+downstream of Oahe Dam, and areas downstream of Big Bend Dam relative to the Oahe Dam breach, as well as warning areas downstream of Fort Randall Dam
+and Gavins Point Dam relative to the Fort Randall Dam breach. Another modeling option that is not detailed in this chapter is warning areas
+downstream of specific dams relative to specific dam breaches (e.g., Warn the population between Oahe Dam and Big Bend Dam relative to the Oahe Dam
+breach, warn the population between Big Bend Dam and Fort Randall Dam relative to the Big Bend Dam breach, etc.).
+
+## Input Data and Pre-Processing
+
+The subsequent sections discuss the input data required to calculate damages and life loss for a cascading dam breach. Most of the input data remains
+similar to the non-cascading dam LifeSim modeling (see the for more information). The subsequent sections discuss hydraulic data, emergency planning
+zones (EPZ), structure inventories, creating alternatives, and simulating alternatives.
+
+### Hydraulic Data
+
+Importing hydraulic data for a cascading dam breach follows the same process as importing hydraulic data for a standard dam breach. Although there are
+ multiple hazard occurrence times (i.e., multiple dam breaches), LifeSim currently only allows the user to select one hazard occurrence time. For
+cascading dam breaches, the most upstream dam is often the focus of the dam safety study. To model cascading breaches, it is easiest to select the
+hazard occurrence time based on the upstream dam breach, which is Oahe Dam in this example.
+
+Fort Randall Dam will have a separate breach time, but this will come into play when selecting warning times for the EPZs rather than the hazard
+occurrence time (if using Option 2 discussed in the Purpose section). Similarly, for all LifeSim models, the hazard occurrence time is the first step
+in the warning and evacuation timeline. The imminent hazard identification times in the alternatives are relative to the hazard occurrence time
+selected for each hydraulic scenario. This is discussed in more detail later in the Alternatives section.
+
+### Structure Inventory
+
+The structure inventory for a cascading dam breach is the same inventory used for standard hydraulic scenarios (i.e., the breach of only Oahe Dam).
+However, if the cascading breaches scenarios are tacked on later in the study/modeling process, the structure inventory may need to be expanded as
+these inundation boundaries are larger than those from the Oahe Dam breach alone. If you have the cascading breach inundation boundaries from the
+start of the study, it is recommended to use the highest loading breach scenario with cascading breach to select the structure inventory. Including a
+buffer on this inundation boundary is recommended to accommodate any changes to the hydraulic model.
+
+### Emergency Planning Zones
+
+EPZs are a key input that are likely to differ for a cascading dam breach scenario. There are two EPZ options for this type of event: (1) use the same
+ double warning EPZ as the standard hydraulic scenario (see the ) and (2) create a new double warning EPZ that includes a separate zone(s) for the
+area(s) downstream of a cascading dam breach(es).
+
+Option 1 is recommended if you believe the entire downstream area would be warned relative to the upstream dam breaching. Option 2 is recommended if
+you believe portions of the downstream area would only receive an evacuation order following the breach of a downstream dam (i.e., the population and
+emergency managers view the risk of the downstream dam breaching as low; they also believe risk is low following the upstream dam breach).
+
+For the Missouri River dams downstream of Oahe, it is possible that emergency managers believe Big Bend (85 miles downstream of Oahe Dam) is at higher
+ risk for breaching since it is within 100 miles of the dam. However, emergency managers in areas downstream of Fort Randall Dam may initially believe
+ the dam will not breach. They would then send out a warning much closer to when Fort Randall Dam breaches compared to when Oahe Dam breaches. The
+rest of this chapter focuses on modeling Option 2 and separating the EPZ at Fort Randall Dam.
+
+#### Modeling Option 2: Creating a New Double Warning EPZ
+
+To model the cascading breach following modeling Option 2, you need to first create a double warning EPZ that includes a separate zone for downstream
+of Fort Randall Dam. The base shapefile of any cascading breach EPZ is the non-cascading double warning EPZ; the non-breach flows remain the same
+between a cascading breach and non-cascading breach. The easiest way to do this is to duplicate the existing double warning EPZ / save the existing
+double warning polygon as a new shape. Then, begin an edit session in ArcGIS on the duplicate double warning shapefile, cut the polygon at Fort
+Randall Dam, edit the attribute table to include an appropriate name (e.g., FtRandall_Downstream), and save edits.
+
+
+
+Then, import the new shapefile into LifeSim with an appropriate name; exemplifies different EPZ names, including
+ an EPZ specifically for modeling Option 2: MHP_breach_casc_FtRandall_Warn.
+
+
+
+### Alternatives
+
+Creating and setting up alternatives in LifeSim varies significantly depending on which modeling method you are using. Both modeling options are
+detailed in the subsequent sections.
+
+#### Modeling Option 1: Warning Relative to Oahe Dam Breach
+
+For Option 1, the cascading dam breach alternative is almost identical to the standard hydraulic scenario. As shown in the figures below, the only
+difference in the alternatives is which Hydraulic Event is selected (non-cascading breach, labeled “NC”, versus cascading, labeled “C”, breach). Both
+use the Maximum High Pool (MHP) double warning EPZ, the same structure inventory, and the same Imminent Hazard ID Times.
+
+
+
+
+
+#### Modeling Option 2: Warning Areas Relative to Specific Dam Breaches
+
+For Option 2, first you need to use the new double warning polygon that was created for the cascading dam breaches. The only difference between the
+two EPZs will be that the polygon is cut at the cascading dam (i.e., Fort Randall Dam). The separate zones are necessary in order to include different
+ Imminent Hazard ID Times relative to 1) Oahe Dam breaching and 2) Fort Randall Dam breaching.
+
+For Option 2, the key difference is warning the areas downstream of the other dam breach (e.g., Fort Randall Dam) relative to its hazard occurrence
+time (i.e., overtopping or breach time). The hydraulic engineer can provide the downstream dam’s breach time and/or overtopping time. Recall, however,
+ that LifeSim can only have one hazard occurrence time per hydraulic scenario. A cascading dam breach has multiple hazard occurrence times; one for
+each dam that overtops/breaches in the scenario. To account for the hazard occurrence time of Fort Randall Dam breaching, the Imminent Hazard ID Time
+needs to be calculated to warn areas downstream of Fort Randall Dam relative to when it breaches. To obtain this information, calculate the time
+difference (in hours) between the two dams breaching (shown in green in the following table).
+
+:::danger
+This table contains cells that span multiple rows or columns. Manually update the React component to properly format the table.
+:::
+
+
+
+From here, you can determine the Imminent Hazard ID Times for the various warning scenarios. The following table shows the calculated Imminent Hazard
+ID Times for the Downstream of Fort Randall EPZ. The warning times shown below warn the population downstream of Fort Randall Dam between 2 hours
+prior to breach and the time of breach (minimal warning) and 6 hours prior to breach to 2 hours prior to breach (ample warning) -- relative to the
+time of Fort Randall Dam’s breach initiation.
+
+:::danger
+This table contains cells that span multiple rows or columns. Manually update the React component to properly format the table.
+:::
+
+
+
+Implementing the warning times from into your alternatives is shown in
+and . The figures show the Maximum High Pool cascading breach. As shown in the figures, the “DS_Oahe_Fail” EPZ is
+ assigned the standard time of -2 to 0 hours. The “DS_FtRandall_Fail” EPZ is assigned the calculated time of +14 to +16 hours. Again, the +14 to +16
+hours is relative to the hazard occurrence, which is Oahe Dam’s breach initiation time.
+
+If you are unsure of which modeling method to use, implement both methods in the study to understand how the different EPZs impact life loss results.
+
+
+
+
+
+As previously mentioned, an additional modeling method is to warn the populations separately downstream of each dam (e.g., the EPZ would include a
+zone downstream of Oahe Dam, a zone downstream of Big Bend Dam, a zone downstream of Fort Randall Dam, and a zone downstream of Gavins Point dam—each
+with imminent hazard ID times calculated based on the respective dam’s breach initiation relative to the Oahe Dam’s breach initiation time.). The
+local emergency managers and dam operators may have a general understanding of how they would respond to a breach of an upstream dam, including
+if/when they would send out evacuation orders. This type of information can help inform which LifeSim modeling method is most appropriate for your
+study’s cascading dam breach scenarios.
+
+### Simulations
+
+For both modeling options, creating a simulation and running it follows the same standard practice. Reference the for more detailed information on
+creating simulations. The only additional reporting consideration is if you want to include unique summary polygons. For example, it may be
+beneficial to summarize results by dam breach area (e.g., one area between Oahe Dam and Fort Randall Dam and another area for everything downstream of
+ Fort Randall Dam, etc.) If you created new EPZs for the cascading dam breach, these shapefiles may be used as the summary polygon.
+
+
+
+(Page intentionally left blank)
+
+
\ No newline at end of file
diff --git a/docs/desktop-applications/lifesim/applications-guide/v1.0/07-estimating-consequences-for-coastal-infrastructure.mdx b/docs/desktop-applications/lifesim/applications-guide/v1.0/07-estimating-consequences-for-coastal-infrastructure.mdx
new file mode 100644
index 000000000..879dbc61b
--- /dev/null
+++ b/docs/desktop-applications/lifesim/applications-guide/v1.0/07-estimating-consequences-for-coastal-infrastructure.mdx
@@ -0,0 +1,429 @@
+---
+title: "Estimating Consequences for Coastal Infrastructure"
+---
+
+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 Figure from "@site/src/components/Figure";
+import FigReference from "@site/src/components/FigureReference";
+
+
+
+# Estimating Consequences for Coastal Infrastructure
+
+## Purpose
+
+This example demonstrates the process for estimating consequences for coastal levees, floodwalls, dune and/or seawalls in LifeSim. The general process
+ is similar to estimating consequences for riverine levees, but there are modeling nuances and warning and evacuation considerations specific to
+infrastructure in a coastal environment. This chapter includes step-by-step instructions (often referring to the Levee applications chapter) for importing
+ the required data into LifeSim, choosing appropriate warning and evacuation data for a study area, and interpreting modeling results. The Coastal
+Infrastructure chapter focuses on South Shore Staten Island (SSSI) modeling that was conducted in 2020 by the Risk Management Center to support a
+risk-informed design (RID) risk assessment. This RID risk assessment took place after the planning process was complete for the SSSI Coastal Storm
+Risk Management planning study. The proposed SSSI Levee includes segments of buried seawalls, levees, and floodwalls.
+
+## Input Data
+
+The subsequent sections discuss the input data required to calculate economic damages and life loss for coastal infrastructure in LifeSim. The input
+data sections, many of which simply refer to the Estimating Consequences for Levees and Floodwall Chapter, include hydraulic data, emergency planning
+zones (EPZ), structure inventories, road networks, destinations, creating alternatives, and simulating alternatives. For reference,
+{"\n"} through Figure 155 below show the SSSI levee and seawall breach locations, structure inventory,
+and road network and destinations, respectively. Refer to these figures for context regarding later sections in this chapter.
+
+
+
+Breach Location 1 in the above figure is the Levee Control Location (LCL). This is the lowest section of the proposed levee and will likely overtop
+first in most cases. Oceanic wind/wave patterns (discussed further in the ‘Importing HEC-RAS Data’ section), however, can sometimes lead to
+overtopping at a different location where levee elevations are higher. Breach Locations 2 and 3 which breach the proposed buried seawall were
+selected by the USACE New York District]. These sections of the proposed project were also analyzed for wind/wave-overtopping.
+
+
+
+
+
+With hurricanes being the assumed source of inundation to coastal levees in the form of storm surge, local emergency managers would likely recommend a
+ shelter-in-place action to those who were unable to or decided not to evacuate well before this non-evacuation depth occurs. As there is no current
+mechanism to stop the evacuation process at a particular time step (i.e., when high wind speeds or significant rainfall prevent mobilization at a time
+ preceding storm surge landfall), a LifeSim model utilizing evacuation on roads could simulate vehicles on roadways and exposed to inundation when
+these last-minute evacuations do not commonly occur.
+
+### Hydraulic Data
+
+When using Hydrologic Engineering Center’s River Analysis System (HEC-RAS) data as LifeSim input, the hydraulic data should be in the form of
+Hierarchical Data Format (HDF) files so the user can easily simulate evacuation when necessary. Unlike riverine/inland levees or floodwalls,
+simulating evacuation in a coastal environment may not be a critical part of estimating direct life loss. In most cases, life loss on roads in a
+coastal context where the source of inundation is most associated with an infrequent storm event (e.g., hurricane) is not expected to be the primary
+risk driver. Lead times for these types of events are generally expected to be greater than 24 hours (e.g., hurricane tracking begins several days
+prior to the storm reaching landfall). For scenarios where lead times are expected to be relatively short, the option to simulate evacuation is still
+available to the user when HDF files are utilized. The HEC-RAS plan HDF file and the HEC-RAS terrain HDF file are needed for each hydraulic scenario
+where evacuation is simulated.
+
+#### Import HEC-RAS Data
+
+Importing HEC-RAS data for coastal levees or floodwalls is generally the same as described in the Levee applications chapter. It remains important to
+understand where and when water is entering the leveed area to best establish the Hazard Occurrence time in LifeSim. For levees in a coastal setting,
+the team must be able to distinguish the source of water (i.e., breach flow, rainfall, flanking, or wind/wave-overtopping). If, for example,
+wind/wave-overtopping during a storm surge leads to water entering the leveed area prior to a levee or floodwall breach, the time of
+wind/wave-overtopping will be set as the Hazard Occurrence time in LifeSim. This should be discussed at length with the team’s hydraulic engineer.
+
+The figure below shows an example wind/wave-overtopping hydrograph from the SSSI LifeSim model. Note that the Hazard Occurrence time (red dashed line
+in ) aligns with the wind/wave combination that led to a peak depth capable of overtopping the levee at the
+selected location (red circle in the map window in ).
+
+
+
+### Emergency Planning Zones
+
+Refer to the for establishing the EPZ for your coastal infrastructure. It is again recommended to discuss what should be considered the leveed area
+with your hydraulic engineer and potentially other team members.
+
+Multiple EPZs may be required to account for different evacuation assumptions related to hurricane events. For example, consider a situation where
+effective evacuation is unlikely and the affected population must shelter-in-place. This would mean the maximum mobilization rate parameter in LifeSim
+ would be set to 0%, or some other static rate if some amount of shadow evacuation (evacuation without a direct order to do so) is assumed. A new EPZ
+will be generated each time the warning and protective action data is customized according to the assumed event (e.g., The user needs 3 EPZs to
+account for different mobilization assumptions: one EPZ to show 100% of the population shelters-in-place, one EPZ to show a 10% shadow evacuation,
+one EPZ with standard mobilization assumptions).
+
+ below shows the adjusted SSSI shelter-in-place EPZ parameters in the Warning and Protective Action Data Editor.
+To access this data editor, right-click the Warning and Protective Action Data subheading just below the ‘Emergency Planning Zones’
+heading in the study tree. Select “Edit Warning and PAI Data”. Under the ‘Protective Action Initiation’ tab of the data editor,
+click the green plus sign to add a custom distribution.
+
+
+
+In the above figure, a deterministic distribution was selected from the dropdown and the table just below.The Time and Initiated fields can be edited.
+ According to , after 10,000 minutes, 0% of the affected population will have initiated evacuation in the
+simulations where this new Shelter-In-Place EPZ is used. If, however, 10% of the affected population has evacuated in previous disasters despite a
+shelter-in-place order, change both ‘Initiated’ values to 10 instead of 0.
+
+#### Using Existing Data to Inform LifeSim Parameters
+
+Refer to the if using existing consequences elicitation data, the Levee Safety Tool, or Emergency Management Agency Websites to inform LifeSim
+parameters. Many counties and major metropolitan areas along the coasts publish evacuation plans for large storm events on their own websites. These
+evacuation plans should be considered when selecting warning and evacuation parameters in the EPZ(s) and in the evacuation inputs (if applicable).
+
+For example, in relation to the SSSI coastal storm study, the New York City official website (NYC.gov) is linked to the site. Here, users can learn
+about specific disaster plans in their area. below shows the home page of the NYC Emergency Management website.
+
+
+
+After scrolling down within the ‘Coastal Storms and Hurricanes’ page depicted in , website users have access to
+the information shown in below.
+
+
+
+Many coastal emergency management websites are organized similarly to . To inform the LifeSim model, it is important
+ to understand who is receiving the order, what they are being told to do, and when they will be told to do it. ‘Know Your Zone’ (often called
+something similar across emergency management sites) is typically the best place to start. Coastal cities or counties usually evacuate by numbered and
+ color-coded zones based on storm surge, forecasted storm conditions, or wind/wave patterns. below shows an
+overview of the Staten Island hurricane evacuation zones.
+
+Notably, it is currently not recommended to include evacuation centers or shelters as Destination Points in LifeSim. As of 2024, there is no way to
+assign a maximum number of persons allowed at a destination point, so this type of assumption likely overestimates the amount of people that could
+evacuate to “shelter locations” in LifeSim. Generally, Destination Points are meant to represent egress routes, not final shelter locations.
+
+
+
+An additional EPZ can be created in which the evacuation zones are delineated. below shows both the general EPZ
+in the SSSI LifeSim model map window and the hurricane evacuation zones from the NYC emergency management website. The latter will be used (visually)
+to split the general EPZ polygon in GIS software or the LifeSim model. Refer to the for creating and editing an EPZ in GIS software.
+
+
+
+Understanding the thresholds used to evacuate each zone is the next piece of the puzzle. If, for example, a 2ft storm surge will lead to the
+evacuation of Zone 1 (red) nearest the coast, the LifeSim modeler will need to communicate with the team’s hydraulic engineer and decide when this
+threshold is reached in the model. The same process will be applied to each zone until the hazard occurs (e.g., breach or overtopping).
+
+#### Importing an Emergency Planning Zone
+
+Refer to the for instructions to import an EPZ into LifeSim.
+
+### Structure Inventory
+
+To use LifeSim to calculate life loss and/or economic damages, a structure inventory needs to be imported into the study. For levees and floodwalls,
+whether in a riverine or coastal setting, the structure inventory should be limited to including structures within the leveed area. Otherwise, it’s
+possible that both economic damages and life loss estimates would be inflated due to including structures that are outside of the leveed area.
+Additionally, LifeSim will not simulate if any structure points are located outside of the EPZ. The National Levee Database () is a resource that
+often includes the estimated leveed area (including coastal structures), which can be downloaded as a shapefile and used in LifeSim. It’s also
+recommended to communicate with the hydraulic engineer when establishing a protected/leveed area.
+
+#### Importing a Structure Inventory
+
+Refer to the to import a structure inventory into LifeSim.
+
+#### Editing the Structure Inventory
+
+Refer to the to edit the structure inventory. Structures attributes, specifically foundation heights and construction types, may need additional
+adjustments in a coastal setting. General structure inventory assumptions may be less applicable in these areas. below shows three structures with
+foundation heights that needed to be edited in the SSSI LifeSim model.
+
+
+
+If the NSI base level data lack structure-specific data sources, some values will be generalized across larger areas (e.g., census block or tract).
+In the above case, these three structures’ (structures 305, 1575, and 9095) foundation heights were increased from 1.5ft to show that the structures’
+first floors are elevated. Moving inland, the terrain elevation increases in this area, leading to a lower assumed foundation height across the tract.
+ If the general NSI foundation heights were 1-foot for all three structures where terrain elevation is lower, for example, much lower flood depths
+would result in the non-evacuated PAR getting “caught” in their structure and sampled for life loss. Because the structures shown in the figure above
+are elevated, it’s possible that the PAR in these structures could safely shelter-in-place and life loss would not be sampled. When foundation height
+errors like this example are aggregated across a shoreline, life loss estimates can potentially be inflated. It is important to spend adequate time
+adjusting structure attributes, especially in a coastal setting.
+
+### Simulating Evacuation
+
+For most riverine or other inland levee projects, evacuation is simulated in LifeSim. In a coastal context, however, evacuation may not be a crucial
+element to the LifeSim model. Life loss on roads in a coastal environment where the source of inundation is most associated with a hurricane event is
+not expected to be the primary risk driver. Since forecasted lead times before hurricane landfall (or imminent hazard identification time) are
+expected to be no less than 24 hours, protective action initiation rates used in the LifeSim modeling are most likely to be the primary risk driver.
+This expected lead time prior to the hurricane landfall enables both the warning issuance delay and first alert parameters to sample approximately
+100% (i.e., the entire population receives a warning), even when incorporating uncertainty distributions. The sampled protective action initiation
+parameter primarily drives the life loss estimates.
+
+If it is decided for certain scenarios that simulating evacuation is necessary (most often for events with relatively short lead times), a road
+network and destination points will need to be imported. Without these two components, it is not possible to simulate evacuation. The recommended
+workflow is to begin with importing a road network and then create destination points.
+
+#### Road Network
+
+Refer to the to import and edit a road network in LifeSim.
+
+#### Destination Points
+
+Refer to the to create, import, and edit destination points in LifeSim. When simulating evacuation to look for potential choke points, reference the
+area’s evacuation plans (e.g., zones and routes) when placing destination points. As stated earlier in the chapter, the destination points should not
+reflect shelter locations; the points should represent major egress routes that lead to safety.
+
+### Creating Alternatives
+
+Refer to the for general information on creating alternatives in LifeSim. However, there are additional considerations when creating alternatives for
+ a coastal model. Much like with riverine levees, there is a warning and delay continuum the PAR may be subjected to. Given limited time and
+resources, it is important to leverage LifeSim in a way that captures a range of possible outcomes.
+
+Similar to inland levees and floodwalls, the relative hazard identification time should be reflective of the community’s ability to monitor the
+project (consider storm conditions), how early the event could be forecasted in advance (usually early for coastal storm events), and the type of
+failure mode (e.g., the emergency managers would have little time to identify a rapidly developing breach, so the relative hazard identification time
+would be close to the time the hazard occurs).
+
+ 163 shows an example alternative representative of a situation in which either the hazard occurs relatively quickly, or emergency managers have
+waited to warn the impacted population (hazard identification between 3 hours prior to its occurrence and 30 minutes after). In the example below,
+this warning may be appropriate for a 0.5 Annual Exceedance Probability (AEP) event as this is a frequent event with potential to impact very few
+people. It’s possible the “warning” would only be based on the population self-warning relative to when they see floodwaters.
+
+
+
+You can create multiple alternatives for each hydraulic scenario with various warning times if there is uncertainty surrounding the relative hazard
+identification time. This provides a range of possible life loss outcomes. shows an example using the same
+hydraulic event but with more optimistic warning assumptions (hazard identification 24 hours prior to its occurrence). As shown in the hydrograph, the
+ depths do exceed 4ft, which could result in life threatening flooding. It’s possible that even this frequent of an event would be forecasted in
+advance.
+
+
+
+It is not uncommon for evacuation orders to be given days prior to the event in a coastal environment. shows a far more optimistic, or “optimal”,
+warning alternative for the same SSSI hydraulic event depicted in 163 and .
+
+
+
+If events like the ones being modeled have previously occurred, adjust the alternative parameters to reflect either what happened or what will likely
+happen based on lessons learned. After major storm events, city and/or county emergency managers may publish a report outlining specific
+recommendations for updates to existing emergency plans; check for these documents when adjusting alternative input parameters in LifeSim.
+
+### Creating Simulations
+
+Once you have created alternatives, you need to simulate the alternatives to compute life loss and economic damages results. Refer to the to create
+simulations in LifeSim.
+
+## Understanding and Interpreting Results
+
+After running simulations, you can view your results in various ways, including by result plots, result tables, and result maps. Each way you view
+results is beneficial in understanding your life loss and economic damage results as well as conducting a quality check on your results. It is
+unlikely that your first simulation will be your last simulation—edits to the structure inventory, EPZs, road network, and/or destination points may
+be needed to obtain accurate and representative results.
+
+Much like with riverine/inland levees, if multiple warning alternatives were created for a single hydraulic scenario, it is important to compare life
+loss estimates across those alternatives. However, when multiple sources of water are present in the model (e.g., breach flow, rainfall, flanking, or
+wind/wave-overtopping), as is common with coastal storm studies, life loss estimates may not align intuitively with the hydrologic events. For
+example, a 0.002 AEP event may result in higher incremental life loss estimates when compared to the 0.001 AEP event because much of the population
+was warned early due to overtopping and evacuated prior to breach. The 0.002 AEP event could also produce less rainfall in the leveed area relative to
+ the 0.001 AEP again resulting in an earlier warning, ample time to evacuate prior to breach, and thus higher incremental life loss.
+
+Similarly, when evacuation is being simulated, additional warning time does not always correspond to lower life loss estimates. For example, ample
+warning may lead to more people attempting evacuation during extreme conditions causing life loss to occur on roads that may have been avoided by
+sheltering-in-place at that point in time. On the other hand, if storm conditions (i.e., high depths and velocities) exceed stability criterion across
+ many structures in the leveed area, sheltering-in-place may result in the highest life loss estimates. Before these narratives can be deduced and
+defended from the LifeSim model, it is important to double-check input parameters and quality check results at the structure level.
+
+### Post-Simulation Calibration
+
+Gaining an understanding of how flood depths and flood arrival times interact with each other and structures within the leveed area is a good place to
+ start. and below break up the SSSI LCL 1ft OT breach inundation area by
+depth and arrival time, respectively.
+
+
+
+
+
+The arrival of two feet of water within the leveed area happens relatively quickly for the event depicted in the figures above. In fact, most of the
+leveed area is inundated by at least two feet of water between 30 minutes to 4 hours relative to the hazard (i.e., initial overtopping). Furthermore,
+much of this area is inundated by depths exceeding 6 feet. These characteristics would suggest life loss could be spread across much of the leveed
+area depending on how the PAR is distributed. shows the spatial distribution of life loss for a minimal warning
+(hazard identification 3 hours prior to overtopping to 30 minutes after) LCL 1ft OT breach scenario.
+
+
+
+In alignment with the depth grid and arrival time grid shown in and , the
+estimated life loss is spread out with slightly higher estimates near the center of the leveed area. Now, with an understanding of depths, arrival
+times, and where life loss is generally occurring, the modeler should focus on structure specific results. Refer to the for creating and editing
+Structure Summary files in LifeSim. shows the Structure Summary Attributes Table for the LCL 1ft OT minimal
+warning breach scenario. Many additional attributes were removed from this attributes table to focus on the fields presented in the figure.
+
+
+
+An understanding of the relationship between each structure’s maximum depth and total mean life loss estimate can help the modeler locate structures
+with characteristics (e.g., foundation height and number of stories) that may need manual calibration. Start by sorting ‘Life_Loss_Total_Mean’ from
+largest to smallest by double-clicking the header twice, or right-clicking and selecting descending order. Structure 11537 (the first entry of the
+table in ) has the highest estimated life loss for this scenario, a foundation height of 3 feet, 1 story, and experiences a maximum depth just below
+10 feet. below shows structure 11537 in the LifeSim map window and Google Earth Street View.
+
+
+
+A closer look shows that this structure has a foundation height less than 3 feet and is actually 2 stories. In this case, life loss could potentially
+be overstated given the ability for PAR to vertically evacuate to the second story above the maximum flood depth experienced at this structure. In
+this example, if the structure had a foundation height closer to 8 feet due to its proximity to the coast, the number of stories would not
+significantly matter because of the maximum depth of 10 feet. PAR within the structure would experience a first-floor depth of about 2 feet and life
+loss would be unlikely. However, these types of discrepancies when aggregated throughout the leveed area can greatly impact the total estimated life
+loss.
+
+If evaluating a shelter-in-place alternative, it is important to relate high life loss structures to the corresponding maximum velocities. Refer to
+and, again, sort by ‘Life_Loss_Total_Mean.’ Compare maximum depths and velocities to each structure’s stability criteria (e.g., wood-anchored,
+masonry, and manufactured). If a structure collapses in over half of the iterations with relatively low depths and velocities, zoom to the structure
+like shown in and ensure that the stability criteria match the structure type. Refer to the and for additional
+ information regarding post-simulation structure inventory calibration.
+
+The SSSI road network was calibrated in a similar fashion. For more detailed coastal levee risk assessments, LifeSim can be used to estimate
+evacuation travel time or potential traffic chokepoints of mobilized PAR. shows the spatial distribution of
+estimated life loss on roads for the SSSI study.
+
+
+
+Refer to the for quality checking the road network after the initial simulation. Once the road network has been calibrated, look for roads with high
+mean life loss estimates in relation to the nearest destination points. For the SSSI study, destinations were placed inland just beyond the inundation
+ (see ). Life loss on roads occurs mostly on smaller access roads located relatively close to the SSSI alignment; several vehicles are caught
+evacuating as they attempt to reach freeways and interstates that can handle more traffic on their way to destination points.
+
+### Applying Results to Risk Assessments
+
+Life loss estimates can vary greatly across warning alternatives (e.g., a standard hurricane warning of 24 hours prior to the event, an optimal
+hurricane warning of at least 3 days prior to the event, and a shelter-in-place scenario with a maximum mobilization rate of 0.) Depending on your
+project and your risk assessment, consider which warning scenarios most align with the expected forecasting and monitoring that would occur.
+Additionally, it’s possible that you will need to include additional warning alternatives to better understand potential life loss for various
+potential failure modes.
+
+Refer to the for additional information on performing quality control checks of LifeSim results.
+
+Following any edits made during the quality control check, rerun all simulations. Once you confirm the new life loss and economic
+results, your coastal levee or floodwall LifeSim model is complete.
+
+(Page intentionally left blank)
+
+
\ No newline at end of file
diff --git a/docs/desktop-applications/lifesim/applications-guide/v1.0/08-estimating-life-loss-in-planning-comparing-alternatives-for-riverine-coastal-flooding.mdx b/docs/desktop-applications/lifesim/applications-guide/v1.0/08-estimating-life-loss-in-planning-comparing-alternatives-for-riverine-coastal-flooding.mdx
new file mode 100644
index 000000000..27922f536
--- /dev/null
+++ b/docs/desktop-applications/lifesim/applications-guide/v1.0/08-estimating-life-loss-in-planning-comparing-alternatives-for-riverine-coastal-flooding.mdx
@@ -0,0 +1,359 @@
+---
+title: "Estimating Life Loss in Planning: Comparing Alternatives for Riverine & Coastal Flooding"
+---
+
+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 TableVertical from "@site/src/components/TableVertical";
+import Figure from "@site/src/components/Figure";
+import TableReference from "@site/src/components/TableReference";
+
+
+
+# Estimating Life Loss in Planning: Comparing Alternatives for Riverine & Coastal Flooding
+
+## Purpose
+
+This example demonstrates the process for estimating consequences and comparing expected life loss across alternatives for planning studies in
+LifeSim. This chapter focuses on the Ala Wai Flood Risk Management General Investigations Study, which is an ongoing Planning study in the U.S. Army
+Corps of Engineers (USACE) Honolulu District. The LifeSim model was completed in 2023 by the USACE Omaha District. The Ala Wai LifeSim model compares
+life loss results across four different alternatives. Notably, there is no existing infrastructure in the study area.
+
+For each of the alternatives, the eight flow-frequency events used in the study’s other flood risk management model were imported into LifeSim. The
+alternatives included the Future Without-Project (FWOP) condition and three structural alternatives. The structural alternatives’ hydraulic scenarios
+represent the Future With-Project (FWP) and do not include breaches in the proposed flood protection infrastructure.
+
+Reference USACE’s , , and for more information on including life loss estimates in USACE planning studies.
+
+This LifeSim model was built prior to the Tentatively Selected Plan (TSP) milestone to compare the change in expected life loss and how flood risk
+changes. Eventually incremental risk of the TSP will need to be understood, but this phase of the planning study focuses on changes in flood risk
+across the final array of alternatives.
+
+This chapter includes instructions for importing the required data into LifeSim, how to choose appropriate warning and evacuation data for a study
+area, and how to interpret modeling results. Additional considerations for LifeSim modeling for planning studies are identified throughout the
+chapter.
+
+## Input Data
+
+The subsequent sections discuss the input data required to calculate damages and life loss across various alternatives for planning studies. The input
+ data sections include hydraulic data, emergency planning zones (EPZ), structure inventories, road networks, destinations, creating alternatives, and
+simulating alternatives.
+
+### Hydraulic Data
+
+The Ala Wai LifeSim model utilized output from the Hydrologic Engineering Center’s River Analysis System (HEC-RAS). Ideally, the HEC-RAS inputs should
+ be in the form of Hierarchical Data Format (HDF) files so the user can easily simulate evacuation in LifeSim. However, summary grids or other output from
+ other hydraulic models could be utilized in LifeSim (reference the and ). For planning studies, simulating evacuation can help address other
+planning objectives or opportunities, such as improving emergency action planning and identifying safe evacuation routes. Including evacuation more
+accurately captures potential life loss in structures and life loss on roads. The HEC-RAS plan HDF file and the HEC-RAS terrain HDF file (and terrain
+TIF files) are needed for each hydraulic scenario. Reference the for step-by-step instructions on importing hydraulic data from HEC-RAS.
+
+It is recommended to include all the hydraulic events used in the economic modeling (most likely 8 different flow-frequency events) in the LifeSim
+model. Similar to the economic damage modeling typically completed in HEC-FDA, it is critical to understand the potential life loss for events of varying
+ frequency and magnitude. Eventually, the life loss ranges computed in LifeSim will be used to estimate Expected Annual Life Loss (EALL), similar to
+how Expected Annual Damages are computed, either in a spreadsheet or a tool like TotalRisk 1.0 (link to TotalRisk here). The more events included in
+the EALL calculation in TotalRisk, the more accurate the EALL is. The resulting EALL is another metric by which planning alternatives can be compared.
+ Refer to the TotalRisk Application Guide to set up the EALL calculation (link to TR app guide here)
+
+Below are some of the hydraulic events included in the Ala Wai LifeSim model (FWOP, Alternative 2B, and Alternative A5). As shown in the figure, the
+0.5 Annual Exceedance Probability (AEP), 0.2 AEP, 0.1 AEP, 0.05 AEP, 0.02 AEP, 0.01 AEP, 0.005 AEP, and 0.002 AEP events are included for each
+alternative.
+
+
+
+#### Other Considerations for Hydraulic Data
+
+For the Ala Wai study area, there are multiple flood sources that flood various areas at different times. It is important to understand the various
+timings involved in the flooding when selecting the Hazard Occurrence time. Be consistent in where you select the hydrograph (i.e., For all hydraulic
+scenarios, the Hazard Occurrence time represents when out-of-bank flooding begins for the same flood source). Separating your EPZ is further discussed
+ in the Emergency Planning Zones section below.
+
+### Emergency Planning Zones
+
+If your planning study includes levees, coastal structures, and/or dams, reference the EPZ Section in the other Application Guide chapters. For
+planning studies, the EPZ shapefile should represent the entire study area. Coordinate with other Project Delivery Team members, especially the
+hydraulic engineer and lead planner to ensure your EPZ matches the study area. The LifeSim model should account for the same flooding and structures
+as other economic models used in the study, such as Hydraulic Engineering Centers’ Flood Damage Reduction Analysis (HEC-FDA) or Generation II Coastal
+Risk Model (G2CRM).
+
+Otherwise, the shapefile used for the EPZ should represent the entire study area. Coordinate with other Project Delivery Team members, especially the
+hydraulic engineer and lead planner to ensure your EPZ matches the study area. The LifeSim model should account for the same flooding and structures
+as other economic models used in the study, such as Hydraulic Engineering Centers’ Flood Damage Reduction Analysis (HEC-FDA) or Generation II Coastal
+Risk Model (G2CRM).
+
+Refer to the for examples of what to consider when assigning warning and evacuation parameters in your EPZ(s).
+
+#### Delineating EPZs
+
+As mentioned in the Hydraulic Data section, oftentimes there are various flooding sources in planning studies. The various flooding sources may flood
+different areas and the flooding may begin at different times. Therefore, each of these areas would have differing hazard occurrence times (i.e.,
+flooding begins at different times in various parts of the study area.) In LifeSim, each hydraulic scenario can technically only have one Hazard
+Occurrence time identified in the Hydraulic Data. However, you can account for various Hazard Occurrence times in the EPZs. By delineating the EPZs
+based on flood timing/flood sources, you can warn various areas relative to when specific hazards occur. It is recommended to work with the Project
+Delivery Team’s (PDT) hydraulic engineer to better understand the flooding sources and flooding timing across the study area (see the for additional
+information).
+
+##### Ala Wai EPZs
+
+In the Ala Wai Planning Study there are several flood sources including tidal surge, riverine flooding from the Mānoa Stream, Makiki Stream, Palolo
+Streams, and flooding along the Mānoa-Palolo and Ala Wai Canals. Following an analysis of the hydraulic timing and flow, the EPZ was delineated into 4
+ zones (see ). This decision was made by both the LifeSim modeler and the PDT’s hydraulic engineer. The delineation of EPZs is critical for study
+areas with various flood timings and/or flood sources. Delineating EPZs is the best way to model various warning times for various impact areas and
+should generally be done with the team’s hydraulic engineer.
+
+As shown in the figure below, there are 4 EPZs in the Ala Wai LifeSim model; this EPZ polygon is used for all hydraulic scenarios, including both FWOP
+ and FWP conditions. They are divided by flood source and hydraulic timing:
+
+The main flood source in EPZ 1 is the Makiki Stream
+
+The main flood source in EPZ 2 is tidal surge
+
+The main flood source in EPZ 3 is the Mānoa Stream
+
+The main flood source in EPZ 4 is the Palolo Streams
+
+The difference in hydraulic timing between the four EPZs is generally less than an hour, which may not seem like a large difference, but the flooding
+in the study area is quite flashy. Advanced forecasting and early warning are unlikely. The life loss estimates are highly sensitive to the hazard
+identification time (i.e., early hazard identification is correlated with lower life loss and late hazard identification is correlated with higher
+life loss), which is why delineating the EPZs for Ala Wai based on flood source and flood timing is important. The warning times for each EPZ are
+discussed more in the section below.
+
+
+
+#### Importing an Emergency Planning Zone
+
+Refer to the and/or the for information on importing EPZs into LifeSim.
+
+### Structure Inventory
+
+To use LifeSim to calculate life loss and/or economic damages, a structure inventory needs to be imported into the study. LifeSim will not compute if
+any structure points are located outside of the EPZ.
+
+#### Importing a Structure Inventory
+
+Refer to the and the for information on importing a structure inventory into LifeSim and editing it.
+
+### Simulating Evacuation
+
+Refer to the for how to simulate evacuation. The Simulating Evacuation section covers (1) importing and editing the road network and (2) creating, importing,
+ and editing the destinations.
+
+### Creating Alternatives
+
+Refer to the , the , and/or the for how to create alternatives.
+
+#### Ala Wai EPZ Imminent Hazard Identification Times
+
+As discussed in the Ala Wai EPZ section, the LifeSim model utilized 4 different EPZs—all with unique hazard occurrence times (i.e., flooding begins at
+ different times in each zone) in the alternatives. Since only one hazard occurrence time can be identified for each hydraulic scenario, you need to
+utilize various imminent hazard identification times for each zone while creating alternatives.
+
+To find the various zones’ hazard occurrence times, add your EPZ polygon to the RAS Map Data Selector Map Window. Then, find each zone’s hazard
+occurrence times by finding where/when flooding first begins in each EPZ. Then, identify which EPZ’s hazard occurrence time will be the hydraulic
+scenario’s hazard occurrence time identified in the hydraulic data. For Ala Wai, EPZ 1 (shown in the following figure) was selected as the “control”
+hazard occurrence time for every hydraulic scenario, which means the imminent hazard ID times for EPZs 2, 3, and 4 were relative to EPZ 1’s hazard
+occurrence time. The figure below shows the hazard occurrence times for each EPZ and each event for Alternative 2B; the figure also shows where the
+Hydrograph Tool pulled the hazard occurrence times for each EPZ (red circles in the figure below).
+
+
+
+ below highlights the various hazard occurrence times in each EPZ for Alternative 2B for the 0.02 AEP, 0.05 AEP,
+and 0.01 AEP events. highlights the calculated imminent hazard identification times.
+
+For the 0.02 AEP and 0.05 AEP events in EPZ 1, a relatively small amount of warning time was given to the public; a uniform distribution of -2 to 0
+hours was used. For the 0.01 AEP event in EPZ 1, the warning time distribution was expanded to potentially give the population more warning; -4 to 0
+hours was used. The same amount of warning time was used for all zones, but zones 2 through 4 were warned relative to EPZ 1’s hazard occurrence time.
+
+For example, for the 0.05 AEP event, EPZ 2’s hazard occurrence time occurs 1.83 hours prior to EPZ 1’s hazard occurrence time. This indicates
+ that EPZ 2 needs to be warned 1.83 hours earlier than EPZ 1. The final Imminent Hazard Identification Times (i.e., warning times) used in
+the alternatives reflect the difference in hazard occurrence times to ensure each EPZ receives the same amount of warning relative to each zone’s
+unique hazard.
+
+:::danger
+This table contains cells that span multiple rows or columns. Manually update the React component to properly format the table.
+:::
+
+
+
+:::danger
+This table contains cells that span multiple rows or columns. Manually update the React component to properly format the table.
+:::
+
+
+
+### Creating Simulations
+
+Refer to the for creating simulations, selecting the appropriate options, and running simulations.
+
+## Understanding and Interpreting Results
+
+After running simulations, you can view your results in various ways, including by result plots, result tables, and result maps. Each way you view
+results helps understand your life loss and economic damage results and quality check your results. It is unlikely that your first simulation will be
+your last simulation—edits to the structure inventory, EPZs, road network and/or destination points are frequently needed to obtain accurate and
+representative results.
+
+Refer to the , the , and/or the for understanding results and finalizing the LifeSim model.
+
+LifeSim utilizes an event-based approach, so there is no annualization across the various flow-frequency events. Use a tool like TotalRisk 1.0 or
+another certified annualization tool to produce expected annual life loss values for each alternative.
+
+(Page intentionally left blank)
+
+
\ No newline at end of file
diff --git a/docs/desktop-applications/lifesim/applications-guide/v1.0/09-estimating-direct-economic-damages.mdx b/docs/desktop-applications/lifesim/applications-guide/v1.0/09-estimating-direct-economic-damages.mdx
new file mode 100644
index 000000000..32556b973
--- /dev/null
+++ b/docs/desktop-applications/lifesim/applications-guide/v1.0/09-estimating-direct-economic-damages.mdx
@@ -0,0 +1,276 @@
+---
+title: "Estimating Direct Economic Damages"
+---
+
+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 Figure from "@site/src/components/Figure";
+import FigureInline from "@site/src/components/FigureInline";
+import FigReference from "@site/src/components/FigureReference";
+
+
+
+# Estimating Direct Economic Damages
+
+## Purpose
+
+This example demonstrates the process for estimating economic consequences in LifeSim. This chapter applies to dam and levee safety, planning studies,
+ and other analyses that focus on economic consequences. This chapter focuses on the Ala Wai Flood Risk Management General Investigations Study, which
+ is an ongoing Planning study in the U.S. Army Corps of Engineers Honolulu District. The LifeSim model was modeled in 2023 by the USACE Omaha
+District. The Ala Wai LifeSim model compares economic damage results across four different alternatives.
+
+For each of the alternatives, the eight flow-frequency events used in the study’s economic damage modeling were imported into LifeSim. The
+alternatives included the Future Without-Project (FWOP) condition and three structural alternatives. The structural alternatives’ hydraulic scenarios
+utilized in LifeSim represent the Future With-Project (FWP) and do not include breaches in the proposed flood protection infrastructure.
+
+This chapter includes instructions on importing the required data into LifeSim, how to edit structures and occupancy types, and how to interpret
+modeling results. Additional considerations for LifeSim modeling for planning studies are identified throughout the chapter.
+
+## Input Data
+
+The subsequent sections discuss the input data required to calculate direct economic damages across various alternatives for planning studies. The
+input data sections include hydraulic data, structure inventories, creating alternatives, and simulating alternatives. The structure inventory section
+ includes significant detail on editing and creating structure occupancy types in LifeSim.
+
+### Hydraulic Data
+
+The Ala Wai LifeSim model utilized output from the Hydrologic Engineering Center’s River Analysis System (HEC-RAS). Ideally, the HEC-RAS inputs should
+ be in the form of Hierarchical Data Format (HDF) to streamline the process; this is the easiest way to calculate both direct economic damages and
+life loss in one LifeSim model. However, summary grids (Reference the ), and other hydraulic models could be utilized in LifeSim (reference the and
+). The HEC-RAS plan HDF file and the HEC-RAS terrain HDF file are needed for each hydraulic scenario. Reference the for step-by-step instructions on importing
+ hydraulic data from HEC-RAS.
+
+It is recommended to include several hydraulic events (greater than 6 different flow-frequency events) in the LifeSim model. Eventually, the life loss
+ estimates will be used to estimate Expected Annual Damages (EAD) in a tool like TotalRisk 1.0, and the more hydraulic events included in that
+calculation, the more accurate the EAD is. Below are some of the hydraulic events included in the Ala Wai LifeSim model (for the FWOP, Alternative 2B,
+ and Alternative A5). As shown in the figure, the 0.5 Annual Exceedance Probability (AEP), 0.2 AEP, 0.1 AEP, 0.05 AEP, 0.02 AEP, 0.01 AEP, 0.005 AEP,
+and 0.002 AEP events are included for each alternative.
+
+
+
+### Emergency Planning Zones
+
+For calculating only economic damages, an emergency planning zone (EPZ) is not required in the LifeSim model.
+
+### Structure Inventory
+
+To calculate economic damages in LifeSim, a structure inventory needs to be imported into the study. There are key additionall things to consider and
+edit in the structure inventory to accurately calculate economic damages. The follow sections focus on viewing, editing, and creating occupancy types.
+ For information on importing a structure inventory, refer to the and .
+
+#### Creating and Editing Occupancy Types
+
+When estimating direct economic damages in LifeSim, additional edits to the structure inventory and occupancy types may be needed to allow for more
+uncertainty in the economic damage computation. The following sections describe the editable aspects of occupancy types in LifeSim, including the
+Depth-Damage Functions (Structure, Content, and Vehicle), Foundation Height Offset, Value Uncertainty (Structure, Content, and Vehicle), Evacuation
+Parameters, and Submergence Criteria. Additionally, you can create new occupancy types (
+{"\n"}), copy occupancy types (
+{"\n"}), and delete occupancy
+types ().
+
+To view, edit, and create occupancy types, right click on Occupancy Types under Structure Inventories in the Study
+Pane. Select Edit Occupancy Type Data from the options.
+
+
+
+The Occupancy Type Editor window opens (shown in the figure below) and displays the various attributes associated with the selected occupancy type.
+The figure below shows the RES1-1SNB (Residential Structure with 1-Story, No Basement) occupancy type.
+
+
+
+##### Occupancy Type Depth-Damage Function Uncertainty
+
+Notably, most of the default structure occupancy types do not include uncertainty in the depth-damage function. The only occupancy types that include
+uncertainty are the RES1 occupancy types (as seen in the figure above). The RES1 depth-damage functions (structure and content) are the default
+depth-damage functions defined in Economic Guidance Memorandum (EGM) 04-01. All commercial, public, industrial, and the other residential occupancy
+types (e.g., manufactured homes, apartment buildings, etc.) do not have uncertainty in the depth-damage functions. However, all existing occupancy
+types can be edited to include uncertainty and new occupancy types can be added by the user.
+
+This example will step through adding uncertainty to the existing EDU1 occupancy type. shows the default
+occupancy type for an educational structure with 1-story (EDU1). Although the default depth-damage functions for EDU1 do not include uncertainty, an
+uncertainty distribution can be defined by the user for each of the depth-damage functions (Structure, Content, and Vehicle).
+
+
+
+ shows the variety of uncertainty distributions for the depth-damage functions. You can choose from a triangular,
+uniform, normal, and lognormal distribution.
+
+
+
+ shows an example of a uniform distribution (minimum % damage and maximum % damage). As shown in the function
+plot, there is more uncertainty included in shallower flood depths (the 0ft to 10ft range), with less uncertainty included in the higher depths. It’s
+recommended to coordinate with other economists, your reviewers, and/or technical experts on representative uncertainty in the depth-damage functions.
+ Alternatively, you could utilize other developed depth-damage functions (e.g., from other Corps studies, FEMA curves, or other published depth-damage
+ functions) and enter the values into LifeSim.
+
+
+
+#### Variation in Structure Values
+
+In addition to including an uncertainty distribution to the depth-damage function, uncertainty can be added to the values of each of the damage
+categories (Structure, Damage, and Vehicle). As shown in the figure below, you can select the Uncertainty Type for the Structure Value. Note the variation
+ is a percentage, not a dollar value. This variation percentage will be applied to each structure with the same occupancy type.
+
+
+
+
+
+In this example, the user wants to include uncertainty regarding the structure values of all EDU1 structures. A triangular distribution is selected,
+and the uncertainty distribution is as follows: -15% as the lower bounds, 0% (no change) as the most likely, and 20% as the upper bounds. For
+example, if an EDU1 structure has a defined structure value of $100K, the structure value will be randomly sampled between $85K and $120K—with $100K
+being the most likely sampled value. This triangular uncertainty distribution is applied to all EDU1 structure values.
+
+
+
+#### Foundation Height Offset Uncertainty
+
+The final uncertainty parameter that can be defined at the occupancy type level is the Foundation Height Offset. Similar to the Variation in Structure
+ Value uncertainty, you can choose a triangular, normal, or uniform uncertainty distribution (shown in ).
+Notably, the defined uncertainty bounds are based on feet, not a percentage of the foundation height. The example uniform distribution below is a
+range of -1ft to 1.5ft, which indicates the defined foundation height for each EDU1 structure will sample that offset relative to the defined
+foundation height. For example, if an EDU1 structure has a defined foundation height of 2ft, in each iteration, the foundation height would be sampled
+ as a number between 1ft and 3.5ft. The uncertainty distribution should be informed by either a foundation height sample or by information from real
+estate. Justification of the selected distribution and uncertainty bounds needs to be included in any documentation.
+
+
+
+
+
+An additional consideration: If there are several variations in a single occupancy type, the user may want to create copies of that same occupancy
+type, with each having the variable attribute(s) defined . For example, you may need multiple occupancy types for schools. If you have sampled
+foundation heights for EDU1 buildings built on slab and sampled foundation heights for EDU1 buildings with basements, this may prompt the user to
+create two EDU1 occupancy types (e.g., EDU1-SLAB and EDU1-WithBSNT) to accurately account for the two foundation height samples and include two
+different depth-damage functions (i.e., the EDU1-WithBSNT would incur damage at lower flood depths).
+
+### Creating Alternatives
+
+After editing your occupancy types and structure inventory, you will create alternatives for each scenario for which you want to calculate economic
+damages. For computing only economic damages, relatively simple alternatives are required. As shown in below,
+you only need to link the structure inventory and correct hydraulic scenario in the Alternative Editor window. Ensure both the Simulate Traffic and
+Calculate Life Loss boxes are unchecked.
+
+
+
+### Creating Simulations
+
+Refer to the for creating simulations, selecting the appropriate options, and running simulations. An additional consideration for estimating direct
+economic damages is selecting an appropriate Output Summary Polygon. Similar to how HEC-FDA requires a delineation of reaches to accurately account
+for uncertainty in the hydraulic data, this should be a consideration in calculating economic damages in LifeSim—especially if the user is going to
+use TotalRisk following the LifeSim modeling. The damage reaches polygon should be incorporated into the Simulations by selecting it as the Output
+Summary Polygon.
+
+#### Delineating Reaches
+
+As stated in , delineating damage reaches is part of the overall study strategy and is an integral part of computing expected annual damages. This is
+a step that the user must consider and it is highly recommended to coordinate with the team’s hydraulic engineer. There are several factors to
+consider when delineating damage reaches including, but not limited to, the following:
+
+Existing levees and proposed levees (i.e., existing and proposed levees should have separate damage reaches)
+
+Flooding sources (i.e., coastal, streams, rivers, etc.)
+
+Flooding characteristics (i.e., higher depths vs shallow depths; fast velocities vs slow velocities)
+
+Population centers (i.e., urban vs rural areas)
+
+Inundation Boundaries (i.e., 0.04 Annual Exceedance Probability (AEP) floodplain and 0.01 AEP floodplain)
+
+ includes additional information on delineating damage reaches in Section 3.3. The TotalRisk application guide chapter xx discusses how to use the
+LifeSim results by damage reach to accurately incorporate hydraulic uncertainty by reach.
+
+#### Ala Wai Damage Reaches
+
+In the Ala Wai Planning Study there are several flood sources including tidal surge; riverine flooding from the Mānoa Stream, Makiki Stream, and the
+Palolo Streams; and flooding along the Mānoa-Palolo and Ala Wai Canals. The flooding sources alone indicate several damage reaches are needed for this
+ study. An additional consideration is if a reach represents the right bank, left bank, or both. The figure below shows each of the Ala Wai reaches
+and is color coded to show which bank(s) the reach includes. With all hydraulic, economic, engineering, and planning considerations, the study has a
+total of 13 damage reaches. The reaches shown in would then be used as your Summary Output Polygon in all
+LifeSim simulations, which allows LifeSim to show results by reach and can be easily used in TotalRisk to estimate expected annual damages (see
+TotalRisk Application Guide).
+
+
+
+
+
+## Understanding and Interpreting Results
+
+After running simulations, you can view your results in various ways, including by result plots, result tables, and result maps. Each way you view
+results is beneficial to understanding your economic damage results as well as conducting a quality check on your results. It is unlikely that your
+first simulation will be your last simulation—edits to the structure inventory are often needed to obtain accurate and representative results.
+Reference the for additional information on understanding and interpreting your results.
+
+The results provided by the LifeSim model are event-based and include uncertainty in the economic damages. However, hydraulic data uncertainty is not
+accounted for. To calculate Expected Annual Damages with uncertainty in the hydraulic data, a tool like TotalRisk 1.0 should be utilized. Reference
+the TotalRisk Applications Guide for more information; the Flood Risk Management Chapter uses the Ala Wai LifeSim results. This specific chapter of
+the TotalRisk Applications Guide discusses how to interpret Expected Annual Damage when using LifeSim economic damage results.
+
+(Page intentionally left blank)
+
+
\ No newline at end of file
diff --git a/docs/desktop-applications/lifesim/applications-guide/v1.0/10-using-summary-grids-in-lifesim.mdx b/docs/desktop-applications/lifesim/applications-guide/v1.0/10-using-summary-grids-in-lifesim.mdx
new file mode 100644
index 000000000..540be5672
--- /dev/null
+++ b/docs/desktop-applications/lifesim/applications-guide/v1.0/10-using-summary-grids-in-lifesim.mdx
@@ -0,0 +1,239 @@
+---
+title: "Using Summary Grids in LifeSim"
+---
+
+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 TableVertical from "@site/src/components/TableVertical";
+import Figure from "@site/src/components/Figure";
+import FigureInline from "@site/src/components/FigureInline";
+import FigReference from "@site/src/components/FigureReference";
+
+
+
+# Using Summary Grids in LifeSim
+
+## Purpose
+
+This chapter demonstrates the process of using summary grids in LifeSim. Importing summary grids allows LifeSim to bypass the need to calculate, or
+pre-process, hydraulic characteristics. The necessary raster files are instead imported directly into the software. This chapter walks through an
+example using Clearwater Dam in Piedmont, MO (Little Rock District) and includes step-by-step instructions for importing the required data and making
+runs in LifeSim using summary grids where life loss was a necessary consideration. Additional information will be provided throughout the chapter for
+cases where only structural or agricultural damages are being considered.
+
+## Summary Grids Import Overview
+
+Summary grids can be created using post-processing tools for several different hydraulic modeling programs, not just Hydrologic Engineering Center’s
+River Analysis System (HEC-RAS). Therefore, this approach can be useful for many LifeSim users. Allowable file types include:
+
+.tif (tag image file format; an image format used for containing high quality graphics),
+
+.flt (floating-point grid; holds values for a single numeric measure, a value for each cell in the rectangular grid),
+
+ESRI Grid (format native to ESRI for storing raster data that defines geographic space as an array of equally sized square cells)
+
+.vrt (virtual format; use of this format is to group a series of grids that should be associated together)
+
+See the following table for an overview of hydraulic characteristics represented by different summary grids and their associated LifeSim computes.
+
+:::danger
+This table contains cells that span multiple rows or columns. Manually update the React component to properly format the table.
+:::
+
+
+
+Note that the maximum depth and maximum velocity grids do not account for hydraulic timing, they simply capture the maximum of the two metrics for any
+ grid cell over the span of the hydraulic simulation. The approach assumes depth and velocity reach their respective maximums at the same time--which
+is not always true--leading to more conservative sampling of the assumed stability criteria for structures in the same cell. If the user were to use
+hierarchal data files (.hdf), where the hydraulic output is broken out into specified timesteps, it is possible that depth and velocity for any given
+cell may not reach their maximums at the same time. It is likely, however, that differences in life loss due to structure stability outcomes between
+the two approaches will be minimal for most studies.
+
+## Importing Summary Grids for Clearwater Dam
+
+As shown in , to use summary grids in LifeSim for a consequences analysis where time and evacuation are being considered (i.e., for life loss
+computes), you will need a minimum of four summary grids – a maximum depth grid, a maximum velocity grid, an arrival time grid with a depth threshold
+ of zero feet (i.e., the first arrival of water), and an arrival time grid with an assumed depth threshold that no longer allows for evacuation (i.e.,
+ a non-evacuation depth).
+
+To start the import process, first right-click on Hydraulic Data in the study pane and select Import from Summary
+Grids, as shown in the following figure.
+
+
+
+The following pop-up window will appear.
+
+
+
+A maximum depth grid (the first input in ) represents the maximum that occurs in each grid cell over the course
+of a hydraulic simulation. Like maximum depth, maximum velocity and maximum D*V represent the greatest velocity and instantaneous D*V that occurred in
+ each grid cell. Maximum D*V is an important variable for stability criteria. More detailed discussion on this topic can be found in Section 4.3 of
+the . As previously mentioned, because the maximum depth, maximum velocity, and maximum D*V grids are not time dependent, LifeSim cannot simulate
+evacuation on roads when utilizing only this style of hydraulic data.
+
+From the Import from Summary Grids window, map to the project’s grids by clicking on the button with the three dots (
+{"\n"}) next to the
+Maximum Depth Grid (Required) line. The file directory selected should contain one of the file formats outlined in the Summary Grids
+Import Overview section (e.g., .tif, .flt, .vrt,) earlier in the chapter. Repeat this process for the Maximum Velocity Grid, a
+required import for life loss estimation. See to view these completed steps for the Clearwater Dam Maximum High
+Pool (MHP) breach scenario. Note: When multiple .tif files are used to make up a larger area, a .vrt must be used in LifeSim unless
+the user is only interested in a smaller subsection of the study area made up of only the single .tif.
+
+
+
+The next required input is the Non-Evacuation Arrival Grid. 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. In
+the Clearwater Dam example, a non-evacuation depth of two feet (this is the standard for USACE) was used in the LifeSim model.
+
+The last required summary grid input for life loss calculations is the First-Inundated Arrival Grid (i.e., the first arrival of
+water, or an arrival grid with a flood depth threshold of zero). shows the selection of all four grids. Note:
+Set the Arrival Time Units to match specified output from the post-processing tools. In the case of Clearwater dam, grids were
+generated using hour-long timesteps.
+
+
+
+
+
+For agricultural computations, duration grids are required to determine damage to crops and replanting potential. Duration grids contain information
+about the duration of time that a cell is inundated. Agricultural damage was not considered for Clearwater Dam.
+
+Before clicking OK and completing the import for the first hydraulic scenario, the user must define the hydrograph.
+{"\n"} below shows this section of the Import from Summary Grids window.
+
+
+
+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 inputs interact with other model inputs (i.e., structure inventory) and
+subsequently leads to consequences. When importing from HEC-RAS, as described in the dam and levee application chapters, the first hydraulic timestep
+will automatically populate. When importing from grids or summary grids, however, the user must define the First Hydraulic Timestep
+field shown in . This value can be found in the hydraulic model.
+
+
+
+The user must also define the hazard occurrence time, as is the case when importing from HEC-RAS. See either the dam and levee application chapters or
+ Section 5.4 of the for a more detailed discussion on hazard occurrence. below shows an example graph demonstrating the hazard occurrence time in
+terms of a downstream flood hydrograph.
+
+
+
+The hydrograph, or the visual representation of the hydrograph, in the Import from Summary Grids window will have no impact on the
+LifeSim calculations. (Note: The hazard occurrence time must be set correctly and will directly impact LifeSim calculations.) A rough
+ hydrograph must be loosely defined for LifeSim to accept the inputs. This can be achieved by simply creating a second row in the hydrograph table,
+specifying a time later in the hydraulic simulation, and adding a value higher than zero as defined in the initial timestep. See
+{"\n"} for reference. Again, this artificial hydrograph will not impact the software’s calculations.
+
+Note that unless a more realistic hydrograph can be defined using output from the original hydraulic model, the artificially defined hydrograph (like
+that in ) cannot be used as visual representation of the model output.
+
+Repeat the above steps for each hydraulic scenario. shows a LifeSim study pane with all imported hydraulic
+scenarios for the Clearwater dam study.
+
+
+
+The remaining model inputs will follow the instructions of the or . Refer to these chapters for information on importing structure inventories,
+emergency planning zones (EPZs), creating alternatives and simulations, and understanding your results.
+
+
+
+(Page intentionally left blank)
+
+
\ No newline at end of file
diff --git a/docs/desktop-applications/rmc-bestfit/users-guide/v1.0/04-working-with-rmc-bestfit.mdx b/docs/desktop-applications/rmc-bestfit/users-guide/v1.0/04-working-with-rmc-bestfit.mdx
index 9b55dfb18..0c7541945 100644
--- a/docs/desktop-applications/rmc-bestfit/users-guide/v1.0/04-working-with-rmc-bestfit.mdx
+++ b/docs/desktop-applications/rmc-bestfit/users-guide/v1.0/04-working-with-rmc-bestfit.mdx
@@ -300,6 +300,8 @@ calculated and the data is plotted in the **Chronology** and **Frequency** plot
'2016',
'2017',
'2018',
+ '-',
+ '-',
],
[
'30,122',
@@ -331,6 +333,8 @@ calculated and the data is plotted in the **Chronology** and **Frequency** plot
'55,982',
'34,585',
'48,324',
+ '-',
+ '-',
],
]}
fullWidth={false}
diff --git a/docs/desktop-applications/rmc-rfa/users-guide/v1.0/01-preface.mdx b/docs/desktop-applications/rmc-rfa/users-guide/v1.0/01-preface.mdx
index dd2cd9310..5237e643f 100644
--- a/docs/desktop-applications/rmc-rfa/users-guide/v1.0/01-preface.mdx
+++ b/docs/desktop-applications/rmc-rfa/users-guide/v1.0/01-preface.mdx
@@ -24,9 +24,11 @@ platform, including a graphical user interface, data entry capabilities, statist
models, stochastic simulation, and results reporting tools. To request a free copy of the software, provide future suggestions,
report errors, or request additional information, please contact the developer at:
-Haden Smith, P.E.
-USACE Risk Management Center
-12596 W. Bayaud Ave Suite 400
-Email: [Cole.H.Smith@usace.army.mil](mailto:Cole.H.Smith@usace.army.mil)
-Phone: 303-963-4575
+Haden Smith, P.E.
+USACE Risk Management Center
+12596 W. Bayaud Ave, Suite 400
+Lakewood, CO 80228
+**Email:** [Cole.H.Smith@usace.army.mil](mailto:Cole.H.Smith@usace.army.mil)
+**Phone:** 303-963-4575
+
diff --git a/docx_converter/main.py b/docx_converter/main.py
index 914e100b4..5a45af236 100644
--- a/docx_converter/main.py
+++ b/docx_converter/main.py
@@ -16,14 +16,14 @@
# ---- Environment Setting ----
# Set to "development" for testing (outputs to temporary location)
# Set to "production" for final conversion (outputs directly to docs/ and static/)
-environment = "development" # ALWAYS start with "development" to test first!
+environment = "production" # ALWAYS start with "development" to test first!
# ---- Figure Path Configuration ----
# FIGSRC: File path used in component src attributes in the generated MDX files.
# 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/toolbox-technical-manuals/internal-erosion-suite/pipe-service-life/v1.0"
+FIGSRC = r"figures/desktop-applications/lifesim/applications-guide/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"/toolbox-technical-manuals/internal-erosion-suite/pipe-service-life"
-NAVTITLE = "Internal Erosion Suite"
-NAVDOC = r"toolbox-technical-manuals/internal-erosion-suite/pipe-service-life"
+NAVLINK = r"/desktop-applications/lifesim/applications-guide"
+NAVTITLE = "Applications Guide"
+NAVDOC = r"desktop-applications/lifesim/applications-guide"
# ---- 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:\Technical Documents\RMC-CPD-2023-11 - RMC Pipe Service Life Toolbox.docx"
+ 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"
# BIB_PATH: Full path to the bib.json bibliography file
- BIB_PATH = r"C:\Git\RMC-Software-Documentation\static\bibliographies\toolbox-technical-manuals\internal-erosion-suite\pipe-service-life\v1.0\bib.json"
+ BIB_PATH = r"C:\Karen\Repositories\RMC-Software-Documentation\static\bibliographies\desktop-applications\lifesim\applications-guide\v1.0\bib.json"
# FIGURES_DIR: Directory where extracted figures will be saved
- FIGURES_DIR = r"C:\Git\RMC-Software-Documentation\static\figures\toolbox-technical-manuals\internal-erosion-suite\pipe-service-life\v1.0"
+ FIGURES_DIR = r"C:\Karen\Repositories\RMC-Software-Documentation\static\figures\desktop-applications\lifesim\applications-guide\v1.0"
# MDX_DIR: Directory where generated MDX files will be saved
- MDX_DIR = r"C:\Git\RMC-Software-Documentation\docs\toolbox-technical-manuals\internal-erosion-suite\pipe-service-life\v1.0"
+ MDX_DIR = r"C:\Karen\Repositories\RMC-Software-Documentation\docs\desktop-applications\lifesim\applications-guide\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:\Technical Documents\RMC-CPD-2023-11 - RMC Pipe Service Life Toolbox.docx"
+ 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"
# BIB_PATH: Full path to the bib.json bibliography file (typically same as production)
- BIB_PATH = r"C:\Git\RMC-Software-Documentation\static\bibliographies\toolbox-technical-manuals\internal-erosion-suite\pipe-service-life\v1.0\bib.json"
+ BIB_PATH = r"C:\Karen\Repositories\RMC-Software-Documentation\static\bibliographies\desktop-applications\lifesim\applications-guide\v1.0\bib.json"
# FIGURES_DIR: Temporary directory for testing extracted figures
- FIGURES_DIR = r"C:\Technical Documents\MDX Conversions\Pipe Service Life\Figures"
+ FIGURES_DIR = r"C:\ExampleFolder\Example_Project_1\Figures"
# MDX_DIR: Temporary directory for testing generated MDX files
- MDX_DIR = r"C:\Technical Documents\MDX Conversions\Pipe Service Life\MDX"
+ MDX_DIR = r"C:\ExampleFolder\Example_Project_1\MDX"
# ---- Constants ----
DOCX_PATH = DOCX_PATH
diff --git a/src/components/ContentBubble.js b/src/components/ContentBubble.js
index 5141b4a30..47c0f6dd3 100644
--- a/src/components/ContentBubble.js
+++ b/src/components/ContentBubble.js
@@ -46,9 +46,9 @@ const ContentBubble = ({ icon, iconLight, iconDark, IconComponent, doc_location,
{doc_name}
{comingSoon && (
-