Real-time data coupling for hybrid testing in a geotechnical centrifuge Open Access

The complexity and level of sophistication of physical models tested within geotechnical centrifuges has developed considerably in recent years. Models are now routinely developed which give realistic representations of soil–structure interaction systems (e.g. Liang et al., 2014; Ritter et al., 2017) as well as provide high-quality measurements of material behaviour. However, there remain various limitations regarding the extent to which physical models can simulate real geotechnical systems. One issue relates to the accurate modelling of the interactions between soils and buried or connected structural entities within centrifuge tests. The production of small-scale models which accurately simulate the real behaviour of these embedded/connected entities is often extremely challenging.

In the area of tunnelling and tunnel–structure interaction, centrifuge modelling has enabled a better understanding of the parameters that control settlement trough shape (Mair et al., 1993; Marshall et al., 2012) as well as the interactions between tunnelling-induced ground displacements and buried infrastructure or foundations (Farrell et al., 2014; Franza and Marshall, 2018; Jacobsz et al., 2004; Marshall and Mair, 2011). However, these experiments have all included simplified models of structural systems. For example, for a building on a raft or piled foundation located above a newly constructed tunnel, numerical and analytical modelling has indicated that the characteristics of the structural system has an effect on the resulting ground and structural deformations (Franza et al., 2017; Franzius et al., 2006; Giardina et al., 2015; Mirhabibi and Soroush, 2013; Mroueh and Shahrour, 2003; Potts and Addenbrooke, 1997). However for physical modelling purposes, the structure is simplified as an equivalent beam or constant pile loads are applied. The use of an equivalent beam within physical modelling tests to replicate a complex structural system such as a concrete frame or masonry building is an over-simplification that can lead to inaccurate or misleading outcomes. The application of a constant load to piles implies the assumption that the superstructure is infinitely flexible, which does not account for the realistic redistribution of loads through the connected superstructure. While it is virtually impossible to accurately replicate a complex structural system within a centrifuge test, numerical modelling of structural systems can give a very good replication of their behaviour. The purpose of this paper is to present the development of a hybrid testing methodology that takes advantage of the relative strengths of physical modelling using a centrifuge (focusing on the geotechnical domain) and numerical modelling (focusing on the structural domain) such that an accurate analysis of a tunnel–soil–pile–building interaction scenario can be achieved.

Hybrid testing consists of the implementation of the substructure approach (Blakeborough et al., 2001) through the coupling of a physical model with a numerical simulation. The physical test allows investigation of key elements of one domain whereas the numerical simulation efficiently accounts for the contribution of an adjoining domain. Physical modelling capabilities are enhanced with this approach because the combined results describe the behaviour of the full domain with greater accuracy than standard physical modelling where simplified boundary conditions are used. Real-time coupling between the problem domains is required in hybrid testing because the data from one domain is used to drive the other; this is especially important for time-dependent problems. The real-time coupling ensures that an acceptable agreement of conditions (for instance, forces or displacements) is achieved at the boundaries shared between the domains. The extension of hybrid testing to scenarios where parameter values are updated automatically due to changes occurring within the coupled subsystem (rather than computed beforehand) is referred to as online or pseudo-dynamic hybrid testing (Mahin et al., 1989; Pan et al., 2006). Hybrid testing has been used in a wide variety of fields in civil engineering, but mainly for structural analysis related to earthquakes. Its application within centrifuge modelling has only developed very recently; for example Kong et al. (2015) implemented displacement-controlled boundary conditions within a geotechnical centrifuge model that were defined based on numerical analyses.

This paper presents an overview of the hybrid test application (tunnel–building interaction) and a description of the developed physical (geotechnical domain) and numerical (structural domain) models. A challenging force-controlled system was developed for the physical model in order to achieve the best replication of the full-scale prototype scenario; this is the first known application of this approach in geotechnical centrifuge testing. The main focus of the paper is on the control systems and a novel data-exchange method developed for real-time communication between the numerical models (in Abaqus) and the physical model (controlled using LabView in this application). This real-time communication represents a novel development in the wider field of hybrid testing. Results are presented which demonstrate the effectiveness of the hybrid testing approach compared to a conventional centrifuge test for the tunnel–building interaction problem.

The hybrid model presented in this paper was developed to study the interaction between tunnelling-induced displacements and an overlying framed building with a piled foundation, as shown in Figure 1(a), using the University of Nottingham Centre for Geomechanics (NCG) centrifuge facility.

The developed hybrid model is referred to as the coupled centrifuge-numerical model (CCNM). A general overview of the methodology is illustrated by Figure 1(b), which relies on the use of a forced-controlled system at the shared boundary conditions of the physical and numerical models. The centrifuge model (geotechnical domain) consists of a tunnel, soil and pile foundations; the numerical model (structural domain) simulates a slice of the overlying superstructure. The CCNM physical and numerical models are initiated and run in parallel. A real-time interface passes information of pile loads and displacements between the two domains. Pile displacements from the centrifuge model are transferred to the numerical model, which performs a structural analysis to calculate the change in foundation loads based on the characteristics of the simulated building. The revised loads are then passed back to the centrifuge model. The initial state of the centrifuge model consists of the tunnel and piles with a constant service load applied. The test is initiated by a small increment of tunnel volume loss, which induces displacements within the soil and piles and causes load redistribution among the piles. The updating of pile foundation loads within the centrifuge model, while allowing piles to move according to their interactions with the tunnelling-induced ground movements, ensures that the soil stresses around each pile (and therefore pile capacity and stiffness) reflect realistic conditions, thereby ensuring an accurate simulation of the global tunnel–building interaction is achieved.

