UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Hybrid simulation and its application to the gravity load collapse of reinforced concrete frames Charlet, Arnaud Yves 2007

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata

Download

Media
831-ubc_2007-0354.pdf [ 18.4MB ]
Metadata
JSON: 831-1.0063277.json
JSON-LD: 831-1.0063277-ld.json
RDF/XML (Pretty): 831-1.0063277-rdf.xml
RDF/JSON: 831-1.0063277-rdf.json
Turtle: 831-1.0063277-turtle.txt
N-Triples: 831-1.0063277-rdf-ntriples.txt
Original Record: 831-1.0063277-source.json
Full Text
831-1.0063277-fulltext.txt
Citation
831-1.0063277.ris

Full Text

H Y B R I D S I M U L A T I O N A N D ITS A P P L I C A T I O N TO T H E G R A V I T Y L O A D C O L L A P S E OF R E I N F O R C E D C O N C R E T E F R A M E S by ARNAUD YVES CHARLET B.A.Sc, Ecole Polytechnique (France), 2005 A THESIS SUBMITTED IN PARTIAL FULFILMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF APPLIED SCIENCE in THE FACULTY OF GRADUATE STUDIES (Civil Engineering) THE UNIVERSITY OF BRITISH COLUMBIA July 2007 © Arnaud Yves Charlet, 2007 ABSTRACT The structural testing method called hybrid simulation is implemented at the University of British Columbia. A tutorial is presented to assist the user on how to perform hybrid simulation of structural systems using the finite element software OpenSees, the software framework for hybrid simulation OpenFresco and an event-driven predictor-corrector scheme ensuring continuous testing. Geographically distributed hybrid simulation is introduced and distributed tests performed between the University of British Columbia and the University of California, Berkeley, are described. A hybrid simulation test setup is developed to investigate and validate the application of hybrid simulation to the gravity load collapse of reinforced concrete frames. A shear-critical reinforced concrete column loaded through three dynamic actuators constitutes the physical substructure while a nonlinear ductile reinforced concrete frame makes up the numerical substructure within the OpenSees environment. A nonlinear transformation method is implemented to allow for an accurate application of the three-degree-of-freedom loading on the specimen through the three-actuator test setup, and a specific predictor-corrector algorithm with variable actuator speed is designed to ensure smooth continuous testing despite the use of an implicit iterative integration scheme. Furthermore, a methodology using an iterative predictor-corrector algorithm with mode-switch is developed to enable the use of force control for the actuators in combination with a displacement-based finite element analysis engine. Results from the hybrid tests are compared with a shaking table test of the same structure, and are shown to exhibit the same general behaviour: shear and axial load failure of the shear-critical column followed by gravity load redistribution. However, the inability of the analytical model to capture the residual drifts observed in the shake table tests resulted in an underprediction of the drift demand on the system. ii TABLE OF CONTENTS A B S T R A C T ii T A B L E OF CONTENTS. . . . . . . . i i i LIST OF T A B L E S vi LIST OF F I G U R E S vii A C K N O W L E D G E M E N T S x 1.0 I N T R O D U C T I O N 1 2.0 B A C K G R O U N D 3 2.1 M E T H O D S FOR E X P E R I M E N T A L TESTING 3 2.2 H Y B R I D SIMULATION : 4 2.3 G L O B A L A R C H I T E C T U R E OF AN H Y B R I D SIMULATION S E T U P 6 3.0 S E T U P F O R H Y B R I D S I M U L A T I O N A T U B C 8 3.1 N U M E R I C A L A N A L Y S I S H O S T C O M P U T E R . . . . 9 3.1.1 FINITE E L E M E N T S O F T W A R E O P E N S E E S 9 3.1.2 O P E N F R E S C O 10 3.2 P R E D I C T O R / C O R R E C T O R H O S T C O M P U T E R 15 3.2.1 X P C T A R G E T R E A L - T I M E E N V I R O N M E N T A N D H A R D W A R E 15 3.2.2 X P C T A R G E T APPLICATION: R E A L - T I M E PREDICTOR/CORRECTOR 16 3.3 M T S R E A L - T I M E C O N T R O L L E R FOR T H E A C T U A T O R S '. 21 3.4 S E R V O - H Y D R A U L I C S Y S T E M WITH A C T U A T O R S 22 3.5 S C R A M N E T C O M M U N I C A T I O N LINK 23 3.6 SPECIFIC INFORMATION ON T H E S T S C O N T R O L L E R 25 3.6.1 INITIALIZATION PROCESS OF T H E S T S C O N T R O L L E R 25 3.6.2 P C SIMULATION M O D E FOR T H E S T S C O N T R O L L E R 26 3.6.3 TIPS ON T H E USE OF T H E S T S C O N T R O L L E R S O F T W A R E 27 3.7 M A T L A B T C P / I P APPLICATION P R O G R A M M I N G I N T E R F A C E 27 4.0 T U T O R I A L ON H Y B R I D S I M U L A T I O N W I T H O P E N S E E S 29 4.1 C R E A T I O N O F T H E N U M E R I C A L M O D E L IN O P E N S E E S 29 4.1.1 M O D E L - B U I L D I N G S C H E M E 29 4.1.2 C R E A T I O N OF T H E E X P E R I M E N T A L C O N T R O L O B J E C T . . . . 30 4.1.3 C R E A T I O N OF T H E E X P E R I M E N T A L S E T U P OBJECT 31 4.1.4 C R E A T I O N OF T H E E X P E R I M E N T A L SITE O B J E C T 35 - 4.1.5 C R E A T I O N OF T H E E X P E R I M E N T A L E L E M E N T O B J E C T 36-• 4.1.6 A N A L Y S I S OPTIONS FOR H Y B R I D S I M U L A T I O N . . . : 38 4.2 S E T U P OF T H E PREDICTOR/CORRECTOR R E A L - T I M E APPLICATION 40 4.2.1 INITIALIZATION FILE 40 4.2.2 D I F F E R E N T TYPES OF PREDICTORS/CORRECTORS A V A I L A B L E 42 4.2.3 C O M P I L A T I O N OF T H E PREDICTOR/CORRECTOR M O D E L 44 4.3 D E T A I L E D PROCEDURE FOR L O C A L H Y B R I D SIMULATION TESTING :45 4.3.1 H Y B R I D S I M U L A T I O N WITH S I M U L A T I O N U N I A X I A L M A T E R I A L S 47 4.3.2 H Y B R I D SIMULATION WITH S T S C O N T R O L L E R IN P C SIMULATION M O D E 51 4.3.3 R E A L H Y B R I D SIMULATION WITH PHYSICAL TESTING 52 4.3.4 , T O O L S FOR D O W N L O A D I N G A N D PLOTTING T H E T E S T D A T A FROM X P C T A R G E T 54 5.0 G E O G R A P H I C A L L Y D I S T R I B U T E D H Y B R I D S I M U L A T I O N 57 5.1 G E O G R A P H I C A L L Y DISTRIBUTED T E S T SETUP 57 5.2 O N E B A Y F R A M E M O D E L 60 5.3 T C L C O M M A N D FILES '. 61 iii 5.3.1 C L I E N T - S I D E T C L C O M M A N D FILE 61 5.3.2 R E M O T E S E R V E R 1 ( U C B E R K E L E Y LAB ) T C L C O M M A N D FILE 62 5.3.3 R E M O T E S E R V E R 2 ( U B C LAB) T C L C O M M A N D FILE 63 5.4 R E S U L T S 64 5.4.1 D I S P L A C E M E N T TIME-HISTORIES 65 5.4.2 CONTINUOUS C O M M A N D GENERATION 66 5.4.3 INTEGRATION STEP DURATION 68 6.0 S E T U P F O R H Y B R I D S I M U L A T I O N O F T H E G R A V I T Y L O A D C O L L A P S E OF R E I N F O R C E D C O N C R E T E F R A M E S 71 6.1 PREVIOUS STUDY ON T H E G R A V I T Y L O A D C O L L A P S E OF R C F R A M E S 71 6.1.1 PRESENTATION OF T H E S T U D Y 71 6.1.2 S H A K E T A B L E TESTS SPECIMENS 72 6.2 H Y B R I D SIMULATION S E T U P 73 6.3 DESIGN OF P H Y S I C A L S U B S T R U C T U R E FOR H Y B R I D SIMULATION 75 6.4 E X P E R I M E N T A L T E S T S E T U P FOR H Y B R I D SIMULATION 80 6.5 O P E N S E E S FINITE E L E M E N T M O D E L 82 6.5.1 M O D E L L A Y O U T 83 6.5.2 O P E N F R E S C O OBJECTS 84 6.5.3 C H O I C E OF T H E INTEGRATION S C H E M E 84 6.5.4 OPTIMIZATION OF T H E H Y B R I D SIMULATION R A T E 90 6.6 O P E N F R E S C O E X P E R I M E N T A L S E T U P O B J E C T E S T H R E E A C T U A T O R S L S H A P E 94 6.7 X P C T A R G E T P R E D I C T O R / C O R R E C T O R S C H E M E 96 6.8 M I X E D D I S P L A C E M E N T A N D F O R C E C O N T R O L S E T U P , 99 6.9 T U N I N G OF T H E A C T U A T O R S - S T E E L D U M M Y SPECIMEN 104 7.0 H Y B R I D S I M U L A T I O N O F G R A V I T Y L O A D C O L L A P S E : TESTS R E S U L T S F O R FIRST S P E C I M E N 106 7.1 E A R T H Q U A K E G R O U N D MOTION A N D P E R I O D O F T H E HYBRID M O D E L 106 7.1.1 E A R T H Q U A K E G R O U N D MOTION 106 7.1.2 PERIOD OF T H E HYBRID M O D E L 108 7.2 H Y B R I D SIMULATION T E S T S FOR SPECIMEN 1 109 7.3 H Y B R I D SIMULATION CHARACTERISTICS 112 7.4 . C O M P A R I S O N OF G L O B A L P E R F O R M A N C E WITH S H A K E T A B L E TEST RESULTS. 116 7.5 S H E A R HYSTERETIC RESPONSE OF T H E C E N T E R C O L U M N 121 8.0 H Y B R I D S I M U L A T I O N O F G R A V I T Y L O A D C O L L A P S E : TESTS R E S U L T S F O R S E C O N D S P E C I M E N 126 8.1 IMPROVEMENTS ON T H E HYBRID SIMULATION SETUP 126 8.1.1 P R O B L E M S IDENTIFIED DURING FIRST HYBRID T E S T 126 8.1.2 E X T E R N A L L V D T FOR C O N T R O L OF T H E HORIZONTAL A C T U A T O R 127 8.1.3 M O D I F I E D PREDICTOR/CORRECTOR S C H E M E : " 129 8.2 CHARACTERISTICS OF T H E S E C O N D HYBRID SIMULATION TEST 133 8.3 C O M P A R I S O N O F G L O B A L B E H A V I O U R WITH S H A K E T A B L E T E S T RESULTS 136 8.4 S H E A R HYSTERETIC RESPONSE OF T H E C E N T E R C O L U M N 139 9.0 S U M M A R Y A N D F U T U R E R E S E A R C H '. 141 9.1 S U M M A R Y 141 9:2 F U T U R E R E S E A R C H 142 R E F E R E N C E S 145 A P P E N D I X A : Example file - ThreeSpanBridgeUBC Local.tcl 149 A P P E N D I X B : As-built specimens drawings 153 A P P E N D I X C: source code for ESThreeActuatorsLshapeb 154 C . l . HEADIER FILE E S T H R E E A C T U A T O R S L S H A P E B 2 D . H 154 C.2. S O U R C E FILE E S T H R E E A C T U A T O R S L S H A P E B 2 D . C P P • 156 APPENDIX D: source code for PredictorCorrector 171 C . 1. H E A D E R FILE P R E D I C T O R C O R R E C T O R . H 171 C.2. S O U R C E FILE P R E D I C T O R C O R R E C T O R . C • 173 A P P E N D I X E: manual of operation for the hybrid simulation of the gravity load collapse of R C frames 183 E . 1 S E T U P OF T H E ANALYSIS FILES A N D PREDICTOR-CORRECTOR M O D E L 183 E.2 F L O W C H A R T OF OPERATIONS 184 APPENDIX F: T R O U B L E - S H O O T I N G :....188 v LIST OF TABLES Table 1: Comparison of the properties of the hybrid simulation and shake table specimens 77 Table 2: Concrete Mix Specifications 78 Table 3: Summary of Analysis Options 94 Table 4: Periods of the two-bay frame (shake table test and hybrid test) 108 Table 5: Description of the first hybrid test series Ill Table 6: Summary of the hybrid simulation parameters for the first test (Hybrid Test 1 Part 4) 115 Table 7: Summary of the hybrid simulation parameters for second test 136 vi LIST OF FIGURES Figure 1: The concept of Hybrid Simulation 6 Figure 2: Global Architecture for Hybrid Simulation... 6 Figure 3: Architecture of the Hybrid Simulation Setup at UBC 8 Figure 4: Numerical Analysis Host Computer and Predictor/Corrector Host Computer... 9 Figure 5: Hybrid Simulation Procedure in OpenSees 11 Figure 6:Examples of Experimental Setup objects for loading a cantilever specimen with 2DOF 13 Figure 7: Stateflow Chart of the Event-driven real-time predictor/corrector 18 Figure 8: Simulink real-time Hybrid Controller (global view) 19 Figure 9: xPCtarget Hybrid Controller block of the Simulink Predictor/Corrector Model 20 Figure 10: STS/Flextest Real Time Controller 21 Figure 11: UBC servo-hydraulic system 23 Figure 12: Scramnet+ SC150e PCI card 24 Figure 13: Connections between the cards in a Scramnet serial-ring network 24 Figure 14: expSetup One Actuator 32 Figure 15: expSetup ThreeActuatorsLshape 33 Figure 16: Experimental Element and Experimental Setup systems of coordinates 34 Figure 17: Cantilever basic system and initial stiffness matrix 37 Figure 18: initialization file of the xPC target controller.. 41 Figure 19: Interpolation procedures for continuous command generation 43 Figure 20: modified Three Span Bridge model 46 Figure 21: cantilever beam test setup at UBC 47 Figure 22: OpenSees command window for ThreeSpanBridge_UBC_Local.tcl 49 Figure 23: Exp. Element Force-Deformation Relationship 50 Figure 24: UC Berkeley MicroNEES test setup 57 Figure 25: OpenFresco client-server Software Architecture 58 Figure 26: UBC-UC Berkeley distributed test setup 59 Figure 27: One Bay Frame Model in OpenSees ; 60 Figure 28: Displacements time histories for the UBC experimental column 65 Figure 29: Displacements time histories for the UCB experimental column 66 Figure 30: Continuous command generation 67 Figure 31: Distribution of Integration Step Duration 68 Figure 32: State from the UCB xPCtarget Predictor/Corrector 69 Figure 33: Shake table test specimens 73 Figure 34: UBC Hybrid SimulationTest Setup 74 Figure 35: Hybrid Simulation Test Specimen 75 Figure 36: Concrete strength gain with age 79 Figure 37: Experimental Test Setup and Instrumentation 80 Figure 38: Out-of-plane bracing mechanism 81 Figure 39: Out-of plane and safety supports for hybrid test setup 82 Figure 40: Opensees Finite Element Model for Hybrid Simulation 83 Figure 41: Integration Schemes - Regular Implicit vs Implicit with Substepping 86 Figure 42: Max. Error in Force and Displacement Response between Regular and Substepping HHT as a Function of the Fixed Number of Iterations 88 Figure 43: Max. Convergence Unbalance as a Function of the Fixed Number of Iterations 89 Figure 44: Relative Error as a Function of the Convergence Tolerance 92 Figure 45: OpenFresco Experimental Setup ESThreeActuatorsLshape 95 Figure 46: ESThreeActuatorsLshape nonlinear transformations 96 Figure 47: Lagrange polynomial prediction/correction used with an iterative implicit integrator 97 Figure 48: New prediction-correction strategies used with an iterative implicit integrator 98 Figure 49: Simulink Hybrid Controller with Force Commands Generation + Mode Switch 100 Figure 50: Stateflow chart of the Predictor/Corrector with Force Command Generation 101 Figure 51: Iterative algorithm for the generation of continuous force commands 103 Figure 52: Steel Dummy Specimen Setup 105 Figure 53: Input ground motion 106 Figure 54: Acceleration and displacement response spectra for the input ground motion 107 Figure 55: Free vibration test of the hybrid two-bay frame with slightly cracked center column 108 Figure 56: Damage of center column during first hybrid test 110 Figure 57: Distribution of Integration Step Duration 112 Figure 58: Distribution of number of iterations per integration step 113 Figure 59: Distribution of the duration of one integration iteration 114 Figure 60: Controller, Simulation and Analysis time-steps 116 Figure 61: Relations between center column axial load, vertical displacement, and horizontal displacement of top of center column for first hybrid simulation test... 117 Figure 62: "growth" of the center column with lateral displacements relative to the outside column 119 Figure 63: time histories of the axial loads and vertical displacements on the center and outside columns (hybrid simulation test) 120 Figure 64: Shear hysteretical response of the center column for Hybrid Test 1 and Shake Table Test '. 121 Figure 65: Force-deformation relationships for the loading frame and the specimen.... 122 Figure 66: Actuator and column lateral displacement 123 Figure 67: Effects of nonlinear geometric transformations on measured hysteresis 124 Figure 68: Hybrid Simulation Setup with External LVDT 127 Figure 69: External LVDT 128 Figure 70: Oscillations in the force feedback (First Hybrid Test) 129 Figure 71: New Predictor-Corrector Scheme with SlowStep state 131 Figure 72: Disp. and Force time histories with the new predictor-corrector scheme 132 Figure 73: Distribution of Integration Step Duration 133 Figure 74: Distribution of number of iterations per integration step 134 Figure 75: Distribution of the duration of one integration iteration 135 vm Figure 76: Relations between center column axial load, vertical displacement, and horizontal displacement of top of center column for first hybrid simulation test... 137 Figure 77: Time histories of the axial loads and vertical displacements, Second Hybrid Test... • 139 Figure 78: Shear hysteretical response of the center column for Hybrid Test 2 and Shake Table Test 140 ix ACKNOWLEDGEMENTS I would first like to express my sincere thanks to my supervisors, Dr. Ken Elwood and Dr Terje Haukaas, for their help and guidance through out this research project. I also particularly value the trust and freedom of action I was given in the realization of this project from its very beginning. My sincere thanks are addressed to Andreas Schellenberg, Ph.D candidate at the University of California at Berkeley, for his continuous support and extremely valuable help in the implementation of hybrid simulation, especially OpenFresco, at the University of British Columbia. I would also like to thank all the staff of the Structures lab : Harald Schrempp, Douglas Smith, Douglas Hudniuk, Bill Leung and Felix Yao, as well as the technicians of the Electronics shop, Scott Jackson and John Wong. Their help during the course of the work is gratefully acknowledged. Finally, I would like to thank my friends at the University of British Columbia, particularly Tim Matthews, Clinton Hoffman, Aaron Korchinski and Jose Centeno, for their help and support throughout all of my graduate studies in Canada. The research described herein was made possible through financial support from the Canadian Foundation for Innovation, New Opportunities Fund. This support is gratefully acknowledged. 1.0 INTRODUCTION The gravity load collapse of a structure during an earthquake involves a complicated interaction between the lateral and vertical capacities of the building. The lack of adequate models capturing this interaction has been identified as a critical deficiency of current methods used to assess the collapse potential of reinforced concrete buildings (Comartin, 2001). Quasi-static and dynamic testing of reinforced concrete columns have been conducted to investigate the shear and axial-load capacity of those members (Minowa et al. 1995, Inoue et al. 2000, Sezen et al. 2002, Ghannoum et al. 2005). However, quasi-static tests imply a predefined loading history and do not account for dynamic effects, whereas shaking table tests are limited in the size and mass of the specimens. Hybrid simulation constitutes the third well-established experimental method for structural seismic testing. The terminology hybrid simulation comes from the fact that a structural system is tested experimentally while its inertia and energy dissipation are simulated numerically. Hybrid simulation also allows "substructuring", i.e. experimental substructures can be included in any finite-element model to perform analyses of large and complex structures. The advantages of using hybrid simulation to assess the collapse potential of structural systems are numerous: physical masses are removed from the experimental setup as they are modeled numerically, improving the safety of the tests; the specimens can be tested at large scale; only the vulnerable substructure is tested experimentally while the remaining structure is modeled numerically, improving the economy of the tests; etc. Those benefits make hybrid testing a safe, efficient and less expensive alternative for experimental simulation of structural collapse. However, several challenges must be overcome to apply hybrid simulation to the structural collapse of reinforced concrete columns: an efficient interface has to be implemented to connect the experimental substructure to the numerical model; specific analysis schemes must be chosen to ensure stability and convergence of the numerical model in spite of the presence of a experimental substructure; a complex three-degree-of-freedom loading has to be applied accurately on the specimen; force control of the 1 actuators would be necessary in the linear range for the stiff axial degrees-of-freedom and has to be combined with a displacement-based finite element model; in this case, a mode-switch algorithm has to be implemented to ensure accurate control after initiation of the specimen failure. In this dissertation, Chapter 2 gives an introduction to the concept of hybrid simulation for structural testing. Chapter 3 describes the implementation of hybrid simulation at the University of British Columbia (UBC), whereas Chapter 4 presents a tutorial on hybrid simulation testing using the finite element framework OpenSees (PEER, 2007). In Chapter 5, the concept of geographically distributed testing is addressed and distributed tests performed between the University of British Columbia and the University of California at Berkeley are presented. Chapter 6 describes a test setup developed to investigate the applicability of hybrid simulation to the gravity load collapse of reinforced concrete frames. Strategies implemented to overcome challenges raised by the use of hybrid simulation for the investigation of gravity load collapse are described. Results from two hybrid tests are discussed in Chapter 7 and 8 and compared with a shaking table test of a reinforced concrete frame (Elwood and Moehle, 2003) to assess the validity of hybrid simulation testing for the investigation of gravity load collapse of reinforced concrete frames. 2 2.0 BACKGROUND 2.1 Methods for experimental testing Understanding the behaviour of civil infrastructures subjected to earthquake shaking is indispensable to be able to design efficiently new buildings and to retrofit older structures, so that seismic hazards can be reduced significantly. The experimental testing of new and existing techniques of seismic design is an important step in this process, and it can be performed through three main experimental methods: shake table testing, quasi-static testing and hybrid simulation. Shake table tests are the most realistic way of simulating earthquake loading on a structure. However, the cost of construction of shake tables - especially multi-degree of freedom tables - and the necessity of building the whole structure to be tested limit its use for smaller projects. Moreover, the limited payload capacity implies a substancial reduction in scale of the models tested, which constitutes a major drawback of this method of testing. Quasi-static testing provides a simple and cost-efficient way of testing large structural members using hydraulics actuators controlled according to a predefined displacement/force loading history. The main shortcomings of this method are that the actual response of the specimen has no influence on the loading history, and that the slow rate of loading implies that dynamic effects such as inertia or rate-dependent effects cannot be accounted for. Hybrid simulation - also called "pseudo-dynamic testing" - is an alternative cost-efficient way of testing large-scale structural components under simulated earthquake loading. Developed over the last 30 years (Takanashi 1975, Takanashi and Nakashima 1987, Mahin et al. 1989, Shing et al. 1996, Magonette and Negro 1998), this experimental method consists in loading a structural specimen with hydraulic actuators as if it were responding to an earthquake ground motion using an on-line computer-controlled simulation of dynamic response. This has the advantages of allowing the simulation of virtually large structures while actually testing only a small part of it - thus 3 reducing the cost of experimental specimens. Moreover, unlike quasi-static testing, dynamic effects such as inertia and damping can be accounted for numerically. 2.2 Hybrid Simulation The terminology "hybrid simulation" comes from the fact that a structural system is tested experimentally - usually at low-speed - while its inertial and damping components are simulated numerically. Hybrid simulation also allows "substructuring", i.e. experimental substructures can be included in any finite element model to perform analysis of large and complex structures. Typically, the subcomponents tested experimentally are parts of the structure that are difficult to model numerically - e.g. portions having a complex non-linear behavior -whereas components whose behavior can be efficiently captured by an analytical model are simulated numerically. The only limitations on the size and number of substructures for a hybrid simulation are related to the space and equipment available in the laboratory. Many improvements have been made on the procedures for hybrid simulation since the method was first developed. Ramp-and-hold loading has been replaced by continuous command signal generation, in order to provide improved results by suppressing the force relaxation effects due to the hold phase. Continuous testing techniques are based on algorithms running in real-time environments to insure the commands for the actuators to be updated at deterministic rates. In the case of rate-dependent experimental substructures, real-time applications have been developed for hybrid simulation to enable loading of the experimental elements at realistic seismic rates (Nakashima et al. 1992, Darby et al. 1999, Horiuchi et al. 1999, Nakashima and Masaoka 1999, Darby et al. 2001, Shing et al. 2002). The hybrid simulation test method has then been further extended by enabling experimental substructures located in geographically distributed laboratories to be tested simultaneously, within a unique numerical model using Internet communications (ramp-and-hold: Campbell and Stojadinovic 1998, Watanabe et al. 2001, Tsai et al. 2003, MOST 2003, continous testing: Mosqueda et al. 2005). 4 The problem statement in hybrid simulation is to determine the dynamic response of a model composed of experimental and numerical substructures, and subjected to any kind of loading. Through the use of OpenFresco (Schellenberg and Takahashi, 2007), the Hybrid Simulation setup at U B C allows to link experimental substructures to any finite element model in OpenSees. The governing equation of motion for any structural system is: Mail) + Cv(0 + R(d(t)) = F{t) (1) where M and C are the mass and damping matrices, aft), v(t) and d(t) are respectively the time-dependent acceleration, velocity and displacement response vectors, R(d(t)) is the vector of nodal restoring forces and F(t) is the applied load vector. The main challenge in numerical analysis is to be able to capture precisely the restoring forces for complex structural elements. In the cases where the behaviour of some component is highly nonlinear and/or hard to model numerically, hybrid simulation can be used to replace the approximate restoring force model with actual data measured from an experiment. The concept of hybrid simulation is illustrated in Fig. 1. Similar to any conventional software, a numerical model is developed on the computer, and its governing equation of motion (1) is solved using time-stepping integration schemes. The main difference in hybrid simulation is that the numerical analysis program is linked to one or more physical substructures in the lab. For example, in Fig. 1, one column of the multi-story frame is tested experimentally and linked to the numerical model on the computer. The hybrid simulation setup at U B C uses the finite element framework OpenSees (PEER, 2007) to solve for the displacement vector d(t) satisfying the governing equation of motion (1) at each time step. For the numerical substructures of the system, the restoring nodal forces corresponding to this displacement vector d(t) are obtained internally through the implemented force-deformation models. On the other hand, for the experimental components of the system, the displacement vector d(t) is applied to the structure by means of hydraulic actuators, and the corresponding restoring forces are 5 directly obtained from the sensors and sent back to the computer program to populate matrices necessary to solve for the displacements at the next time step. X". test \ specimen! Numerical model Experimental model Figure 1: The concept of Hybrid Simulation (Mosqueda et al. 2005) 2.3 Global architecture of an Hybrid Simulation Setup Numerical Analysis Host Computer (1) Real-Time Controller for the actuators (2) Communication links (5) Servo-Hydraulic System with Actuators (3) Specimen with Instrumentation (4) Figure 2: Global Architecture for Hybrid Simulation The different components necessary to run any hybrid simulation test are grouped in the following components shown in Fig. 2: (1) a computer hosting the numerical analysis software that will compute the displacement commands based on the model and on the force feedback from the transducers (2) a real-time controller to operate precisely the actuators according to the displacement/force commands (3) a servo-hydraulic system consisting of a set of actuators, servo-valves and a pressurized oil supply (4) a test specimen with the actuators attached at the degrees of freedom to be controlled, and with the necessary instrumentation to measure the force and displacement response (5) communication links and interfaces between the computer, the controller, the actuators and the specimen transducers. If continuous loading is wanted on the specimen (instead of ramp-and-hold), an extra computer running a real-time predictor/corrector (6) must be included between the Numerical Analysis Host Computer and the Real-Time Controller in order to issue command signals at a fast and fixed rate no matter how long the integration scheme takes to solve for the next displacement commands. 7 3.0 SETUP FOR HYBRID SIMULATION AT UBC As explained in Section 2.3, six main components are necessary to perform continuous hybrid simulation (the real-time predictor/corrector being used to create a continuous loading history). In the hybrid simulation setup at UBC, the corresponding components are shown in Fig. 3 and described in more details in the following subsections. Numerical Analysis Host Computer (Section 3.1) Softwate: OpenSees > « TCP/IP channel Predictor/Corrector Host Computer (Section 3.2) Softwate: Simuiink model running in xPCtaiyet i * > « Scramnet Fiber Optics Connection (Section 3.5) MTS Controller (Section 3.3) Softwate: FiexTest or Structural Test System (STS) Servo-Hydraulic System with Actuators (Section 3.4) Specimen with Instrumentation Figure 3: Architecture of the Hybrid Simulation Setup at U B C 8 3.1 Numerical Analysis Host Computer The first component of the Hybrid Simulation Setup at UBC is the Numerical Analysis Host Computer (Fig. 4). This computer is hosting the finite element framework OpenSees (Section 3.1.1) used for the numerical analysis, and the interface between OpenSees and the control system for the actuators is made through the software OpenFresco (Section 3.1.2). Figure 4: Numerical Analysis Host Computer and Predictor/Corrector Host Computer 3.1.1 Finite Element Software OpenSees OpenSees (PEER, 2007) (Open System for Earthquake Engineering Simulation) is a software framework for simulation applications in earthquake engineering using finite 9 element methods, developed by the Pacific Earthquake Engineering Research Center (PEER) since 1997. Useful information and documentation on OpenSees is available on the website: http://OpenSees.berkeley.edu OpenSees is an object-oriented software used by the earthquake engineering research community in North America (mainly in the USA inside the NEES network). It is implemented in C++ through an open-source development process. Most users perform numerical analysis in OpenSees using the Tel scripting language. The main advantage of using this particular finite element software for hybrid simulation comes from the possibility of directly linking OpenSees to any hybrid simulation setup through the software OpenFresco. Moreover, the object-oriented and open-source approach allows anyone to add components to fit his particular needs in earthquake engineering research. 3.1.2 OpenFresco OpenFresco (Open-source Framework for Experimental Setup and Control, Schellenberg and Takahashi, 2007) is an object-oriented software framework that enables researchers to carry out hybrid simulation of structural systems by acting as an interface between a finite element software and any laboratory testing equipment. So far there has been no common framework for the development and deployment of hybrid simulation. Previously, experiments were performed using highly customized software implementations. These were dependent on the control system, the computational procedure used, the site equipment, and they were difficult to adapt to different structural problems. The lack of flexible software for hybrid simulation has until now been a major drawback in the development of this advanced testing method. OpenFresco was developed by Andreas Schellenberg (PhD student, Department of Civil Engineering, University of California at Berkeley) and Yoshikazu Takahashi (Kyoto University, Japan) from 2003 to 2006 to provide a robust, transparent, adaptable and easily extensible framework for hybrid simulation. No modification of the numerical 10 simulation framework is needed, other than the addition of new finite elements representing the physical elements tested. With OpenFresco, the calls to obtain element stiffness, restoring force and other parameters are made just like they would be made in any finite element analysis, except that they are executed physically somewhere in a lab by applying command displacements on a physical substructure. Fig. 5 presents a flowchart of the hybrid simulation procedure in OpenSees. Finite Element Analysis Start the Direct Integration Analysis: Attdyse(ivutt6teps.di); for i -0 to i<nmnSteps do [Calculate and set new Trial Response (Quantities, increment Loads and Time b^y dt: jthehvtegrator-rne wStep(dt); / Solve the current Time Step: | tl»LiiieaiAlg->sor/eCun*ntSt«!p(), Form Effective Tangent or Initial Stiffness A in A.x= b: thelntegratoi->foiTOTatigeni(); Form the Unbalanced Force b in A.x = b: the!nte?jtator-^formUnbaknce(), Solve A.x = b for x: theSOE-?so]ye(); Update the Response at t+dt: t l» I ntegratoi ->updale(:y, V Commit the Domain: thdntegrator-komimtC);. Analytical Substructure | Calculate Tangent or itnti * l 1 Stiffness: JJ getTaiigMttStiffiwsK}, or i gethiitial5tiffness(); Calculate Resisting Forces j getftesistmgForee^), Experimental Suhstinctuie Return Initial Stiffness since Tangent Stiffness can not be obtained: 5etImtialStiffness(), Command Actuators to impose Trial Displacements: >xecute(dsp,vel,acc); [ Measure Forces at Target: ! Aeqmre(cispDaq,l Figure 5: Hybrid Simulation Procedure in OpenSees (NEES Hybrid Simulation workshop, 2006) 11 The architecture of OpenFresco is now outlined. OpenFresco is composed of four main abstract classes: ExperimentalSite, ExperimentalSetup and ExperimentalControl and ExperimentalElement. The first class, ExperimentalSite, has been introduced to accomodate geographically distributed experimental setups. Three instances of this class are available: RemoteExpSite, LocalExpSite and ActorExpSite. LocalExpSite is used when a direct communication with the ExperimentalSetup is available within the OpenSees environment. RemoteExpSite/ActorExpSite are chosen when the experimental control is in a geographical location different from the computational simulation (OpenSees); in this case, this remote location is an ActorExpSite and RemoteExpSite handles the communication (through Internet) between the computational server and the remote server linked to the testing equipment by the means of the Actor and Shadow classes of OpenSees. More detailed information on the functioning of OpenFresco for distributed testing can be found in Takahashi and Fenves (Takahashi and Fenves, 2005). The second class defined in OpenFresco, ExperimentalSetup, transforms the degree-of-freedom (DOF) displacement vector de (Fig. 6) issued by the finite element software OpenSees to a displacement vector sc that will be applied to the actuators by the control system. This displacement vector sc depends on the geometry and kinematics of the loading setup, as different configurations of the actuators can be chosen to apply the same displacement vector at a given DOF: 12 I loading stele : 2 dot , - - — ~ ~ — — — _ _ v I *ct1 . ExpwimentaSalup <E STwoStatieActuator*! 0 ) e specified D O F (I - f t ) " \ d t , . displacement \ vector V. ot element _ i MxMm 12 Rigid tilde (length:!. * » 2 : Exo«nmentaSetup (ESThfwStrtcActiUMor*) Rigid Link (length L i AUuakx #1 Actuated #2 (ksgtkL) f Actuator * J fkngthiL) rd,i id) I control signal vector ! .:)<:• T n :«|C«rilro| Figure 6:Examples of ExperimentalSetup objects for loading a cantilever specimen with 2 D O F (Mosqueda et al. 2005) The third class, ExperimentalControl, represents the control system commanding the actuators and is responsible for converting and sending the actuator displacements to the controller or the predictor/corrector, as well as receiving the data acquisition signals. Two types of ExperimentalControl implemented in OpenFresco are used in UBC: ECxPCtarget and ECSimUniaxialMaterials. ECxPCtarget is responsible for establishing the communication with the real-time predictor/corrector running on the xPC target 13 computer, as well as sending the discontinuous displacement commands to the predictor/corrector and receiving the measured restoring forces. ECSimUniaxialMaterials is used to simulate the behavior of any number of actuators through any uniaxial materials force-deformation relationships from OpenSees. This simulation mode allows to test the numerical model before connecting to the laboratory testing equipment. The last class, ExperimentalElement, defines the different finite elements that can be used as an interface between the finite element model and the physical substructure. The following instances are available: expElement Truss, expElement BeamColumn, expElement Generic, expElement ZeroLength and expElement InvertedVBrace. These elements are similar to any type of finite element in OpenSees except that the calls to obtain element stiffness, restoring force and other parameters are transfered to the physical substructure through the three objects ExperimentalSite, ExperimentalSetup and Experimental Control. The use of these different classes will be described in Chapter 4, and more information on OpenFresco can be found in OpenFresco Framework for Hybrid Simulation: Installation and Example Guide (Schellenberg et al., 2006), and the PhD dissertation Advanced Implementation of Hybrid Simulation (Schellenberg, 2007). Notes: There are 2 ways of using OpenFresco for hybrid simulation: in case of distributed testing, if UBC is only playing the role of experimental substructure then OpenFresco.exe will be used. If the numerical analysis is performed on the workstation then OpenSees.exe will be the main software and OpenFresco will be used by OpenSees through OpenFresco.dll. Make sure that OpenFresco.exe, OpenSees.exe and the four dll (Dscoml32.dll, OpenFresco.dll, Pnpscr.dll and xpcapi.dll) are located in the same folder. 14 3.2 Predictor/Corrector Host Computer The predictor/corrector host computer is running a real-time algorithm that enables continuous hybrid testing by generating continuous command signals for the actuators controller regardless of delays in the computation in OpenSees (or in the communication between the computers in the case of geographically distributed testing). The first subsection will introduce the xPCtarget real-time environment (The Mathworks, 2007) that is used to run the predictor-corrector scheme, and the corresponding hardware requirements will be detailed. The second subsection will present the predictor-corrector algorithm used to perform continuous hybrid testing. 3.2.1 xPCtarget real-time environment and hardware xPCtarget (The Mathworks, 2007) is a specific kernel that allows to run custom algorithms in real-time on any type of computer. These custom applications can be generated from Simulink (The Mathworks, 2007) and Stateflow (The Mathworks, 2007) models, as explained in Section 3.2.2. The xPCtarget environment imposes drastic requirements on the host hardware; the most important of them are listed below: - The target computer must have at least 2 PCI slots available (more would be preferrable to fix possible IRQ assignment problems, see troubleshooting section) - The PCI Ethernet card provided by Matlab (Intel Pro 100 / S) must be used for the TCP/IP connection between the Host and Target computer. Note that a list of the other compatible Ethernet cards and their corresponding driver number (to specify in the xPC Explorer settings) is available on the Mathworks website. 15 - The Scramnet PCI card must be mounted on the PCI slot such that the assigned IRQ number does not create conflicts with the Ethernet card (see troubleshooting section) - In order to be able to write data from the real-time application,, the hard-drive must be a PATA hard-drive formatted in FAT32 (or FAT16), and the main partition size must be 4Gb maximum. Note that Pentium 4 processors are known not to perform well with the xPCtarget kernel. The command xpcbench('this') in Matlab (The Mathworks, 2007) allows to assess the performance of the hardware used for xPCtarget in comparison to reference configurations. The poor behaviour of the xPCtarget predictor/corrector on the Dell Pentium 4 computer used originally (undetected errors during execution halted communication between the Numerical Analysis Host Computer and the Predictor/Corrector Host Computer) led to the replacement of the Dell Pentium 4 with an AMD Athlon64 providing much better performance. No requirements are specified for the Numerical Analysis Host Computer; in particular there is no requirement on its Ethernet card since this card is managed by Windows. However, the Ethernet cards of both Host and Target computer used for the xPCtarget connection must have a static IP address. 3.2.2 xPCtarget application: real-time predictor/corrector As mentioned earlier, the xPCtarget environment allows running real-time applications generated from Simulink and Stateflow models. Simulink is a block library tool for modeling, simulating and analyzing dynamic systems. Combined with Real-Time Workshop (The Mathworks, 2007), another toolbox in the Matlab environment, Simulink can generate C code for real-time implementations of systems. Stateflow is an interactive design and simulation tool for event-driven systems. All these tools are used to create the event-driven real-time predictor/corrector algorithm used for Continuous Hybrid Simulation. This algorithm was originally developed by Nakashima and Masaoka (1999) and subsequently refined by Mosqueda (2003) and 16 Schellenberg (2005). Further modifications on this predictor/corrector were implemented specifically for the hybrid simulation of the gravity load collapse of reinforced concrete frames, and will be presented in section 6.8. Continuous Hybrid Simulation is performed when continuous command signals are generated and sent to the actuators independently of the time needed for solving each integration step of the numerical model. As explained in 2.2, this is done to improve the results by suppressing the force relaxation effects due to the hold phase. The predictor-corrector is an algorithm running in the xPC target real-time environment; its goal is to insure that the commands for the servo-hydraulic controller are updated at deterministic rates. To do that, the following procedure is followed (Fig. 7): After reaching the target displacement corresponding to the commands sent by the numerical model in OpenSees, the actuators are kept in motion by predicting a command signal based on an interpolation of the previous target displacement values (predictor mode, corresponding to the Predict state in Fig. 7). Meanwhile, OpenSees is carrying out computations for the next target displacement. - When the integration task is over, the new target displacement is received by the predictor-corrector which switches to the corrector mode ( corresponding to the Correct state in Fig. 7): using polynomial interpolation, the algorithm corrects the path of the actuators in order to smoothly reach the target value at the end of the simulation time step. If the integration task lasts for too long, the actuators could deviate substantially from the intended trajectory and overshoot the next target displacement. That's why the algorithm switches to an AutoSlowDown phase (AutoSlowDown state in Fig. 7) when the prediction phase exceeds a given portion of the simulation time step. In this case, the motion of the actuators is smoothly slowed down until the next target displacement is received from OpenSees. 17 "*1 ore' HybridController Iriitialize en: i = 0; iSD = 0: diSD = 1; initData(nAct); zeroDspf&corn); [nag=1J ..... >• i; I Correct en: state = 0: en: setCui£tep(&com,(i+iDelay)/N); en: setMewDsp(&dsp); en: di = miri(max(diSD+1/(D.2'Nr(i-iSD),0.001),1,0), en: i = rnin(i+di,M); en: correctP3(£.com,(i+iDelay)/N); du: di = min(maK(diSD+1/(0.2^J'f(i-iSD),0.00l),1 0); du: i = min(i+di,M): \ du: correctP3(&com,(i+iDeray)/N); 1 Predict en: state = 1; en: diSD = 1; en: i = 1; iSD = 0; en: predictP3(&com ,£i+iDeiay)/N); du: d u: p r e d i 11P3 (&c o rn, (i +i D e I a y)/N); a. J |fia.g==11 (i>=0.6*N &&flag~=1] i*" AutoSlowDown en: state = 2; en: diSD = 4-i/ip.2*M); en: i += diSD; iSD = i; en: predictP3(&com,{i+iDelay)/N); du: diSD = 4-i/(0.2*N); du: i += diSD; iSD = i; du: predic;tP3(&c om,(i+iDelay)/N); Fig. 7 presents the Stateflow chart defining this event-driven predictor/corrector scheme. The Predict, Correct and AutoSlowDown states have been described before; N is the number of subiterations within one simulation step (addressed in Section 4.2), and flag is an indicator switching to the value of 1 whenever the new target displacement is received from OpenSees. / and iSD are substeps indices (SD refering to the SlowDown phase) whereas di and diSD are increments for these indices. For more information on the detailed functioning of the chart one should refer to Mosqueda (2005) and Schellenberg (2005). S C 1 S O intt i n p u t t f o m sc ramrte t master s p a n oti mod*s dispi c m d s tore* c m d s displ tb*$ force fbk* d^Uaf1 t'bks \<atve c m d s us*r 3dcs user user e n c s dig irtftS Hybrid Controller o»jtf>ut to s c r a m n e t m a s t e r <-p3r. 3 >* Ext rac t xPC Target Hybrid Controlier 3 -3 ietmS Ha d i g o u t s master span dig out? H H - 3 Figure 8: Simulink real-time Hybrid Controller (global view) (Schellenberg, 2005) JUBCRT AclualTest | Fig. 8 presents a global view of the Simulink real-time model containing the predictor/corrector scheme. Note the interface with the Scramnet shared memory (input from Scramnet, output to Scramnet) that allow the application to read and write data that are instantly available to the actuators' controller. 19 updateFlag uFlag zeros(1,nAcf) targDsp flag targetFlag dspln frcln new Target flag Data Store Memory dsp flag Predictor-Corrector File Scope Id: 4 Signal Offset Moving Ave rage Filter Signal Moving Ave rage Offset w Filter tDsp File Scope Id: 2 File Scope Id: 3 counter measDsp Out measDsp In measFrc In measFrc Out atTarget File Scope Id: 1 measDsp dsp Out TerminatoM File Scope Id: 5 Figure 9: xPCtarget Hybrid Controller block of the Simulink Predictor/Corrector Model (Schellenberg, 2005) Fig. 9 shows the details of the subsystem xPCtarget Hybrid Controller present in Fig. 8. This subsystem is responsible for generating the continuous commands com for the actuators from the target displacements targDsp received from OpenSees through the Stateflow chart Predictor-Corrector whose details are shown in Fig. 7. This subsystem is also responsible for the filtering (Moving Average Filter) and the reading (within the atTarget block) of the force and displacement feedbacks once the target have been reached, as well as the recording of the internal variables (File Scope blocks). Because of the obvious complexity of the model, more detailed explanations on its functioning are not provided in this dissertation; this information is available in Mosqueda (2005) and Schellenberg (2005). 20 3.3 MTS Real-Time Controller for the actuators Figure 10: STS/Flextest Real Time Controller A MTS controller (Fig. 10) is used for the real-time control and operation of the hydraulic actuators of the hybrid simulation setup. Two control software can be used within this MTS controller: FlexTest GT (MTS, 2007) or Structural Test System, commonly known as STS (MTS, 2007). Note that the FlexTest GT controller is not used in the hybrid simulation setup described in this dissertation. Enclosed in the MTS Control Console (Fig. 10), the MTS controller is made up of 2 main components: 21 a PowerPC performing the control algorithms and linked to the servovalves, manifolds, tranducers and encoders of the test setup - the Graphical User Interface (GUI) software (STS or FlexTest) running on the associated MTS Host Computer and linked to the PowerPC through a TCP/IP Ethernet connection. The control of the actuators is realized through the GUI software (STS or FlexTest) running on the MTS Host Computer, or through the remote control Pod for basic commands. The GUI software is only the Graphical User Interface associated with the PowerPC and all the control algorithms are performed on the PowerPC. 3.4 Servo-Hydraulic System with Actuators The servo-hydraulic system used for hybrid simulation in UBC consists of 3 dynamic actuators with 2-stage servovalves (2x35kips and lx70kips), 1 dynamic actuator with a 3-stage servo valve (1000 kN), several static actuators of various capacities, and a hydraulic pump for pressurized oil supply used with one 250 gpm MTS manifold and one 50 gpm MTS manifold (Fig. 11), 22 a) 1000 IeN Dynamic Actuatoi Figure 11: U B C servo-hydraulic system 3.5 Scramnet communication link As shown earlier on Fig. 3, a Scramnet (Systran, 2007) shared memory network is used for the communication between the Predictor/Corrector Host Computer and the MTS controller for the actuators. Scramnet is a real-time communications network based on the concept of replicated shared-memory. By means of a special card (PCI, VME6U, etc, Fig. 12), each host processor on the network has access to its own local copy of shared memory that is updated over a high-speed fibre optics serial-ring. This kind of network is optimized for the high-speed transfer of data among multiple real-time computers that are all solving for portions of the same real-time problem. 23 • » s * Figure 12: Scramnet+ SC150e PCI card Instructions on the use of the Scramnet fibre optics connections: Each Scramnet card has 4 fibre optics connectors: the 2 "Tx" connectors (Transmitters) of a board must be connected to the 2 "Rx" (Receivers) connectors of the next card in the Scramnet serial-ring network, whereas the 2 "Rx" connectors must be connected to the "Tx" connectors of the previous card in the ring, as shown in Fig. 13. However, there is no polarity inside each category ("Tx" or "Rx"), i.e. any of the two cables coming from the "Tx" connectors can be plugged in any of the two "Rx" connectors of the next card. The Scramnet shared memory network is working properly if the Scramnet light on the main panel of the STS software turns green when the xPC target computer is switched on. Scramnet card 3 Tx 0 0 Rx 0 0 Scramnet card 1 Tx 0 0 © 0 R x Scramnet card 2 do 0 Scramnet serial-ling network >-Figure 13: Connections between the cards in a Scramnet serial-ring network (Note: three cards shown for illustration purposes, but U B C system has only two cards.) 24 Caution: when using fibre optics cables, one should take care of not exceeding a minimum bend radius of 2 inches in order not to break the fibres. Do not step on the fibre optics cables. 3.6 Specific information on the STS controller This section provides specific information on the use of the STS controller. In particular, the initialization process is explained in a first subsection, and details are provided on the use of the special PC simulation mode that allows to run a verification test without actually turning on the pump. The last section provides useful tips for the use of the STS software. 3.6.1 Initialization process of the STS controller The initialization process of the STS controller requires the following steps: 1. Switch on the Uninterruptible Power Supply (UPS) 2. Switch on the controller Host Computer 3. When the Windows environment is loaded and ready on the Host Computer, double-click on "FTP from STS" on the Desktop. This will specify the path of the files downloaded by the PowerPC during the boot process. 4. Run "Coops.ht" from the Host Computer desktop. This software is not necessary but allows to visualize the boot process. 5. Switch on the PowerPC. The different steps on the boot process for the PowerPC are displayed in "Coops.ht". If the PowerPC was already running and you want to reboot, the controller, press "Ctrl+X" when the "Coops.ht" window is active. This will restart the initialization process for the PowerPC. 25 6. Once the initialization process is done, "Done executing startup script" will be displayed in the Coops window. You can then run "STS.exe" from the Host Computer desktop. "Coops.ht" can be closed. 3.6.2 PC Simulation mode for the STS controller The PCsimulation mode for the STS controller consists in using a Simulink model to simulate the behaviour of the hydraulic actuators and their payloads without having to switch on the pump. It allows checking the proper behaviour of the Hybrid. Simulation framework (numerical model, communication links, predictor/corrector, control algorithms, etc) before it is used with the actual test specimens. To run STS in PCSimulation mode: - in settings.set, Super.dll must be replaced by SuperSim.dll - start the STS GUI (sts.exe), and check Use simulatedfeedback in the main panel - open the PCSimulation Simulink model (PCSimulation.mdt) and press play - start the function generator on the STS software, and open the oscilloscope to visualize the displacement/force command and feedback. PCSimulation is working if we can observe non-zero displacement/force feedback due to any displacement command from the function generator. Notes: If some of the actuators have to be simulated in force control, the Simulink model must be run at a sample rate higher than the controller in order to decently capture the dynamics of the system (in force control, the dynamics have a larger bandwidth due to the absence of velocity and displacement integration). This can be done in PCsimulation mode by modifying the parameter upsampleFactor in the initialize.m file. The default value used in displacement control is upsampleFactor=2, meaning that the Simulink model runs 2 times faster than the controller rate (which is fixed to 1024Hz). In the case of force control, it is useful to increase this upsampleF actor value up to 26 10 or more. This will improve the accuracy of the dynamic response computed by the numerical model, but it will also slow down the execution speed of the Simulink model. An internet connection is necessary in order to be able to start Matlab and Simulink. However, the network connection is not necessary anymore once Matlab is initialized, and it can then be used as the internet connection for the OpenSees host computer. 3.6.3 Tips on the use of the STS controller software This section provides a few tips for the use of the STS software: Some of the choices in the pulldown menus have the symbol "->" at the right end (examples: Change access ->, Translate -> in the File menu). To access the different options available, you have to slide the mouse cursor all the way to the extreme right of the menu box at the height of the "->" symbol. Clicking on the command name will not display the available options. - The STS software always uses "Settings.sef'.as the default setting file during the initialization process. In order to use the settings saved for a given test setup, one must first change the access level from Basic to Extended through the command Change access ->. The Restore settings command will then be available to load a previously defined settings file. More information on how to use the STS software can be found on the MTS Reference Binder Volume 1 of 5 (Reference, Job No. USE 28037, University of British Columbia, Structural Test System). 3.7 Matlab TCP/IP Application Programming Interface Brad Thoen from MTS developed an Application Programming Interface (API) in the Matlab environment in order to be able to run the STS controller from Matlab through a 27 TCP/IP connection. The files can be found in ubcsts\api on the STS Host Computer, and an example of the use of these commands is illustrated in ApiExample.m. These commands can be useful if hybrid simulation needs to be implemented in a Matlab-base finite element software such as G2. 28 4.0 TUTORIAL ON HYBRID SIMULATION WITH OPENSEES This chapter presents a detailed tutorial on hybrid simulation using OpenSees as the numerical analysis software. Section 4.1 provides explanations on the modifications to the numerical model in OpenSees required to enable hybrid simulation. Section 4.2 gives information on the setup of the predictor-corrector application used for continuous testing, whereas Section 4.3 presents the detailed procedures for hybrid simulation through the use of an example model. 4.1 Creation of the numerical model in OpenSees The implementation of hybrid simulation in OpenSees only requires the use of experimental elements (through the definition of 4 Tel objects) and the use of specific integration schemes inside the usual simulation framework. 4.1.1 Model-building scheme The construction of the numerical model follows the same scheme as in any simulation with OpenSees, except that an Experimental Element has to be defined to integrate the physical substructure in the model. The creation of an Experimental Element is made through the definition of four objects: expControl, expSetup, expSite and expElement. Here are the required steps: Just after the command model BasicBuilder, the OpenFresco dll package has to be loaded by adding the command loadPackage OpenFresco (see the tel file example). The Experimental Control has to be created. Two instances of expControl can be used at UBC: expControl SimUniaxialMaterials and expControl xPCtarget. 29 - The Experimental Setup has to be defined. The choice of the expSetup depends on the configuration of the loading setup: expSetup OneActuator, expSetup Three Actuators, etc. - The Experimental Site object must be created by chosing between expSite LocalSite, expSite RemoteSite and expSite ActorSite. - The Experimental Element must then be defined. The following instances are available: expElement EETruss, expElement EEBeamColumn, expElement EEGeneric, expElement EEZeroLength and expElement EEInvertedVBrace. Note: the required arguments for each of the selected objects can be found in TclExpControlCommand.cpp, TclExpSetupCommand.cpp, TclExpSiteCommand.cpp and TclEEBeamColumnCommand.cpp (for the Beam Column experimental element for example). Search for an output line saying "Want: expElement beamColumn eleTag iNode jNode transTag..." These files are located in the OpenFresco 2.0 source folder and can also be accessed through the Visual Studio 2005 solution OpenFresco.sin. 4.1.2 Creation of the Experimental Control object Two instances of expControl can be used at UBC: expControl SimUniaxialMaterials and expControl xPCtarget. expControl SimUniaxialMaterials is used for simulation purposes: the behaviour of the experimental substructure is modelled numerically through the use of previously defined Uniaxial Materials. These Uniaxial Materials must describe the force-displacement relationship of the substructure at the location of each actuator. For example, the lateral stiffness of the "green cantilever column" setup (shown later in Fig. 21) is about 16kN/cm. If the set of units used in the OpenSees model is {kN,cm} (or if the conversion factors have been correctly defined in the expSetup), a uniaxial elastic material of modulus 16 could be used with expControl SimUniaxialMaterials in the case of a OneActuator setup pushing laterally. The syntax is: expControl SimUniaxialMaterials Stag SmatTags Example: 30 uniaxialMaterial Elastic 1 16; # lateral stiffness 16kN/cm expControl SimUniaxialMaterials 1 1; expControl xPCtarget is chosen when the xPC target real-time environnement is used as the interface between the OpenSees numerical simulation and the controller. The syntax is: expControl xPCtarget tag type ipAddr ipPort appName appPath. ipAddr and ipPort are the IP address and IP port of the xPCtarget computer (setup arbitrarily at UBC with the values given in the following example), appName is the name of the Simulink application that will be downloaded to the xPCtarget computer (it must have been previously compiled), and appPath is the path of this application in the host computer (Note that Tel requires two \ instead of one normally). Example: expControl xPCtarget 1 1 "148.150.203.192" "22222" "HybridContr oiler Poly 3 "\ "D:\\xPC target Predictor ControllerW" 4.1.3 Creation of the Experimental Setup object The choice of the expSetup depends on the configuration of the loading setup: expSetup OneActuator, expSetup TwoActuators, expSetup Three Actuators, expSetup InvertedVbrace, expSetup NoTransformation and expSetup Aggregator. An illustrated description of these different configurations can be found online in the presentations of the NEES Hybrid Simulation workshops (NEES, 2006) (Implementation Framework -OpenFresco [Schellenberg], HSW-OpenFresco.pdf). Note that the required arguments for each method should be checked by looking at TclExpSetupCommand.cpp. Two instances of expSetup have been used in UBC: expSetup OneActuator and expSetup ThreeActuatorsLshape (developed specifically for the UBC three-actuator test setup, see Part 6.7). 31 Actuator Specimen Figure 14: expSetup One Actuator (NEES Hybrid Simulation workshop, 2006) expSetup OneActuator (Fig. 14): Syntax: expSetup OneActuator tag <-control ctrlTag> dir <-ctrlDispFact f> <-ctrlVelFact f> <-ctrlAccelFact f> <-ctrlForceFact f> <-ctrlTimeFact f> <-daqDispFact f> <-daqVelFactf> <-ctrlAccelFactf> <-daqForceFactf> <-daqTimeFactf> A l l parameters between "<>" are optional. ctrlTag is the tag of the corresponding experimental control, dir is the direction of loading (1-6 for a 3D 6-DOF element). ctrlDispFact, ctrlVelFact, CtrlAccelFact, ctrlForceFact , ctrlTimeFact are conversion factors (e.g. unit conversions, similitude factors, etc) for the control commands sent to the controller; for example, after they have been converted into actuators commands, the displacement commands from OpenSees are multiplied by ctrlDispFact and then sent to the controller. daqDispFact, daqVelFact, daqAccelFact, daqForceFact, daqTimeFact are conversions factors for the data acquisition^ signals; for example, the force feedback from the load cells is divided by daqForceFact before it is converted back to the element DOF forces. Example: expSetup OneActuator 1 -control 1 2 -ctrlDispFact 2.54 -daqDispFact 2.54 \ 32 -daqForceFact 4.4482; Figure 15: expSetup ThreeActuatorsLshape expSetup Three Actuator sLshape - due to the L shape of the loading frame (Fig. 15) : Syntax: expSetup ThreeActuatorsLshape tag <-control ctrlTag> LaO Lai La2 LO LI L2 L3 L4 L5 <-nlGeom> <-posActOpos> <-phiLocXphi> <-ctrlDispFactf> <-ctrlVelFactf> <-ctrlAccelFact f> <-ctrlForceFact f> <-ctrlTimeFact f> <-daqDispFact f> <-daqVelFactf> <-ctrlAccelFactf> <-daqForceFactf> <-daqTimeFactf> All parameters between "<>" are optional. ctrlTag is the tag of the corresponding experimental control. LaO, Lai and La2 are the lengths at zero-displacement of the three actuators of the test setup (see Fig. 15). LO, LI, L2, L3, L4 and L5 are the different lengths of the loading frame as shown in Fig. 11. -nlGeom is an optional parameter that enables 33 the nonlinear geometrical transformations for the conversion of displacements into actuators commands (default: linearized transformations). posActO is an optional parameter specifying the position of the horizontal actuator relatively to the specimen, being set either to right or left (default: left). phiLocX specifies the angle in degrees between the experimental element system of coordinates and the experimental setup system of coordinates (Fig. 16) (positive if clockwise, ex: phiLocX=90 for the setup shown in Fig. 15). a) Experimental Element BeamColumn b) Experimental Setup ThieeActuatoisJntGff system of coordinates system of coordinates Figure 16: Experimental Element and Experimental Setup systems of coordinates (Left figure: NEES Hybrid Simulation workshop, 2006) ctrlDispFact, ctrlVelFact, CtrlAccelFact, ctrlForceFact , ctrlTimeFact are conversion factors (e.g. unit conversions, similitude factors, etc) for the control commands sent to the controller; for example, after they have been converted into actuators commands, the displacement commands from OpenSees are multiplied by ctrlDispFact and then sent to the controller. daqDispFact, daqVelFact, daqAccelFact, daqForceFact, daqTimeFact are conversions factors for the data acquisition signals; for example, the force feedback from the load cells is divided by daqForceFact before it is converted back to the element DOF forces. Note that there should be as many factors as there are actuators to control: for a 34 ThreeActuatorsLshape setup, -ctrlDispFact 2.54 2.54 2.54 -daqForceFact 4.4482 4.4482 4.4482 Example: expSetup ThreeActuatorsLshape 1 -control 1 $LaO $Lal $La2 $L0 $L1 $L2 SL3 $L4 $L5 -nlgeom -posActl right -phiLocX 90 -ctrlDispFact 2.54 2.54 2.54 -daqForceFact 4.4482 4.4482 4.4482; Note: in the case of distributed testing, the expSetup object can be defined either on the numerical simulation side or on the physical substructure side. 4.1.4 Creation of the Experimental Site object The Experimental Site object must be created by chosing between expSite LocalSite, expSite RemoteSite and expSite ActorSite. The first one will be used for a local hybrid simulation, ie when physical substructure and numerical computation are performed in the same location. The second one will be used on the numerical simulation side of a distributed test whereas the last one will be used on the physical substructure side of a distributed test. Syntax and examples: # expSite LocalSite Stag SsetupTag expSite LocalSite 1 1 # expSite RemoteSite Stag <-setup $setupTag> SipAddr SipPort <$dataSize> expSite RemoteSite 1 "127.0.0.1" 8091 35 # expSite ActorSite Stag -setup SsetupTag SipPort <$dataSize> expSite ActorSite 1 -setup 1 8091 256 4.1.5 Creation of the Experimental Element object The following instances of the Experimental Element class are available: expElement Truss, expElement BeamColumn, expElement Generic, expElement ZeroLength and expElement InvertedVBrace. An illustrated description of these different elements can be found online in the presentations of the NEES Hybrid Simulation workshops (NEES, 2006) (see Implementation Framework. OpenFresco. [Schellenberg], HSW-OpenFresco.pdf). The required arguments for each element type method should be checked in TclEEBeamColumnCommand.cpp, TclEETrussCommand.cpp, etc. Specific recorder arguments have been implemented in order to store the target and measured commands, local and global forces, etc of these experimental elements. The available recorder arguments can be found in the definition of the setResponse method inside EEBeamColumn2d. epp, EETruss.cpp, etc. So far expElement ZeroLength and expElement BeamColumn has been used at UBC. Here are the syntax and an example for each of them: # expElement zeroLength SeleTag $iNode $jNode -dir Sdirs -site SsiteTag -initStif $Kij <-orient $xl $x2 $x3 $yl $y2 Sy3> <-iMod> <-mass $m> expElement zeroLength 113 -dir 2 -site 1 -initStif 2.8 -orient 010-100 # expElement beamColumn SeleTag $iNode SjNode StransTag -site SsiteTag -initStif SKij <-iMod> <-rho Srho> 36 expElement beamColumn 203 308 108 1 -site 1 -initStif 4748.2 7 0 0 0 29.17 -845.73 0 \ -845.73 32706.4 -initStif $Kij corresponds to the initial stiffness matrix (3x3) of the element in the basic cantilever system (Fig. 17), in the units of the numerical model in OpenSees. Figure 17: Cantilever basic system and initial stiffness matrix (Left figure: N E E S Hybrid Simulation workshop, 2006) It is important to provide a good estimate of the initial stiffness matrix of the element because no computation of the experimental tangent stiffness has been implemented in OpenFresco. As a result, only the initial stiffness is used in the solution algorithm. The following element data can be recorded using the recorder object in OpenSees: globalForces (in the global system of coordinates), localForces (in the element system of coordinates), basicForces (in the cantilever basic system of coordinates), targeiDisplacements, targetVelocities, targetAccelerations (in the cantilever basic system of coordinates) and measuredDisplacements, measuredVelocities, measuredAccelerations (in the cantilever basic system of coordinates). More details on the available recorder arguments can be found in the definition of the setResponse method inside EEBeamColumn2d. cpp. Examples: recorder Element -file ElmtFrc. out -time -ele 203 basicForces; 37 recorder Element -file ElmttDefout -time -ele 203 targetDisplacements; recorder Element -file ElmtjnDef.out -time -ele 203 measuredDisplacements; 4.1.6 Analysis Options for Hybrid Simulation Specific Integrator objects for OpenSees have been implemented (Schellenberg, 2007) to account for the following characteristics of Hybrid Simulation: - overshooting in the convergence algorithm should be avoided because of the path dependent behaviour of the physical element, - in order to avoid slowing down the simulation, as few calls as possible should be made to obtain the restoring forces from the physical substructure, - a constant Jacobian equal to the initial stiffness has to be used in the numerical method since the tangent stiffness is not available from the physical substructure. The different Integrator objects available are: Explicit Integrators: - Explicit Newmark Method - Central-Difference Method - explicit Alpha-Method - generalized explicit Alpha-Method Explicit integrators are usually the best solution for hybrid simulation since their explicit formulation requires no iteration during the convergence process, thus allowing for an increase in the hybrid simulation speed (see Section 4.2). However, explicit integrators are usually conditionally stable; this leads to requirements on the maximum analysis time step that can be used, which is limited by the smallest period of the structure analyzed, and they also require mass to be specified at every node in the numerical model. As a result, explicit integrators can usually not be effectively used for models with a large number of degrees of freedoms. 38 Implicit Integrators: - Newmark Method - Alpha-Method - HHT Method (also called Generalized Alpha-Method) - Collocation Method Implicit integrators present the advantage of being unconditionally stable, what results in no limitation on the maximal time step used during the analysis. However, their iterative convergence scheme is detrimental to the overall hybrid simulation speed since a variable number of iterations are usually required to compute one analysis time step. Moreover, these implicit integrators are used in combination with a Newton algorithm, and lead to an uneven distribution of the amplitude of the convergence increments undesirable for hybrid simulation (see Section 6.6.3 for details). Implicit Integrators with sub-stepping (constant number of iterations): - Newmark-HybridSimulationMethod - HHT-HybridSimulationMethod - Collocation-HybridSimulationMethod These integrators have been developed to get rid of the uneven distribution of the amplitude of the convergence increments typical of implicit integration schemes, which is not desirable for hybrid simulation (a detailed discussion on implicit integrators with or without substepping is presented in Section 6.6.3). They use a fixed number of iterations to distribute more uniformly the convergence increments during the convergence process and avoid jumps and speed variations in the actuators motion. However, it is shown in Section 6.6.3 that their performance is quite poor for highly nonlinear models. Predictor-Corrector Integrators: 39 - Alpha-OS Method - Generalized Alpha-OS Method The a-operator splitting (a-OS or alpha-OS) scheme is a convenient linearisation of the so-called a-method. It is a non-iterative implicit time integration scheme particularly useful for hybrid simulation (more information in Combescure et al, 1997). Note that the Predictor-Corrector Integrators require a Linear Algorithm object. More information on all these integration schemes is available on the OpenSees webpage and in Schellenberg (2007). 4.2 Setup of the predictor/corrector real-time application The real-time application running on the xPC target computer is the interface between the simulation software OpenSees and the actuators controller. It is in charge of the generation of continuous command signals updated at deterministic rates using a three-state event-driven controller as explained in 3.6. 4.2.1 Initialization file The different parameters used in the xPC target application are defined in the initializeSimulation.m file. This file is called when the predictor/corrector Simulink model is loaded in Matlab. It initializes not only the parameters specific to hybrid simulation but also all the parameters necessary to setup the Scramnet communication between the xPC target computer and the hydraulic controller. Modifications should only be made to the "Hybrid Controller Parameters" section of initializeSimulation.m presented in Fig. 18: 40 ;s INITIALIZE SIMULATION to i n i t i a l i z e the parameters needed to b u i l d the Simulink model % modified by Andreas Schellenberg (andreas.3chellenberqBqmx.net) 11/2004 c l e a r ; close a l l ; c l c ; HYBRID CONTROLLER PARAMETERS !; set time steps| HybridCtrlParameters.nAct =1; HybridCtrlParameters.dtlnt = 0.01; HybridCtrlParameters.dtSim = 2 A ( - 4 ) ; HybridCtrlParameters.dtCon = 1/1024; HybridCtrlParameters.delay =0; % number of c o n t r o l l e d actuators % i n t e g r a t i o n time step (sec) % simulation time step (sec) c o n t r o l l e r time step (sec) !: delay due to undershoot (sec) ?; c a l c u l a t e max number of substeps HybridCtrlParameters.N = round(HybridCtrlParameters.dtSim/HybridCtrlParameters.dtCon); % c a l c u l a t e number of delay steps HybridCtrlParameters.iDelay = round(HybridCtrlParameters.delay./HybridCtrlParameters.dtCon) % c a l c u l a t e t e s t i n g rate Rate = HybridCtrlParameters.dtSim/HybridCtrlParameters. d t l n t HybridCtrlParameters.nAct defines the number of actuators controlled by the real-time application. Note that different Simulink models should be used in the cases of one or more than one actuators because the command signal will either be a scalar or a vector. For example, HybridControllerPolyS lAct.mdl should only be used for a one actuator setup, and HybridControllerPoly3jiAct.mdl can be used for two or more actuators as soon as initializeSimulation.m is correctly defined. HybridCtrlParameters. dtlnt defines the integration time step. This value has to be identical to the integration time step used in the OpenSees model. HybridCtrlParameters.dtSim defines the simulation time step. It corresponds to the actual time step at which the hybrid simulation will be run. HybridCtrlParameters. dtCon is the hydraulic controller time step. Its value is fixed to 1/1024s, because the STS controller performs the control algorithms at the fixed frequency of 1024 Hz. This is also the frequency at which data acquisition signals are obtained from the controller. Figure 18: initialization file of the xPC target controller 41 Note that because the controller time step is 1/1024 s, HybridCtrlParameters.dtSim has to be a multiple of 1/1024 to ensure an integer value for the number of interpolation substeps in the xPC controller. The actual rate of hybrid simulation testing will be equal to the ratio HybridCtrlParameters.dtSim / HybridCtrlParameters.dtlnt: if the simulation time step is set to 0.0625s when the OpenSees integration time step is 0.01s, the testing rate will be equal to 6.25, ie the hybrid simulation is running 6.25 times slower than real time (assuming only one iteration per integration time step in OpenSees). Important note: Everytime you change a parameter in initializesimulation.m, you have to reload the whole Simulink model of the predictor-corrector and rebuild the target application in order to have the modifications taken into account in the xPCtarget application. 4.2.2 Different types of predictors/correctors available Different types of prediction/correction strategies are available for the generation of continuous command signals. The computation of the continuous command signals is performed inside the Stateflow event-driven controller by the means of C functions implemented in the files PredictorCorrector.h and PredictorCorrector.c. These C files are linked to the Simulink model. 42 Figure 19: Interpolation procedures for continuous command generation Here are the available predictor/corrector strategies available (Fig. 19): ramp-and-hold procedure, linear, quadratic or cubic Lagrange polynomial interpolation, linear, quadratic or cubic Lagrange polynomial interpolation and use of the current displacement when switching from prediction to correction, cubic Hermite polynomial interpolation and use of the current displacement when switching from prediction to correction, interpolation based on displacement, velocity and acceleration plus use of the current displacement when switching from prediction to correction, fourth order Lagrange polynomial interpolation imposing zero velocity when reaching the target displacements plus use of the current displacement when switching from prediction to correction. Linear Regression prediction scheme based on the previous target displacements to compute the slope used in the prediction phase Quadratic correction scheme imposing two zero velocity conditions when switching from prediction to correction and when reaching the target. 43 The choice of the strategy is made by chosing the C function called in each of the states of the predictor/corrector Stateflow chart. For example, calling PredictP3 and CorrectP3 implies that a basic cubic Lagrange polynomial interpolation will be performed at each substep. (see Predictor Corr ector.h and Predictor Correctors for the syntax of each method). The use of the current displacement when switching from prediction to correction allows one to avoid any discontinuity in the generated commands that can lead to jumps in the actuators, especially when dynamic actuators are used on a stiff test structure. High-order polynomial interpolation schemes have been shown to provide an effective smoothening of the actuators commands when the displacement increments are evenly distributed (examples: explicit integrators, or implicit integrators with substepping). However, they lead to oscillations in the force commands when implicit integrators are used, since the uneven distribution of the convergence increments tends to create a plateau in the target commands (see Section 6.8). To address this issue, the last two predictor/corrector strategies listed above were developed and will be addressed in Section 6.8. More information on these prediction/correction schemes can be found in Schellenberg (2007). 4.2.3 Compilation of the predictor/corrector model Once the initialization and the choice of the prediction/correction strategy have been made, the Simulink model of the xPC Predictor/Corrector has to be compiled to build the real-time application that will be downloaded to the xPC target computer. First of all, make sure that the following files are located in the same folder: - the predictor/corrector Simulink model (ex: HybridControllerPoly3.mdl) - PredictorCorrector.h PredictorCorrector.c 44 initializeSimulation.m - HybridsimLib.mdl (contains a library of Simulink blocks used in all predictor/corrector models) slblocks.m (defines the Hybrid Simulation block library) You can then open the predictor/corrector Simulink model by double-clicking on the file name. During the loading of the model, calls will be made to initializeSimulation.m, HybridSimL ib. mdl and slblocks. m. Once the Simulink model is ready, start the compilation by typing "CTRL+B" or by selecting the command Tools->Real Time Workshop->Build Model. This process will lead to the creation of a .dim file (ex: HybridControllerPoly3.dlm) which is the real-time application that will be downloaded to the xPC target computer during the initialization phase of OpenFresco. Note that any modification in the initialization file {initializeSimulation.m) will not be taken into account unless the Simulink model is reloaded in Matlab, and the xPC target application also needs to be rebuild ("CTRL+B"). Changes made on the Simulink/Stateflow model also require the target application to be rebuilt. 4.3 Detailed procedure for local Hybrid Simulation testing Parts 4.1 and 4.2 provided some explanations on the creation of the OpenSees numerical model and on the setup and compilation of the Predictor/Corrector real-time application that will be used during the Hybrid Simulation. Through the use of an example presented below, this part will go through the steps to be followed when performing a local Hybrid Simulation test in the following modes: Hybrid Simulation with SimUniaxialMaterials experimental control - Hybrid Simulation with xPCtarget experimental control and with STS controller in simulation mode 45 - real Hybrid Test with xPCtarget experimental control and STS controller in physical testing mode Note that this Chapter deals with local hybrid simulation - ie when the numerical computations and the physical testing are performed in the same lab. Geographically distributed testing will be addressed in Chapter 5. The example used is a modified version of the "Three Span Bridge" example described in Part 5 of the OpenFresco User Manual (Schellenberg et al., 2006). Examples files for OpenFresco can be downloaded from the NEESforge website (https://neesforge.nees.org/proiects/OpenFresco). The "Three Span Bridge" model consists of three girders for the deck, two piers and four abutments (Fig. 20). The abutments are modeled using zero-length elements, the girders are elastic BeamColumns elements and the only difference with the Three Span Bridge model described in the OpenFresco User Manual is that only the left pier is modeled as a BeamColumn experimental element, the right pier being a simple elasticBeamColumn element. elasticBeamColumn 6 elasticBeamColumn 7 elasticBeamColumn 8 zeroLength * 9 10 l i ^roLength _^rML.^ry 4 zeroLength experimental beamColumn elasticBeamColumn elasticBea Colu n Figure 20: modified Three Span Bridge model (modified from Schellenberg et al, 2006) This example uses the 1968 El Centro earthquake ground motion stored in the file ELC270.txt with a time step of 0.01 s. As mentioned before, this part deals with local hybrid simulation; consequently, the example file used is ThreeSpanBridgeUBCLocal.tcl (Appendix A). It is based on ThreeSpanBridge Local.tcl (Schellenberg et al., 2006) modified to be used with a simple cantilever test setup in the UBC structures lab (Fig. 21). 46 Make sure that OpenFresco.exe, OpenSees.exe and the four dll (Dscoml32.dll, OpenFresco.dll, Pnpscr.dll and xpcapi.dll) are located in the same folder. 4.3.1 Hybrid Simulation with Simulation Uniaxial Materials Before performing an actual Hybrid Test with the physical substructure, it is always useful to test the numerical model by the means of Simulation Uniaxial Materials that model numerically the behaviour of the physical substructure at each actuator degree of freedom. For this reason, the SimUniaxialMaterials experimental control is used for the experimental element with an elastic uniaxial material. When defining this material, the stiffness modulus modulus must be chosen so that the material describes the force-47 deformation relationship at the degree of freedom controlled by the actuator: for the UBC cantilever test setup (Fig. 21), the stiffness is about 16.15kN/cm. The experimental element uses the OneActuator experimental setup described in 4.1.3. Because there is no client-server communication in this local configuration, the experimental site is set to LocalSite. To run the simulation with Simulation Uniaxial Materials the following steps have to be performed: Start the OpenSees executable file (OpenSees.exe) - If the OpenSees executable is not in the same directory as the ThreeSpanBridge_UBC_Local.tcl file, change to. that directory from the OpenSees prompt At the command window prompt, type source ThreeSpanBridge UBC Local.tcl and hit enter. This runs the simulation, (see Fig. 22) 48 I) \Nl lsfor i>cU)pir l i f to / ()\win H\o|ii.nSi.c.s LKC HSEl OpenSees — Open System F o r Ea r thquake E n g i n e e r i n g Simulation H P a c i f i c Earthquake E n g i n e e r i n g R e s e a r c h C e n t e r 1.7-3 = <c> C o p y r i g h t 1999 ,2000 The Regents o f the Univers i ty of C a l i f o r n i a fill R i g h t s Rese rved <Copyright and D i s c l a i s e r 0 l i t tp: /Vwww. berke l e y .edu/OpeoSee s / copyr ight . h tml >| >penSees > sou rce ThreeSpanfiridjje.JJBC.JLiOcal.tcl f*HBMIHG ExperinentalElement : t g e t l a r t g e n t S t i f f < > - Element: 2 angentStiff cannot be c a l c u l a t e d . Return I n i t i a l s t i f f i n s t e a d , ubsequent g e t T a n g e n t S t i f f warnings w i l l be s u p p r e s s e d . E i g e n v a l u e s at s t a r t o f t r a n s i e n t : lambda one era p e r i o d S.328928c*001 7 .29995068476 0.86071613063 fa.4B6278e*B02 11 .8586592834 0.529839432689 a.721718e*802 13 .1214252275 0.4.7884938167? 2.17238?e*882 14.73901.96418 0.426296012889 E l a p s e d Tine - 1318904 microseconds p e r i t e r a t i o n OpenSees > Figure 22: OpenSees command window for ThreeSpanBridgeUBCLocal . tc l Note in Fig. 22 the warning "ExperimentalElement: getTangentStiff()". It recalls that no computation of the tangent stiffness is made for the experimental element. Instead, the initial stiffness matrix provided in the expElement command is used in the numerical algorithm. 49 Figure 23: Exp. Element Force-Deformation Relationship We can verify in Fig. 23 that the Uniaxial Materials used with the experimental control SimUniaxialMaterials define directly the relationship between the actuator force feedback and the actuator displacement feedback in the sets of units chosen for the actuators, through the units used in the OpenSees model and the conversion factors defined in the experimental setup (see 4.1.3.): we defined a force-deformation relationship of 16.15 kN/cm through the command uniaxialMaterial Elastic 3 16.15, and we defined the metric/imperial conversion factors in the experimental setup {expSetup OneActuator 1 -control 1 2 -ctrlDispFact 2.54 -daqDispFact 2.54 -daqForceFact 4.4482;). If we convert the stiffness of 16.15kN/cm in imperial system, we obtain 9.22kips/in which is the stiffness that we can read on Fig. 23. This example also illustrates how a different set of units can be used for the control system and for the numerical analysis through the use of the conversion factors. 50 4.3.2 Hybrid Simulation with STS controller in PC simulation mode The next test before running the actual Hybrid Test consists in checking the proper behaviour of the xPC target/predictor corrector as well as the communication links with the STS controller through Scramnet. In this simulation, the left pier of the bridge will be tested as a physical substructure through the use of the UBC cantilever test setup (Fig. 21) To enable the use of the xPC target interface we replace the SimUniaxialMaterials experimental control by the following xPCtarget experimental control: expControl xPCtarget 1 1 "148.150.203.192 " "22222 " "HybridContr oiler Poly 3 " "D:\\xPC target Predictor Controller\\" As explained in 4.1.2., the previous command line means that we will connect to the xPC target computer whose IP is "148.150.203.192" through the port "22222", and we will use the predictor/corrector named "HybridControllerPoly3" (previously compiled) whose path on the Host Computer is "D:\\xPC target Predictor ControllerW". The new tcl command file should be renamed ThreeSpanBride JJBC_xPC Local, tel. The STS controller has to be switched to PCSimulation mode so that the behaviour of the actuator can be modelled numerically through the use of the PCSimulation.mdl Simulink model (see section 3.3 for details). Don t forget to update the value of the payload stiffness inside PCSimulation.mdl to the correct value of 16.15kN/cm. To run the hybrid simulation with the STS controller in PCsimulation mode, the following steps have to be performed: - Boot the xPCtarget computer in DOS (remove the xPCtarget boot disk), and delete the data files corresponding to the previous test (type del *.dat). (Don t delete the command, bat file !) After completion of this task, reboot the 51 xPCtarget computer with the xPCtarget boot floppy disk to load the xPCtarget real-time kernel. Start the OpenSees executable file (OpenSees.exe) If the OpenSees executable is not in the same directory as the ThreeSpanBrideJUBCxPC Local.tcl file, change to that directory from the OpenSees prompt - in OpenSees, type source ThreeSpanBride_UBC_xPC_Local.tcl and hit enter. This will start the xPC target initialization process load and start the PCsimulation Simulink model by clicking on the "Play" command in STS, in displacement control move (virtually) the actuator to the zero force position (force control does not work properly in PCsimulation mode). Specify "Scramnet" as the program source for STS. in OpenSees, press enter to do the data acquisition process start the STS data recorder and press Run on the STS GUI in OpenSees, press enter to start the simulation - at the end of the analysis, when the xPCtarget application is still loaded, execute the Matlab function endSimulationXPCtarget.m on the Host Computer in order to download, convert and save the data stored by the xPCtarget predictor/corrector. 4.3.3 Real Hybrid Simulation with physical testing This step corresponds to the actual Hybrid Test. The procedure is similar to 4.3.2. except that the STS controller will not be running in simulation mode. There is no difference on the numerical side and the same Tcl input file, ThreeSpanBride UBC_xPC Local.tcl, will be used to perform a hybrid simulation with physical testing. 52 To run a hybrid simulation with physical testing, the following steps have to be performed: - Boot the xPCtarget computer in DOS (remove the xPCtarget boot disk), and delete the data files corresponding to the previous test (type del *.dat). (Don t delete the command.bat file !) After completion of this task, reboot the xPCtarget computer with the xPCtarget boot floppy disk to load the xPCtarget real-time kernel, (you can also delete the file through the use the Matlab script removeflles.m- for this the xPCtarget kernel must be loaded) Start the OpenSees executable file (OpenSees.exe) If the OpenSees executable is not in the same directory as the ThreeSpanBride UBC_xPC Local, tcl file, change to that directory from the OpenSees prompt in OpenSees, type source ThreeSpanBride_UBC_xPC Local, tcl and hit enter. This will start the xPC target initialization process in STS, position the actuators to the desired initial configuration (zero force, given geometrical position...). Don t forget to set the actuator back to displacement control and to specify "Scramnet" as the program source for STS. in OpenSees, press enter to do the data acquisition process start the STS data recorder and press Run on the STS GUI in OpenSees, press enter to start the simulation at the end of the analysis, when the xPCtarget application is still loaded, execute the Matlab function endSimulationXPCtarget.m on the Host Computer in order to download, convert and save the data stored by the xPCtarget predictor/corrector. 53 4.3.4 Tools for downloading and plotting the test data from xPCtarget The Hybrid Controller model running in the xPCtarget environment includes xPC File Scope blocks that allow writing data directly to binary files on the xPCtarget computer hard-drive. This section presents a few Matlab scripts useful to download, convert and plot the data from the xPCtarget computer after completion of a hybrid simulation test. These scripts were initially developed by Andreas Schellenberg and modified to suit the UBC experimental test setups. Note that the scripts described here concern a OneActuator setup as used in the previous sections. In the case of a ThreeActuators setup, endSimulationXPCtarget6.m should be used for example (this script would call the function plotOutputXPCtarget2.m). Simple modifications in the script should be done to select the quantities plotted or if the file recorders have been modified in the Simulink model. Method endSimulationXPCtarget.m: This script is a Matlab function that automatically performs the downloading, conversion, saving and plotting of the data stored during a hybrid test. The syntax in Matlab is: data = endSimulationXPCtarget('fdename') where data is the variable where the data will be stored and filename is the name of the Matlab .mat file where data will be saved. Note that filename.mat will be created in the Matlab current directory. This script must be executed when the Host Computer is connected to the xPCtarget computer. For example, it should be executed just at the end of a hybrid test - before the xPC target computer is shut down and while the target application is still running, to make sure that the test data is correctly transferred to the Host Computer for post-treatment. The Matlab variable data will be created as a structure containing 2 variables, fileName which contains the name of the corresponding xPCtarget binary file and values containing the data included in this file. 54 Example: data(l).fileName would return the file name targDsp.dat, and data(l).values(l:10,:) would return the first ten lines of the data contained in the file. Note that executing the command data = endSimulationXPCtarget('filename') after a hybrid test will take a long time due to a slow connection between target and host computers, and depends on the duration of the actual test. The files stored on the xPCtarget computer hard-drive can weigh a few hundreds megabytes and have to be downloaded to the Host Computer through a slow TCP/IP connection. Method getXPCtargetVar.m: This scripts defines a Matlab script used inside endSimulationXPCtarget6.m. It allows to retrieve, convert and store the data contained in the files whose names are given as arguments: Example: data = getXPCtargetVar•({'targDsp.dat', 'commDsp.dat' }) would download, convert and save in the variable data all the data contained in the binary xPCtarget files targDsp.dat and commDsp.dat. Method plotOutputXPCtarget.m: This script plots the data contained in the Matlab structure given as argument. In particular, it plots the target, command and measured displacements time histories, the actuator force time history, the state time history, the counter time history and the updateFlag and targetFlag time histories. More information on these variables can be found by studying the Hybrid Controller Simulink and Stateflow model. 55 Method plotElapsedTime.m: This script uses the time step durations obtained through the Tcl command time and stored in the file ElapsedTime. txt to plot the histogram of the distribution of integration step durations during a test. It also computes the average integration step duration that can be used to select the appropriate hybrid simulation rate. See the Tcl examples files in Appendix for the use of the time command within the Opensees script. 56 5.0 GEOGRAPHICALLY DISTRIBUTED HYBRID SIMULATION 5.1 Geographically distributed test setup Geographically distributed testing refers to the simultaneous testing of substructures located in different remote locations. It allows for the evaluation of complex structural models by the simultaneous use of testing facilities from different laboratories. Several geographically distributed hybrid simulation tests were performed in UBC using testing facilities from the Structures lab at the University of British Columbia and from the Earthquake Engineering Research Center at the University of California at Berkeley. The cantilever test setup (Fig. 21) consisting of a lOOOkN MTS actuator connected to a steel cantilever beam was used as the UBC experimental testing setup, whereas the MicroNEES cantilever test setup - equipped with replaceable coupons - was used as the UC Berkeley experimental testing setup (Fig. 24). Figure 24: U C Berkeley MicroNEES test setup When performing a distributed test with OpenFresco, a three-tier client-server architecture is used. The three tiers are a client, responsible of the finite element computation (in OpenSees), a remote server directly linked to the control system in the lab, and a middle-tier server acting as the interface between the finite element software and the remote server (see Fig. 25). 57 Client TCP/IP (Socket) Middle-Tier Set m SimAppEiemServer ExoennwitaElenient LocalExperimantaSKe ExperimenlalSetup E »periment8lContfol Control System : in Laboratory EE-Software GenericCltentElmt Client TCP/IP (Socket) Mid <&>.: " ! ShnAppElemServer E xpc-nmentalElement RemoteExpSite ExpenmentaJSetup I TCP/IP (Channel; ActorExpSite _ * * , FiqwimanfalSelup i ExperimentalContttI in Laboratory Figure 25: OpenFresco client-server Software Architecture for Local (left) and Distributed Simulation (right) (Schellenberg, 2007) During the distributed tests between UBC and UC Berkeley, the computational client and the middle-tier server were located on the same workstation in the UC Berkeley control room. The first remote server was also in UC Berkeley and was connected to the MicroNEES control system, whereas the second remote server was the UBC Simulink Host computer which is connected to the UBC STS control system (Fig. 26). Mass 3 if—5-OOF 1 Element 3 Element 1 One Bay Frame Opensees model Mass 4 ——as*» DOF 2 Element 2 i i l l Remote Server 1 (OpenFresco) High speed internet TCP/IP MicroNEES test setup (experimental element 1) j i' Sit! Client 1 + Middle-Tier Server (Opensees+ OpenFresco) University of California at Berkeley, USA High speed internet TCP/IP Remote Server 2 (OpenFresco) UBC cantilever test setup (experimental element 2) University of British Columbia, Canada Figure 26: U B C - U C Berkeley distributed test setup 59 Communication between UC Berkeley and UBC was done through a high speed TCP/IP internet connection. The OpenSees numerical model used for these distributed tests was the "One Bay Frame" model described in Part 3 of the OpenFresco User Manual (Schellenberg et al., 2006), and shown in Fig. 26. 5.2 One Bay Frame model The One Bay Frame model (Fig. 27) is a simple two-DOF model consisting of two columns, Element 1 and 2, connected by a spring, Element 3. A lumped mass is placed at the top of each column. The two column bases are fixed. The columns are axially rigid, and the tops are free to rotate. Mass 3 3 ~ Element 1 DOF 1 7 Element 3 Mass 4 DOF 2 Element 2 Figure 27: One Bay Frame Model in OpenSees (Schellenberg et al., 2006) This example uses the 1940 El Centro ground motion, whose data is stored in the file elcentro.txt at every 0.02s. Both experimental elements were modelled as ZeroLength experimental elements whose horizontal force-displacement relationships were obtained from the two physical substructures in Berkeley and UBC. The Element 1 physical substructure was the 60 MicroNEES test setup in UC Berkeley whereas the Experimental Element 2 was the UBC cantilever test setup (see Fig. 26). 5.3 Tcl command files As explained in 5.2, the distributed hybrid simulation tests involve three computers. The first workstation, located in UC Berkeley, is responsible of the numerical computation in OpenSees (client) and is also hosting the OpenFresco interface (middle-tier server) which communicates with the remote server. Both functions are performed through the use of a unique Tcl command file (OneBayFrame Client 1.tcl) that is run in OpenSees. The OpenFresco features are loaded in the OpenSees environment through the dynamic-link library OpenFresco.dll, called by the command "loadPackage OpenFresco". The second computer, called remote server 1, is located in UC Berkeley and is responsible of the communication with the MicroNEES test setup that constitutes the Experimental Element 1. This computer runs the software OpenFresco.exe with the command file One Bay Frame JServerla. tcl. The last computer, called remote server 2, is located in UBC and is responsible of the communication with the UBC cantilever test setup that makes up the Experimental Element 2. This computer also runs OpenFresco.exe with the command file OneBayFrame Server 1 b.tcl. 5.3.1 Client-side Tcl command file The client-side Tcl file (or client+middle-tier server since here both are lumped into one computer) called OneBayFrame Client Ltd defines the OpenSees numerical simulation model as well as the client-side OpenFresco commands for distributed Hybrid Simulation. The architecture is similar to any Tcl command file for a structural simulation in OpenSees, except that the few following commands have to be added: - loadPackage OpenFresco loads the OpenFresco features through the dynamic-link library OpenFresco.dll, 61 - the experimental sites have to be defined through the command expSite. In the present configuration, two Remote Experimental Sites (UBC and UC Berkeley-lab experimental sites) are defined through the commands: expSite RemoteSite 1 "127.0.0.1" 8090; # UC Berkeley lab expSite RemoteSite 2 "147.82.46.169" 8091; # UBC lab The given IPs correspond to the remote servers static IPs, and the ports (8090 and 8091) specify through which ports the data will be transfered. - the experimental elements are defined through the command expElement: # expElement zeroLength SeleTag SiNode SjNode -dir Sdirs -site SsiteTag -initStif SKij <-orient $xl $x2 $x3 $yl $y2 $y3> <-iMod> <-mass $m> expElement zeroLength 113 -dir 2 -site 1 -initStif 2.8 -orient 010-100 expElement zeroLength 2 2 4 -dir 2 -site 2 -initStif 5.6 -orient 010-100 It is important to remember that the choice of the integrator object (altogether with the algorithm object) will influence the efficiency of the Hybrid Simulation procedure (see 4.1.6). Notice that in this case the Experimental Setup objects have not been defined on the client side. OpenFresco leaves the choice of defining them on either side of the client-server architecture. 5.3.2 Remote Server 1 (UC Berkeley lab) Tcl command file The remote server 1 Tcl file, called OneBayFrame Serverla.tcl, defines the OpenFresco objects needed to interface with the control system of the physical substructure. This is done within an OpenSees-like model with the following commands: model BasicBuilder -ndm 2 -ndf 2 creates the environment for the OpenFresco objects 62 - the Experimental Control object is defined: expControl xPCtarget 1 1 "192.168.2.20" "22222" "HybridControllerPoly3_lAct" "D: \ \PredictorCorrector\\RTActualTestModels \\c&mAPI-xPCTarget-STS\ \" These parameters refer to the characteristics of the predictor/corrector that will be used within the xPC target interface to the control system. Any other instance of expControl can be used: SimUniaxialMaterials (for simulation), Scramnet, dSpace, etc depending on the interface with the control system. the Experimental Setup object is chosen to be defined on the server side: expSetup OneActuator 1 -control 1 1 an Ac tor Site Experimental Site has to be defined to communicate with the RemoteSite defined on the client side: expSite ActorSite 1 -setup 1 8090 Again, the port is defined to specify where the data will be sent back to the client workstation. Finally the remote server process is started to activate the communication link: startLabServer 1 5.3.3 Remote Server 2 (UBC lab) Tcl command file The second remote server Tcl file, called OneBayFrame_Serverlb. tcl, is similar to the first one: model BasicBuilder -ndm 2 -ndf 2 expControl xPCtarget 1 1 "148.150.203.192" "22222" "HybridControllerPoly3 1Act" "D.WxPC target Predictor ControllerW" 63 expSetup OneActuator 1 -control 1 1 -ctrlDispFact 2.54 -daqDispFact 2.54 -daqForceFact 4.4482; # UBC setup with units conversion # expSite ActorSite Stag -setup SsetupTag SipPort <SdataSize> expSite ActorSite 2 -setup 1 8091 256 startLabServer 2 Note that conversion factors have been defined in the expSetup object to account for the different set of units. Moreover, the option <$dataSize> has been provided in the ActorSite object to specify the size in bits of the data packet sent between the client and server sides. This option allows to specify a minimum data size since too small packets travel slower throughout an internet connection. 5.4 Results The distributed test presented herein has been designed with the simple goal of verifying the ability of the OpenSees/OpenFresco architecture to perform geographically distributed testing. As a consequence, the results are only useful to illustrate the functioning of the global architecture and do not intend to represent the seismic behaviour of a realistic structural system. The hybrid simulation tests presented in this section were performed at the rate of 12.5 times slower than real time, in order to provide enough time for Opensees to compute the next displacement command and to account for the communication delays due to internet. The integration time step in Opensees being set to 0.02s - which is the ground motion record time step, this rate of 12.5 means that a regular simulation time step during the hybrid test would last for 12.5 x 0.02s = 0.25s. 64 5.4.1 Displacement time-histories Because of the large differences in stiffness, displacement capacity, nonlinear behaviour of the experimental test setups used in UBC and UC Berkeley, scaling factors have been used to ensure that a proper loading could be applied on both test apparatus. As a result, no consistency should be expected in the response of the UBC and UCB experimental substructures, and the following plots are only presented to illustrate that real-time testing of two experimental substructures located in geographically distributed labs can be efficiently performed. Fig. 28 and 29 present the overall displacement response of the two substructures located in UBC and UC Berkeley. Target disp is the target displacement computed by OpenSees, command disp is the continuous displacement command generated by the predictor-corrector scheme, and measured disp is the actual displacement feedback measured on the actuator. The big difference in stiffness and the different conversion factors between the two experimental substructures explain the differences in the response. Displacements from xPC-Target: UBC Actuator I I i i i i I i i I I 0 50 100 150 200 250 300 350 400 450 500 Time [sec] Figure 28: Displacements time histories for the U B C experimental column 65 Displacements from xPC-Target: UCB Actuator 200 250 Time [sec] 500 Figure 29: Displacements time histories for the U C B experimental column 5.4.2 Continuous command generation As explained in section 3.2, a predictor-corrector algorithm has been implemented in the xPC target real-time environment to insure that smooth and continuous commands are sent to the servo-hydraulic controller at a deterministic rate. The goals of this method are to suppress the force relaxation effects typical of the ramp-and-hold procedure andtto accommodate for variable integration time steps (implicit integrators) or communication delays in geographically distributed testing. 66 1.2 E 1 I 0.8 01 o CD " | - ° . 6 b 0.4 Displacements from xPC-Target: UBC Actuator 1 1 • 1 target disp command disp measured disp / [ t Z'JCY / ] . I _ J . I: \ ! 1 75 76.5 Time [sec] 77 75.5 76 Displacements from xPC-Target: UCB Actuator 77.5 78 E 0.5 target disp " command disp measured disp • 1 ^ ^ - ^ ^ = c ! 1 1 ^ i i i i i i i 70 71 72 73 Time [sec] 74 75 76 Figure 30: Continuous command generation This continuous command generation scheme is illustrated in Fig. 30. As explained earlier, the chosen rate of 12.5 implies a simulation time step of 0.25s. This means that new target displacements will be sent by Opensees approximately every 0.25s. (Note that the integration time and the communication delays may vary between steps and the predictor/corrector scheme might switch to the Autoslowdown state, therefore increasing the actual simulation rate.) Fig. 30 shows the target displacement received from Opensees (black), the continuous command displacement generated by the predictor/corrector scheme (blue) and the measured displacement feedback sent back to Opensees. We can observe that the discontinuous target displacement received from Opensees approximately every 0.25s is converted into a smooth continuous displacement command sent to the actuator at the deterministic rate of 1024Hz. The predictor/corrector used during this test was 67 performing third order Lagrange polynomial interpolation on the current and previous target displacements. Note that the displacement and force feedbacks are not measured continuously but only once every integration step at the exact moment when the target displacement is reached. This explains the discontinuous shape of the measured displacement and force signals. 5.4.3 Integration step duration Because of the variability in the duration of the numerical integration process and in the communication delays through internet, the duration of the integration steps varies. 1200 1000 800 CL a> CO "5 600 <D -Q E 3 400 200 a Distribution of Integration Step Duration Average Step Duration: 2914403 msec l 200 300 400 500 600 Integration Step Duration [msec] 700 800 900 Figure 31: Distribution of Integration Step Duration The histogram in Fig. 31 presents the distribution of the integration step duration during the hybrid test. As mentioned before, the simulation rate was chosen to be 12.5 in order to provide enough time for the integration and communication processes at each time step, which corresponds to a simulation time step of 0.25s=250ms. However, Fig. 31 68 shows that the average step duration during the test was 291.44ms. This means that most of the simulation time steps went through the AutoSlowDown phase (see section 3.2.2) because the integration+communication processes required more than the 250ms normally allowed for each step. State from xPC-Target 2, -r r 1 • — : — — i 1 : • 1.8 j-j 1.6 . : ; H 1.2 ; :- | - | | | ; l i CO 0.8- | o.6 •. • : | [••;-•••• -0.4- [ ••••••••| ]••; -0.2 i Time [sec] Figure 32: State from the U C B xPCtarget Predictor/Corrector This trend can be verified by plotting the state variable from one of the xPCtarget predictors/correctors (Fig. 32): state 0 corresponds to the Correction state, when the new target displacement has been received and the path of the actuator is corrected to reach this target, state 1 is the Prediction state, when polynomial interpolation on the previous target displacements is used to generate a predicted displacement command, and state 2 is the AutoSlowDown state where the actuators are smoothly slowed down to account for the delays in the integration and communication processes. We can notice that every time step goes to the AutoSlowDown phase for about 40ms, which explains the average simulation step of 291.44ms instead of 250ms. 69 Optimum performance during this test would have been obtained by increasing the simulation rate to 14.5 or 15 to reach a simulation step of 290ms or 300ms. However, most of the delay during a distributed comes from the internet communication process and is constantly changing depending on the instantaneous traffic on the internet, what makes it difficult to estimate precisely before a test. In order to obtain an estimate of the integration+communication duration during a distributed test, it is useful to run a first distributed test in simulation mode, and then plot the distribution of the integration step duration to obtain an estimate of the average step duration. Based on this information, the optimal simulation rate can be chosen to maximize the simulation speed while minimizing the amount of AutoslowDown. 70 6.0 SETUP FOR HYBRID SIMULATION OF THE GRAVITY LOAD COLLAPSE OF REINFORCED CONCRETE FRAMES The previous chapters addressed the implementation of hybrid simulation at the University of British Columbia. This chapter presents the test setup that was developed at UBC to investigate the applicability of hybrid simulation to the gravity load collapse of reinforced concrete frames. This test setup was based on some related work and shake table tests undertaken by Elwood and Moehle (2003) as summarized in Section 6.1. Section 6.2 describes the hybrid simulation setup developed for this study. Section 6.3 presents the physical substructure used for the hybrid tests whereas Section 6.4 introduces the corresponding experimental test setup. Section 6.5 describes in details the OpenSees finite element model developed for this study; emphasis is given on the selection of the integration scheme due to the high nonlinearity that will be encountered in the experimental and numerical substructures. Section 6.6 presents the experimental setup in OpenFresco implementing a nonlinear transformation method to allow for an accurate application of the loading on the specimen, whereas section 6.7 introduces the xPCtarget predictor-corrector scheme used for continuous hybrid testing. Section 6.8 describes the new methodology developed to enable the use of force control for the actuators in combination with the displacement-based software, OpenSees. Finally, Section 6.9 presents a steel dummy test setup developed for tuning and calibration purposes. 6.1 Previous study on the gravity load collapse of RC frames 6.1.1 Presentation of the study An analytical and experimental study was undertaken by Elwood and Moehle (2003) to investigate the shear and axial load failure of columns leading to the gravity load collapse of reinforced concrete building frames during earthquakes 71 First, two empirical capacity models were developed to provide an estimate of the drift at shear and axial load failure for existing reinforced concrete columns. Those capacity models were incorporated into a uniaxial material model implemented in the OpenSees analytical framework. When attached in series with a beam-column element, this material model can be used to model either shear or axial failure. Moreover, a shear-axial coupling was incorporated in the material model to approximate the response of a column after the onset of axial failure. Furthermore, a series of shake table tests (Section 6.1.2) was designed to provide data on the degradation of axial load capacity after shear failure of a reinforced concrete column, and the resulting redistribution of shear and axial loads to the rest of the building system.Test data was compared with predictive models and with nonlinear analytical models incorporating the proposed models for the drift at shear and axial load failure. Finally, an analytical model of a frame with three shear-critical columns demonstrated that the proposed column model can be used to assess the gravity load collapse potential of a reinforced concrete frame (Elwood and Moehle, 2003). 6.1.2 Shake table tests specimens The shake table test specimens (Elwood and Moehle, 2003) consisted of a three-column frame with a shear-critical center column (Fig. 33). Care was taken in selecting appropriate member sizes and strengths to achieve the desired behavior (including shear and possibly axial failure of the center column, yielding of the outside columns prior to failure of the center column, appropriate beam deflections after axial failure of the center column, controlled transfer of loads from the wide beam to the columns). Two specimens were tested, differing only by the axial stress on the center column (axial load of 0.10 and 0.24f cAg). Both specimens were subjected to one horizontal component from a scaled ground motion recorded during the 1985 Chile earthquake. 72 4'-10 Transverse torsional team 6' 5' wide team designed to model tending stiffness of typical spandrel beam " (masses not shown for clarity) Designed to support gravity oads after failure of center column #4 corner bars #5 center bars W2.9 wire 6" o.c. • Force transducers to measure reactions at base of columns Section B Figure 33: Shake table test specimens (Elwood and Moehle, 2003) 6.2 Hybrid Simulation Setup As explained in 2.2, Hybrid Simulation with substructuring offers a cost-efficient way of testing large-scale structural components under simulated earthquake loading, and it might prove to be a sensible alternative to traditional shake table tests. Validation of the concept of Hybrid Simulation could be achieved by the comparison of tests results with shake table tests data. One of the goals of the present research project was to perform Hybrid Simulation tests with substructuring that would attempt to reproduce the shake table tests presented in the previous section (Elwood and Moehle, 2003). One advantage of the concept of Substructuring in Hybrid Simulation is that the parts of the structure whose behaviour is effectively captured by an analytical model can be simulated numerically in a Finite Element software, while the components difficult to model numerically - e.g. portions having a complex non-linear behaviour - will be physically tested. This should ensure that the critical behaviour of the whole structure is still captured by the hybrid model. Results from nonlinear analytical models (Elwood and Moehle, 2003) indicated that the behaviour of the outside ductile columns as well as their footings and the top beam of the 73 two-bay frame can be decently captured by a refined nonlinear model in OpenSees. However, it was noticed that the fiber elements used for the outside columns underestimated the drifts and permanent displacement observed during the tests. The influence of this underestimation of the drift response on the results of the hybrid tests will be discussed later. Being the critical component of the structure, the center column would still be physically tested through the use of a three-actuator dynamic test setup able to reproduce faithfully the loading imposed on the member during the seismic excitation of the whole structure (see Fig.34). Q-— frfTrrt JL Experimental te*t setup 3 DOF controlled '* by 3 dynamic actuators —_xx -Refined Finite Element model in Opensees / / Experimental substructure EQ ground motion _Eter- X Figure 34: U B C Hybrid SimulationTest Setup 74 6.3 Design of Physical Substructure for Hybrid Simulation min. 1" clear cover over any bar SECTION B-B 2-20M H- 10M stirrups ® 1 -1 /2" ox. 2-25M SECTION A-A 10 W2.9 lies @ 6" o.c. 1 +— 10M corner bars D — 15M center bars 1" clear cover over long, bars -(column only) 2-20M 1QM ties 3 1-1/2" ac, 2-25M E SECTION C-C min. 1" clear cover over any bar 1'-5 1/2" Figure 35: Hybrid Simulation Test Specimen (design dimensions) T As in the previously described shake table tests (Elwood and Moehle, 2003), the shear-critical center column was designed as a one-half reproduction of a 9'8" tall, 18"xl8" square column. From previous tests (Sezen, 2002, Elwood and Moehle, 2003), it was expected that the center column would sustain flexural yielding before developing shear failure. The center column detailing (Fig. 35) was chosen to obtain the best fit to the half-scaling of Sezen's specimens and to Elwood's specimens (in spite of the different unit system -imperial rebar sizes had to be replaced by metric sizes). Reinforcing wire W2.9 (W18.7 75 metric) with a nominal cross-section of 0.029in.2 was used to model the #3 reinforcing bars used by Sezen (2002) for transverse reinforcement. Although the yield stress of the reinforcing wire was significantly higher than that of full-scale rebars, the wire was selected to achieve the appropriate scaled elastic stiffness. One 15M and two 10M rebars were used as longitudinal reinforcement on each face of the center column to achieve, as close as possible, the scaled area for three #9 rebars used by Sezen on each face of the full-scale specimen (Charlet: 0.62in.2 per face, Elwood: 0.71 in.2 per face, scaled Sezen: 0.75in.2). Note that using two 15M and one 10M per face (0.78in.2) would have provided a better fit to Sezen's detailing,, but it would also have increased the capacity of the column against axial load failure. The maximum capacity of the vertical actuators used in the test setup is very close to the axial load of 0.24f cAg. If a first specimen had not failed under 0.24f cA g, we would have been unable to increase this axial load to reach axial failure if the specimen had been designed with the higher reinforcement ratio, so using a lower reinforcement ratio was decided to make sure that axial load failure could be reached within the capacities of the actuators. The remaining elements (footing and top beam) were designed to be strong enough so that all damage is concentrated in the column, with the footing and beam remaining in elastic range (factor of safety higher than 2 on code design). Hence, a fairly high reinforcement ratio is used in these elements: two 25M longitudinally at the bottom of footing and top of upper beam, two 20M longitudinally at the top of footing and bottom of upper beam, and 10M stirrups at 2" o.c. in footing, upper beam and in the base and top of the column embedded in the horizontal elements (Fig. 35). Note that the dimensions showed in Fig. 35 represent the design dimensions, and some slight variations were observed in the as-built specimens. The as-built details of the specimens are available in Appendix B. Three nominally identical test specimens were constructed in horizontal position. No strain gages were positioned on the reinforcement cages since only the global element response obtained the actuators force and displacement transducers are necessary for hybrid simulation. Normal weight concrete was cast in one lift; the maximum aggregate 76 size was chosen to be 5mm because of the very tight transverse reinforcement in the footings of the specimens. Specimens were wet-cured for only 2 days and then stored in the laboratory until testing. The wet curing was kept to a minimum to avoid overstrength of the concrete that would lead to the exceedance of the actuators capacity. Companion cylinders were stored with the specimens and tested at.7, 21, 28 days and the days of testing according to ASTM procedures. Table 1 summarizes the properties of the column specimens compared to the shake table tests specimens. Table 1: Comparison of the properties of the hybrid simulation and shake table specimens Shake table specimen 2 (Elwood and Moehle, 2003) Hybrid simulation test specimen 1 Hybrid simulation test specimen 2 Concrete strength f c at 28 days 19.51 MPa (o = 0.24MPa) 26.31 MPa (a = 2.53MPa) 26.31 MPa (a = 2.53MPa) Concrete strength f c at testing 23.92 MPa (a= 1.12MPa) 29.49 MPa (a = 0.46MPa) 31.96 MPa (o= 1.73MPa) Longitudinal reinforcement ratio 2.5% 2.3% 2.3% Horizontal reinforcement ratio 0.2% 0.2% 0.2% Table 2 provides more information on the concrete mix used for the specimens. 77 Table 2: Concrete M i x Specifications Cement CSAType 10 Water reducer Pozzolith 200N, 5oz/100kg of cement powder Plasticizer Rheobuild 1000, 3% Air entrainment None Maximum aggregate size 5 mm (Bird Eye type) Sand to Aggregate ratio 52% Water/Cement ratio 0.4 Slump 150 mm Minimum 28-day strength 21 Mpa(3000psi) Maximum 2 8-day strength 24Mpa (3500 psi) 78 35 30 25 Q_ £ 20 CD T3 10 0 First Specimen Second Specimen 0 20 40 60 80 100 120 140 160 180 200 Time [days] Figure 36: Concrete strength gain with age Fig. 36 shows the strength gain of the concrete with its age. Three cylinder tests were used to determine the concrete strength at 28 days and at the day of testing for the 2 specimens, and one cylinder only was used to determine the 7-day and 21-day strengths. Note that most of the concrete cylinders were cast at the beginning of the casting process, however additional cylinders were also cast at the time concrete was poured in the specimen used for the second test. Fig. 36 shows that some differences are visible between the concrete used at the beginning and the end of the casting; this is explained by the addition of plasticizer just before pouring that might have been non-homogenously mixed with the concrete. 79 6.4 Experimental Test Setup for Hybrid Simulation External LVDT (second test only) Figure 37: Experimental Test Setup and Instrumentation (the external L V D T was added for the second hybrid test) The center column was physically tested through a three-actuator dynamic test setup (Fig. 37) able to reproduce faithfully the loading imposed by the numerical model on the member during the seismic excitation of the two-bay frame. The horizontal actuator was located at midheight of the column (ie inflexion point for a symmetric loading) in order to minimize the moment compensation that the vertical actuators would have to perform. Instrumentation, shown in Figure 37, consisted of three uniaxial load cells mounted on the actuators pistons, three high precision LVDTs embedded in the actuators, two spring pots to measure the specimen horizontal and vertical displacements and two 6-DOF load cells under the footing of the specimen. Note that the 6-DOF load cells as well as the spring pots are only used as redundant instrumentation for post-treatment, whereas the actuators force and displacement transducers feedbacks provide the real-time response of 80 the center column used for the online computation of the response of the whole two-bay frame structure. An out-of-plane bracing mechanism (Fig. 38), commonly known as a pantograph, was designed to restrain the specimen in the out-of-plane direction while allowing unrestrained movement in the loading plane. Figure 38: Out-of-plane bracing mechanism Furthermore, a pair of safety slings was incorporated in the test setup to prevent any damage to the testing apparatus after loss of the axial load capacity of the reinforced concrete column (Fig. 39). 81 Safety slings Figure 39: Out-of plane and safety supports for hybrid test setup 6.5 OpenSees Finite Element Model The OpenSees finite element model used as the numerical substructure for hybrid simulation of the gravity load collapse of reinforced concrete frames is a modified version of the analytical model developed by Elwood and Moehle (2003) to reproduce the seismic behaviour of the previously described shake table test specimens. 82 6.5.1 Model layout T i D Node without mass D Ncxle with mass Zero-length section (or * slip spring (2 eotnckleitl nodes) ~ Rigid beam clement m Nonlinear fiber beam-eoliiinii element — Beam element — Experimental Bean-Column element Figure 40: Opensees Finite Element Model for Hybrid Simulation The layout of the nodes and elements of the analytical model for hybrid simulation is shown in Fig. 40. The beams as well as the footings are modeled as linear-elastic, in order to limit the complexity of the model and increase the speed of the analysis. Nonlinear fibre beam-column elements are used to model the ductile outside columns. These nonlinear beam-column elements are based on the flexibility method (de Souza, 2000) and use fibre sections with confined and unconfined concrete models and a Clough-type hysteretic model for the reinforcement. Zero-length sections are located at the extremities of each outside column to account for the slip of the longitudinal bars from the footings and beam, and an experimental beam-column element represents the center column and its footing. The confined concrete model used for the outside columns is based on the Mander model (Mander et al., 1988), whereas an unconfined concrete model is used to model the cover. A Clough-type hysteretical model was used for the outside columns reinforcement since it proved to provide a better estimate of the measured response than a Guiffre-Menegotto-Pinto model with isotropic strain hardening. The equivalent viscous damping was set at 2% of critical for the fundamental mode of the frame by using mass-proportional damping. 83 More detailed information on the model can be found in Elwood and Moehle (2003). 6.5.2 OpenFresco objects The OpenFresco objects necessary to define the experimental substructure for hybrid simulation have been described in section 4.1. The following choices have been made to perform hybrid simulation of the two-bay frame system : - experimental site expSite LocalSite, since numerical analysis and experimental testing are performed in the same lab, experimental setup expSetup ThreeActuatorsLshape, developed specifically to account for the nonlinear geometry and kinematics of the three-actuator test setup used to load the reinforced concrete column, and described in section 6.6, experimental control expControl xPCtarget, used jointly with the specific xPCtarget Predictor/Corrector scheme HybridControllerLRP4S0_nAct described in section 6.7, experimental element expElement beamColumn with initial stiffness assessed from low amplitude elastic cycling testing before the actual hybrid test. 6.5.3 Choice of the integration scheme Because of the presence of the experimental substructure, performing hybrid simulation with OpenSees requires a careful choice of the analysis options. In particular, one must select the integration scheme and the corresponding convergence test that would provide the most accurate numerical solution while respecting the following requirements specific to hybrid simulation: - overshooting in the convergence algorithm should be avoided because of the path dependent behaviour of the physical element, - in order to avoid slowing down the simulation, as few calls as possible should be made to obtain the restoring forces from the physical substructure, 84 - a constant Jacobian equal to the initial stiffness has to be used in the numerical method since the tangent stiffness is not available from the physical substructure. As mentioned in section 4.1.6, specific Integrator objects have been developed by Schellenberg (2007) to accommodate for these requirements: - Newmark-HybridSimulation Method - HHT-HybridSimulation Method (also called Generalized Alpha-HybridSimulation) - Collocation-HybridSimulation Method - Alpha-OS Method The first three Integrator objects characterized by the term HybridSimulation are implicit integrators using the method called sub-stepping: instead of using a variable number of iterations to reach the convergence tolerance at each step, these integration schemes use a constant number of iterations and do not check for the final convergence unbalance. To do so, only a fraction of the displacement increment obtained after solution of the system of equations is applied at every iteration, so that the total displacement increment for the time step is more equally distributed between the iterations (Fig. 41). In contrast, using regular implicit integration schemes such as Newmark would usually imply a large displacement increment during the first iteration followed by increasingly smaller increments during the next iterations until convergence is reached (Fig. 41). This uneven distribution of displacement increments during the convergence process is undesirable for hybrid simulation as it would lead to a slowing-down of the actuators motions instead of a constant motion speed. 85 Cumulative Displacement Increment during One Integration Time Step with Different Integration Schemes Cumulative Displacement Slowing-down of actuators motio Increment > s \ -T i i Variable [Number of Iterations Simulation Time Step a) Regular Implicit Cumulative Displacement Increment Convergence Unbalance -Time Fixed dumber of Iterations -Time Simulation Time Step b) Implicit-HybridSimulation with substepping Figure 41: Integration Schemes - Regular Implicit vs Implicit with Substepping Note that the convergence speed is much slower when substepping is used because only a fraction of the displacement increment is applied at each iteration, so that a much larger number of iterations might be required to obtain the same convergence accuracy. Moreover, since no convergence check is done at the end of the iterations and since the number of iterations is fixed beforehand, a non-negligible force unbalance might be carried over to the next time steps, especially when a highly nonlinear substructure (either experimental or numerical) is included in the hybrid simulation. On the other hand, using regular implicit integration scheme such as Newmark or Hughes-Hilber-Taylor (HHT) will lead to a slowing-down of the actuators motion due to the uneven distribution of the displacement increment between iterations. Furthermore, regular implicit integration schemes might lead to overshooting issues when the convergence process implies to go backwards in the actuators motion in order to reach numerical equilibrium. This problem is usually avoided with substepping techniques since only a small fraction of the displacement increment is applied at every step. More information on integration schemes with substepping can be found in Wei (1997). The Alpha-OS Method is a Predictor-Corrector Integrator: integration is performed in only one iteration, through a prediction phase followed by a correction phase. More information on the OS (Operator Splitting) method can be found in Hughes et al. (1979) and Nakashima et al. (1990). 86 Regular integration schemes in Opensees require the user to define a convergence test object that will be used to determine the number of iterations performed before reaching the specified convergence tolerance: Example: test Energylncr 1.0e-10 25 2 (or test NormDispIncr, test NormUnbalance) However, the implicit-HybridSimulation schemes with substepping presented previously require a different test object which only specifies the fixed number of iterations and the print flag: Example: test FixedNumlter 16 2 will impose a fixed number of iterations of 16 and will print out information when convergence is achieved. Note that the print flag allows to print the achieved Energylncrement convergence obtained at each iteration or the end of the fixed number of iterations, and can be used as a post-processing tool to check the accuracy of the convergence process. Note: the FixedNumlter test must be defined in the Opensees input file before the integrator: test FixedNumlter 16 2; integrator HHTHybridSimulation . 99 0.84 0.0 0.0 0.0; The choice of the integration scheme used during the hybrid test will greatly affect the accuracy and efficiency of the numerical analysis. As a consequence, a sensitivity analysis was conducted to investigate the effect of the integration scheme on the accuracy of the analysis. The HHT-HybridSimulation method would be preferable to the Newmark-HybridSimulation as the integration scheme because it allows for the specification of numerical damping useful to damp higher modes oscillations. Numerous analysis with a different fixed number of iterations were performed on a nonlinear model of the two-bay 87 frame and results were compared with those obtained with the regular HHT integration scheme (with a tolerance of le-10) (Fig. 42 and 43). Maximum Error for HHT Hybrid N Iterations Compared to Regular HHT 6.5 5.5! LU E E >=: 03 4.5 4 3.5 3 2.5 Disp. Error • Force Error 20 40 60 80 100 Fixed Number of Iterations N 120 140 Figure 42: Max. Error in Force and Displacement Response between Regular and Substepping H H T as a Function of the Fixed Number of Iterations 88 4.5 x i f f3 Maximum Energy Increment after N Iterations as a Function of N CO cz o S 3.5 CD £ 3 CU I 2.5 u 2 cz LU | 1 1-5 X CB 0.5 \ I 1 \ \ •\ ; \ ; \ 20 40 60 80 100 Fixed Number of Iterations N 120 140 Figure 43: Max. Convergence Unbalance as a Function of the Fixed Number of Iterations We can notice in Fig. 42 and 43 that the increase in convergence accuracy does not follow a linear trend as the fixed number of iterations increases. For example, the maximum convergence unbalance (Fig. 43) - that can be related to the achieved convergence tolerance - does not decrease linearly with the increasing number of iterations. On the contrary, the incremental gain in convergence accuracy diminishes as the number of iterations increases: even with the huge fixed number of iterations of 128, the achieved Energylncr tolerance with HHT-HybridSimulation is only 5e-4 (when a tolerance of le-8 would be desired) whereas an Energylncr tolerance of le-10 is achieved with an average of 16 iterations when regular HHT is used. Reaching a reasonable convergence tolerance with the HHT-HybridSimulation would imply an unrealistically 89 large number of iterations and would lead to a drastic reduction in the actual testing speed. Note that the efficiency of the Implicit-HybridSimulation methods is highly dependent of the amount of nonlinearity present in the system. Excellent results have been obtained with this method for almost linear systems (Wei, 1997). As a result, we can conclude that although the substepping method improves the distribution of displacement increments between iterations and enables smoother actuators motion, it also penalizes the convergence efficiency of the implicit method and makes the Implicit-HybridSimulation methods not suitable for the hybrid simulation of highly nonlinear systems. Based on these results, a regular implicit integration scheme was chosen for the hybrid simulation of the gravity load collapse of reinforced concrete frames. The Hilber-Hughes-Taylor (HHT) method would have been preferable to the Newmark method because of its ability to introduce numerical damping useful to damp higher modes oscillations. However, it was noticed during preliminary tests on the hybrid model that the HHT method was actually less efficient that the Newmark method (many more iterations needed for convergence). For this reason, the regular Newmark integration method was finally chosen for the hybrid tests. Note that using regular HHT or Newmark might lead to unloading or reloading issues in case of overshooting during the convergence process. However, this problem should be reduced by the fact that most of the convergence increment is made during the first iteration, so that the following correction increments where overshooting could be encountered usually have a very small amplitude. 6.5.4 Optimization of the Hybrid Simulation Rate Optimization of the hybrid simulation rate is achieved through the choice of the following parameters: - Integration time step in the OpenSees numerical model: the smaller the integration time step, the more accurate the response but the lower the actual 90 testing rate. Indeed, selecting an integration time step of 0.001s instead of 0.01s will imply an actual simulation rate approximately 10 times slower (assuming that approximately the same number of iterations is required for convergence) since the integration and communication process will have to be performed about 10 times more often. Number of iterations per integration step: minimizing the number of iterations required for convergence at each step will increase the hybrid simulation rate, since every iteration requires to impose the command displacements on the physical substructure, acquire the force feedback and solve for the new increment Simulation time step in the xPCtarget predictor/corrector: the simulation time step must be minimized while making sure that enough simulation time is accorded to the integration/communication process and actuator motion. Indeed, a too small simulation step will lead to the use of the AutoSlowDown mode during the wait and will result in periods of slowing-down of the actuators motions. Note that the xPCtarget application will not function properly when the simulation time step is too low (issues with the speed of writing on the hard-drive and reading from the Scramnet card). - Convergence tolerance: increasing the tolerance will reduce the number of iterations required for convergence, thus increasing the hybrid simulation speed. However, it must be emphasized that increasing the tolerance will also reduce the accuracy of the analysis by raising the amount of force unbalance carried over from one time step to the next one. In the case of hybrid simulation of a highly nonlinear system - as encountered here with the shear and axial load failure of the center column and with the use of nonlinear fiber elements in the numerical model - the integration time step in the OpenSees model must be chosen as small as possible to accurately capture the sudden changes in stiffness and ensure that convergence can always be achieved. Note that failure to converge during a time step - as well as algorithm-switch if failure in convergence - must absolutely be avoided during hybrid simulation because loading will still be applied to the physical 91 substructure at every subiteration even if convergence is not reached at the end of the step. The number of iterations might be either variable in the case of regular integration schemes or fixed beforehand in the case of integrators with substepping methods (section 6.5.3). Because of the convergence inefficiency of the Implicit-HybridSimulation schemes described in section 6.5.3, and in order to reduce the required number of iterations, the regular Newmark method was chosen. A sensitivity analysis was carried out to investigate the effect of the specified convergence tolerance on the accuracy of the results (Fig. 44). Indeed, lowering the convergence tolerance increases the number of iterations required for convergence and slows down the actual hybrid testing rate. Maximum Relative Error (Reference :. ToNIOe-IQ) as a Function of the Convergence Tolerance • Top of Center Column 10 71 r 0 a A::i;tl Force • / •i I | i 50 ^Moment' M d Veitical Displacement P 9 10 Minus LoglO of the Eng«gy Increment Tolerance Figure 44: Relative Error as a Function of the Convergence Tolerance 92 Fig. 44 plots the maximum relative error for displacements and forces at the top of the center column - with reference to the smallest tolerance (le-10) - for convergence tolerances on energy increment between le-4 and le-10. Results show that using an energy increment tolerance bigger than le-6 can lead to very large errors in the computed response (up to 75%), especially on stiff degrees of freedom (axial force). On the other hand, using a convergence tolerance smaller than le-8 does not improve the accuracy of the results much, but could imply much more iterations before convergence. Based on these results, an energy increment convergence tolerance of le-8 was chosen in order to obtain the fastest yet accurate hybrid simulation. However, non-convergence after 50000 iterations was experienced during the first hybrid (Section 7.2), and led to the choice of a tolerance of le-6 for the second hybrid test. Note that the choice of the Newton algorithm used with the implicit integrator will also influence the number of iterations required for convergence: a Modified Newton algorithm (tangent stiffness only updated at the beginning of the step, not at every iteration), or a Newton algorithm with initial stiffness would require more iterations for convergence. However, since the tangent stiffness is not available for the experimental substructure and the initial stiffness is used for solving, a regular Newton algorithm would imply a mix of tangent stiffness for the numerical substructure and initial stiffness for the experimental substructure and could result in an inappropriate distribution of forces within the structure. Another advantage of using the Newton algorithm with initial stiffness is that this method usually shows better convergence properties than the regular Newton method in the case of high nonlinearities. The consideration of these different arguments - in particular the expected high nonlinearities during the shear and axial failure of the experimental substructure - lead to the choice of a regular Newton algorithm with initial stiffness in combination with the regular HHT implicit integration scheme. Table 3 summarizes the analysis options selected for hybrid simulation of the gravity load collapse of reinforced concrete frames in order to optimize the hybrid simulation rate while preserving a good numerical accuracy. 93 Table 3: Summary of Analysis Options Integration time step 0.001s (ground motion sampled at 0.01s) Integration scheme regular Newmark Convergence tolerance le-8 (test on the Energy Increment) Algorithm Newton with Initial Stiffness 6.6 OpenFresco Experimental Setup Object ESThreeActuatorsLshape The accuracy of the hybrid test depends on the ability of the test setup to reproduce faithfully the 3-DOF loading imposed by the numerical model on the top of the center column during the seismic excitation of the whole structure. This loading is imposed through the three dynamic actuators by the means of command displacements computed by the OpenFresco method Experimental Setup. A new instance of the Experimental Setup class was developed for the specific three-actuator loading configuration presented in Fig. 29. This method, called ESThreeActuatorsLshape, is responsible for transforming the beam-column element degrees of freedom displacements from Opensees into actuators displacement commands (Fig. 45). 94 Figure 45: OpenFresco Experimental Setup ESThreeActuatorsLshape a) experimental setup b) initial configuration c) large displacements In the case of large displacements (Fig. 45c), the accurate application of the element DOF commands (d) through actuator displacements (dLa) implies considering the nonlinear geometry and kinematics of the configuration. This is. achieved through trigonometric transformations on the command side, where dLa is a nonlinear function of d (Fig. 46a): 95 a) Trigonometric closed-form formulation: dLa=f((l): «f£ol«^.£a1+£3WQ>£0-stn(a0»<*;2»i'+s XG+<f(0)--A0cos(ft0-ra(2JK-Z« i b) N o closed-form solution for d=g(dLa) -> Nevvton-Raphson al.goritlmi to solve for d k n o w i n g dJLa : Rjd.dLa hO'-'MdjiLil ^1,, ^ = 0 Figure 46: ESThreeActuatorsLshape nonlinear transformations Since dLa is a nonlinear function of d, no closed-form solution is available on the data aquisition side, and a Newton-Raphson algorithm is used to solve for d (Fig. 46b). The ESThreeActuatorsLshape method was implemented within the C++ environment and added within the OpenFresco project solution through the files ESThreeActuatorsLshape.h and ESThreeActuatorsLshape.cpp. More information on the nonlinear transformations used can be found by exploring these two files located in Appendix C and in the source code of OpenFresco 2.0 on the Numerical Analysis Host Computer. 6.7 xPCtarget Predictor/Corrector scheme The UBC hybrid simulation setup for the investigation of the gravity load collapse of reinforced concrete frames employed a modified version of the xPCtarget predictor/corrector model refined by Schellenberg (2005) and presented in section 3.2. The modifications concern the implementation of new prediction/correction models in order to accommodate for the use of the regular HHT implicit integration scheme. Indeed, as explained in section 6.5.3, regular implicit integration schemes lead to an dial dm dLa 2 \ 96 uneven distribution of displacement increments during the convergence process, with large displacement increment during the first steps followed by minimal corrective increments. This feature tends to create some "hold" phases or "plateaux" in the target displacements where the polynomial interpolation schemes developed by Mosqueda (2003) and Schellenberg (2005) proved to have a poor prediction/correction behaviour characterized by spurious oscillations (Fig. 47). 0 . 0 2 h W i 0.019 0.018 0.017 a. 0 016 to T3 CN | 0.015 0.014 0.013 0.012 0.011 Displacements from xPC-Target: Actuator 2 -Target Disp. from OpenSees Generated Command Disp. \j ii li : V t A = a i . v IL V/i-l y si v V/il Vi! /I: . \ / ft ii 319.5 319.6 319.7 319.8 3 1 9 9 320 320.1 320.2 320.3 320.4 320.5 Figure 47: Lagrange polynomial prediction/correction used with an iterative implicit integrator 97 Displacements from xPC-Target Actuator 2 0.0198 0.0196 0.0194 .» 0.0192 < 0.019 0.0188 0.0186 0.0184 Target Disp. from OpenSees Generated Command Disp. ^ 1 280.9 280.95 281 281.05 281.1 281.15 281.2 281.25 281.3 281.35 Time [sec] Figure 48: New prediction-correction strategies used with an iterative implicit integrator A new prediction strategy was developed based on the computation of the prediction slope through a linear regression on a given number of previous target displacements from OpenSees. The mathematical expression of the linear regression of a set of points (x,y) is: cov(x,_y)/ _N _ y = ——^-(x-x) + y V(x) where cov(x,y) is the covariance, V(x) the variance and x is the mean. Details in the mathematical expression of this prediction model can be found in the method predictLR (Linear Regression) in the C++ files PredictorCorrector.h and PredictorCorrector. c, available in Appendix D. 98 Furthermore, a new correction strategy was also implemented to avoid the sudden changes in slopes between the prediction and correction modes (spikes in Fig. 47). This new method called correctP4S0 (4th order Polynomial, Slope=0) uses a 4th order polynomial interpolation where zero slopes are imposed at the beginning and end of the correction phase, to ensure smooth transitions with the Prediction and AutoSlowDown phases. Details in the mathematical expression of this correction model can be found in the method correctP4S0 in the C++ files in Appendix D. Fig. 48 shows the target and command displacements generated for the same hybrid model with the new prediction/correction models: the spiky oscillations in the command signal are almost totally suppressed and a smooth continuous command is now generated. 6.8 Mixed Displacement and Force Control Setup The high axial stiffness of the reinforced concrete specimen can be the cause of inaccuracies in the control of the vertical actuators if these ones are under displacement control. As a result, it would be preferable to use these vertical actuators under force control to limit inaccuracies in the application of the loading. For this reason, an iterative algorithm was implemented within the Stateflow chart (Fig. 49) of the real-time controller (Fig. 50) to generate continuous force commands for the vertical actuators. These force commands are based on the displacement commands from OpenSees, the measured displacements and the effective stiffness of the specimen which is updated at the controller at a rate of 1024Hz. 99 Hybrid Controller with Force Commands Generation mantr spat; «ah,<* ;rrrfs 43 | M " T ' S xPC Ta rge t &1 <t<ift-?**;){th a fgcs f i^ 1 [iisclHT Acm.llTt-s> | Figure 49: Simulink Hybrid Controller with Force Commands Generation + Mode Switch 100 QTQ C 'Jl © C/3 O o n •0 <e a. S" o n o *1 o •n o n> n o 3 3 SS 3 Q. O rt 3 n -i S3 o" 3 HybridController Initialization of model Initialize en: i= 0; iSD= 0; en: diSD = 1; en; initData(nAct); en: zeroDsp(corn); Correct err di = min(max(diSO+1/(0.2*N)*(j-iSD),0.001).l .0); en: i = min(i+di.N); en: eorrectP4S0(targetdispiHDelay)<N), en: dspfbk= dspin; frcfbk= frcln; en: recordFrcDsp(dspfbk,frcfbk,com); i = JL mm du: dspfhk= dspln; frcfbk= frcln; k=(i-1 +iDelay+(j*1)/M}/t*«l du: Correctfrorce(targetdisp,Ksec,c6m.dspfbk,frcftik,k,M-j. du: recordFrcOsp(dspfbk,frc<bk,com); du:j+*; _j lnit_Predir;t en: state = 1; en: diSD = 1; en:i = 0;iSD = i Initialization of Predict state (Initialization of Correct state ? "Loops for the force command generation Loops for prediction/correction / Predict en; en; predictLR«t en: dspfbjps-ct§pln; en: j»ei5raFrcDsp(d = 0. p,<i+iDelav)/N); frcfbk= frcln; spfbk.frcfbk.com); |du':'Ispf51< = flspTn; trcfPTSTreIn;l< i^':r^DeTay+?j+l du: Predietforce{targetdisp,Ksec,corn,dspfbk,frcfbk,k,M-j; du: recordFrcDsp(dspfbk,frcfbk,com); »u:j±±, nit_Correct en: state - 0; en: se!CurOsp(corn,(i+iDelay)/N): en: dspLocal = dsp; en: setNevvDsp(dspLocal); AutoSlowDown en: i •= diSD;iSO= i, en: predictLR(targetdisp.(i+iDelay)/N); en; dspfbk= dspin; frcfbk = frcin; en: recordFrcDsp(dspfok,frcft»k,com); en: j = 0; du; dsplbk = dspin; frcfbk = frcln; k= (i- 1+i0elay+(j*l )/M)/N du: Predictf orce(targetdisp,Ksec,corn,dspfbk,frcfbk,k,M-j) du: recordFrcOsp(dspfbk.frcft>k,com); du:i++: nit_AutoSlowDown en; state = 2; e^n: diSD = 4-i/(0.2'N),l r Initialization of AutoSlowDown state / The main difference between this enhanced Predictor/Corrector and this original Predictor/Corrector scheme presented in Fig. 10 lies in the addition of an extra layer of iterations (Loops for force command generation) within each of the prediction/correction iterations (Loops for prediction/correction) in order to reach the displacement commands sent by OpenSees with the vertical actuators now in force control. Note that the vertical actuators can only be in force control while the specimen is in its linear range: displacement control is mandatory as soon as the specimen starts experiencing significant stiffness degradation, in order to avoid acceleration of the loading frame and subsequent crushing of the specimen if kept under force control. For this reason, a mode switch algorithm has been implemented to monitor the effective stiffness of the specimen and switch the vertical actuators from force to displacement control as soon as the effective stiffness goes under a predefined threshold. In the linear range of the specimen, force commands are generated according to Equation 3: where j = 0..M-1 is the iteration index, Kj is the secant stiffness based on the displacement and force feedbacks of the previous iterations, fj and dj are the displacement and force measured at the end of the previous iteration j, and M is the fixed number of iterations to reach - in force control - the target displacement d t arget computed by the predictor/corrector based on the displacement command from OpenSees. fJ+i=fj+Kj with Kj=-fj-fj-i dj-dj-i (3) 102 Figure 51: Iterative algorithm for the generation of continuous force commands (dcj is the target displacement that would be reached without stiffness changes, dj is the actual displacement) Within each substep of the predictor/corrector algorithm, M subiterations are performed to reach the target displacement dtarget with the vertical actuators in force control. The force commands fj+i are issued every 1/1024s. Note that the secant stiffness used in the computation corresponds to the state of the specimen during the previous iteration (1/1024s earlier), consequently the displacement CIM reached at the end of the iterations may be slightly different from the command displacement, dtarget, if the specimen experienced changes in stiffness during the iterations. In the example presented in Fig. 51, the stiffness of the specimen has decreased by 15% at the end of the iteration process, which leads to a displacement d3 which is 3% larger than the target displacement, dtarget-However, this algorithm is only used in the linear range of the specimen, so that the inaccuracies that may result from a change in the actual stiffness are small compared to the inaccuracies that would result from the use of displacement control on a stiff specimen. 103 Note that problems encountered with the simultaneous tuning of the actuators in force control prevented the actual testing and calibration of this mixed force-displacement predictor/corrector scheme. Indeed, the simultaneous tuning in force control of the three interacting actuators presented large difficulties, characterized by sudden unstabilities of the system leading to very high loads applied to the substructure. For safety reason, and until good control can be reached in force control, choice was made to perform the hybrid tests with the three actuators under displacement control. As a result, the algorithm with force command generation and mode-switch could neither be tried or validated on the test setup. More investigations on tuning in force control must be performed in order to reach a safe control, and this is a prioritary step in order to be able to actually test and validate the mixed force-displacement control strategy described in this section. 6.9 Tuning of the Actuators - Steel Dummy Specimen The tuning process for the actuators always presents the risk of sudden loss of control leading to the unvolontary application of very large forces on the test setup. In order to avoid damage on the reinforced concrete specimen during the tuning process, and in order to test the global hybrid simulation architecture, a steel dummy specimen was designed and substituted for the reinforced concrete column (Fig. 52). 104 Pautosi'aplis i x L J r ± 3 M i l d Steel ^ Rod: Ste. . .Column Yielded Steel - Pedestral IK —, Square Section Hol low Steel Beam -feSfci— , rig Figure 52: Steel Dummy Specimen Setup As mentioned before, instabilities of the control system under force control lead to the choice of performing the hybrid tests with the three actuators under displacement control. Preliminary tests were performed on this dummy specimen setup to test the behaviour of the global hybrid simulation architecture with OpenSees/OpenFresco, the behaviour of the predictor/corrector schemes and the accuracy of the actuators tuning in displacement control. Force and displacement limits detectors were set in the STS software to avoid damage in case of unstability of the control. Data recorders were used in both the STS software and OpenSees. Note that the configuration of the test setup implies to compensate for the moment induced at the top of the columnd due to the unsymetric dead load of the steel L shape through the use of the actuators. Caution must be used when testing is performed on the reinforced concrete column specimens as the moment due to the self-weight of the loading setup exceeds the cracking capacity of the column: compensation through the actuators or safety restraints on the loading setup must be used at any time to avoid unvoluntary damage on the test specimens. 105 7.0 HYBRID SIMULATION OF GRAVITY LOAD COLLAPSE: TESTS RESULTS FOR FIRST SPECIMEN This chapter presents the results of the first hybrid test on the gravity load collapse of reinforced concrete frames. Section 7.1 describes the ground motion used during the analysis, and presents estimates of the period of the hybrid two-bay frame structure. The next sections present the characteristics and results of the first hybrid test in more details. 7.1 Earthquake ground motion and period of the hybrid model 7.1.1 Earthquake ground motion Both hybrid models (first and second specimens) were subjected to the same horizontal component from a scaled ground motion recorded during the 1985 Chile earthquake (Fig. 53). To allow for an accurate comparison with the shake table results, the accelerations used for the hybrid tests were recorded on the shake table during the shake table test (Elwood and Moehle, 2003). Minimal differences observed between the original ground motion and the one recorded on the shake table are documented in Elwood and Moehle, 2003. 10 20 30 40 Time (sec) 50 Figure 53: Input ground motion (recorded on shake table, Specimen 2, Elwood and Moehle, 2003) The original ground motion (Chile, 1985) was selected so that it provided enough intensity to lead to shear failure of the center column, and also so that the maximum displacement ductility demand on the frame be limited to avoid failure of the outside columns. Furthermore, a long duration ground motion was chosen so that the mechanics 106 of axial failure can be observed over a large number of cycles (Elwood and Moehle, 2003). The selected Chile ground motion was scaled in time by a factor of V0.5 to account for the 1:2 length scale factor of the specimens. Filtering was also performed to remove the high and low frequencies that were beyond the range of the shake table controller used by Elwood and Moehle (2003). Acceleration and displacement response spectra for the ground motion used during the hybrid tests are presented in Fig. 54. 0.0 0.2 0.4 0.6 0.8 1.0 1.2 1.4 1.6 1.8 2.0 0.0 0.2 0.4 0.6 0.8 1.0 1.2 1.4 1.6 1.8 2.0 Period (sec) Period (sec) Figure 54: Acceleration and displacement response spectra for the input ground motion 107 7.1.2 Period of the hybrid model 0.04 0.03 0.02 0.01 1 o O 1* -0.01 -0.02 -0.03 -0.04 II 6 Free v ib ra ion period: T=0 .32 cracked column) •U-U \h v v i| 1 v; 10 11 Time [sec] Figure 55: Free vibration test of the hybrid two-bay frame with slightly cracked center column Free vibration tests to determine the period of the hybrid model were omitted before conducting the actual hybrid tests under seismic excitation. Because of a software crash that stopped the analysis after a few seconds of ground motion, free vibration tests could be performed on the hybrid model with a slightly cracked center column (Fig. 55). The corresponding estimate of the period of the hybrid two-bay frame is shown in Table 4 in comparison with the period of the shake table test specimen. Table 4: Periods of the two-bay frame (shake table test and hybrid test) Period (s) Shake table test specimen 2 uncracked (Elwood and Moehle, 2003) 0.21s Shake table test specimen 2 Slight cracking on colums (Elwood and Moehle, 2003) 0.25s Free vibrations test with slightly cracked center column 0.32s 108 Note that the measured stiffness for the center column used in this free-vibrations test takes into account the flexibility of the loading frame (Section 7.4), and is only two thirds of the stiffness of the specimen itself. As a result, the lateral stiffness of the hybrid two-bay frame used to compute the free-vibration period is approximately 8/9 of the actual one (1/3 + 1/3 + 2/3x1/3 since all three columns have almost the same lateral stiffness). It is interesting to compute an approximation of the period that would be obtained if the flexibility of the loading frame was removed: As a result, if Thybrid including the loading frame .flexibility is measured to be 0.32s, the actual measured period of the hybrid model without this added flexibility would be approximately: This corrected value of the period of the two-bay frame is closer to the value of 0.25s measured on the cracked shake table test specimen (Elwood and Moehle, 2003), but further investigation on this difference should be performed. 7.2 Hybrid Simulation Tests for Specimen 1 Good results were obtained from the hybrid tests of the two-bay frame system with Specimen 1: as expected from the shake table tests, shear failure and axial load failure of the experimental center column were observed (Fig. 56). Thybrid = ln^mlkhybrid = 2 ^ A mi actual actual 109 a) Shear failure b) Axial load failure Figure 56: Damage of center column during first hybrid test However, this first hybrid test was characterized by repeated crashes of the predictor-corrector application during the analysis. As a result, this first test was broken down into the 4 parts described in Table 5, and the modifications noted in the table were performed on the predictor-corrector applications and on the OpenSees analysis options to try to mitigate this crashing issue. Note that, as mentioned in Section 7.1.2, a free vibration test was performed on the hybrid model just after the first crash of the predictor-corrector application. 110 Table 5: Description of the first hybrid test series Test Name Time in ground motion Hybrid Model Characteristics Comments Hybrid Test 1 Part 1 Os - 13.90s Predictor-Corrector: N=16 sub iterations, limited data recording OpenSees analysis: Tolerance le-8 Crash of Predictor-Corrector (loss of Host-Target communication). No cracking of experimental column. Hybrid Test 1 Part 2 11.78s-20.43s Predictor-Corrector: N=16 subiterations, no data recording OpenSees analysis: Tolerance le-8 Failed to converge after 50000 iterations Light cracking of experimental column. Hybrid Test 1 Part 3 - Free vibrations test Free vibrations after applying 2 kips laterally at the top Predictor-Corrector: N=16 subiterations, no data recording OpenSees analysis:. Tolerance le-8 Free vibrations test OK. Hybrid Test 1 Part 4 11.78s-34.328s Predictor-Corrector: N=12 subiterations, no data recording OpenSees analysis: Tolerance le-6 Crash of Predictor-Corrector after shear and axial load failure of center column The results presented in the following sections - and subsequently called first hybrid test - correspond to Hybrid Test 1 Part 4 only, since Parts 1 and 2 correspond to the low amplitudes cycles of the ground motion. The tolerance in OpenSees was increased to le-6 for Part 4 in order to avoid the convergence failure observed in Part 2 and reduce the average number of iterations required for convergence. Note that, according to Fig. 44, with a tolerance of le-6 the results are still very accurate for most of the displacement and force quantities (1% error 111 for all quantites, except 8% error for axial force); as a consequence the accuracy of the numerical analysis is still acceptable with this higher tolerance. 7.3 Hybrid simulation characteristics Distribution of Integration Step Duration 6000 5000 4000 a. 3000 CD E 2000 1000 1 1 1 Average £ tep Duration: 1 72.7809 msec ; I I I il.llllllllll.llll.ini '<>"!"- i i 500 1000 1500 Integration Step Duration [msec] 2000 2500 Figure 57: Distribution of Integration Step Duration Fig. 57 presents the histogram of the distribution of duration of the analysis integration steps. The average duration of an integration step in OpenSees was about 173ms, meaning that 1ms of analysis for the numerical model required on average 173ms of simulation time. In other words, the average hybrid simulation rate for the first hybrid test (Hybrid Test 1 Part 4) was 173 times slower than real-time. Note that the simulation rate is not constant throughout the test but varies with the number and duration of the iterations required by OpenSees to reach the convergence tolerance through the use of the regular Newmark integration scheme combined with a Newton algorithm with initial stiffness. For example, the tall bar for the 20-40ms range 112 indicates that during approximately 5300 integration steps the simulation rate was between 20 and 40 times slower than real-time, but the large amount of iterations required for some of the time steps lead to a much slower average simulation rate. 6000 5000 4000 Distribution of Number of Iterations per Integration Step IS) Oj 3000 CD E 2000 1000 0 1 i Average N jmber of: Iteration s: 14.66 92 I III l i l t torn ii i i '-0 20 40 60 80 100 120 140 160 180 Number of Iterations Figure 58: Distribution of number of iterations per integration step Fig. 58 plots the distribution of the number of iterations required for convergence for each integration step. Note that although most of the integration steps only required one iteration for convergence, some of them needed up to 180 iterations; this lead to an average number of iterations of about 14.7 for the whole test. 113 Distribution of Integration Iteration Duration 18000 16000 14000 1 12000 CO CD 10000 tn o CD 8000 E -z. 6000 4000 2000 i j i Ave rage. Step. Deration:. 1:1.7809. m sec ! i,.. i i i 1 10 15 20 25 30 35 40 Integration Step Duration [msec] 45 50 Figure 59: Distribution of the duration of one integration iteration Fig. 59 plots the distribution of the duration of one iteration in the convergence process. One iteration is performed every simulation time step (specified in the predictor/controller settings), and consists in the computation of the displacement increments by OpenSees, the communication of this new target to the real-time xPCtarget controller, the smooth application of this command by the actuators, the reading of the force and displacement feedbacks at target and the communication of this data back to OpenSees in order to populate the restoring force vector for computation of the next analysis step. Fig. 59 indicates the variability in the computation time in OpenSees as well as the communication delays. Fig.59 shows an average iteration duration of 11.78ms, when the specified simulation time step was 11.72ms (see Table 7 below). This means that the integration and communication process described earlier for each simulation step was carried out within the specified simulation time step of 11.72ms for 99.5% of the iterations. This implies that the choice of the simulation time step was optimal: a 114 simulation time step too small compared to the time needed by OpenSees would have lead to some frequent AutoSlowDown phases and the average iteration duration would have been way longer than the specified simulation time. On the other hand, a simulation time step too long compared to the time needed by OpenSees would have been detrimental to the overall simulation rate. Table 6 summarizes the hybrid simulation parameters for the first hybrid test (Hybrid Test 1 Part 4), and Fig. 60 illustrates the meaning of each of these parameters. Table 6: Summary of the hybrid simulation parameters for the first test (Hybrid Test 1 Part 4) Integration/Analysis time step in OpenSees 0.001s = 1ms Controller time step 0.977ms (1024Hz) Simulation time step 11.72ms (=12x0.977ms i.e. N=12 subiterations) Average number of iterations per analysis time step 14.7 (convergence tolerance: le-6) Average simulation rate (expressed as ratio of analysis time step) 173 115 IS 0.16 0.14 0.12 0.08 0.0B 0.04 0.02 0 One controller.time step (1/1024 s) = one sub iteration for the Predicto r/Cor recto r 1 simulation time step = 12 subiterations one OpenSees iteration 4 simulation time steps •A OpenSees iterations = 1 OpenSees analysis time-step "0 0.005 0.01 0.015 0.02 0.025 0.03 0.035 0.04 0.045 0,05 Time [sec] Figure 60: Controller, Simulation and Analysis time-steps (it is assumed that convergence is achieved after 4 iterations for this step) 7.4 Comparison of global performance with shake table test results This section presents the global results from testing of the first reinforced concrete column specimen (Hybrid Test 1 Part 4). The center column of the hybrid model suffered shear failure followed by axial failure and load redistribution to the outside columns, and showed an overall behaviour very similar to the one observed on the shake table test of the same two-bay frame system (Elwood and Moehle, 2003). Remember that the steel reinforcement ratios and concrete strength of the center column are slightly different (Table 2), and that the accuracy of the numerical modelling has a big influence on the match between the hybrid simulation and shake table tests data; hence a direct comparison of the numerical values is not relevant. 116 -2 -1 0 1 2 3 4 5 Horizontal Displacement [in] -1 0 1 2 3 4 5 Horizontal Displacement [in] : 3 -2 -1 0 1 2 3 4 5 Horizontal Displacement [in] a) Hybrid Test 1 T 0 2 d *—. 0 ill £ -0.2 CD g -0.4 S" -0.6 3 "55 -0.8 o It -1 > -1 2^ -3 -2 -1 0 1 2 3 4 5 Horizontal Displacement [in] b) Shake table test (speeimen 2) Figure 61: Relations between center column axial load, vertical displacement, and horizontal displacement of top of center column for first hybrid simulation test Fig. 61 displays the relations between center column axial load, vertical displacement, and horizontal displacement of the top of the center column for the first hybrid simulation test and the corresponding shake table (Elwood and Moehle, 2003, Specimen 2). Note that the results from the first hybrid simulation test showed in Fig. 61.a) present less cycles than expected after axial failure because of a software crash in the last third of the ground motion (see 7.1). 117 As in the shake table test (Elwood and Moehle, 2003), after axial failure of the center column an alternative load path is provided for the gravity load through redistribution to the outside columns. As a result, the axial load in the failing center column is not lost all at once. As in the shake table test, the results from the first hybrid test suggest that the same two mechanisms govern the increase in vertical shortening of the column: first, large pulses that cause a sudden increase in vertical displacement after a critical drift is attained; and second, smaller oscillations that appear to "grind down" the failure plane. However, the limited amplitude of the drifts observed during the hybrid test tends to reduce the influence of the first mechanism for this test. A noticeable difference between both tests consists in the concentration of damage during positives pulses for the shake table test, whereas damage seems to be distributed between positive and negative pulses during the hybrid test. This trend can be explained by the poor behaviour of fiber elements in predicting residual drift; indeed, previous studies (Elwood and Moehle 2003; Hachem 2002) have shown that fiber elements do not provide accurate estimates of the residual displacements observed at the end of shake table tests. Moreover, a different trend can be observed for the horizontal displacement-axial load behaviour before degradation (top plots of Fig. 61) for the hybrid test compared to the shake table test. The shake table test shows a diminution in the axial load during lateral displacements whereas an increase in axial load is observed during lateral displacement for the hybrid test. This difference can be explained by a larger "growth" with lateral displacement of the center column compared to the outside columns during the hybrid test (Fig. 62). As a result, the beam bends upward (instead of bending downwards during the shake table test), adding compression to the column (instead of reducing the axial load). Note that this discrepancy disappears after shear failure and that the same behaviour is then observed for hybrid and shake table results (reduction in axial load with lateral displacements). The reason lies in the center column ceasing to grow with lateral displacement after shear failure; indeed, shear deformations now govern the lateral response, and flexural deformations responsible for the vertical elongation of the column are now negligible. 118 -0.24 Lateral Displacement [in] Figure 62: "growth" of the center column with lateral displacements relative to the outside column (average relative vertical displacement = distance from the top of the center column to a straight line connecting the tops of the outside columns, ie center column vertical displacement minus average displacement of outside columns) Note that further research must be completed to fully understand the behaviour observed in Fig. 62; in particular, one should investigate the apparent increase in relative displacement between center and outside columns during subsequent cycles. 119 -20!, Center Column 10 15 Analysis Time [sec] 20 25 0 4 0.2 Or CD E cu o ro Q_ _> Q o -0.2 cu > -0.4. Left Column Right Column -Center Column 10 15 Analysis Time [sec] 20 25 Figure 63: time histories of the axial loads and vertical displacements on the center and outside columns (hybrid simulation test) Fig. 63 presents the time histories of the axial loads and vertical displacements on the center and outside columns for the hybrid simulation test. The first five seconds correspond to a ramp phase where the axial load is progressively applied on the reinforced concrete column. Note that a failure of the recorders for the axial loads of the outside columns does not allow the visualization of the increase of axial load on the outside columns. However, the progressive loss of axial load observed on the center column after about 21 s demonstrates that load redistribution on the outside columns was captured since the total dead load on the structure remained the same throughout the test. The process of axial load distribution was not complete when the software crashed at 22.548s. 120 7.5 Shear hysteretic response of the center column Fig. 64 presents the shear hysteretic response of the center column for the first hybrid simulation test (Hybrid Test 1 Part 4) and the corresponding shake table test (Elwood and Moehle, 2003, Specimen 2). - 2 - 1 0 1 2 3 4 Horizontal Displacement [in] a) Hybrid Test 1 Q . CO CD JO (f) c E O U 20 10 o5 -10 c a -20 - 2 - 1 0 1 2 3 4 Horizontal Displacement [in] b) Shake tabic test (specimen 2) Figure 64: Shear hysteretical response of the center column for Hybrid Test 1 and Shake Table Test Note that stiffness and strength degradation have been captured by the hybrid model. Furthermore, as in the shake table test, the negative stiffness is clearly visible after initiation of the shear failure of the center column. A quick observation shows that the lateral elastic stiffness appears to be approximately 20kips/in for the hybrid simulation test, whereas it was measured to be about 29kips/in during the shake table test. This difference comes from the fact that Fig. 64a) represents the force and displacement feedbacks measured on the horizontal actuator - i.e. on the loading frame and not on the specimen - after nonlinear transformations within the experimental setup object ESThreeActuatorsLshape. A comparison with the displacement data recorded by the horizontal spring pot at the top of the specimen (Fig. 34) allows the separation of the actual displacement response of the specimen and the deformations of the loading frame (Fig. 65). 121 Force-Deformation for Loading Frame Column Deformation [in] Figure 65: Force-deformation relationships for the loading frame and the specimen Note that the plots of Fig. 65 are much more jagged than the plot from Fig. 64a, because Fig. 65 plots the data recorded at the controller sample rate of 1ms, whereas Fig. 64a plots the data recorded by OpenSees for every integration step at convergence only, ie on average every 173ms (see Part 7.2 for detailed information on the characteristics of the hybrid simulation test). As a result, the force oscillations due to the fast application of the displacement increments by the actuators are much more visible on Fig. 65. It is interesting to see that the loading frame presents an almost linear behaviour in spite of its bolted connection, and its actual stiffness (approximately 60kips/in) can be substracted from the "loading frame+specimen" series system to obtain an actual elastic stiffness for the concrete column alone of about 32kips/in (very close to the value of 29kips/in observed during the shake table test). Fig. 66 plots the actuator and specimen lateral displacements during part of the simulation. 122 Figure 66: Actuator and column lateral displacement Note that the effects of the nonlinear geometric transformations implemented in ECThreeActuator sLshape to account for possible angles on the actual forces and displacement applied by the actuators (Fig. 42) can be observed on Fig. 67 plotting the shear hysteretic behaviour based on transformed (noted OpenSees) and non transformed data (noted measured in the graph). 123 Force-Deformation for Column _25 I i I i i i i 1 i i 1 -2.5 -2 -1.5 -1 -0.5 0 0.5 1 1.5 2 2.5 Horizontal Displacement [in] Figure 67: Effects of nonlinear geometric transformations on measured hysteresis This effect is maximum when the axial load applied by the vertical actuators and the lateral displacement of the loading frame are maximum. For example, for a lateral displacement of 2 inches, the actual lateral force experienced by the specimen is approximately equal to the horizontal actuator force minus the horizontal component of the forces in the inclined vertical actuators. If the horizontal actuator force is 20kips and the vertical load applied by the actuators is 50kips, for a lateral displacement of 2 inches the effective lateral force sustained by the specimen is only 20-50*2/60=18.3 kips (this is a linear approximation, 60 inches being the length of the vertical actuators), and this value corresponds to the difference between the forces recorded by OpenSees and the values measured on the horizontal actuator. Consequently, a precise estimate of the actual forces and deformations sustained by the concrete specimen would imply to use the nonlinear geometric transformations 124 implemented in OpenFresco in combination with an external displacement transducer located on the specimen itself, to avoid measuring the deformations of the loading frame. 125 8.0 HYBRID SIMULATION OF GRAVITY LOAD COLLAPSE: TESTS RESULTS FOR SECOND SPECIMEN 8.1 Improvements on the hybrid simulation setup 8.1.1 Problems identified during first hybrid test As mentioned in Chapter 7, a few problems were identified during the first hybrid test and lead to some modifications in the hybrid simulation setup: Deformations of the loading frame making the experimental substructure appear softer in the hybrid model. The solution consisted in controlling the horizontal actuator through an external LVDT located at the top of the specimen (Part 8.1.2), so that deformations of the loading frame are not measured. Oscillations in the force feedback due to the fast application of steep displacement increments during the first iteration of each analysis time step (see Part 6.5.3). This major issue was solved through an important modification of the real-time predictor/corrector scheme: extra states were added in the model in order to slow down the analysis and the actuators motion when a steep displacement increment was to be applied (Part 8.1.3). Crashes of the predictor-corrector application leading to interruptions of the hybrid test. To address this issue, the Pentium 4 computer used as the xPCtarget Host was replaced by an AMD Athlon64. The performances of this new computer for real-time xPCtarget applications were assessed to be improved considerably (through the use of the Matlab function xpcbench('this')). 126 8.1.2 External LVDT for control of the horizontal actuator Figure 68: Hybrid Simulation Setup with External L V D T As described in Part 7.3, part of the command displacement imposed on the horizontal actuator was taken by the elastic deformation of the loading frame, resulting in reduced displacements imposed on the concrete specimen itself. The solution consisted in controlling the horizontal actuator through an external LVDT located at the top of the specimen (Fig. 68). A ball bearing combined to a compression spring (Fig. 69) ensured a permanent contact between the LVDT and the steel contact surface while enabling rotation and vertical motion of the loading frame during the testing. External L V D T 127 Figure 69: External LVDT 1 2 8 8.1.3 Modified predictor/corrector scheme 0 1 c 0 CO p CD J5 -0.1 Q, « j Q CN -0.2 tS < 1108 ton convergence process 1110 1112 1114 1116 Time {sec] r-Command Disp. Disp Feedback 1118 1120 1110 1112 1114 Time [sec] 1116 1118 1120 Figure 70: Oscillations in the force feedback (First Hybrid Test) As mentioned in Part 8.1.1, oscillations on the force feedback were observed during the fast application of steep displacement increments (Fig. 70). As explained in Part 6.5.3, these steep displacement increments come from the use of a Newton algorithm (combined with a regular Newmark integration scheme): during the convergence process, a large increment is applied during the first iteration, followed by a variable number of low-amplitude corrective iterations until the convergence tolerance is reached. 129 In the predictor-corrector model used for the first test, the same amount of time was given to the actuator to apply the target increment received from OpenSees, regardless of the amplitude of this increment (this amount of time is less than to the simulation time step specified in the initialization file of the Simulink model, ie 12ms for the first test). As a results, the large increments obtained during the first iteration of each analysis time step (approximately 0.02-0.03 in) had to be applied in a very short time - approximately 6ms, and this was responsible for the oscillations observed in the force response (Fig. 70). Fixing this problem implied to limit the velocity of the actuators during the application of the steep displacement increments to ensure a smooth force response. The simplest strategy to try to achieve this goal consisted in detuning the horizontal actuator to make it less reactive to its command. This strategy proved to be ineffective on a dynamic actuator because of the inherent high speed of its servovalve: a full detuning of the PID controller associated with the actuator had no effect on limiting its velocity. Note that detuning the actuator would have added some delay in the control loop. This delay would have had to be accounted for in the predictor-corrector model to ensure that the reading of the force feedback be delayed of the corresponding amount of time. Indeed, it is critical that the force feedback sent back to OpenSees be performed at- the exact time when the target displacement is reached, taking into account eventual delays in the control loop. The final strategy implemented to get rid of the force oscillations consisted in a significant modification of the predictor/corrector model. Indeed, limiting the velocity of the actuator implies that more time is given to the actuator to apply large displacement increments, but it also involves that the reading of the force feedback be delayed by the same amount of time, to ensure the consistency between the target displacement and the restoring force sent back to OpenSees. New states were added to the original Stateflow chart (Fig. 12) to ensure that the actuators and analysis are delayed when a large target increment is detected (Fig. 71) 130 Normal: Correction of the path of the actuators to smoothly reach Ihe OpenSees target SlowStep: Actuators slowed down when steep displacement increment (avoid jumps) Initialize — Correct: Initialization of Normal and SlowStep Predict: Actuators kept in motion by interpolation Event-driven predictor/corrector MATLAB Sunulmk+Stateflow (R) AutoSlow Down: i f delay's in computation Figure 71: New Predictor-Corrector Scheme with SlowStep state The architecture of this new model is identical to the original version (see Part 3.2.2) except that the Correct state is now split into two components : - Normal: this state is activated if the displacement increment between the new and previous command for the horizontal actuator is below a specified threshold. The behaviour of this state is identical to the Correct state from the previous model (Part 3.2.2): the path of the actuators is corrected through the chosen interpolation procedure in order to smoothly reach the new target from OpenSees - SlowStep: this state is activated when the displacement increment for the horizontal actuator exceeds a specified threshold. In this case, more time is given to the actuators while the reading of the force feedback is delayed, and this amount of extra time is proportional to the amplitude of the displacement increment. 131 Note that the implementation of the SlowStep state is similar to the AutoSlowDown state (Part 3.2.2): the incrementation of the internal counter (describing the subiterations within each simulation time step) is slowed down when any of these two states is activated, meaning that the actual duration of the simulation step is increased accordingly. More detailed information on the behaviour of the event-driven predictor/controller (in particular its internal counter) can be found in Mosqueda (2005) and Schellenberg (2005). Fig. 72 shows the behaviour of this new predictor-corrector scheme: the force oscillations have now disappeared, leading to a smooth force response. Note that the quality of the tracking between displacement command and feedback is not as good as during the first hybrid test because of the use of an external LVDT of lower quality instead of the built-in high-precision LVDT of the actuator. 0.35 u E Q. m Q < 0 3 512 Actuators and analysis slowed down when big increments detected 5512.5 5513 Actuators and analysis accelerated during small corrective increments 5513.5 5514 Time [sec] 55145 5515 Command Disp Disp Feedback 5515.5 5516 No more force oscillations i _ i i a. s. 3.5 0) P 5 u. 01 Z 3 o < 5512 5512,5 5513 5513 5 5514 5514 5 5515 5515.5 5516 Time [sec] Figure 72: Disp. and Force time histories with the new predictor-corrector scheme 132 8.2 Characteristics of the second hybrid simulation test Distribution of Integration Step Duration CO Q. CD -t—> w 0) 16000 14000 12000 10000 8000 6000 4000 2000 i 1 i 1 ; Average- Step Duration:- 4:47.-3705 • msec-1 I 1 lllllllllllllniillllll Ilm,,,! i > i 200 400 600 800 1000 1200 1400 1600 1800 2000 Integration Step Duration [msec] Figure 73: Distribution of Integration Step Duration Fig. 73 presents the histogram of the distribution of duration of the analysis integration steps. The average duration of an integration step in OpenSees for the second hybrid test was about 147ms, meaning that 1ms of analysis for the numerical model required on average 147ms of simulation time. In other words, the average hybrid simulation rate for the second test was 147 times slower than real-time. Again, the simulation rate varies during the analysis, depending on the number and duration of the iterations required to reach the specified convergence tolerance. The fastest integration time step was computed within 8.7ms (one iteration for convergence), whereas the slowest took 1902ms (139 iterations required for convergence). 133 CO CD GO CD S2 E 16000 14000 12000 10000 8000 6000 4000 2000 0 Distribution of Number of Iterations per Integration Step 3. Number, t i if Iterations' 7 3.1.95 i ll III i II II ii in in 1.1. ,i .. .. I i 0 20 40 60 80 Number of Iterations 100 120 140 Figure 74: Distribution of number of iterations per integration step Fig. 74 plots the distribution of the number of iterations required for convergence for each integration step. Note that for the same convergence tolerance of le-6, the average number of iterations was only 7.3 for the second hybrid test compared to 14.6 for the first hybrid test. The maximum number of iterations was also smaller during Test 2 (140 against 180). These results can be explained by the disappearance in Test 2 of the force oscillations caused in test 1 by the fast application of displacement increments. The smooth force response during Test 2 seemed to help the OpenSees convergence process by reducing the required number of iterations. 134 2 1.8 1.6 g. 1-2 a: 55 *- 1 o 1 I CD E 0.8 x 10 Distribution of Integration Iteration Duration 0.6 0.4 0.2 0 1 1 1 ' 1 1 1 Average Sfe'p Duration: 18.2728 msec II j I ; \ j ; || ; \ \ \ i "0 20 40 60 80 100 120 140 160 180 Integration Step Duration [msec] Figure 75: Distribution of the duration of one integration iteration Fig. 75 plots the distribution of the duration of one iteration in the convergence process. It shows an average iteration duration of 18.27ms for the second hybrid test, compared to 11.78ms for the first test. This longer duration is due to the slowing down of both the actuators and the analysis during the big displacement increment happening at the first iteration of each analysis time step. However, it should be emphasized that this longer iteration duration is beneficial to the overall simulation speed since it lead to a reduced average number of iterations required for convergence, and resulted in a smaller overall simulation rate (147 times slower than real-time for the second hybrid test, compared to 173 for the first test). Table 7 summarizes the hybrid simulation parameters for the second test. 135 Table 7: Summary of the hybrid simulation parameters for second test Integration/Analysis time step in OpenSees 0.001s = 1ms Controller time step 0.977ms (1024Hz) Average simulation time step 18.27ms Average number of iterations per analysis time step 7.3 (convergence tolerance: le-6) Average simulation rate (expressed as ratio of analysis time step) 147 8.3 Comparison of global behaviour with shake table test results This section presents the global results from testing of the second reinforced concrete column specimen. As in Test 1, the center column of the hybrid model suffered shear failure followed by axial failure and load redistribution to the outside columns, and showed an overall behaviour consistent with the one observed on the shake table test of the same two-bay frame system (Elwood and Moehle, 2003). 136 -3 -2 -1 0 1 2 3 4 5 Horizontal Displacement [in] -3 - 2 -1 0 1 2 3 4 5 Horizontal Displacement [in] -1 0 1 2 3 4 5 Horizontal Displacement [in] a) Hybrid Test 2 3 - 2 -1 0 1 2 3 4 5 Horizontal Displacement [in] b) Shake table test (specimen 2) Figure 76: Relations between center column axial load, vertical displacement, and horizontal displacement of top of center column for first hybrid simulation test Fig. 76 displays the relations between center column axial load, vertical displacement, and horizontal displacement of the top of the center column for the second hybrid simulation test and the corresponding shake table (Elwood and Moehle, 2003, Specimen 2). 137 Similar to the first hybrid test, the axial load in the failing center column is lost gradually since an alternate load path is available to redistribute the gravity load on the outside columns. Again, the same two mechanisms as those identified by Elwood and Moehle (2003) seem to govern the increase in vertical shortening of the column: large pulses that cause a sudden increase in vertical displacement after a critical drift is attained, and smaller oscillations that appear to "grind down" the failure plane. However, once more the limited amplitude of the drifts observed during the hybrid test tend to nearly eliminate the influence of the first mechanism. A main difference between the second hybrid test and the shake table test results consists in the large residual drift observed during the shake table test. This trend is not captured by the hybrid simulation, and seems to be due to the fiber elements constituting the outside columns: their numerical behaviour tends to accentuate the tendency of the system to come back to the center position. As a result, damage is not concentrated in the positive pulses as in the shake table test but appear to be distributed equally between positive and negative pulses, leading to an almost symmetrical response. As in the first hybrid test, an increase in axial load is observed during lateral displacement for the second hybrid test, whereas the shake table test shows a diminution in the axial load during lateral displacements. This difference is once more explained by a larger "growth" with lateral displacement of the center column compared to the outside columns during the hybrid test. Furthermore, this discrepancy disappears again after shear failure, since shear deformations replace flexural deformations as the governing mechanism for the lateral response of the center column. The last major difference between this second hybrid test and the shake table test lies in the amount of vertical shortening experienced by the center column during failure: this might be explained by the limited capacity of the numerical model to capture accurately the drifts experienced by the structure (see Elwood and Moehle, 2003 - Chapter 8), and is also explained by the use of a linear beam in the numerical column that does not capture the nonlinear deformations actually occuring during the shake table test. 138 Analysis Time [sec] 0.4 Q 1 1 1 1 1 ^ n r . ^  L tA 1 kk Mi \l± iAi tLt ,;, ^—^ \ — L e f t Column —Center Column Right Column -s i i I . — - --, - T • u t ) 10 20 30 40 50 60 70 80 Analysis Time [sec] Figure 77: Time histories of the axial loads and vertical displacements, Second Hybrid Test Fig. 77 presents the time histories of the axial loads and vertical displacements on the center and outside columns for the second hybrid test. Again, the first five seconds correspond to the ramp phase where the axial load is progressively applied on the reinforced concrete column. We can clearly notice the process of load redistribution between the center and outside columns during failure of the center column. Indeed, the center column starts to lose axial load after about 30s of the analysis, and its initial axial load is progressively redistributed to the outside columns, thus maintaining the vertical load equilibrium in the structure. 8.4 Shear hysteretic response of the center column Fig. 78 presents the shear hysteretic response of the center column for the second hybrid simulation test and the corresponding shake table test (Elwood and Moehle, 2003, Specimen 2). 139 Figure 78: Shear hysteretical response of the center column for Hybrid Test 2 and Shake Table Test It can be noticed that stiffness and strength degradation have again been captured by the hybrid model. Furthermore, as in the shake table test, the negative stiffness is visible after initiation of the shear failure of the center column. It is important to notice that the degradation of the center column happens over many more cycles during Hybrid Test 2, compared to the shake table test (Fig. 78b) and compared to Hybrid Test 1 (Fig. 64). The difference with Hybrid Test 1 simply lies in the disappearance of the actuators jumps caused by the fast application of the displacement command increments : these jumps caused a quicker failure of the concrete specimen. Moreover, as in Hybrid Test 1, the shear hysteretic response during Hybrid Test 2 is characterized by the unability of the hybrid model to capture the residual drift suffered by the two-bay frame under excitation by the ground motion. Note that the slight kinks in the force shear hysteretic plot visible in Fig. 78a are due to a stick-slip problem in the swivels of the vertical actuators. Indeed, the oil pressure in the swivels should be reduced in order to diminish the rotational friction coefficient within these swivels and account for the longer lever-arm due to the length extensions added to the original actuators. 140 9.0 SUMMARY AND FUTURE RESEARCH 9.1 Summary The structural testing method called hybrid simulation was successfully implemented at the University of British Columbia. Distributed tests were performed between the University of British Columbia and the University of California, Berkeley to demonstrate the concept of geographically distributed hybrid testing. The primary focus of this study was on the application of hybrid simulation to the gravity load collapse of reinforced concrete frames. Compared with traditional shake table tests, the application of hybrid simulation to the investigation of structural collapse will reduce costs, enable the investigation of multiple variables, and improve the safety of collapse testing. For that purpose, a hybrid simulation test setup of a two-bay reinforced concrete frame was developed, with an experimental substructure representing the shear-critical centre column and a nonlinear numerical substructure representing the ductile outside columns and stiff beam. The study included several unique developments for hybrid simulation, including: o A nonlinear transformation method was implemented to allow for an accurate application of the three-degree-of-freedom loading on the specimen through a three-actuator test setup. o A specific predictor-corrector algorithm with variable actuators speed was designed to ensure smooth continuous testing despite the use of an implicit iterative integration scheme. o A methodology using an iterative predictor-corrector algorithm with mode-switch was developed to enable the use of force control for the actuators in combination with the displacement-based software OpenSees. o The highly nonlinear experimental substructure of the hybrid model was tested beyond shear and axial failure without experiencing any stability or convergence issue. 141 o The fiber element model for the outside columns allowed for the investigation of the stability and accuracy of hybrid simulation for a highly nonlinear numerical substructure. Results from the hybrid tests investigating the gravity load collapse of reinforced concrete frames were compared with a shaking table test of the same structure, and were shown to exhibit the same general behaviour with shear and axial load failure of the shear-critical column followed by gravity load redistribution from the experimental to the numerical substructure. However, the inability of the analytical model to capture the residual drifts observed in the shake table tests resulted in an underprediction of the drift demand on the system. The combination of all the components developed during the current study enabled the author to push the boundaries of hybrid simulation by performing the experimental testing of a complex reinforced concrete model beyond shear and axial failure of a single component. These developments in hybrid testing offer new possibilities in the field of simulation of structural collapse. 9.2 Future research The future research can be subdivided into two categories: first, research that should be carried out on the current test data to achieve a better understanding of the test results; and then research that should be performed to improve the application of hybrid simulation to the gravity load collapse of reinforced concrete frames. The following topics should be addressed regarding the current test data: . o A comparison between the shake table test, the hybrid test and the OpenSees analysis using limite state material (Elwood and Moehle, 2003) would allow for the investigation of the shortcomings and advantages of the different methods and 142 a better understanding of the impact of inaccuracies of the OpenSees model on the hybrid test results. o Comparisons between the response time histories (drift, shear, axial load, etc) during the hybrid test and the shake table test would be useful to assess the differences in response between the hybrid frame and the shake table frame. In particular, differences in the period estimates of the two structures and their influence on the dynamic response should be further investigated. o The role of the vertical inertia forces - accounted for numerically during the hybrid tests - should be considered, particularly their influence in balancing the vertical forces during the axial load redistribution. o Further investigation should be done on the relative vertical growth of the columns during the hybrid and shake table tests, to try to justify the trends observed in Fig. 62 (consideration of whether the results stem from differences between the outside columns in the shake table tests and the numerical model or from differences between the growth of the center column in the shake table test and the experimental element in the hybrid tests). The following topics should be investigated in order to improve the application of hybrid simulation to the gravity load collapse of reinforced concrete frames: o Improving the accuracy of the numerical model, particularly related to residual displacements, would be necessary to ensure that the response of the hybrid model is fully consistent with shake table test results. o The influence of the linear beam used in the hybrid model, as well as the influence of the drift underestimation, should be examined to try to quantify the observed differences in vertical shortening of the center column. o The influence of the deformations of the different components of the loading setup (horizontal loading beam, pedestrals, bolt connections, swivels, floor plates, etc.) should be investigated to quantify the amount of error introduced in the force and displacement feedbacks used for the numerical analysis of the hybrid model. 143 For that purpose, a refined instrumentation of the loading setup would be required for subsequent tests. The concept of tuning the actuators in force control should be investigated in order to enable the use of the new predictor-corrector model developed in this study, which mixes force and displacement control through the use of an iterative algorithm with mode-switch. Otherwise, the development of a mixed force-displacement solver for OpenSees would enable the use of force or displacement commands straight from OpenSees for control of different actuators. Improved integration schemes should be developed or implemented in OpenSees to increase the hybrid simulation speed by reducing the number of iterations required for convergence while maintaining the numerical accuracy of the process. In particular, the implicit integration schemes with substepping described in Section 6.5.3 should be enhanced to provide sufficient accuracy in the case of highly nonlinear models within a reasonable number of iterations. 144 REFERENCES Comartin, CD., 2001, PBEE Needs, Buildings Perspective: Critical Needs throughout the Performance Spectrum, 2001 PEER Annual Meeting,Oakland, California. Combescure, D. and Pegon, P., 1997, Alpha-Operator Splitting Time Integration Technique for Pseudodynamic Testing - Error Propagation Analysis, Soil Dynamics and Earthquake Engineering, Volume 16, Number 7, October 1997 , pp. 427-443(17) de Souza, R.M., 2000, Force-based Finite Element for Large Displacement Inelastic Analysis of Frames, Ph.D. Dissertation, University of California, Berkeley. Elwood, K.J. and Moehle, J.P., 2003, Shake Table Tests and Analytical Studies on the Gravity Load Collapse of Reinforced Concrete Frames, PEER report 2003/01. Ghannoum, W.M., Shin, Y.B. and Moehle, J.P., 2005, Collapse Tests of Lighlty Confined Reinforced Concrete Columns and Frames, Proceedings of the First NEES/E-Defense Workshop on Collapse Simulation of Reinforced Concrete Building Structures, PEER report 2005/10, Pacific Earthquake Engineering Research Center, University of California, Berkeley. Hachem, M.M., 2002, Seismic Performance of Circular Reinforced Concrete Bridge Columns Under Bidirectional Earthquake, University of California, Berkeley. Hughes T J.R., Pister K.S., Taylor R.L. Implicit-explicit finite elements in nonlinear transient analysis. Computer Methods in Applied Mechanics and Engineering 1979; 17-18:159-182. Inoue, N., Inai, E., Wada, A., Kuramoto, H., Fujimoto, I., and Iiba, M., 2000, A Shaking Table Test of Reinforced Concrete Frames Designed Under Old Seismic Regulations in Japan, Proceedings of the 12th World Conference on Earthquake Engineering, New Zealand Society for Earthquake Engineering, Upper Hutt, New Zealand, Paper No. 1783. Magonette, G.E., Negro, P., 1998, Verification of the pseudodynamic test method, European Earthquake Engineering: 12(l):29-39. Page 11 145 Mahin S.A., Shing, P.B., Thewalt, C.R. and Hanson, R.D., 1989, Pseudodynamic Test Method - Current Status and Future Direction, Journal of Structural Engineering, 115(8): 2113-. 2128. Mander, J.B., Priestley, M.J.N, and Park, R., 1988, Theoretical Stress-Strain Model for Confined Concrete, Journal of Structural Engineering, Vol.114, No.8, pp.1804-1826. Minowa, C, Ogawa, N., Hayashida, T., Kogoma, I., and Okada, T., 1995, Dynamic and Static Collapse of Reinforced-Concrete Columns, Nuclear Engineering and Design, Vol. 156, pp. 269-276. Mosqueda, G., 2003, Continuous Hybrid Simulation with Geographically Distributed Substructures, Ph.D. Dissertation, University of California, Berkeley Mosqueda, G., Stojadinovic, B. and Mahin, S., 2005, Implementation and Accuracy of Continuous Hybrid Simulation with Geographically Distributed Substructures, UCB/EERC 2005-02, University of California, Berkeley. Nakashima M, Kaminosono T, Ishida M, Ando K. Integration techniques for substructure pseudo-dynamic test. 4th US National Conference on Earthquake Engineering; Palm Springs, CA, May 1990. Nakashima, M. and Masaoka N., 1999, Real-time on-line test for MDOF systems, Earthquake Engineering & Structural Dynamics, 28(4), p. 393-420. NEES@Berkeley, Hybrid Simulation Workshop, http://nees.berkelev.edu/Events/200612a—workshop-hvbridsim/agenda.shtml Pacific Earthquake Engineering Research Center, 2007, OpenSees - Open System for Earthquake Engineering Simulation, University of California, Berkeley. Schellenberg, A. and Mahin, S., 2005, Integration of hybrid simulation within the general-purpose computational framework OpenSees, Proceedings of the Eighth U.S. National Conference on Earthquake Engineering, San Francisco, California. Schellenberg, A., 2005, Predictor-Corrector Algorithms for Event-Driven Controllers in Hybrid Simulation, CE 299 Report, University of California, Berkeley. 146 Schellenberg, A., and Mahin, S., 2006, Application of an experimental software framework to hybrid simulation of structures through collapse, Proceedings of the First European Conference on Earthquake Engineering and Seismology, Geneva, Switzerland. Schellenberg, A., Kim H.K., Takahashi Y., Fenves G. L., and Mahin S. A., 2006, OpenFresco Framework for Hybrid Simulation: Installation and Example Guide, available through NEESit. Schellenberg, A., Mahin, S.A. and Fenves, G.L., 2006, Application of an experimental software framework for international hybrid simulation, Proceedings of the Fourth International Conference on Earthquake Engineering, Taipei, Taiwan. Schellenberg, A., Yang, T.Y., Stojadinovic, B., and Elwood, K., 2006, Hybrid simulation of structural collapse, Proceedings of the Fourth NEES Annual Meeting, Washington D.C. Schellenberg, A., Mahin, S.A. and Fenves, G.L., 2007, A software framework for hybrid simulation of large structural systems, Proceedings of the ASCE Structures Congress, Long Beach, California. Schellenberg, A., 2007, Advanced Implementation of Hybrid Simulation, Ph.D. Dissertation, University of California, Berkeley. Schellenberg, A. (University of California, Berkeley) and Takahashi, Y. (Kyoto University, Japan), 2007, OpenFresco, Open-source Framework for Experimental Setup and Control. Sezen, H., 2002, Seismic Response and Modeling of Reinforced Concrete Building Columns, Ph.D Dissertation, Dpt of Civil and Environmental Engineering, University of California, Berkeley. Shing, Vannan, Cater, 1991, Implicit Time Integration for Pseudodynamic Tests, Earthquake Engineering and Structural Dynamics, Wiley 20(6): 551-576 147 Shing, P.B., Nakashima, M., Bursi, O., 1996, Application of pseudodynamic test method to structural research, Earthquake Spectra, Vol. 12 pp.29-56. Stojadinovic, B., Mosqueda, G. and Mahin, S., 2006, Event-Driven Control System for Geographically Distributed Hybrid Simulation, Journal of Structural Engineering, Volume 132-Issue l,pp. 68-77 Systran Corporation, SCRAMNET, vvww.systran.com Takahashi, Y. and Fenves, G., 2005, Software Framework for Distributed Experimental-Computational Simulation of Structural Systems, Earthquake Engineering and Structural Dynamics, published online on Wiley InterScience (www.interscience.wilev.com) DOI: 10.1002/eqe.518 Takanashi, K., Udagawa, K., Seki, M., Okada, T. and Tanaka, H., 1975, Nonlinear Earthquake Response Analysis of Structures by a Computer-Actuator On-Line System, Bulletin of Earthquake Resistant Structure Research Center. Takanashi, K. and Nakashima, M., 1987, Japanese Activity On On-Line Testing, Journal of Engineering Mechanics. The Mathworks, 2007 Matlab, Simulink, Stateflow, Real-time Workshop and xPC target, www.mathworks.com Wei, Z., 1997, Fast Hybrid Test System for Substructure Evaluation, PhD Dissertation, University of Colorado. 148 APPENDIX A: Example file - ThreeSpanBridge_UBC_Local.tcl # File: ThreeSpanBridgeJJBCLocal.tcl # # SRevision: $ # $Date: $ # $URL: $ # # Written: Andreas Schellenberg (andreas.schellenberg@gmx.net) # Modified: Arnaud Charlet (acharlet@civil.ubc.ca) # Created: 09/06 # Revision: 01/07 # # Purpose: this file contains the tcl input to perform # a local hybrid simulation of a three span bridge with # one experimental beam column element. # -# Start of model generation # — # create ModelBuilder (with two-dimensions and 3 DOF/node) model BasicBuilder -ndm 2 -ndf 3 # Load OpenFresco package # -# (make sure all dlls are in the same folder as openSees.exe) loadPackage OpenFresco # Define geometry for model # set mass 0.12 # node Stag $xCrd SyCrd Smass node 1 0.0 0.00 node 2 108.0 -54.00 node 3 216.0-42.00 node 4 324.0 0.00 node 5 0.0 0.00 -mass Smass Smass 116.6 node 6 108.0 0.00 -mass Smass Smass 116.6 node 7 216.0 0.00 -mass Smass Smass 116.6 node 8 324.0 0.00 -mass Smass Smass 116.6 node 9 108.0 0.00 -mass Smass Smass 116.6 node 10 216.0 0.00 -mass Smass Smass 116.6 # set the boundary conditions # fix Stag SDX SDY $RZ fix 1 1 1 1 fix 2 1 1 1 fix 3 1 1 1 fix 4 1 1 1 # Define materials # 149 # uniaxialMaterial Steel02 SmatTag $Fy $E $b $R0 $cRl $cR2 Sal $a2 $a3 $a4 uniaxialMaterial Elastic 1 1E10 uniaxialMaterial Steel02 2 6.0 12.0 0.05 18.5 0.925 0.15 0.0 1.0 0.0 1.0 #uniaxialMaterial Elastic SmatTag $E uniaxialMaterial Elastic 3 16.15 # Define experimental control # # expControl SimUniaxialMaterials Stag SmatTags expControl SimUniaxialMaterials 1 3 # Define experimental setup # # expSetup OneActuator Stag <-control SctrlTag> Sdir <-ctrlDispFact $f> ... expSetup OneActuator 1 -control 1 2 -ctrlDispFact 2.54 -daqDispFact 2.54 -daqForceFact 4.4482; # U B C setup with units conversion imperial/metric # Define experimental site # # expSite LocalSite Stag SsetupTag expSite LocalSite 1 1 # Define numerical elements • # # geometric transformation # geomTransf type Stag geomTransf Linear 1 geomTransf Corotational 2 # abutment isolators # element zeroLength SeleTag SiNode SjNode -mat SmatTag -dir Sdirs -orient $xl $x2 $x3 Sypl Syp2 Syp3 element zeroLength 1 1 5 -mat 1 2 -dir 1 2 -orient 0 1 0 - 1 0 0 element zeroLength 4 4 8 -mat 1 2 -dir 1 2 -orient 0 1 0 - 1 0 0 # hinges at top of columns # element zeroLength SeleTag SiNode SjNode -mat SmatTag -dir Sdirs -orient $xl Sx2 $x3 Sypl $yp2 Syp3 element zeroLength 8 6 9 -mat 1 1 -dir 1 2 -orient 0 1 0 - 1 0 0 element zeroLength 9 7 10 -mat 1 1 -dir 1 2 -orient 0 1 0 - 1 0 0 # bridge deck # element elasticBeamColumn SeleTag SiNode SjNode SA SE SIz StransTag element elasticBeamColumn 5 5 6 3.55 29000 22.1 1 element elasticBeamColumn 6 6 7 3.55 29000 22.1 1 element elasticBeamColumn 7 7 8 3.55 29000 22.1 1 # right pier # element elasticBeamColumn SeleTag SiNode SjNode $A $E $Iz StransTag element elasticBeamColumn 3 3 10 2 29000 20 1 # Define experimental element # 150 # expElement beamColumn SeleTag SiNode SjNode StransTag -site SsiteTag -initStif $Kij <-iMod> <-rho $rho> expElement beamColumn 2 2 9 1 -site 1 -initStif 14825.8 0 0 0 9.22 -410.4 0 -410.4 24351.8 # Define dynamic loads # # set time series to be passed to uniform excitation set dt 0.01 #set scale 1.0 #set accelSeries "Path -filePath CosinePulse.txt -dt $dt -factor [expr 386.1*$scale]" #set scale 0.6 #set accelSeries "Path -filePath SACNF01.txt -dt $dt -factor [expr 386.1*$scale]" set scale 1.0 set accelSeries "Path -filePath ELC270.txt -dt $dt -factor [expr 386.1 *$scale]" # create UniformExcitation load pattern # pattern UniformExcitation Stag $dir pattern UniformExcitation 1 1 -accel SaccelSeries # calculate the rayleigh damping factors for nodes & elements set alphaM 0.0; # D = alphaM*M set betaK 0.0; # D = betaK*Kcurrent setbetaKinit 0.014836; # D = beatKinit*Kinit set betaKcomm 0.0; # D = betaKcomm*KlastCommit # set the rayleigh damping #rayleigh SalphaM SbetaK SbetaKinit SbetaKcomm; # # End of model generation # # # Start of analysis generation # — -# create the system of equations system BandGeneral # create the DOF numberer numberer Plain # create the constraint handler constraints Plain # create the convergence test test Energylncr 1.0e-6 10 #test FixedNumlter 2 # create the integration scheme #integrator NewmarkHybridSimulation 0.5 0.25 integrator HHTHybridSimulation 0.667 integrator AlphaOS 0.6667 # create the solution algorithm algorithm Linear 151 # create the analysis object analysis Transient # # End of analysis generation # # # Start of recorder generation # # create the recorder objects recorder Node -file NodeDsp.out -time -node 6 -dof 1 disp recorder Node -file NodeVel.out -time -node 6 -dof 1 vel recorder Node -file NodeAcc.out -time -node 6 -dof 1 accel recorder Element -file ElmtFrc.out -time -ele 2 basicForces recorder Element -file Elmt_Def.out -time -ele 2 basicDeformations # # End of recorder generation # - — -# # Finally perform the analysis # # perform an eigenvalue analysis set pi 3.14159265358979 set lambda [eigen 4] puts "\nEigenvalues at start of transient:" puts "lambda omega period" foreach lambda Slambda { set omega [expr pow($lambda,0.5)] set period [expr 2*$pi/pow($lambda,0.5)] puts "Slambda Somega Speriod"} puts " " # open output file for writing set outFilelD [open elapsedTime.txt w] # perform the transient analysis set tTot [time { for {set i 1} {Si < 4000} {incr i} { set t [time {analyze 1 $dt}] puts SoutFilelD $t } }] puts "Elapsed Time = StTot \n" # close the output file close SoutFilelD wipe # # End of analysis # APPENDIX B: As-built specimens drawings o T v T 2" clear cover on 20M 5 sets of stirrups instead of 6 l"3/4 clear cover on 15M 5 sets of stirrups instead of 6 5 1/4" 1 "3/4 clear cover on 15M 15M 20M 10M 2" clear cover on 20M All three specimens presented these as-built dimensions. 1 public: // constructors ESThreeActuatorsLshapeb2d(int tag, double actLengthO, double actLengthl, double actLength2, double rigidLengthO, double rigidLength 1, double rigidLength2, double rigidLength3, double HgidLength4, double rigidLength5, ExperimentalControl* control = 0, int nlGeom = 0, char *posActO = "left", double phiLocX = 0.0); ESThreeActuatorsLshapeb2d(const ESThreeActuatorsLshapeb2d& // destructor virtual ~ESThreeActuatorsLshapeb2d(); // public methods virtual int setSize(lD sizeT, ID sizeO); virtual int commitState(); virtual int setup(); // public methods to transform the responses virtual int transfTrialResponse(const Vector* disp, const Vector* vel, const Vector* accel, const Vector* force, const Vector* time); virtual ExperimentalSetup *getCopy(); // public methods for output void Print(OPS_Stream &s, int flag = 0); protected: // protected tranformation methods virtual int transfTrialDisp(const Vector* disp); virtual int transfTrialVel(const Vector* vel); virtual int transfTrialAccel(const Vector* accel); virtual int transfTrialForce(const Vector* force); virtual int transfTrialTime(const Vector* time); virtual int transfDaqDisp(Vector* disp); virtual int transfDaqVel(Vector* vel); virtual int transfDaqAccel(Vector* accel); virtual int transfDaqForce(Vector* force); virtual int transfDaqTime(Vector* time); private: // private tranformation methods virtual int transfTrialVel(const Vector* disp, const Vector* vel); virtual int transfTrialAccel(const Vector* disp, const Vector* vel, const Vector* accel); double LaO; // length of actuator 0 double L a i ; // length of actuator 1 double La2; // length of actuator 2 double L0; // rigid link length 0 ESThreeActuatorsLshapeb2d::ESThreeActuatorsLshapeb2d(int tag, double actLengthO, double actLengthl, double actLength2, double rigidLengthO, double rigidLengthl, double rigidLength2, double rigidLength3, double rigidLength4, double rigidLength5, ExperimentalControl* control, int nlgeom, char *posactO, double philocx) : Experimental Setup(tag, control), LaO(actLengthO), Lai (actLengthl), La2(actLength2), LO(rigidLengthO), L1 (rigidLength 1), L2(rigidLength2), L3(rigidLength3), L4(rigidLength4), L5(rigidLength5), nlGeom(nlgeom), phiLocX(philocx), rotLocX(3,3) { strcpy(posActO,posactO); // call setup method this->setup(); for(inti=0; i<3; i++) firstWarning[i] = true; } ESThreeActuatorsLshapeb2d::ESThreeActuatorsLshapeb2d(const ESThreeActuatorsLshapeb2d& es) : ExperimentalSetup(es), rotLocX(3,3) { LaO = es.LaO; La i =es.Lal; La2 = es.La2; LO = es.LO; L l =es .Ll ; L2 = es.L2; L3 =es.L3; L4 = es.L4; L5 = es.L5; nlGeom = es.nlGeom; phiLocX = es.phiLocX; strcpy(posActO,es.posActO); // call setup method this->setup(); for (int i=0; i<3; i++) firstWarning[i] = true; } ESThreeActuatorsLshapeb2d::~ESThreeActuatorsLshapeb2d() { // does nothing } int ESThreeActuatorsLshapeb2d::setSize(ID sizeT, ID sizeO) 157 // check sizeTrial and sizeOut // for ESThreeActuatorsLshapeb2d object // a component of sizeT/sizeO must be equal // to 3 if it is non-zero. int i ; for(i=0; K O F R e s p T i m e ; i++) { if((sizeT[i] != 0 & & sizeT[i] != 3) || (sizeO[i] != 0 & & sizeO[i] != 3)) { opserr « "ESThreeActuatorsLshapeb2d::setSize - wrong sizeTrial/Out\n"; opserr « "see User Manual.\n"; opserr « "sizeT = " « sizeT; opserr « "sizeO = " « sizeO; return OFReturnTypefailed; } } if((sizeT[OF_Resp_Time] != 0 & & sizeT[OF_Resp_Time] != 1) || (sizeO[OF_Resp_Time] != 0 & & sizeO[OF_Resp_Time] != 1)) { opserr « "ESThreeActuatorsLshapeb2d::setSize - wrong sizeTrial/OutAn"; opserr « "see User Manual.W; opserr « "sizeT = " « sizeT; opserr « "sizeO = " « sizeO; return OF_ReturnType_failed; } return OF_ReturnTypecompleted; } int ESThreeActuatorsLshapeb2d::commitState() { return theControl->commitState(); } int ESThreeActuatorsLshapeb2d: :setup() { // setup for ctrl/daq vectors of ESThreeActuatorsLshapeb2d sizeCtrl->Zero(); sizeDaq->Zero(); for(int i=0; i<OF_Resp_Time; i++) { (*sizeCtrl)[i] =3; (*sizeDaq)[i] = 3; } (*sizeCtrl)[OF_Resp_Time] = 1; (*sizeDaq)[OF_Resp_Time] = 1; this->setCtrlDaqSize(); // initialize rotation matrix rotLocX.Zero(); double pi = acos(-l.O); rotLocX(0,0) = cos(phiLocX/180.0*pi); rotLocX(0,1) = -sin(phiLocX/180.0*pi); rotLocX(l,0) = sin(phiLocX/180.0*pi); rotLocX(l , l) = cos(phiLocX/180.0*pi); rotLocX(2,2)= 1.0; return O F R e t u r n T y p e c o m p 1 eted; } int ESThreeActuatorsLshapeb2d::transfTrialResponse(const Vector* disp, const Vector* vel, const Vector* accel, const Vector* force, const Vector* time) { // transform data i f (disp != 0) { this->transfTrialDisp(disp); for (int i=0; i<(*sizeCtrl)[OF_Resp_Disp]; i++) (*cDisp)[i] *=(*cDispFact)[i]; } i f (disp != 0 & & vel !=0){ this->transfTrialVel(disp,vel); for (int i=0; i<(*sizeCtrl)[OF_Resp_Vel]; i++) (*cVel)[i] *= (*cVelFact)[i]; } i f (disp != 0 & & vel != 0 & & accel != 0) { this->transfTrialAccel(disp,vel,accel); for (int i=0; i<(*sizeCtrl)[OF_Resp_Accel]; i++) (*cAccel)[i] *= (*cAccelFact)[ij ; } i f (force != 0) { this->transfTrialForce(force); for (int i=0; i<(*sizeCtrl)[OFJResp_Force]; i++) (*cForce)[i] *= (*cForceFact)[i]; } i f (time != 0) { this->transfTrialTime(time); for (int i=0; i<(*sizeCtrl)[OF_Resp_Time]; i++) (*cTime)[i] *= (*cTimeFact)[i]; } return OF_ReturnType_completed; } Experimental Setup* ESThreeActuatorsLshapeb2d::getCopy() { ESThreeActuatorsLshapeb2d *theCopy = new ESThreeActuatorsLshapeb2d(*this); return theCopy; } void ESThreeActuatorsLshapeb2d::Print(OPS_Stream & s , int flag) { s « "ExperimentalSetup:" « t h i s - > g e t T a g ( ) ; s « " type: ESThreeActuatorsLshapeb2d\n"; s « " actLengthl : " « LaO « endln; s « " actLength2 : " « La i « endln; s « " actLength3 : " « La2 « endln; s « " rigidLengthl:" « LO « endln; s « " HgidLength2:" « L l « endln; s « " rigidLength3:" « L2 « endln; s « " rigidLength4: " « L3 « endln; s « " rigidLength5: " « L4 « endln; s « " rigidLength6:" « L5 « endln; s « " nlGeom : " « nlGeom « endln; s « " posActl : " « posActO « endln; s « " phiLocX : " « phiLocX « endln; if(theControl != 0) { s « "\tExperimentalControl tag:" «theControl->getTag(); s « *theControl; }} int ESThreeActuatorsLshapeb2d::transfTrialDisp(const Vector* disp) { // rotate direction static Vector d(3); d = rotLocX*(*disp); // linear geometry, horizontal actuator left if (nlGeom == 0 & & strcmp(posActO,"left") == 0) { // actuator 0 (*cDisp)(0) = d(0); // actuator 1 (*cDisp)(l) = d(l)-L0*d(2); // actuator 2 (*cDisp)(2) = d(l) + Ll*d(2); } // linear geometry, horizontal actuator right else if (nlGeom == 0 & & strcmp(posActO, "right") == 0) { // actuator 0 (*cDisp)(0) = -d(0); // actuator 1 (*cDisp)(l) = d(l)-L0*d(2); // actuator 2 (*cDisp)(2) = d(l) + Ll*d(2); } // nonlinear geometry, horizontal actuator left else if (nlGeom == 1 & & strcmp(posActO,"left") == 0) { if (firstWamingfO] == true) { opserr « "WARNING ESThreeActuatorsLshapeb2d::transfTrialDisp() -« "nonlinear geometry with horizontal actuator left " « "not implemented yet. Using linear geometry instead.\n\n"; firstWarning[0] = false; } // actuator 0 (*cDisp)(0) = d(0); // actuator 1 (*cDisp)(l) = d(l)-L0*d(2); // actuator 2 (*cDisp)(2) = d(l) + Ll*d(2); } // nonlinear geometry, horizontal actuator right else if (nlGeom == 1 & & strcmp(posActO, "right") == 0) { double R0 = sqrt(L0*L0 + L3*L3); double R l = sqrt(Ll*Ll + L4*L4); double R2 = sqrt((Ll+L2)*(Ll+L2)+L5*L5); double alphaO = atan(L3/L0); double alpha 1 = atan(L4/Ll); double alpha2 = atan(L5/(L 1+L2)); // actuator 0 (*cDisp)(0) = -d(0); // actuator 1 (*cDisp)(l) = pow(pow(Lal+L3+d(l)-R0*sin(alpha0+d(2)),2.0)+pow(L0+d(0)-R0*cos(alpha0+d(2)),2.0),0.5)-Lal; // actuator 2 (*cDisp)(2) = pow(pow(La2+L4+d(l)-Rl*sin(alphal-d(2)),2.0)+pow(Ll-d(0)-Rl*cos(alphal-d(2)),2.0),0.5)-La2; } return OF_ReturnType_completed; } int ESThreeActuatorsLshapeb2d::transfTrialVel(const Vector* vel) { return OFReturnTypecompleted; } int ESThreeActuatorsLshapeb2d::transfTrialVel(const Vector* disp, const Vector* vel) { // rotate direction static Vector d(3), v(3); d = rotLocX*(*disp); v = rotLocX*(*vel); // linear geometry, horizontal actuator left if (nlGeom == 0 & & strcmp(posActO,"left") == 0) { // actuator 0 (*cVel)(0) = v(0); // actuator 1 (*cVel)(l) = v ( l ) - Ll*v(2); // actuator 2 (*cVel)(2) = v(l) + L2*v(2); } // linear geometry, horizontal actuator right else if (nlGeom == 0 & & strcmp(posActO,"right") == 0) { // actuator 0 (*cVel)(0) = -v(0); // actuator 1 (*cVel)(l) = v ( l ) - L l * v ( 2 ) ; // actuator 2 (*cVel)(2) = v(l) + L2*v(2); } 161 // nonlinear geometry, horizontal actuator left else if (nlGeom == 1 & & strcmp(posActO,"left") == 0) { if (firstWarning[0] == true) { opserr « " W A R N I N G ESThreeActuatorsLshapeb2d::transfTrialVel() « "nonlinear geometry with horizontal actuator left" « "not implemented yet. Using linear geometry instead.\n\n"; firstWarning[0] = false; } // actuator 0 (*cVel)(0) = v(0); // actuator 1 (*cVel)(l) = v ( l ) - L l * v ( 2 ) ; // actuator 2 (*cVel)(2) = v(l) + L2*v(2); } // nonlinear geometry, horizontal actuator right else if (nlGeom == 1 & & strcmp(posActO,"right") == 0) { if (firstWarning[0] == true) { opserr « " W A R N I N G ESThreeActuatorsLshapeb2d::transfTrialVel() « "nonlinear geometry with horizontal actuator right" « "not implemented yet. Using linear geometry instead.\n\n"; firstWarning[0] = false; } // actuator 0 (*cVel)(0) = -v(0); // actuator 1 (*cVel)(l) = v ( l ) - Ll*v(2); // actuator 2 (*cVei)(2) = v(l) + L2*v(2); } return OF_ReturnType_completed; } int ESThreeActuatorsLshapeb2d::transfTrialAccel(const Vector* accel) { return OFReturnTypecompleted; } int ESThreeActuatorsLshapeb2d::transfTrialAccel(const Vector* disp, const Vector* vel, const Vector* accel) { // rotate direction static Vector d(3), v(3), a(3); d = rotLocX*(*disp); v = rotLocX*(*vel); a = rotLocX*(*accel); // linear geometry, horizontal actuator left if (nlGeom = 0 & & strcmp(posActO,"left") == 0) { // actuator 0 (*cAccel)(0) = a(0); // actuator 1 (*cAccel)(l) = a( l ) -Ll*a(2) ; // actuator 2 (*cAccel)(2) = a(l) + L2*a(2); } // linear geometry, horizontal actuator right else if (nlGeom == 0 & & strcmp(posActO,"right") == 0) { // actuator 0 (*cAccel)(0) = -a(0); // actuator 1 (*cAccel)(l) = a ( l ) - Ll*a(2); // actuator 2 (*cAccel)(2) = a(l) + L2*a(2); } // nonlinear geometry, horizontal actuator left else if (nlGeom == 1 & & strcmp(posActO,"left") == 0) { if (firstWarning[0] == true) { opserr « " W A R N I N G ESThreeActuatorsLshapeb2d::transfTrialAccel() « "nonlinear geometry with horizontal actuator left" « "not implemented yet. Using linear geometry instead.\n\n"; firstWarningfO] = false; } // actuator 0 (*cAccel)(0) = a(0); // actuator 1 (*cAccel)(l) = a( l ) -Ll*a(2) ; // actuator 2 (*cAccel)(2) = a(l) + L2*a(2); } // nonlinear geometry, horizontal actuator right else i f (nlGeom == 1 & & strcmp(posActO,"right") == 0) { if (first Warning[0] == true) { opserr « " W A R N I N G ESThreeActuatorsLshapeb2d::transfTrialAccel() « "nonlinear geometry with horizontal actuator right" « "not implemented yet. Using linear geometry instead.\n\n"; firstWarningfO] = false; } // actuator 0 (*cAccel)(0) = -a(0); // actuator 1 (*cAccel)(l) = a( l ) -Ll*a(2) ; // actuator 2 (*cAccel)(2) = a(l) + L2*a(2); } return OF_ReturnType_completed; } int ESThreeActuatorsLshapeb2d::transfTrialForce(const Vector* force) { // rotate direction static Vector f(3); f = rotLocX*(*force); // linear geometry, horizontal actuator left if (nlGeom == 0 & & strcmp(posActO,"left") == 0) { // actuator 0 (*cForce)(0) = f(0); // actuator 1 (*cForce)(l) = 1.0/(L0+Ll)*(Ll*f(l) - f(2) + f(0)*L5); // actuator 2 (*cForce)(2) = 1.0/(L0+Ll)*(Ll*f(l) + f(2) - f(0)*L5); } // linear geometry, horizontal actuator right else if (nlGeom == 0 & & strcmp(posActO,"right") == 0) { // actuator 0 (*cForce)(0) = -f(0); // actuator 1 (*cForce)(l) = 1.0/(L0+Ll)*(Ll*f(l) - f(2) + f(0)*L5); // actuator 2 (*cForce)(2) = 1.0/(L0+Ll)*(Ll *f(l) + f(2) - f(0)*L5); } // nonlinear geometry, horizontal actuator left else if (nlGeom == 1 & & strcmp(posActO,"left") == 0) { if (firstWarning[0] == true) { opserr « " W A R N I N G ESThreeActuatorsLshapeb2d::transfTrialForce() « "nonlinear geometry with horizontal actuator left " « "not implemented yet. Using linear geometry instead.\n\n"; firstWarning[0] = false; } // actuator 0 (*cForce)(0) •= f(0); // actuator 1 (*cForce)(l) = 1.0/(L0+Ll)*(Ll*f(l) - f(2) + f(0)*L5); // actuator 2 (*cForce)(2) = 1.0/(L0+Ll)*(Ll *f(l) + f(2) - f(0)*L5); } // nonlinear geometry, horizontal actuator right else i f (nlGeom == 1 & & strcmp(posActO,"right") == 0) { if (firstWarning[0] ==true) { opserr « " W A R N I N G ESThreeActuatorsLshapeb2d::transfTrialForce() « "nonlinear geometry with horizontal actuator right" « "not implemented yet. Using linear geometry instead.\n\n"; firstWarningfO] = false; } // actuator 0 (*cForce)(0) = -f(0); // actuator 1 (*cForce)(l) = 1.0/(L0+Ll)*(Ll*f(l) - f(2) + f(0)*L5); // actuator 2 (*cForce)(2) = 1.0/(L0+Ll)*(Ll*f(l) + f(2) - f(0)*L5); } return OF_ReturnType_completed; } int ESThreeActuatorsLshapeb2d::transfTrialTime(const Vector* time) { *cTime = *time; return OFReturnTypecompleted; } int ESThreeActuatorsLshapeb2d::transfDaqDisp(Vector* disp) { // linear geometry, horizontal actuator left if (nlGeom == 0 & & strcmp(posActO,"left") == 0) { (*disp)(0) = (*dDisp)(0); (*disp)( 1) = 1.0/(L0+Ll )*(L 1 *(*dDisp)( 1) + L0*(*dDisp)(2)); (*disp)(2) = 1.0/(L0+Ll)*(-(*dDisp)(l) + (*dDisp)(2)); } // linear geometry, horizontal actuator right else if (nlGeom == 0 & & strcmp(posActO,"right") == 0) { (*disp)(0) = -(*dDisp)(0); (*disp)(l) = 1.0/(L0+Ll)*(Ll*(*dDisp)(l) + L0*(*dDisp)(2)); (*disp)(2) = 1.0/(L0+Ll)*(-(*dDisp)(l) + (*dDisp)(2)); } // nonlinear geometry, horizontal actuator left else i f (nlGeom == 1 & & strcmp(posActO,"left") == 0) { if (firstWarningfO] == true) { opserr « "WARNING ESThreeActuatorsLshapeb2d::transfDaqDisp() - " « "nonlinear geometry with horizontal actuator left" « "not implemented yet. Using linear geometry instead.\n\n"; firstWarningfO] = false; } (*disp)(0) = (*dDisp)(0); (*disp)(l) = 1.0/(L0+Ll)*(Ll*(*dDisp)(l) + L0*(*dDisp)(2)); (*disp)(2) = 1.0/(L0+Ll)*(-(*dDisp)(l) + (*dDisp)(2)); } // nonlinear geometry, horizontal actuator right else if (nlGeom == 1 & & strcmp(posActO,"right") == 0) { Vector R(3), X(3), dX(3); Matrix K(3,3); int iter = 0; int maxlter =15; double tol= 1E-9; double R0 = sqrt(L0*L0 + L3*L3); double R l = sqrt(Ll*Ll + L4*L4); double R2 = sqrt((Ll+L2)*(Ll+L2)+L5*L5); double alphaO = atan(L3/L0); double alpha 1 = atan(L4/Ll); double alpha2 = atan(L5/(Ll+L2)); // initialize the solution X with the displacements obtained assuming linear geometry. X(0) = -(*dDisp)(0); // X ( l ) is the horizontal displacement X ( l ) = 1.0/(L0+Ll)*(Ll*(*dDisp)(l) + L0*(*dDisp)(2)); // X(2) is the vertical displacement X(2) = 1.0/(L0+Ll)*(-(*dDisp)(l) + (*dDisp)(2)); // X(3) is the rotation do { R(0) = (*dDisp)(0)+X(0); R(l) = -pow((*dDisp)(l)+Lal,2.0) + pow(Lal+L3+X(l)-R0*sin(alpha0+X(2)),2.0) + pow(L0+X(0)-R0*cos(alpha0+X(2)),2.0); R(2) = -pow((*dDisp)(2)+La2,2.0) + pow(La2+L4+X(l)-Rl *sin(alphal-X(2)),2.0) + pow(Ll-X(0> Rl*cos(alphal-X(2)),2.0); 165 K(0,0)=1; K(0,1) = 0; K(0,2) = 0; K(1,0) = 2.0*(L0+X(0)-R0*cos(alpha0+X(2))); K ( l , l ) = 2.0*(Lal+L3+X(l)-R0*sin(alpha0+X(2))); K(l,2) = -2.0*(Lal+L3+X(l)-R0*sin(alpha0+X(2)))*R0*cos(alpha0+X(2))+2.0*(L0+X(0)-R0*cos(alpha0+X(2)))*R0*sin(alpha0+X(2)); K(2,0) = -2.0*(L1-X(0)-R1 *cos(alphal-X(2))); K(2,l) = 2.0*(La2+L4+X(l)-Rl*sin(alphal-X(2))); K(2,2) = 2.0*(La2+L4+X( 1 )-Rl *sin(alphal-X(2)))*R 1 *cos(alphal-X(2))-2.0*(L 1 -X(0> R l *cos(alphal -X(2)))*R1 *sin(alphal -X(2)); // Newton's method dX = R/K; X -= dX; iter++; } while ((dX.NormO >= tol) & & (iter <= maxlter)); // issue warning i f iteration did not converge if (iter >= maxlter) { opserr « "WARNING ESThreeActuatorsLshapeb2d::transfDaqDisp() - " « "did not find the displacements solution after " « iter « " iterations and increment norm: " « dX.Norm() « endln; } (*disp)(0) = X(0); (*disp)(l) = X ( l ) ; (*disp)(2) = X(2); } // rotate direction if necessary if(phiLocX !=0.0) { (*disp) = rotLocXA(*disp); } return OF_ReturnType_completed; } int ESThreeActuatorsLshapeb2d::transfDaqVel(Vector* vel) { // linear geometry, horizontal actuator left if (nlGeom == 0 & & strcmp(posActO,"left") = 0) { (*vel)(0) = (*dVel)(0); (*vel)(l) = 1.0/(L0+Ll)*(Ll*(*dVel)(l) + L0*(*dVel)(2)); (*vel)(2) = 1.0/(L0+Ll)*(-(*dVel)(l) + (*dVel)(2)); } // linear geometry, horizontal actuator right else if (nlGeom == 0 & & strcmp(posActO,"right") == 0) { (*vel)(0) = -(*dVel)(0); (* vel)(l) = 1.07(L0+L 1)*(L 1 *(*dVel)( 1) + L0*(*dVel)(2)); (*vel)(2) = 1.0/(L0+Ll)*(-(*dVel)(l) + (*dVel)(2)); } // nonlinear geometry, horizontal actuator left else If (nlGeom == 1 & & strcmp(posActO,"left") == 0) { if (firstWarning[l ] == true) { opserr « " W A R N I N G ESThreeActuatorsLshapeb2d::transfDaqVel() « "nonlinear geometry with horizontal actuator left" « "not implemented yet. Using linear geometry instead.\n\n"; firstWarning[l] = false; } (*vel)(0) = (*dVel)(0); (*vel)(l) = 1.0/(L0+Ll)*(Ll*(*dVel)(l) + L0*(*dVel)(2)); (*vel)(2) = 1.0/(L0+Ll)*(-(*dVel)(l) + (*dVel)(2)); } // nonlinear geometry, horizontal actuator right else if (nlGeom — 1 & & strcmp(posActO,"right") == 0) { if (first Warning[l] == true) { opserr « " W A R N I N G ESThreeActuatorsLshapeb2d::transfDaqVel() « "nonlinear geometry with horizontal actuator right" « "not implemented yet. Using linear geometry instead.\n\n"; firstWarning[ 1 ] = false; }-(*vel)(0) = -(*dVel)(0); (*vel)(l) = 1.0/(L0+Ll)*(Ll*(*dVel)(l) + L0*(*dVel)(2)); (*vel)(2) = 1.0/(L0+Ll)*(-(*dVel)(l) + (*dVel)(2)); // rotate direction if necessary if(phiLocX !=0.0) { (*vel) = rotLocXA(*vel); } return OF_ReturnType_completed; } int ESThreeActuatorsLshapeb2d::transfDaqAccel(Vector* accel) { // linear geometry, horizontal actuator left if (nlGeom == 0 & & strcmp(posActO,"left") == 0) { (*accel)(0) = (*dAccel)(0); (*accel)(l) = 1.0/(L0+Ll)*(Ll*(*dAccel)(l) + L0*(*dAccel)(2)); (*accel)(2) = 1.0/(L0+Ll)*(-(*dAccel)(l) + (*dAccel)(2)); } // linear geometry, horizontal actuator right else i f (nlGeom == 0 & & strcmp(posActO,"right") == 0) { (*accel)(0) = -(*dAccel)(0); (*accel)(l) = 1.0/(L0+Ll)*(Ll*(*dAccel)(l) + L0*(*dAccel)(2)); (*accel)(2) = 1.0/(L0+Ll)*(-(*dAccel)(l) + (*dAccel)(2)); } // nonlinear geometry, horizontal actuator left else i f (nlGeom == 1 & & strcmp(posActO,"left") == 0) { if (firstWarning[2] == true) { opserr « " W A R N I N G ESThreeActuatorsLshapeb2d::transfDaqAcce « "nonlinear geometry with horizontal actuator left" « "not implemented yet. Using linear geometry instead.\n\n"; firstWarning[2] = false; } (*accel)(0) = (*dAccel)(0); (*accel)(l) = 1.0/(L0+Ll)*(Ll*(*dAccel)(l) + L0*(*dAccel)(2)); (*accel)(2) = l,0/(LO+Ll)*(-(*dAccel)(l) + (*dAccel)(2)); } // nonlinear geometry, horizontal actuator right else i f (nlGeom == 1 & & strcmp(posActO,"right") == 0) { if (first Warning[2] == true) { opserr « " W A R N I N G ESThreeActuatorsLshapeb2d::transfDaqAccel() « "nonlinear geometry with horizontal actuator right" « "not implemented yet. Using linear geometry instead.\n\n"; firstWarning[2] = false; } (*accel)(0) = -(*dAccel)(0); (*accel)(l) = 1.0/(L0+Ll)*(Ll*(*dAccel)(l) + L0*(*dAccel)(2)); (*accel)(2) = 1.0/(L0+Ll)*(-(*dAccel)(l) + (*dAccel)(2)); } // rotate direction if necessary if(phiLocX !=0.0) { (*accel) = rotLocXA(*accel); } return OF_ReturnType_completed; } int ESThreeActuatorsLshapeb2d::transfDaqForce(Vector* force) { // linear geometry, horizontal actuator left if (nlGeom == 0 & & strcmp(posActO,"left") == 0) { (*force)(0) = (*dForce)(0); (*force)(l) = (*dForce)(l) + (*dForce)(2); (*force)(2) = -L0*(*dForce)(l) + Ll*(*dForce)(2) + L5*(*dForce)(0); } // linear geometry, horizontal actuator right else i f (nlGeom == 0 & & strcmp(posActO,"right") == 0) { (*force)(0) = -(*dForce)(0); (*force)(l) = (*dForce)(l) + (*dForce)(2); (*force)(2) = -L0*(*dForce)(l) + Ll*(*dForce)(2) - L5*(*dForce)(0); } // nonlinear geometry, horizontal actuator left else if (nlGeom == 1 & & strcmp(posActO,"left") == 0) { if (firstWarning[2] == true) { opserr « " W A R N I N G ESThreeActuatorsLshapeb2d::transfDaqForce() « "nonlinear geometry with horizontal actuator left" « "not implemented yet. Using linear geometry instead.\n\n"; firstWarning[2] = false; } (*force)(0) = (*dForce)(0); (*force)(l) = (*dForce)(l) + (*dForce)(2); (*force)(2) = -L0*(*dForce)(l) + Ll*(*dForce)(2) + L5*(*dForce)(0); } // nonlinear geometry, horizontal actuator right else i f (nlGeom == 1 & & strcmp(posActO,"right") == 0) { // first use Newton-Raphson to solve for the element DOF displacements to know the exact geometry : Vector R(3), X(3), dX(3); Matrix K(3,3); int iter = 0; int maxlter =15; double tol = 1E-9; double R0 = sqrt(L0*L0 + L3*L3); double R l = sqrt(Ll*Ll + L4*L4); double R2 = sqrt((L 1 +L2)*(L 1 +L2)+L5 *L5); double alphaO = atan(L3/L0); double alpha 1 = atan(L4/Ll); double alpha2 = atan(L5/(Ll+L2)); // initialize the solution X with the displacements obtained assuming linear geometry. X(0) = -(*dDisp)(0); // X ( l ) is the horizontal displacement X ( l ) = 1.0/(L0+Ll)*(Ll*(*dDisp)(l) + L0*(*dDisp)(2)); // X(2) is the vertical displacement X(2) = 1.0/(L0+Ll)*(-(*dDisp)(l) + (*dDisp)(2)); // X(3) is the rotation do { R(0) = (*dDisp)(0)+X(0); R(l ) = -pow((*dDisp)(l)+Lal,2.0) + pow(Lal+L3+X(l)-R0*sin(alpha0+X(2)),2.0) + pow(L0+X(0)-R0*cos(alpha0+X(2)),2.0); R(2) = -pow((*dDisp)(2)+La2,2.0) + pow(La2+L4+X(l)-Rl *sin(alphal-X(2)),2.0) + pow(Ll-X(0)-Rl*cos(alphal-X(2)),2.0); K(0,0)= 1; K(0,1) = 0; K(0,2) = 0; K(1,0) = 2.0*(L0+X(0)-R0*cos(alpha0+X(2))); K ( l , l ) = 2.0*(Lal+L3+X(l)-R0*sin(alpha0+X(2))); K(l ,2) = -2.0*(Lal+L3+X(l)-R0*sin(alpha0+X(2)))*R0*cos(alpha0+X(2))+2.0*(L0+X(0)-R0*cos(alpha0+X(2)))*R0*sin(alpha0+X(2)); K(2,0) = -2.0*(L1-X(0)-Rl*cos(alphal-X(2))); K(2, l) = 2.0*(La2+L4+X(l)-Rl*sin(alphal-X(2))); K(2,2) = 2.0*(La2+L4+X(l)-Rl*sin(alphal-X(2)))*Rl*cos(alphal-X(2))-2.0*(Ll-X(0)-Rl*cos(alphal-X(2)))*Rl*sin(alphal-X(2)); // Newton's method dX = R/K; X -= dX; iter++; } while ((dX.Norm() >= tol) & & (iter <= maxlter)); // issue warning i f iteration did not converge if (iter >= maxlter) { opserr « "WARNING ESThreeActuatorsLshapeb2d::transfDaqForce() - " « "did not find the displacements solution after " « iter « " iterations and increment norm: " « dX.Norm() « endln; } // compute angles of incline of each actuator : double betaO = asin((L5+X(l)-R2*sin(alpha2-X(2)))/(LaO+(*dDisp)(0))); double betal = asin((-X(0)+R0*cos(alpha0+X(2))-L0)/(Lal+(*dDisp)(l))); double beta2 = asin((-X(0)-Rl*cos(alphal-X(2))+Ll)/(La2+(*dDisp)(2))); 169 (*force)(0) = -(*dForce)(0)*cos(betaO) - (*dForce)(l)*sin(betal) - (*dForce)(2)*sin(beta2); (*force)(l) = (*dForce)(0)*sin(betaO) + (*dForce)(l)*cos(betal) + (*dForce)(2)*cos(beta2); (*force)(2) = -(*dForce)(0)*cos(betaO+X(2))*L5 + (*dForce)(0)*sin(betaO+X(2))*(Ll+L2) -(*dForce)(l)*cos(betal-X(2))*L0 + (*dForce)(2)*cos(beta2-X(2))*Ll; } // rotate direction if necessary if(phiLocX !=0.0) { (*force) = rotLocXA(*force); } return OF_ReturnType_completed; } int ESThreeActuatorsLshapeb2d::transfDaqTime(Vector* time) { *time = *dTime; return OF_ReturnType_completed; } int correctP4S0(double *dsp, double x); // method using the linear regression of the last 4 points to impose the predicted slope : int predictLR(double *dsp, double x); // method using the linear regression of the last 10 points to impose the predicted slope : int predictLR10(double *dsp, double x); // method using simple linear interpolation int correctL(double *dsp, double x); // method using linear interpolation plus a 30% delay on the next step to apply steps more smoothly int correctLdelay(double *dsp, double x); // method using linear interpolation plus a 30% delay on the next step to apply steps more smoothly int predictLdelay(double *dsp, double x); // method for hold in ramp-and-hold procedure int predictDO(double *dsp, double x); // methods using linear Lagrange polynomials and current disp // when switching between prediction and correction int predictDl (double *dsp, double x); int correctDl(double *dsp, double x); // methods using quadratic Lagrange polynomials and current disp // when switching between prediction and correction int predictD2(double *dsp, double x); int correctD2(double *dsp, double x); // methods using cubic Lagrange polynomials and current disp // when switching between prediction and correction int predictD3(double *dsp, double x); int correctD3(double *dsp, double x); // methods using cubic Hermite polynomials and current disp // when switching between prediction and correction int predictDV(double *dsp, double x); int correctDV(double *dsp, double x); // methods using disp, vel and accel and current disp // when switching between prediction and correction int predictDVA(double *dsp, double x); int correctDVA(double *dsp, double x); // global variables int i , nAct; double dtCon, xi; double *dspl, *dsp2, *dsp3, *dsp4, *dsp5, *dsp6, *dsp7, *dsp8, *dsp9, *dspl0, *dspXi; double *vell , *vel2; double *accl; #endif 172 return 0; } int zeroData() { xi = 0; for (i=0; i<nAct; i++) { dspl[i] = 0; dsp2[i]=0; dsp3[i]=0; dsp4[i] = 0; dsp5[i] = 0; dsp6[i] = 0; dsp7[i]=0; dsp8[i]=0; dsp9[i] = 0; dspl0[i] = 0; dspXi[i] = 0; vell[i] = 0; vel2[i] = 0; accl[i] =0; } return 0; } int zeroDsp(double *dsp) { for (i=0; i<nAct; i++) { dsp[i] = 0; } return 0; } int setCurDsp(double *dsp, double x) { xi = x; for (i=0; i<nAct; i++) { dspXi[i] = dsp[i]; } return 0; } //========================== int setNewDsp(double *dsp) { for (i=0; KnAct; i++) { // update displacements dspl0[i] = dsp9[i]; dsp9[i]=dsp8[i]; dsp8[i] = dsp7[i]; dsp7[i] = dsp6[i]; 174 dsp6[i] = dsp5[i]; dsp5[i] = dsp4[i]; dsp4[i] = dsp3[ij; dsp3[i] = dsp2[i]; dsp2[i] = dspl [i]; dspl[i] = dsp[i]; // update velocities 0(hA2) //vell[i]= 1.0/2.0*(3.0*dspl[i] - 4.0*dsp2[i] +dsp3[i]); //vel2[i] = 1.0/2.0*(dspl[i] - dsp3[i]); // update velocities 0(hA3) //vell[i] = 1.0/6.0*(11.0*dspl[i] - 18.0*dsp2[i] // +9.0*dsp3[i]-2.0*dsp4[i]); //vel2[i] = 1.0/6.0*(2.0*dspl[i] + 3.0*dsp2[i] // -6.0*dsp3[i]+ dsp4[i]); // update velocities 0(hA4) vell[i] = 1.0712.0*(25.0*dspl[i] - 48.0*dsp2[i] + 36.0*dsp3[i] - 16.0*dsp4[i] + 3.0*dsp5[i]); vel2[i] = 1.0712.0*(3.0*dspl[i] + 10.0*dsp2[i] - 18.0*dsp3[i] + 6.0*dsp4[i] - dsp5[i]); // update acceleration O(h) //accl[i] = dspl[i] - 2.0*dsp2[i] + dsp3[i]; // update acceleration 0(hA2) //accl[i] = 2.0*dspl[i] - 5.0*dsp2[i] + 4.0*dsp3[i] - dsp4[i]; // update acceleration 0(hA3) //accl[i] = 1.0/12.0*(35.0*dspl[i] - 104.0*dsp2[i] // + 114.0*dsp3[i] - 56.0*dsp4[i] + 11.0*dsp5[i]); // update acceleration 0(hA4) accl[i] = 1.0/12.0*(45.0*dspl[i] - 154.0*dsp2[i] + 214.0*dsp3[i] - 156.0*dsp4[i] +61.0*dsp5[i] - 10.0*dsp6[i]); } return 0; int setNewVel(double *vel, double dtlnt) { for (i=0; i<nAct; i++) { vel2[i]=vell[i]; vellfi] =dtlnt*vel[i]; } return 0; 175 int setNewAcc(double *acc, double dtlnt) { for (i=0; KnAct; i++) { accl [i] = dtlnt*dtlnt*acc[i]; } return 0; } //================='============================= double getNumSubSteps(double vAct, int actID, double vActMax, int Nmin) { double Nmaster, Nslave; actID—; // change to zero indexing Nmaster = ceil(fabs(dspl [actID] - dsp2[actID])/(vAct*dtCon)); // none of the slaved actuators should exceed vActMax for (i=0; i<nAct; i++) { Nslave = ceil(fabs(dspl[i] - dsp2[i])/(vActMax*dtCon)); . Nmaster = (Nmaster>Nslave) ? Nmaster : Nslave; } Nmaster = (Nmaster>Nmin) ? Nmaster : Nmin; Nmaster = (Nmaster>10) ? Nmaster : 10; // need at least 10 substeps return Nmaster; } //====================================================== int predictPl (double *dsp, double x) { for (i=0; i<nAct; i++) { dsp[i] = dspl[i]*(1.0+x) - dsp2[i]*(x); } return 0; } / /================================== int correctPl (double *dsp, double x) { for (i=0; i<nAct; i++) { dsp[i] = dspl[i]*(x) -dsp2[i]*(x-1.0); } return 0; } 176 int predictP2(double *dsp, double x) { for (i=0; i<nAct; i++) { dsp[i] = dspl[i]*(1.0+x)*(2.0+x)/(2.0) - dsp2[i]*(x)*(2.0+x) + dsp3[i]*(x)*(1.0+x)/(2.0); } return 0; } / / = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = int correctP2(double *dsp, double x) { for (i=0; i<nAct; i++) { dsp[i] = dspl[i]*(x)*(1.0+x)/(2.0) -dsp2[i]*(x-1.0)*(x+1.0) + dsp3[i]*(x)*(x-1.0)/(2.0); } return 0; } //===================================== int predictP3(double *dsp, double x) { for (i=0; i<nAct; i++) { dsp[i] = dspl[i]*(1.0+x)*(2.0+x)*(3.0+x)/(6.0) -dsp2[i]*(x)*(2.0+x)*(3.0+x)/(2.0) + dsp3[i]*(x)*(l .0+x)*(3.0+x)/(2.0) - dsp4[i]*(x)*(l .0+x)*(2.0+x)/(6.0); } return 0; } //==================================== int correctP3(double *dsp, double x) { for 0=0; i<nAct; i++) { dsp[i] = dspl[i]*(x)*(1.0+x)*(2.0+x)/(6.0) -dsp2[i]*(x-1.0)*(x+1.0)*(x+2.0)/(2.0) + dsp3[i]*(x)*(x-l .0)*(x+2.0)/(2.0) - dsp4[i]*(x)*(x-l .0)*(x+l .0)/(6.0); } return 0; } //==================================== int predictD0(double *dsp, double x) { 177 for (i=0; i<nAct; i++) { dsp[i] = dspl [i]; } return 0; } //========================= int predictDl (double *dsp, double x) { for (i=0; KnAct; i++) { dsp[i] = dspXi[i]*(1.0+x)/(xi) -dsP2[i]*(1.0+x-xi)/(xi); } return 0; } //========================= int correctD 1 (double *dsp, double x) { for (i=0; i<nAct; i++) { dsp[i] = dspl[i]*(x-xi)/(1.0-xi) + dspXi[i]*(x-1.0)/(xi-1.0); } return 0; } / /======================= int predictD2(double *dsp, double x) { for (i=0; i<nAct; i++) { // dsp[i] = dspl [i]*(l .0+x)*(2.0+x)/(2.0) // - dsp2[i]*(x)*(2.0+x) // + dsp3[i]*(x)*(l .0+x)/(2.0); dspfi] = dspXi[i]*(1.0+x)*(2.0+x)/(xi)/(1.0+xi) - dsp2[i]*(2.0+x)*(l .0+x-xi)/(xi) + dsp3 [i] *( 1.0+x)*( 1.0+x-xi)/( 1.0+xi); } return 0; } y / = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = int correctD2(double *dsp, double x) { for (i=0; i<nAct; i++) { dspfi] = dspl[i]*(x)*(x-xi)/(1.0-xi) + dspXi[i]*(x-1.0)*(x)/(xi-1.0)/(xi) + dsp2[i]*(x-1.0)*(x-xi)/(xi); } 178 return 0; } int predictD3(double *dsp, double x) { for (i=0; KnAct; i++) { // dsp[i] = dspl[i]*(1.0+x)*(2.0+x)*(3.0+x)/(6.0) // - dsp2[i]*(x)*(2.0+x)*(3.0+x)/(2.0) // +dsp3[i]*(x)*(1.0+x)*(3.0+x)/(2.0) // - dsp4[i]*(x)*(l .0+x)*(2.0+x)/(6.0); dsp[i] = dspXi[i]*(1.0+x)*(2.0+x)*(3.0+x)/(xi)/(1.0+xi)/(2.0+xi) -dsp2[i]*(x)*(2.0+x)*(3.0+x)*(1.0+x-xi)/(2.0*xi) + dsp3[i]*(x)*(l.'0+x)*(3.0+x)*(1.0+x-xi)/(1.0+xi) -dsp4[i]*(x)*(1.0+x)*(2.0+x)*(1.0+x-xi)/(2.0)/(2.0+xi); } return 0; } / / = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = int correctD4(double *dsp, double x) { for (i=0; i<nAct; i++) { dsp[i] =dspl[i]*0.25*(x+1.0)*(3.0*xi*x-5.0*x+7.0-5.0*xi)*(-xi+x)*(x)/(xi-1.0)/(xi-1.0) + dspXi[i]*(x)*(x+l .0)*(x-l .0)*(x-l .0)/(xi)/(xi+1.0)/(xi-l .0)/(xi-l .0) - dsp2[i]*(x+1.0)*(x-1.0)*(x-1.0)*(-xi+x)/(xi) + dsp3[i]*0.25*(x-1.0)*(x-1.0)*(-xi+x)*(x)/(xi+1.0); } return 0; } / /==== = = = = = = = = = = = = = = = = = = = = = = = = = ; = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = ============== // here 30% of the next step will be used to reach the target // the delay in initializeSimulation.m must be 30% too ! int correctLdelay(double *dsp, double x) { for (i=0; i<nAct; i++) { dsp[i] = dspXi[i]*(l-(x-xi)/(1.30-xi)) + dspl[i]*(x-xi)/(1.30-xi); } return 0; } / / = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = // here 33% of the next step will be used to reach the target // the delay in initializeSimulation.m must be 33% too ! // Note that since OpenSees is waiting 33% of the time step, the simulation time must be increased accordingly 179 // to leave enough time for the integration+communication processes. int predictLdelay(double *dsp, double x) { for (i=0; KnAct; i++) { if(x<=0.30) { dsp[i]=(dspXi[i]*(l-(l-xi)/(1.30-xi)) + dspl[i]*(l-xi)/(1.30-xi))*(l-x/0.30) + dspl[i]*x/0.30; } else { } } return 0; dsp[i] = dspl[i]; //= int correctL(double *dsp, double x) { for (i=0; i<nAct; i++) { dsp[i] = dspXi[i]*(1.0-(x-xi)/(1.0-xi)) + dspl[i]*(x-xi)/(1.0-xi); } return 0; } //========================================================================== int correctP4S0(double *dsp, double x) { for (i=0; i<nAct; i++) { dsp[i] = dspXi[i]*(-2*x*x*x+3 *(xi+l )*x*x-6*xi*x+3 *xi-1 )/(xi-1.0)/(xi-1.0)/(xi-1.0) + dspl[i]*(2*x*x*x-3*(xi+l)*x*x+6*xi*x+xi*xi*(xi-3))/(xi-1.0)/(xi-1.0)/(xi-1.0); } return 0; } //= int predictLR(double *dsp, double x) { for (i=0; KnAct; i++) { dsp[i] = dspl[i]*(3*x/10+l) + dsp2[i]*(x/10) - dsp3[i]*(x/10) -dsp4[i]*(x*3/10); } return 0; 180 / / = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = int predictLR10(double *dsp, double x) { for (i=0; i<nAct; i++) { dsp[i] = dspl[i]*(4/330*x*4.5+l) + dsp2[i]*(4/330*x*3.5) + dsp3[i]*(4/330*x*2.5) + dsp4[i]*(4/330*x*1.5) + dsp5[i]*(4/330*x*0.5) - dsp6[i]*(4/330*x*0.5) -dsp7[i]*(4/330*x*1.5) - dsp8[i]*(4/330*x*2.5) -dsp9[i]*(4/330*x*3.5) -dspl0[i]*(4/330*x*4.5); } return 0; } / / = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = int correctD3(double *dsp, double x) { for (i=0; KnAct; i++) { dsp[i] = dspl[i]*(x)*(1.0+x)*(x-xi)/(2.0)/(l-xi) + dspXi[i]*(x-1.0)*(x)*(1.0+x)/(xi-1.0)/(xi)/(1.0+xi) + dsp2[i]*(x-1.0)*(1.0+x)*(x-xi)/(xi) - dsp3[i]*(x-1.0)*(x)*(x-xi)/(2.0)/( 1.0+xi); } return 0; } / / = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = int predictDV(double *dsp, double x) { for 0=0; i<nAct; i++) { dsp[i] = dspl[i]*(1.0+x)*(1.0+x)*(1.0-2.0*x) + vell[i]*(x)*(1.0+x)*(1.0+x) .+ dsp2[i]*(x)*(x)*(3.0+2.0*x) + vel2[i]*(x)*(x)*(1.0+x); } return 0; } / / = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = int correctDV(double *dsp, double x) { for 0=0; i<nAct; i++) { dsp[i] = dspl[i]*(-x+xi)*(-2.0+x+xi)/(-1.0+xi)/(-1.0+xi) - vel 1 [i]*(-1.0+x)*(x-xi)/(-1.0+xi) 181 + dspXi[i]*(-l .0+x)*(-l .0+x)/(-l .0+xi)/(-l .0+xi); } return 0; //=================================================================== int predictDVA(double *dsp, double x) { for (i=0; i<nAct; i++) { dsp[i]=dspl[i] + vell[i]*(x) + accl[i]*(x)*(x)/(2.0); } return 0; } //=================================================================== int correctDVAfdouble *dsp, double x) { for (i=0; KnAct; i++) { dsp[i] = dsp 1 [i]*(-x+xi)*(3.0-3.0*x+x*x-3.0*xi+x*xi+xi*xi)/(-1.0+xi)/(-1.0+xi)/(-1.0+xi) - vel 1 [i]*(-1.0+x)*(x-xi)*(-2.0+x+xi)/(-1.0+xi)/(-1.0+xi) -accl[i]*(-1.0+x)*(-1.0+x)*(x-xi)/(2.0)/(-1.0+xi) + dspXi[i]*(-l .0+x)*(-l .0+x)*(-l .0+x)/(-l .0+xi)/(-l .0+xi)/(-l .0+xi); } return 0; } //======= = = = = = == = = = = = = = = = == = = = = = = = = = = = = = = = = = = == = = = = =================== 182 APPENDIX E: manual of operation for the hybrid simulation of the gravity load collapse of RC frames This appendix consists in a manual of operation to assist the user in performing a hybrid test using the setup described in Part 6. E.1 Setup of the analysis files and predictor-corrector model Before performing a hybrid test, one must make sure that the Tcl analysis files are correctly set up. Here is a list of a few checks that should be done beforehand: o Check the name and path of the predictor-corrector application that will be used during the hybrid test. This critical information is specified in the definition of the experimental control object in the file ColumnElementsRigidEle.tcl: expControl xPCtarget 1 1 "148.150.203.192" "22222" "HC_12_slowstep0004_modif_06J5_07" "D:\\xPC target Predictor Controller\\06-2007\\" o In the example above, the predictor-corrector application used is HC_12_slowstep0004jnodif_06_15_07.dlm located in D:\\xPC target Predictor Controller\\06-2007\\ on the Numerical Analysis Host Computer. Note the presence of two "\" in the path instead of one usually; this is a specificity of the Tcl language. It is important to know that the .dim file is the only file that is required and will be used during the hybrid test: it is the compiled application corresponding to the Simulink model HC_12_slowstep0004_modif_06_15_07.mdl. o Check the consistency between the integration time step (also called analysis time step) in the OpenSees model and in the predictor-corrector model. If an integration time-step of 0.001s is specified in the Tcl input file for OpenSees, then this same value must be specified for the parameter dtlnt in the file initializeSimulation.m corresponding to the Simulink model of the predictor-183 corrector. Remember that the Simulink model must be closed and reloaded in Matlab and then recompiled if any modification is made to this initialization file (and it must be recompiled if any modification is made to the Simulink model). E.2 Flowchart of operations To perform a hybrid simulation of the gravity load collapse of reinforced concrete frames, the following steps should be followed : a) Initialization process: o Start the STS controller software according to the instructions provided in Section 3.3, and load for example the settings file (Second Hybrid Test, June 15 2007): threeactuatorsLshape_06-200ISecondTest. set o Move the computers cart from Room 129 to the Structures lab, next to the MTS controller o Slide the xPCtarget computer out ; this is done to avoid overheating of the computers since no vent is present within the cart. Be cautious not to damage the fiber optics in the back of the xPCtarget computer o Plug in the fiber optics (orange cables in the back of the cart) to the front slots of the MTS controller. Follow instructions in Section 3.5 o Plug in the computers (preferably to the power cord coming from the MTS console, in order to take advantage of the Uninterrupted Power Supply enclosed in the MTS console) o Switch on the Numerical Analysis Computer o Switch on the xPCtarget computer in DOS to check that no data file is present on the xPCtarget hard-drive. Delete any data file if present (but don t delete the command.bat file !). The presence of large data files can be lead to the crash of the predictor-corrector application, because deleting all files on the hard-drive is 184 part of the initialization process of this application, and deleting large files could lead to a time-out error. Insert the xPCtarget boot floppy disk and restart the xPCtarget computer to boot up the xPCtarget kernel. Once the xPCtarget kernel is booted, the xPCtarget screen must display loader mode, meaning that it is ready to receive the xPCtarget application from the Numerical Analysis Host computer. Check that the Scramnet communication is OK: the Scramnet OK light on the STS software must turn green when the xPCtarget computer is turned on. Make sure that the Program source in the STS software is set to Scramnet, and that the use simulated feedback box is not checked. Make sure that the 3 actuators are in displacement control Make sure that the safety stop button is not pushed (that would cause an interlock in STS), and verify that the limit detectors (force, displacement) are correctly set up for each controlled channel. Check the setup of the data recorder, and verify that the destination file is correct. Check that the digital and analog readouts, digital meters A and B, and oscilloscope are open and displaying the desired variables Reset the interlocks in the STS software by clicking on Reset. The interlocks light on the STS main panel must turn green. Otherwise, check the message log to find the source of the interlock. If used, start the laptop running the Daisylab data acquisition software. Ask Scott Jackson for the use of this software and of the corresponding laptop. On the Numerical Analysis Host Computer, start OpenSees (procedure already described in Section 4.3.3). Load the Tcl input file (type source inputfile.tcT) and hit enter. This will start the xPC target initialization process. 185 o Turn on the water tap at the North East extremity of the Structures lab. This water tap should be connected to a hose that goes all the way to the hydraulic pump in the basement, and this water supply is used for cooling of the pump engine. Failure to open the water supply can damage the pump, especially when performing long duration tests. o In STS, switch on the pump, then switch on the manifolds (1 and 2 must be selected to enable the 3 actuators) (first to low pressure, then to high pressure) o In STS, position the actuators to the desired initial configuration (zero force in the load cells or close enough, desired initial geometrical positions). Again, make sure that the actuators are in displacement control and that Scramnet is specified as the program source for STS. b) Performing the hybrid testing: o On the Numerical Analysis Host Computer, in OpenSees, press enter to perform the data acquisition process. o start the STS data recorder (and the Daisylab recorder if used on another computer) and press Run on the STS GUI o in OpenSees, press enter to start the simulation. The analysis steps must pass in the command window, confirming that the analysis is started. c) At the end of the hybrid test: o When the simulation is over (ie when OpenSees has finished the computation of the analysis), stop the data recorder in STS, and the Daisylab data recorder if used on another computer. The pump can be turned off. o Note that the xPCtarget application is still running until a command is issued to stop it. This can be done through Matlab on the Numerical Analysis Host computer by typing tg=xpc followed by tg.stop. Note that if OpenSees is still 186 running Matlab won t be able to connect to the target computer. Indeed, OpenSees is using the C-API interface through OpenFresco, and this interface cannot be used at the same time as the Matlab interface. If the hybrid test must be stopped before the end of the analysis, one must first stop OpenSees in order to then be able to stop the xPCtarget application through Matlab. Once the analysis is stopped, and when the xPCtarget application is still loaded (either still running or stopped through Matlab commands), execute the Matlab function endSimulationXPCtarget.m (check that the data files listed in this script correspond to the actual data files recorded) on the Host Computer in order to download, convert and save the data stored by the xPCtarget predictor/corrector. (Note that no data was recorded on the xPCtarget computer during the second hybrid test described in Chapter 8) 187 APPENDIX F: TROUBLE-SHOOTING Problem Solution Unable to compile the latest OpenSees (1.7.3) from CVS with Visual Studio 2005: error: cannot link the library libc.lib libc.lib corresponds to the previous versions of Visual Studio, and has to be ignored in Visual Studio 2005. To do so, go in Project -> Properties -> Linker -> Input -> Ignore libraries and add libc.lib Unable to load the Simulink model on the xPCtarget computer: ECxPCtargetQ error in the OpenSees DOS command window, or the OpenSees command window closes without reason - check that data files from previous analysis have been deleted from the xPCtarget hard-drive. (If not, deleting these big files during the starting process will lead to a time out error in OpenFresco) To delete these file, boot the xPC computer in DOS and type del *.dat (deleting might take a long time). - check that the xPCtarget connection with Matlab is closed. Connection with the xPCtarget computer can be done either through Matlab or through the C API used in OpenFresco, but not both at a time. To close the connection in Matlab, type tg=xpc to check the connection status and then close(xpc) if connected. - check the physical connection between the Host and xPCtarget computers: it must be done through a crossover network cable The xPCtarget application is running (timer running) but the actuators are not moving - check the STS settings: Use simulated feedback must be disabled, the Run button must be pressed, the controlled actuators must be in displacement control, the Scramnet connection light must be green, the STS program source must be set to Scramnet 188 Unable to download the data from the xPCtarget computer after a test using endsimulationXPCtarget. m - check that the xPCtarget environment is still loaded - check that Opensees is stopped (either Successful, or close the command window if the analysis failed or was not responding). You can control xPCtarget either through the OpenFresco C API or through Matlab, not both at a time - check that the Matlab connection with xPCtarget is ok: type tg=xpc in the Matlab command line and check the connection status - check the size of the data files to be downloaded. The TCP/IP connection between the Host Computer and the xPCtarget computer might fail if the file is too big (more than about 150Mo). In this case, install the DOS boot files on a USB stick, boot the xPCtarget computer with the USB DOS boot stick (check the BIOS boot sequence if not working) and copy manually the files in DOS from the hard-drive to the USB stick Unable to open on the Host computer the data files downloaded from the xPCtarget computer the data files are written on the xPCtarget hard-drive in a xPCtarget- specific binary type. These files must be converted to text data files through the Matlab function readxpcfile.m. Unable to open the files from the STS Data Recorder the data files written with the Data Recorder are binary files. They need to be translated into text files using the Translated Binary to Text command in the File pulldown menu on the STS main panel 189 Unable to write on the xPCtarget hard-drive The xPCtarget hard-drive must be a Parallel ATA hard-drive formatted in FAT32 (or FAT 16). The main partition must be less than 4Go. The hard-drive must be connected to the extreme end of the PATA connection cable. The xPCtarget application failed during its initialization (just after downloading) Check that there is no conflict between the Scramnet card and the other PCI cards (Ethernet...) by following the instructions in xPC target scramnet interrupt setup.txt located in ubcsts/Documents. Note that Step 2 does not work on recent computers as the IRQ numbers are assigned automatically to the PCI devices, so you need to swap the cards between the different PCI slots until a good IRQ number is assigned to the Scramnet card. Real Time workshop requires that the IRQ number of the Scramnet card used as the timer source be between 5 and 11. 190 

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
http://iiif.library.ubc.ca/presentation/dsp.831.1-0063277/manifest

Comment

Related Items