Documentation for transient pore pressure model for predicting slope failure constrained by remote sensing data

The GSTP project objective is to de-risk an operational methodology for determining the probability of slope failure (quantified using the 'factor of safety' approach) from rain events by developing a remotely sensed, rainfall driven landslide model that can be used in slope failure management. Therefore, the goal of the project is to develop a technical system designed to progress the current science of predicting rain-induced natural slope failure. It uses the concept of creating ‘virtual models’ of the physical environment and its characteristics from space observations which is used as a digital twin, on which various rainfall scenarios can be run to simulate the landscape behaviour.

The purpose of this document is document software developed in work package 4. This work package involves development of the landslide model, dividing the work in three different tasks: evaluation of model performances against a test site monitored in-situ; evaluation of the model performances on the same site solely using remote-sensing data; comparison of the results of the two approaches.

WP 4 aims to evaluate the performance of using remote sensing data to detect and anticipate landslide activity. Simulating slope failure involves a very high degree of uncertainty. A common approach consists in modelling steady state pore pressure in response to a threshold rainfall event to generate static safety maps. An alternative approach is to simulate the transient pore pressure to consider the time-evolution of the effect of precipitation and soil water content on slope stability. Such a model is highly case-dependent and requires a significant amount of expensive and time-consuming in-situ monitoring of soil hydraulic, mechanical and hydrogeologic features. The aim of this code is to use an already-monitored site to apply the Iverson (2000) model and compare the performance of the model constrained with in-situ data with the model constrained with remote-sensing derived data. The following documentation proposes a protocol to run the model from the different data sets and how to visualise and explore the outputs. The core of the modelling code is written in C++ to ensure computational efficiency. The automation for multiple simulations and I/O management is written in python.

A number of parameters are required by model:

For a specific site, neither remote-sensed nor in-situ data would constrain discrete values for each parameters. We therefore run the model using a Monte Carlo sampling schemes on range of possible parameters. In the case of testing the model against in-situ data, ranges of parameters are determined by different mechanical and hydraulic tests. Calibration is achieved with field observation of ground motion. In the case of testing the model against remote-sensed constraints, the ranges of parameters are suggested from general ranges in the literature and calibrating failures are recorded from InSAR data that detect ground motion.

The main applicable output of the model is a factor of safety (FS) for a soil columns that determines when the slope is subjected to fail. This factor of safety is an absolute value defined by equation 18 in Iverson (2000). It suggests failure when the FS is ⇐ 1. This factor of safety is calculated for a given time and depth of the modelled soil column, driven by a rainfall time series.

The code has been developed within the open-source [LSDTopoTools]https://lsdtopotools.github.io/ research software suite. The deliverable has been packaged into a zip file with the final report and contains all the code required for running the analysis.

The C++ code requires compilation into an executable before use. This can be done with the GNU g++ compiler, installed in most UNIX and IOS distributions. The Analysis_driver folder in the root folder contains a make file that automates the compilation. Navigate to the directory where this make file in a terminal window and compile with:

It generates an executable file named iverson_model.exe in the same folder and is ready to be used.

The python package can be installed in any python environment satisfying the following dependencies: numpy, scipy, pandas, pytables and matplotlib. The package is downloaded with the github repository in the folder python_tools and can be installed in the python environment using pip install . in the python_tools folder.

Once compiled, the C++ executable can be run from the command-line and need to be directed to a parameter file. The parameter file is a text file containing a series of values telling the C++ model what parameters to use. The parameter files can be written as follow in a text file:

The executable needs to know the path and the name of the parameter file to read them correctly. From a terminal in the folder containing the compiled executable, the following command will run the model:

Note that the parameter file is a text file and can be saved with any extensions (e.g., .param, .driver). The following parameters can be provided to the model.

The C++ model produces 6 csv files containing the evolution of various characteristics of the soil column. Four csv files contain the time series of the different components of the Factor of Safety (FS) functions of time and depth. The independent components of FS are described in equations 28 (a,b and c) of Iverson (2000) and their time series are in files XXX_time_series_depth_Fcomp.csv , where XXX is the write fname in the parameter file and Fcomp the corresponding component. It also output the final FS as well as the evolution of the transient pore pressure (Psi) in the file time_series_depth_Psi.csv. All of these files have the same structure:

Each model run therefore predicts the evolution of the factor of safety for a single soil column through time. Once a time has been identifies, a raster can be fed to the model to generate a risk map. The raster, assumed to be represented by the simulations, will be downsampled, the slope will be calculated and factor of safety is calculated for each soil column. The following lines can be added to the parameter file to enable the spatial analysis:

Where full_1D_output: false disables other ouputs, spatial_analysis: true enables the analysis, reload_alpha: false enable/disable the reloading of previously calculated slope map, resample_slope determines if the raster is down-sampled before slope calculation (for speed purposes) with a new resolution detailed with resample_slope_res, topo_raster is the name of the raster witout its extension (it has to be an ENVI bil file), polyfit_window_radius is the precision of slope calculation, n_threads is the number of threads to use for multithreading and time_of_spatial_analysis is the identify time on the precipitation time series. It produces a raster with the factor of safety for each soil column.

The model needs to be initialised with ranges of parameters as follow:

Most of the parameters are self-explanatory: range_X define the minimum and maximum values for the corresponding parameter; OMS_X define the precision step of the random sampling (D_0 and Ksat are in log space); n_depths defines the number of depth to be investigated, program points to the path+name of the exe file (compiled model); path_to_rainfall_csv and rainfall_csv points to the rainfall csv file and finally path_to_root_analysis points to the root directory of the analysis (many subdirectories may be created below).

To run the simulation, simply add the following line of code on the same script:

Where failure_time_s is an optional feature if a specific time is chased: it would add a data to the output expressing the time of first failure compare to that one (it does not affect the other outputs); n_proc defines the number of processors to be used in parallel: the code is pleasingly parallel which means all the tasks are independent from each others and can be run at the same time; n_test defines the number of simulations to run. For example, we ran 70000 simulation on 24 cores on our server with a broad range of parameter taken from literature with the following script:

The most important output is a csv file (can be open by any common software) named failure_global.csv. It contains a synthesis of each simulation with (i) the parameters tested and (ii) the time of failure. It allowed us to produce the histograms of time of failure and isolate successful parameters.

Another file is generated containing more details about each run (time series): because of the significant amount of data produced by the simulations, the software uses the hdf5 data structure via pandas to manage it. We strongly advice to use pandas in python to explore the data. One can open a file with the list of keys as follow:

To access the dataframe of one single run and potentially save it for more data mining:

Assessing performance can be difficult: due to the high number of simulations run within the Monte Carlo framework, there are many unsucessful similations, but the general pattern still highlights the failure quite well. The following code produces first order performance metrics based on the file produced by the python package. It takes the time of observed failures and an interval to calculate the ratio of successful simulations. It can be used to isolate the successful combination of parameters that lead to real failures.