The pursuit of the best possible replication of a realistic tunnel–piled building interaction scenario dictated the need for the challenging force-controlled system for the piles. A displacement-controlled approach offers benefits from a control perspective; however, for this application, the appropriate displacement to be applied to the piles is unknown. The settlement of a pile due to an increment of tunnel volume loss depends on the soil–pile interaction mechanisms modelled in the centrifuge; without the appropriate modelling of these soil–pile interactions in the centrifuge, the variation of pile settlements for each increment of tunnel volume loss is not quantifiable (the numerical model alone cannot give an accurate assessment of what the displacements should be). Even for the more straightforward case of constant pile head loads, it would be unclear what pile head displacement should be imposed in a displacement-controlled hybrid test of this scenario.

The application considered a framed building constructed on displacement piles with no contact between the superstructure and the soil. This tunnelling scenario is difficult to analyse with available analytical methods or conventional numerical simulations. As detailed by Marshall and Mair (2011) using centrifuge tests of tunnelling beneath isolated displacement piles (with constant service loads), pile installation alters the pre-tunnelling ground condition. Consequently, two-stage analytical methods using greenfield movements as inputs (which neglect the effects of pile driving or jacking) (e.g. Franza et al., 2017) are not appropriate. Cavity expansion analyses have been used to assess the loss of load capacity of displacement piles (Marshall, 2012; Marshall and Haji, 2015), however, these do not provide predictions of pile displacements. Standard numerical analysis methods provide poor predictions of the shape and magnitude of tunnelling-induced displacements, hence their use for the study of tunnel–structure interaction problems involves uncertainties (Franzius et al., 2005). The CCNM method therefore represents a unique and valuable technique that can provide insights into the realistic response of these piled structures to tunnelling.

The current CCNM application considers the effect of tunnelling-induced displacements on a single row of piles and building columns. The effect of tunnel face advancement is not studied. As illustrated in Figure 2, the problem (at prototype scale) consists of the excavation of a 5·4 m diameter tunnel with 10·8 m of cover in loose sand (relative density of 30%) beneath the tip level of four displacement piles (final embedment length L_p = 9 m and pile diameter d_p = 0·78 m). The piles were all loaded by an initial service load of 1·8 MN (500 N model scale); their ultimate capacity was evaluated to be 3·6 MN (1000 N model scale) based on single-pile load tests performed in addition to the CCNM tests, giving an initial factory of safety of 2.

The building is an eight-storey concrete frame (Young's modulus E = 30 GPa, Poisson's ratio ν = 0·15) with transverse width B = 13·5 m and total height H = 24 m. Both beams and columns of the frame have square cross-sections of 0·5 × 0·5 m. The tunnel is eccentrically located with respect to the structure below pile 1 (piles numbered in Figure 2). As shown in Figure 2, piles 1 and 2 are within the main influence zone defined by Jacobsz et al. (2004), in which large pile settlements may be induced by tunnelling; therefore, the scenario has potential to cause structural damage and pile failure. The experimental load-control system transferred only vertical forces to the pile caps. The connections at the top of the piles restrained the piles laterally and provided a degree of rotational constraint. In the numerical analyses, a hinged joint was assumed at the pile–superstructure connection since the real rotational stiffness of the connection at the pile cap in the experiments was not known. This simplification had a minimal effect on results because, as demonstrated by Franza et al. (2017), the influence of the pile–structure connection is minor for framed buildings when pile heads are isolated or connected by slender structural elements (as is the case in this study).

The scenario considered may not give a perfect replication of a realistic construction scenario, however, the focus of these tests was on evaluating the performance of the CCNM methodology and studying the mechanistic changes in foundation load response; future testing will consider more realistic construction scenarios.

The developed CCNM methodology can be categorised as a pseudo-dynamic hybrid test. The CCNM method couples data at the interface between the experimental and numerical models by way of rapid data exchange such that each model can quickly respond to changes occurring within the other model. The interface between the two models is located at the top of the pile caps where data of pile load and displacement is transferred between models (see Figure 1(b)). Figure 3 shows the architecture of the CCNM application. The four action points (user interface (UI), application coordinator, numerical model and physical model) are responsible for the successful implementation of the CCNM application.

