A coordinated repair routing problem for post-disaster recovery of interdependent infrastructure networks

Abstract

Disasters may cause significant damages and long-lasting failures in lifeline infrastructure networks (such as gas, power and water), which must be recovered quickly to resume providing essential services to the affected communities. While making repair plans, it is important to consider the interdependencies among network components to minimize recovery times. In this paper, we focus on post-disaster repair operations of multiple interdependent lifeline networks, which involve functional dependencies. We assume that each network component, whether damaged or not, becomes nonfunctional if it depends on another nonfunctional component, and it is recovered when all components that it depends on become functional. We introduce a post-disaster coordinated infrastructure repair routing problem, in which dedicated repair teams of each lifeline infrastructure travel through a road network to visit the sites with damaged network components. We present a mixed integer programming model that assigns repair teams to the sites and constructs routes for each team in order to minimize the sum of the recovery times for all network components. We develop a constructive heuristic and a simulated annealing algorithm to solve the proposed coordinated routing problem. We test the performance of the proposed solution algorithms on a set of instances that are developed based on two interdependent lifeline networks (e.g., power and gas). The computational results show that our heuristics can quickly find high-quality solutions. Our results also indicate that coordinating repair operations can significantly improve the overall recovery time of interdependent infrastructure networks.

Appendices

Appendix A: Interdependency parameters

We provide the interdependency parameters for the illustrative example presented in Sect. 3.1.4 below (Table 11).

Table 11 Interdependency parameters ($d_{ij}$ values) for the network in the illustrative example

Appendix B: The instance generator

We briefly introduce our Instance Generator, which is a dashboard developed by using R programming language. This dashboard allows us to generate IIRRP test instances that involve two interdependent infrastructure networks systematically. The source code for the dashboard in R is available upon request from the researchers.

The dashboard, which is shown in Fig. 4, generates the input files for the IIRRP model and the SA heuristic. Additionally, it visualizes the generated infrastructure network as in Fig. 2a). The dashboard accepts a single input file (network_input.txt in the figure), which lists the coordinates of the depots and sites involving the infrastructure nodes in the network. All other parameter levels are set through the dashboard. Based on the selected parameter levels, the input data are automatically generated as described in Sect. 5.1.

Fig. 4

Instance generator

Appendix C: Results: effects of cooling parameter

In our computational experiments, we use a geometric cooling schedule and present results obtained with $\alpha =0.90$. We test the performance of the proposed $SA_2$ algorithm by using alternative cooling parameters. Here we present results obtained by $\alpha =0.85$ and $\alpha =0.95$. Table 12 shows the percentage gap between solutions obtained by $SA_2$ and CPLEX for 16 small instances (i.e., Set 1 instances), similar to Table 5.

For $\alpha =0.90$, it takes $SA_2$ 1,179 CPU seconds on average to solve these instances, which decreases to 739 when $\alpha =0.85$. However, we observe that solution performance worsens when we cool the temperature at a faster rate. For example, when $\alpha$ is reduced to 0.85, the average gap percentage with respect to CPLEX increases to 0.16% from 0.07%; furthermore, average $n_{best}$ decreases from 5.9 to 4.3. On the contrary, we observe that the performance is improved when $\alpha =0.95$; for example, average gap decreases to $-0.01$. However, we observe a significant increase in average CPU time (i.e., about 70%) when algorithm is cooled slower. These results show the trade-off between the solution quality and time. Decision makers can choose a proper cooling rate depending on the urgency of planning on the ground. In our experiments, we use $\alpha =0.90$ that balances solution quality and time.

Table 12 Comparison of $SA_2$ solutions with different cooling parameters and CPLEX solutions for small instances (Set 1)