Train-Track-Bridge Interaction (TTBI)

Author: Wojciech Pruszkowski, SOFiSTiK AG

I’d like to give all credit and thanks to Wojciech and SOFiSTiK AG for compiling this article and allowing us to publish it on SOFiSTiK FOR YOU.

As development isn’t standing still, alternative workflows for this specific task are available and possible. Therefore, I recommend considering the programme module FEABENCH.

1. Introduction

In recent years, there has been a significant focus on the importance and development of rail transport. These initiatives result not only in newly built infrastructure but also in verifying the existing one against modern high-speed rail traffic requirements.
Along with the increased train transit speeds, a dynamic interaction between the train, track, and bridge systems can not only become a dominant factor in a bridge design process but can also heavily affect the service of tracks and the performance and safety of passing trains. Thus, it is paramount to consider the interdependency of train, track, and bridge in a one-coupled system.

This tutorial will guide an experienced engineer and advanced SOFiSTiK user through creating a coupled Train-Track-Bridge Interaction (TTBI) capable system, performing a time-history analysis, and displaying results.

This tutorial assumes the user commands the expert engineering knowledge needed to perform a TTBI analysis reliably and, therefore, does not explain the theoretical background of the performed tasks in depth, focusing primarily on the execution in SOFiSTiK instead. All design and modelling assumptions made in the tutorial example are demonstrative and should be adjusted or replaced by the design engineer to correctly address the specific analytical problem.

Note:
A TTBI analysis is primarily a code-based task and thus requires advanced knowledge of operating SOFiSTiK using the numerical input language CADINP and the TEDDY editor.

2. Analysis goals and model assumptions

The overall configuration and level of complication of the FE system used to analyze a railway bridge heavily depend on a design brief and analytical objectives. These can include:

It is therefore recommended to assess the design task’s analytical requirements, perform sensitivity studies if required, and adjust the model accordingly. It is probable that if a design brief excludes the need to investigate, e.g., passenger comfort, it can be sufficient to model a train system in a simplified manner.

3. General workflow

The following workflow sequence in SOFiSTiK using SSD and the appropriate SOFiSTiK modules is recommended:

4. Bridge system

The tutorial example uses a supported, single-span, reinforced concrete bridge modelled as a beam element (ref. [11]):

The SOFiPLUS preprocessor has been used in the tutorial example because it allows for the creation of kinematic constraints using graphical inputs, but any preprocessor can be used to define the system.

Note:
Please note that this tutorial does not cover additional considerations needed to accurately and reliably assess the bridge system’s dynamic response. These include performing a time-history analysis on a system in a relevant state (e.g., cracked), adjusting the concrete’s Youngs modulus to the age corresponding with the analysis assumptions, and more.

5. Track system

A track model and its complexity should reflect the design requirements. A multilayer 2D ballasted track system has been assumed in the tutorial example, as proposed by [1], [3] and [12]:

The track system is comprised of a set of rails modelled as beams with applicable material and section properties, resting on evenly spaced sprung mass systems with multiple springs (spring stiffness K) and dashpot (viscous damping C) subsystems approximating the track’s vertical stiffness. Please refer to the relevant literature (ref. [1], [2], [3], [12] and more) for more information on this approach and its associated mechanical properties. Lateral direction is assumed to be rigid, longitudinal stiffness is assumed to be either rigid or represented by a non-linear spring approximating the Rail-Structure-Interaction (RSI) effect.

A complete track system cannot be modelled in SOFiPLUS using graphic input exclusively, as the option of assigning viscous damping to the spring element is not currently available directly and requires TEDDY inputs. Two modelling steps are required to create a track system. In the first step, the SOFiPLUS is used to create rails, nodes and kinematic constraints required for system stability:

The second step requires TEDDY input in SSD and aims to extend an already existing system created in the previous step by adding nodal masses to the finite element nodes and by creating spring elements with the appropriate stiffness and viscous damping. Please note that by properly controlling the group numbering of kinematic links, it is possible to efficiently generate the TEDDY code required using the SOFiSTiK Result Viewer and an Excel spreadsheet:

Code example:
+prog sofimsha
syst rest
ctrl rest 2

sto#k_bal_deck 1000*1000
sto#d_bal_deck 50

sto#mass_ballast 0.412

spri no #springID na #nodeA ne #nodeB cp #k_bal_deck dp #d_bal_deck
…

mass no #nodeID mz #mass_ballast
…

end

It is also recommended that the track system be extended beyond the bridge structure by modelling the approaches. These track extensions allow for mitigating the initial impact on a system caused by the appearance of a train. The length of the approaches is an engineering-judgment-based decision as it is highly dependent on other factors (e.g., model sensitivity, RSI requirements) and should be balanced with the increased computational demands of the longer system.

To provide clarity of results, gravitational acceleration is not present in the system. If a train model is to move across the bridge system and is deformed under its own weight (or any other loading), a manual coordinate update is required.

Code example:
+prog ase
head self-weight
lc 1 facd 1 titl ‘self-weight’
end

+prog ase
head coordinates-update
syst plc 1 stor yes
end

6. Rail-Structure-Interaction (RSI)

The widespread use of continuously welded rails (CWR) in railroad construction, especially for high and very high-speed tracks, has placed a new focus on a complex interaction between the expandable railway bridge deck and the CWR track. A differential movement caused by traffic loading or varying thermal strains of bridge and track may lead to buckling or breaking of rail sections resulting in safety concerns. Moreover, assuming a rigid longitudinal connection between the track system and the bridge deck may lead to falsely incorporating rail beam elements in the main bridge load-bearing action and to changing its dynamic response, especially for short bridge spans and at the abutments. It is, therefore, important to introduce track longitudinal flexibility into the system, regardless of whether the RSI criteria and possible failure modes are to be investigated.

A bilinear spring in the track longitudinal direction has been assumed in this tutorial example, as proposed by [13]:

A non-linear spring with bi-linear characteristics (or any other) can be introduced in the SOFiSTiK model by using a user-defined Work Law. Please refer to the relevant literature (ref. [13]) for more information regarding the mechanical properties of the proposed spring connection.

7 Track irregularities

Track irregularities represent deviations from the ideal track section and geometry and thus increase the dynamic excitation of the train-track-bridge system. For more information, please refer to the relevant literature (ref. [12]) and the local railway regulations.

It is possible to introduce track irregularities into the SOFiSTiK analysis using Power Spectral Density (PSD) functions adapted to local railway governing body requirements (e.g., German track spectrum). The user must define An appropriate PSD function in the SOFILAD module (SIMQ function), along with relevant wavelengths, irregularity parameters, frequency increments and sampling numbers. The resulting track irregularity load cases can then be referenced in the DYNA calculation using LCUV / LCUT / LCUR functions.

Note:
Please refer to the TEDDY example bridge1.dat for a practical implementation example.

8. Train system

A track model and its complexity should reflect the design requirements. The tutorial example presents two possibilities.

8.1 Train as moving load

In this approach, a train is represented by a series of static forces that disregard the train’s mechanical properties.

To be applied in the analysis, a train load model needs to be defined as a SOFILOAD load case. An extensive list of predefined load models is available in SOFiSTiK and can be loaded as a load case using TEDDY with minimal effort.

Code example:
+prog sofiload
…

lc #LC type none titl ‘loadtrain HSLM A1’
trai hslm p1 a1

end

Alternatively, a fully custom load model can be defined in TEDDY.

Code example:
+prog sofiload
…

LC #LC type none titl ‘User Loadtrain’
trai user
trpl P 100
trpl p 100 a -2
trpl p 100 a -8
trpl p 100 a -2

end

8.2 Train as a multi-body model

In this approach, a train is represented by a vehicle or a series of vehicles, that consists of a body, 2 bogies, 4 axles and a primary and secondary suspension system, as proposed by [1], [2] and [3]. As applicable, every element has a mass, moment of inertia and suspension characteristics. Suspension elements are represented by a spring and a dashpot working in parallel, modelled in SOFiSTiK as a single FE spring element covering both spring and dashpot properties. A 2D train model with a single vehicle has been used in the tutorial example (a 3D model is also possible using the same principles).