The application coordinator is the central component of the CCNM implementation; it controls data transfer between the numerical and physical models and operates according to configurations set within the UI. The UI enables user interaction with the system and updates the user on system status, computational results, actuator system actions, pile loads/settlements and tunnel volume loss. The UI and application coordinator are built as two threads written in the National Instruments (NI) LabView program development environment. The application coordinator retrieves pile displacement data from the physical model (measured using linear variable differential transformers, LVDTs) which are then accessed from by the numerical simulation. It also retrieves pile reaction forces from the numerical simulation, which are then defined as the target loads sent to the physical model.

The centrifuge package used in these tests was developed from the plane-strain tunnelling model detailed in Zhou et al. (2014), which comprises a 90 mm diameter cylindrical flexible membrane model tunnel embedded into a transparent acrylic front wall and passing through a rear aluminium wall of a plane-strain strongbox. Tunnelling-induced displacements are replicated by extracting fluid from the model tunnel to induce a known value of tunnel volume loss, V_l,t (volume loss control system illustrated in Figure 4(a)). In the absence of any structure within the soil, displacements are intended to occur uniformly along the tunnel length. The tunnel depth in all tests described in this paper was 225 mm to axis level. Tests were conducted at an acceleration level (centrifuge scaling factor, N) of 60g (60 times gravity). A dry silica sand known as Leighton buzzard fraction E was used for all tests. Further details of this model can be found in Zhou (2015); this paper is focused on the additional equipment used to simulate the piles and actuate/control pile loading.

Figure 4 provides various views of the centrifuge model used for the CCNM testing. Four L03 MecVel ballscrew actuators (maximum 5 kN load and 100 mm stroke), shown in Figure 4(a), were used to independently control the load on four 12 mm diameter cylindrical aluminium rods (the model piles, shown in Figure 4(c)). The model piles had a total length of 185 mm, 60° conical tips, and a fully rough interface obtained by bonding sand to the periphery of the piles, resulting in a final diameter, d_p, of 13 mm. Due to space restrictions, the actuators were placed to the rear of the strongbox and a lever system (see Figure 4(c)) was used to transfer loads to the tops of the piles. Guide rails and carriages (see Figure 4(b)) were used to ensure alignment of the actuators. Loading bars (see Figure 4(b) and (c)) were used to transfer load from the levers to the tops of the piles. The loading bars were placed within low friction polytetrafluoroethylene (PTFE) guides (see Figure 4(b)) to ensure that only vertical loads were transferred to the piles. A die-spring with a stiffness of 155 N/m was included in the cap (see Figure 4(a)) of each actuator to reduce the sensitivity of the load response to movements of the actuator, which was necessary to ensure the CCNM control system remained stable. Each pile cap was fitted with an LVDT and load cell (see Figure 4(b) and (c)) to measure vertical displacement and force, respectively. Limit switches were installed on each of the actuators to ensure they did not move outside of designated limits. Further details of this equipment can be found in Franza et al. (2016).

In both research and practice, to study the effects of structural characteristics on soil–structure interaction problems, simple two-dimensional (2D) models, which are reliable and computationally inexpensive, are often adopted to obtain a first approximation. However, 2D models require simplification of the structural scheme and assumptions regarding material and cross-sectional behaviour, all of which may lead to inaccuracies. Finite-element (FE) analysis software can be used to develop three-dimensional (3D) models with increased levels of complexity compared with 2D frame analyses. FE analysis software allows for the implementation of advanced constitutive relations for materials, accounting for non-linearity and damage.

For linear elastic superstructures, the numerical model can be reduced to a condensed stiffness matrix that can be built prior to the hybrid test using a structural analysis program (i.e. structural analyses do not need to be done during the centrifuge test) (Kong et al., 2015). This approach is highly efficient, however it limits the scope of application since more complex structural models that include material non-linearity and/or damage cannot be accommodated. To allow for future extension of the modelling technique towards complex structural problems, the CCNM application was developed to include both simple 2D frame analyses as well as rigorous 3D FE analyses that are fully executed (i.e. boundary conditions, loads and material state are updated in each numerical simulation, depending on the state of the system) in parallel to centrifuge testing. In this work, however, as a first step towards achieving a detailed structural analysis, the superstructure behaviour was limited to linear elastic. Two structural models of the framed superstructure with fixed pillar-beam connections were implemented: a 2D frame consisting of Euler–Bernoulli beam elements (Figure 5(a)), and a 3D solid model (Figure 5(b)). The 2D frame was solved numerically with a MATLAB script using finite elements and the direct stiffness method. The 3D numerical model was developed and solved with the FE software Abaqus using eight-node linear bricks for the mesh with a cubic shape and a side length of 0·1 m. Each column base in the 3D numerical frame was rigidly connected to a reference point to reduce the degrees of freedom of the frame base to those of four points that also model the pile head displacements and rotations. Finally, for both models, base/reference point rotational degrees of freedom were released based on the assumption of hinged pile–structure connections (see Figure 2).

For each fixed frequency loop, results of the FE models were obtained by imposing pile head settlements (measured in the centrifuge models) at the base of the frame and evaluating the corresponding reaction forces (i.e. the redistribution of building weight). These reaction forces were then transferred to the interface that updated the pile head loads of the physical model (at real-time frequency) accordingly.

A real-time control and instrumentation system that can perform data acquisition (DAQ) and actuator control in a highly synchronous fashion was developed for the CCNM application. The field programmable gate array (FPGA) technology was adopted, which is a high-end integrated circuit that consists of highly reconfigurable elements (logic gates) and enables extensive hardware level control (Monmasson et al., 2011). This FPGA technology was selected over typical microcontrollers which have issues relating to flexibility, reconfiguration after deployment, and integration into high-end control systems; they also require extensive development processes (Ullmann et al., 2004). FPGA controllers execute code using parallel logic gates and can, therefore, achieve parallel programming, which allows for low latency for simultaneous control of repeated elements (e.g. actuators in the experimental equipment).

The real-time system adopted comprises an FPGA-based programmable automation controller (PAC) from NI (ethernet-RIO; NI-9149); interchangeable DAQ and control modules, and a personal computer (PC) running LabView developed software that acts as the application coordinator. The NI-9149 (known as eRIO) is a rugged chassis that allows the use of reconfigurable input–output (I/O) modules over an ethernet network. The NI-9205 DAQ module was added to the eRIO to obtain signals from the displacement and load sensors. Relay functionality was achieved with a relay module (NI-9474) and a digital I/O module (NI-9403) was used to detect the limit switches. The Mecvel L03 actuators required pulse-width modulation (PWM) generated control signals, which were provided by a servo drive module (NI-9505).

Some of the sensor signals acquired through the DAQ module are used within the eRIO as feedback for the actuator control and some are transmitted through a local ethernet network to the LabView program on the local PC in the centrifuge control room. The rugged nature of the eRIO is crucial to the CCNM application as it allowed the eRIO to be mounted on the centrifuge swing arm where it experiences elevated accelerations. The FPGA chassis and modules are mounted on the centrifuge platform in close proximity to the sensors to limit noise levels in the signals. This configuration was tested up to 100g without adverse effects on hardware performance or signal quality.

A decentralised control system framework was adopted for the overall CCNM application to ensure faster, more reliable control as well as design flexibility and improved safety for the mechanical system. The decentralised control system split up the CCNM application responsibilities into smaller actions that could be executed locally while contributing to the global objectives. This is realised within three logical loops illustrated in Figure 3.

The application coordinator loop is responsible for (a) monitoring UI interactions; (b) collecting relevant updated information from the FPGA controller mounted on the centrifuge through the ethernet local area network (LAN) connection; (c) transmitting the incremental pile settlements v to the application responsible for executing the numerical model; (d) feeding new target loads based on results from the numerical model to the FPGA system; (e) logging the data from the two modelling systems; and (f) sending keep-alive signals to the FPGA to indicate continued safe operation.

In the numerical model simulation loop, the CCNM application is currently able to implement two different numerical tools: a MATLAB model or an Abaqus model. In the first implementation (referred to as ‘IMP1’), detailed by Franza (2016), the application coordinator includes calls to the MATLAB executable through a MATLAB script node embedded within LabView; this call executes the 2D frame model within the MATLAB environment and retrieves results. The IMP1 implementation was initially selected due to the ease of integration of MATLAB within LabView and the possibility to achieve, with the matrix stiffness method, low computational times that are suitable for real-time load-control systems. To integrate more sophisticated FE models, a second implementation was developed (‘IMP2’) that executes the 3D numerical model in Abaqus. For IMP2, to ensure that the numerical and physical models are connected to each other through rapid data exchange, either a Python script (which edits the text file inputs to Abaqus) or an efficient Abaqus subroutine (that performs transmission control protocol/Internet protocol (TCP/IP) data transfer) may be implemented. Further details on tested data-transfer schemes are provided later.

The FPGA controller loop was run at a real-time frequency of ≈ 500 Hz and used to (a) perform high-speed acquisition from the centrifuge instrumentation, comprised of four load cells, five LVDTs (four for piles and one for tunnel volume loss system) and 12 limit switches; (b) control the actuators to achieve target forces derived from the PC LabView program by implementing automatic load control using a proportional, integral, derivative (PID) algorithm; (c) communicate the system state to the PC LabView program; and (d) maintain mechanical system safety by limit switch monitoring and safe shut down protocol on failure of the intermittent keep-alive signal from the PC.

The LabView UI on the PC displays real-time information about the sensors and allows the user to control the actuators through either manual control mode or automatic load control. Manual actuator settings transmitted to the FPGA motor controller execute actuator extension or retraction. Automatic load control initiates the automatic PID force controller on the FPGA to actuate in the physical model a load demand input by the user or the numerical simulation loop. The PID algorithm is a typical control algorithm used for error correction in control systems; it compares the error between the target variable and the measured variable and produces an output that is a function of the proportional, integral and derivative of that error. The PID algorithm receives the load targets from (1) user-defined settings on the UI, or (2) force targets extracted from results of the numerical modelling application.