The train model also needs to define a wheel-rail contact (spring Ke in the figure above). The engineer needs to adjust the type of interface to the analytical scope. To investigate a possible loss of wheel-to-rail contact, a simple rigid link, linear spring, Hertzian spring, or a complete, compression-only nonlinear spring are all possibilities.

Note:
rain mechanical properties and geometry need to be derived externally. Please refer to [5] for example values of some common train types.

A train model needs to be created manually using a SOFIMSHA or SOFIMSHC module within the same workspace as track and bridge systems. A degree of text input is required to define train suspension elements consisting of FE springs with viscous damping properties assigned, but for the overall train geometry creation, any available preprocessor is applicable if the meshing process and the resulting node numbers are controlled.

To provide clarity of results gravitational acceleration is not present in the system. It is therefore necessary to apply the self-weight of a train in the form of static loading at the points of wheel-to-rail contact. These forces need to be calculated manually based on the train’s mass and the number of axles. The train nodal masses are recalculated into forces once accelerations resulting from a dynamic excitation are also present in the system, adding to (or subtracting from) the pre-defined gravity forces.

To couple a train system with track and bridge systems, a train system needs to be represented as a SOFILOAD load case containing moving loads (TRAI USER and TRPL functions). Every node of the train system must be referenced in the load case using a TRPL function, with rail contact nodes also requiring the appropriate amount of train self-weight gravity loading (TRPL P variable).

Code example:
+prog sofiload
…

lc #LC type none
trai user

trpl p #force1 a #distance1 cont #node1
trpl cont #node2
…

end

The coding complexity and the degree of information that needs to be carried over from the SOFIMSHA/SOFIMSHC module to SOFILOAD module for creating a functional train multibody model can be significant. It is, therefore, recommended that TEDDY or GRASSHOPPER be used for smooth and convenient data handling and coding.