The amplification of signal noise from the centrifuge model by the scaling factor (N) in the data passed to the numerical model (simulating at prototype scale) added an additional constraint to signal filtering. LVDT data filtering was required to mitigate unrealistic load changes P′ in the centrifuge model. Using centrifuge scaling laws, target load at model scale is P′ = K[N(v^r + v^e)]/N² for a given prototype structure with stiffness K, where v^r and v^e are the model pile settlements and the error in the LVDT measurement due to signal noise, respectively (both at model scale). Target load fluctuations due to LVDT signal noise are P^e = Kv^e/N. This aspect becomes more critical as superstructure stiffness K increases.

The measurement system adopted was found to have peak-to-peak noise levels of 5 mV resulting in ± 0·0125 mm noise on the 50 mm LVDTs at model scale. This noise level was equivalent to ± 0·75 mm at prototype scale using N = 60. This fluctuation is not compatible with structural analysis of realistic buildings, prompting the implementation of appropriate signal filtering. A fourth-order Butterworth low-pass filter with a 30 Hz cut-off frequency was implemented in the FPGA program just after the acquisition step. The result was a reduction of the peak-to-peak noise to 0·3 mV, equivalent to an acceptable ± 0·05 mm fluctuation at prototype scale. In contrast to the LVDT data, signals from the load cells for the load controller algorithm require higher frequency updates, so minimal signal filtering was adopted for data used in load control. A 1 kHz cut-off frequency low-pass filter was used for load control signals.

In general, minimisation of noise from the LVDTs, which depends on hardware, system resolution and adopted filtering, is beneficial to the CCNM performance. Prior to hybrid testing, it is important to assess what an acceptable noise level might be, which is based on the scaling factor N and the prototype scenario being studied. The feasibility of hybrid testing for the given acceptable noise level should be verified (e.g. CCNM load-control application of a fully rigid structure is not practically achievable) and, if it is feasible, suitable hardware and control components should be used that are able to satisfy the experimental requirements in terms of accuracy. This aspect is discussed in more detail later in the paper using preliminary data obtained using the CCNM application.

Safety is a critical factor during centrifuge testing. The developed CCNM application implemented three safety precautions to prevent the load apparatus (actuators and lever system) from damaging the CCNM hardware, sensors or physical components of the experimental set-up. First, a watchdog timer in the FPGA timed out if a keep-alive pulse was not received from the PC within a set time interval (Δt = 500 ms). The watchdog timeout was set to cut power to the motors to prevent potential catastrophic hardware failure in the event of an unexpected PC stall or crash. The second safety precaution implemented the monitoring of limit switches which were positioned at the physical limits of the actuators to prevent excessive actuator motion. Two switches were deployed in each direction to provide limits at software and hardware levels; the software-activated limits merely stopped further motion in the direction when the first limit switch was triggered. In the unlikely event of a software system failure, continued motion would trigger the second limit switch in that direction, causing the hardware limits to disable the entire motor. Finally, data from the LVDTs were employed to warn the user of the lever motion exceeding a given threshold.

To allow for real-time data exchange while addressing a target level of structural complexity, two numerical model implementations (IMP1 and IMP2) were used. The following discussion highlights performance indicators of the different implementations. Of particular importance were: (i) the time required for establishing communication between programs (Δt_c); (ii) the time associated with program start/shutdown processes (Δt_p); and (iii) the time needed to run a numerical analysis (i.e. in MATLAB or Abaqus) (Δt_r).

It will be shown that, for the tunnel–building interaction application considered here (in sand with a controlled rate of tunnel volume loss), the timescale of data transfer between the physical and numerical domains is not important. However, the intention of the CCNM development was to enable a diverse range of future applications, including those where time constraints are critical (e.g. dynamic/cyclic soil–structure interactions or applications involving clay).

A MATLAB function file implementing the 2D frame analysis was executed with a MathScript node, a LabView application module that allows integration with MATLAB codes. MATLAB executes the script and returns the results to the calling node. The application coordinator calls the MathScript node within its loop; it waits until the script is completed and then passes results, consisting of target reaction forces, to the FPGA.

When running the 2D frame simulation in MATLAB, the required time was Δt_r = 8 ms. Implementation of the Mathscript node in LabView was completed in a total script execution time of Δt = Δt_c + Δt_p + Δt_r = 35 ms (i.e. Δt_c + Δt_p = 27 ms). This execution time was satisfactory in view of the fact that the convergence time of the actuators (the time to reach the target force) was ≈ 200 ms. Additional time (≈ 20 ms) was also required to complete other tasks in the LabView program. Therefore, the execution of the LabView program was set to loop every Δt = 60 ms, ensuring a deterministic response of the CCNM application. This frequency rate was sufficient for the proposed tunnelling application, as will be discussed later.

The need to include more rigorous structural analyses within the CCNM applications prompted the development of a methodology to integrate Abaqus. The main challenge with this concerned the requirement for fast and reliable data transfer to-and-from the CCNM application coordinator (i.e. the time taken to start Abaqus after applying the boundary conditions referring to the latest state of the physical domain and to retrieve the numerical results, i.e. Δt_p and Δt_c). The time to run the Abaqus model of the 3D frame in Figure 5(b) depended on the computer used to run the analysis; for the tested systems Δt_r ranged from 250 to 312 ms. The objective was to obtain a methodology that allowed the transfer of data to/from Abaqus with the smallest time delay possible (i.e. minimise Δt_p + Δt_c). Options considered for the implementation of Abaqus were (i) Abaqus input file scripting and (ii) Abaqus subroutine as network socket, as discussed in the following sections.

When using Abaqus in hybrid testing, a common practice is to modify the input file to Abaqus using a scripting program, then trigger the Abaqus program and extract the results from a text file (rather than the default output database file used by Abaqus). An example of this is presented in Wang et al. (2006) where the reaction of structures to seismic loads was studied. Wang et al. (2006) coupled an Abaqus model to an earthquake actuator system using text file-based data exchange. A control program was written in Visual Basic to act as the application coordinator and an FE model control program was written in Fortran 90 external to the Abaqus subsystem. The coordinator was developed to manage the physical model and exchange data with the finite-element method (FEM) control program. The FEM control program was tasked with generating input files, triggering FE analyses, and interpreting results to extract reaction forces. The FE model program triggers the Abaqus simulation and waits for the simulation to be complete before writing data to a file. It then waits 1000 ms (a ‘technical delay’ – addressed in the following section) before reading and interpreting the results from the output file and then transmits that data to the main coordinator across the network.

A limitation of this methodology relates to the data-exchange mechanism. Data exchange between the numerical model and the FE model control program is done by file access, which requires a technical delay (1000 ms in the example above) to ensure that multiple programs don't try to access the same file simultaneously, causing a file-access failure. For implementation of this methodology with Abaqus in the CCNM application, this delay would also be required, resulting in a relatively low update rate of the control program. This would lead to a time delay that is orders of magnitude larger than the 27 ms (Δt_p + Δt_c) which was achieved with IMP1 using MATLAB. Therefore, it was concluded that this methodology did not satisfy the intended performance of the CCNM application.

It was assumed that a lack of integration between the externally developed FEM control software and Abaqus was responsible for the technical delay experienced by Wang et al. (2006) and that a more tightly integrated solution would obviate the technical delay. A direct implementation using Abaqus scripting was, therefore, attempted to improve this data-exchange mechanism. Abaqus scripting allows users to write code based on the application programming interface (API), which lets users interact with the data and models used from within the Abaqus interface. Python scripts are commonly used to edit Abaqus inputs and extract results from the default database files. Abaqus can inform a Python script when a simulation is complete, eliminating the need for the technical delays. Based on this concept, IMP2.1 was developed that consists of a script which (i) modifies the input file, (ii) executes the simulation start in Abaqus, (iii) waits for simulation completion, (iv) extracts the results from the database file and (v) transmits this result to LabView. It was found that for the frame presented in Figure 5(b), an additional Δt_p = 11 s was needed for the start/shutdown of Abaqus processes. The issue with this method is the time taken between simulation initiation and the actual start of the analysis as well as the time between the end of the analysis and the end of the Abaqus simulation process. Abaqus requires other processes to be run for every input file computed; the additional time for these processes varies with system performance and was up to 20 s with slower PCs that were tested. Consequently, it was concluded that IMP2.1, which starts and ends the FE software for every change of the boundary condition in the physical model (i.e. pile settlements), was also insufficient. A better solution, detailed in the next section, was therefore sought.

An alternative approach was developed by taking advantage of Abaqus incremental modelling capabilities and inbuilt data manipulation/modelling modification subroutines, which allow changes to be made to the model at each simulation increment within a given step. In Abaqus, an analysis step (i.e. a period of time over which the response of a model to a given set of loads and boundary conditions is determined) is broken down into a number of increments. Data programming capabilities of subroutines within Abaqus were exploited to effectively feed in displacement boundary conditions at the start of every increment of a model simulation and then transfer results out of Abaqus at the end of the increment.

Despite the benefits of using subroutines within Abaqus, they have not been exploited in hybrid testing to the extent of what has been done in the CCNM application. Previously, Abaqus subroutines have been used to change boundary conditions (Hügel et al., 2008; Lee et al., 2013) and access data or manage communication between a user-defined database and a model simulation status (Ure et al., 2012). In addition to these subroutines, IMP2.2 implemented additional subroutines to access and exchange data between Abaqus and the application coordinator at every analysis increment, thereby eliminating the need for time-consuming and unnecessary Abaqus processes.

Pan et al. (2016) used a TCP/IP protocol for data exchange between the application coordinator and the FE model control program with a minimum of 1 s ‘technical delay’ between the end of a simulation and data file access. In IMP2.2, this approach was extended to apply this protocol from within the Abaqus subsystem and connect the application coordinator directly with the Abaqus simulation (i.e. direct communication with the numerical domain). This novel implementation for communication between Abaqus and LabView within the CCNM application eliminates the previously required ‘technical delay’. A network socket connection, which is a two-way data link between two programs running on a network, was set-up between the application coordinator and the Abaqus subroutine. The implementation used the local host network (the virtual network that resides on the local PC); however, the approach could be extended to connect between any two remotely connected systems, which may be beneficial for other related applications.