Note:
For a practical implementation example of a parametric, train multibody model with multiple vehicles, please refer to the Rolling Stock Analysis tutorial (https://www.sofistik.de/documentation/2023/en/tutorials/dynamics/rolling-stock/rolling-stock.html) and its TEDDY example tsi-beam-03c.dat.

9. Direct Time History Analysis

To configure a time history analysis in the DYNA module a set of general parameters needs to be assembled including:

• bridge and abutment length,
• train length,
• train speed,
• load line/axis reference number,
• load train load case with associated irregularities (if applicable),
• Lehr’s damping factor for the bridge system (see e.g. [1], A.3.2).

A set of analysis parameters for the DYNA module must also be defined.

9.1 Number of time steps (STEP N)

The number of time steps, paired with the time step interval, should provide enough time allowance for a complete train system (or loading) to traverse the track and for damping to dissipate the energy in the bridge.

9.2 Time step interval (STEP DT)

A suitable time step interval depends on the frequency of the expected response. A smaller time step size provides a higher degree of definition and allows the inclusion of higher frequency events in the result set while increasing the computational cost. Conversely, a larger time step interval decreases the computational cost while being more prone to damping out the components with smaller periods. For the train-track-bridge interaction problem, the time step interval value highly depends on the properties of the track and train systems and their interaction. The initial value of DT=0.005[s] or less is recommended if no other information is available, and it should be refined accordingly with the model sensitivity studies. For more information, please refer to the relevant literature (e.g. [12]).

9.3 Mass and Stiffness proportional damping (STEP A/B or GRP RADA / RADB)

For more information, please refer to the DYNA manual (eq. 3.15 and 3.16) and the relevant literature. Please note that if the Rayleigh damping cannot be applied globally, e.g. due to the presence of track and vehicle systems, it should be applied to the bridge system through the appropriate group number.

9.4 Numerical method (STEP THE)

Both explicit and implicit direct time history analysis is possible with the SOFiSTiK module DYNA. A range of different numerical methods is also available for implicit analysis.

The engineer should select and configure a numerical method for the given analytical task. For the analysis based on a train as a load model, the Newmark method is recommended (THE=1, BET, and DEL using default values). For the analysis based on a multibody train model, the Wilson method is recommended (THE=1.4, BET, and DEL using default values). Both recommendations are indicative only.

Note:
To assess the overall correctness of the model and the numerical method selection and configuration, several sanity checks are recommended: keeping the scale of deformation within a realistic range, keeping the max accelerations under dynamic excitation within a realistic range, and comparing the max static and dynamic element forces and stresses.

9.5 Results (CTRL RLC, EXTR and HIST)

The extent of results stored for every time step can be configured in DYNA using the CTRL RLC function. It is not recommended in DYNA analysis to request a complete result set for every time step in a scenario with a large number of time steps and multiple passing speeds to investigate, as it significantly increases processing time. A complete CTRL RLC +1+2+4+8 is recommended in smaller systems or in limited scenarios, e.g., numerical method fine tuning or sensitivity study.

The DYNA module has an in-built capability to create and store result envelopes using the EXTR function, regardless of the CTRL RLC settings and results stored for time steps The DYNA HIST function can assemble a time history of particular results and present it as a graphic plot, regardless of the CTRL RLC settings and results stored for time steps. Please refer to the DYNA manual for more information.

Note:
The DYNA EXTR and DYNA HIST functionalities can be mirrored using the MAXIMA and the Results Viewer if the appropriate results for time steps have been saved in CTRL RLC.

10. Results display

Depending on the result type, SOFiSTiK provides several tools for displaying and postprocessing the analysis results.

10.1 Graphic module

A standard set of results is available, e.g., internal forces’ envelopes assembled with DYNA EXTR or using MAXIMA.

10.2 Result Viewer

A fully configurable and tabularized result set can be displayed and presented in a diagram form, e.g., tutorial example bridge midspan deformation and acceleration for every time step.

10.3      Report

A complete text summary, including possible graphic plots if specified with DYNA HIST, is also available.

Example

Download the Train-Track-Bridge Interaction (TTBI) example. (version 2024)

Literature

[1]        UIC Code 776-2, Design requirements for rail-bridges based on interaction phenomena between train, track and bridge, 2009.

[2]        T. Arvidsson, Train–Track–Bridge Interaction for the Analysis of Railway Bridges and Train Running Safety, 2018.

[3]        W. Zhai, Z. Han, Z. Chen, L. Ling & S. Zhu, Train–track–bridge dynamic interaction: a state-of the-art review, 2019.

[4]        D. Cantero, T. Arvidsson, E.J. Obrien, R. Karoumi, Train–track–bridge modelling and review of parameters, 2015.

[5]        G. Kouroussis, D.P. Connolly, O. Verlinden, Railway induced ground vibrations – a review of vehicle effects, 2014.

[6]        W.M. Zhai, K.Y. Wang, J.H. Lin, Modelling and experiment of railway ballast vibrations, 2003.

[7]        D.V. Nguyen, K.D. Kim, P. Warnitchai, Simulation procedure for vehicle-substructure dynamic interactions and wheel movements using linearized wheel-rail interfaces, 2008.

[8]        R.E. Dahlman, E. Lundberg, Parametric Studies of Train-Track-Bridge Interaction, 2021.

[9]        K. Nguyen, J.M. Goicolea and F. Galbadon, Comparison of dynamic effects of high-speed traffic load on ballasted track using a simplified two-dimensional and full three-dimensional model, 2012

[10]      C. Katz, Enhanced analysis of train-bridge interaction, 2006.

[11]      Müller, Bauer, Hensel, Lubinski, Seiler, Eisenbahnbrücken in Massivbauweise nach Eurocode 2 (3. Auflage), 2015.

[12]      ERRI Technical Report D 214, Rail bridges for speeds above 200 km/h, 1999-2000.

[13]      UIC Code 774-3, Track – bridge Interaction. Recommendations for calculations, 2001.