The CCNM LabView coordinator was set-up as the TCP/IP socket server that (i) waits for socket connections; (ii) sends new boundary conditions on initiation of the connection; (iii) waits for the reply that contains the new target loads, which are a function of calculated reaction forces; (iv) updates an FE analysis global variable with new target loads as well as gets updates on pile settlements from the global variable; and (v) repeats steps (ii)–(iv) until the CCNM application is terminated by the user, at which point it sends a termination dataset at step (ii). The Abaqus subroutine was used to (i) initiate connection with a socket server at the start of the ABAQUS program using the UExternalDB subroutine to know the start point; (ii) get boundary condition data and parse it into the boundary condition variables using the DISP subroutine; and (iii) get Abaqus-derived reaction forces using the URDFIL subroutine. The LabView/Fortran socket connections were configured to send/receive 64 bytes of data, which was sufficient to transfer the intended reaction forces from Abaqus and the pile displacements from the physical model.

IMP2.2 provides a very efficient integration of Abaqus within the CCNM application, mainly because it removes the necessity to start/stop Abaqus at each change to the boundary conditions. The total time required to run the IMP2.2 analysis of the frame in Figure 5(b) and exchange data with LabView was Δt = Δt_c + Δt_p + Δt_r = 330 ms. The time for Abaqus to solve the analysis of the frame was Δt_r = 312 ms for the specific computer used during the test. A transmission time of Δt_c = 1 ms for 64 bytes was determined by timing a data-exchange process between LABView and a standalone Fortran subroutine. This means IMP2.2 achieved a Δt_p = 17 ms for the tested configuration.

Tunnelling beneath a pile can cause displacements in two ways. First, ignoring the potential for loss of base/shaft capacity, from an analytical perspective it would be expected that a rigid pile would deform according to some average of the greenfield displacements that occur along the pile length. This response may cause displacements that result in serviceability issues to a structure, however from an ultimate limit state perspective, the pile and foundation would remain safe. On the other hand, if the changes to the ground stresses caused by tunnelling result in a loss of capacity of the pile, then larger displacements would occur whereby the pile is pushed into the ground until it can mobilise the resistance needed to support the applied load. If ‘conventional’ experiments are conducted, whereby a constant load (e.g. building dead weight) is applied to a row of piles, then the response illustrated in Figure 6(a) might be expected. This plot compares displacements obtained from a ‘conventional’ constant load centrifuge test to those obtained using the CCNM IMP1 (MATLAB) methodology, as well as greenfield displacements at locations corresponding to the pile heads (ground surface). The shaded horizontal lines in Figure 6(a) denote two limit thresholds of pile displacement: 0·026d_p based on Jacobsz et al. (2004) (equivalent to 20 mm at prototype scale) and 0·1d_p.

At the location of pile 1, the greenfield displacement at the pile head (i.e. surface – shown in Figure 6(a)) and tip (not shown) were approximately equal; they reached about 0·1d_p at V_l,t = 3%. In the constant load test, the pile in position 1 experienced a brittle failure at V_l,t ≈ 0·2%, hence the test had to be stopped. Clearly, the constant load pile 1 response is outside of the response defined by greenfield displacements, and based on these data one might conclude that this pile would experience catastrophic failure at a very low value of tunnel volume loss. However, the IMP1 CCNM test results, where the load applied to each pile is adjusted based on the characteristics of the modelled building frame, show that pile 1 does not experience catastrophic failure; a gradual increase is observed in pile 1 displacements at a rate slightly higher than the surface greenfield displacements at the same location. Figure 6(b) plots the change in load (ΔP) for the four piles during the test. The data illustrate how the building is able to redistribute loads from pile 1 to some of the other piles, mainly pile 3. The load applied to pile 1 is noted to decrease by up to 80 N (16% of initial service load) at V_l,t = 3%; this reasonably small reduction in load has a considerable impact on the response of pile 1 to tunnel volume loss.

Pile 4 is noted to experience the most significant reduction in load. This is due to the overall bending stiffness of the modelled building and the tendency of the building to rotate as a result of the tunnelling-induced ground displacements. The edge nearest the tunnel wants to displace more than the far edge, hence, in relative terms, pile 3 is driven into the soil and pile 4 is unloaded. Although the load applied to pile 3 increases by about 220 N (44% of initial service load) at V_l,t = 3%, the displacements of the pile are minimal (Figure 6(a)) because its capacity has not been significantly affected by tunnel volume loss (due to its distance from the tunnel). Assuming that the capacity of pile 3 is unchanged and given the initial safety factor of 2, the pile still has sufficient capacity in reserve to sustain the additional loads. The post-tunnelling safety factor of pile 1, on the other hand, is likely close to unity.

The CCNM test outcomes provide a different perspective on predicted foundation behaviour compared to the conventional constant load tests. Based on CCNM test data, the evaluation of building response is mainly from a serviceability perspective and a reasonable assessment of the post-tunnelling capacity of the pile group can be achieved. This is in contrast to the overly pessimistic (and unrealistic) evaluation of foundation response based on the constant load tests. Conclusions drawn regarding acceptable limits of maximum tunnel volume loss are also different between the constant load and CCNM tests. Available influence zones of tunnel–pile interaction (e.g. Jacobsz et al., 2004) are therefore very conservative as they don't consider the beneficial effect of the connected structural system.

The data obtained from the IMP1 CCNM centrifuge tests (Figure 6) were also used to test the real-time Abaqus integration with LabView (IMP2.2) and to evaluate the effect of longer simulation times (Δt_r) for more elaborate structural models. The pile displacements measured during the IMP1 centrifuge test were used as an input for a ‘virtual’ IMP2.2 test (i.e. an IMP2.2 centrifuge test was not done) in order to calculate target reaction forces. This virtual experiment ensured that variability in response was due solely to the numerical implementation (i.e. it removed the effect of variability caused by changes in the soil or experimental set-up between tests).

Figure 7 plots the change in pile load (ΔP) with tunnel volume loss from three tests: the CCNM IMP1 centrifuge test, a virtual CCNMv (the v indicates virtual) IMP2.2 test with a total time of Δt ≈ 300 ms (for the computer used for this analysis, Δt_r = 270 ms) and CCNMv IMP2.2 with a total time of Δt ≈ 30 s. The different analysis times were set by adjusting the time at which boundary conditions were updated in Abaqus. The third test (with ≈ 30 s analysis time) considers what would happen for a computationally demanding Abaqus analysis. The trends of the IMP2.2 data in Figure 7 are similar to the IMP1 data, indicating that the IMP2.2 methodology was effective. Comparing IMP2.2 (300 ms) to IMP1, for the same input displacements, the predicted reaction forces of some of the piles (most notably pile 1) was different. This is due solely to the different responses of the 2D frame and the 3D Abaqus simulation (as is expected).

The IMP2.2 (30 s) data can be used to assess if a numerical simulation of a computationally demanding structural model is compatible with the CCNM methodology. For some excavation-induced soil–structure interaction problems, the trigger event within the physical domain can be carried out at a low rate (e.g. in the current application, tunnel volume loss can be initiated very slowly). In this case, it is possible to accommodate computationally demanding numerical models in the CCNM. As shown by the IMP2.2 (30 s) data, the force variation has a stepped shape; however, the magnitude of these steps is limited due to the slow rate of tunnel volume loss. In these cases, the use of IMP2.2 rather than IMP2.1 results in a limited efficiency improvement and either IMP2.1 or IMP2.2 could be used. For applications where the timescale of the triggering event is critical (e.g. dynamic/cyclic soil–structure interactions, excavations in clay), the efficiency of data transfer between the numerical and physical domains may be crucial in order to enable more computationally demanding numerical analyses.

This paper presented the development of the CCNM hybrid test equipment and methodology. The method takes advantage of the relative strengths of centrifuge tests to model soil behaviour, and numerical modelling to simulate structural behaviour. The CCNM application was applied to study the tunnel–building interaction problem; the effect of tunnelling on a series of piles was evaluated in the centrifuge and pile displacement data were transferred to a numerical analysis used to evaluate the redistribution of pile loads based on the input displacements and the characteristics of the structure. The updated pile loads from the numerical analysis of the structure were then used to update the loads applied to the piles in the centrifuge test. This challenging force-controlled system (the first of its kind used for geotechnical centrifuge testing) was necessary to enable an accurate replication of the global tunnel–building interaction scenario.

The developed methodology can incorporate structural analyses within either MATLAB or Abaqus. Three implementation schemes were presented and the applicability of each method was evaluated against CCNM and application requirements. A novel data-exchange method between Abaqus and LabView was presented which provides a significant enhancement compared with previously published methods for related hybrid tests; this development will enable the CCNM methodology to be adapted to study applications where timescale of triggering events is critical (e.g. dynamic/cyclic loading or applications involving clay). Results were presented from a CCNM test in the centrifuge which evaluated the effect of tunnelling on a framed building with a pile foundation using a computationally efficient 2D frame analysis in MATLAB. It was demonstrated that inaccurate and misleading outcomes can be obtained from ‘conventional’ constant load centrifuge tests compared with CCNM tests where pile loads are adjusted according to the response of the connected structure. It was concluded that previously published tunnel–pile interaction zones may be overly conservative as they do not include for the effect of pile load redistribution through a connected structure. It was demonstrated that the CCNM methodology can accommodate more rigorous (and time-consuming) FE analyses of structures and the implications of long simulation run times on CCNM performance was evaluated using the tunnel–building interaction analysis case.

The developed CCNM methodology can provide more realistic predictions of the response of buildings and foundations to tunnelling. Further testing and developments for the study of tunnel–building interactions are underway. In addition, the CCNM methodology has the potential to enhance centrifuge modelling capabilities in a range of other applications, which are currently being explored at the University of Nottingham.

This work was supported by the Engineering and Physical Sciences Research Council [grant number EP/K023020/1, 1296878].