Crashworthiness Analysis using HyperMesh and Radioss Assignment 6-Frontal Crash Simulation Challenge

OBJECTIVE

To perform a crash analysis on the front half of a Dodge Neon BIW, also known as a frontal crash. The analysis is to be carried on the deformation and the forces created as a result of the crash at a speed of 35 mph. Along with the analysis, certain output requests were to be generated and they are as follows:

• Sectional force in the rails at the location of indicated node 174247.
• The axial force received on the rails from the bumper.
• Shotgun cross-sectional forces.
• A-pillar cross-section.
• Acceleration curve received on the accelerometer at base of B-pillar (on B-pillar rocker).
• Intrusions on the dash wall 66695, 66244.

BACKGROUND

The crash test is a virtual reconstruction that replicates the same forces and speeds that would occur if the vehicle was to be involved in an actual crash. In this type of testing, since nothing is physically impacting the Body-in-White (BIW), no physical deformation or damage occurs to the body’s structure, allowing multiple crashworthiness tests to be conducted in succession. This type of simulation is an integral part of the design process and can help save both time and money since it can be implemented instead of costly, destructive testing programs.

source: https://www.lancemore.jp/ls-dyna/example_260.html

For this project, the case setup and simulation are to be done in Hypermesh and Hypercrash, whereas Hyperview and Hypergraph 2D will be used for post-processing. Hypergraph will be used to plot energies, Von-Mises stresses, plastic strains, acceleration curves, and force and Hyperview will be used to view the simulation.

As part of the process, we are to create a rigid wall, check penetrations, assign an initial velocity of 35mph, carry out mass balancing to ensure the total weight comes to 700 kgs, and finally, create sections, intrusions and accelerometers as part of the output request requirements.

MODEL IMAGE

PROCEDURE

The model is imported through the 'import via solver deck' option on either Hypermesh. The first thing we need to verify is the applied interface, which is type 7. We need to ensure that it has all the proper settings.

There are multiple type 7 cards for this model - they can all be deleted by right-clicking them all and selecting 'delete' in the model browser. We can go ahead and create a new interface card by right-clicking in the model browser section > create > contact. We shall be creating a type 7 card with the following properties:

For the slave and master node settings, all the components in the model are selected. Therefore, this interface card will cover all the components in the model.

Moving on to the other requirements,

CREATION OF RIGID WALL

For this, the model was imported to Hypercrash. To switch to Hypercrash, we need to go to Applications > Hypercrash from the Hypermesh window.

A rigid wall is an object that is used to define an interaction between a non-deformable entity and a deformable entity. Nothing can go beyond it and it is non-yielding. There are multiple types, like infinite plane, infinite cylinder, spherical, and parallelogram. But for this case, we shall be using the infinite plan option, which creates a rigid wall along the entirety of a selected plane.

To create a rigid wall in Hypercrash, we can go to the top toolbar and access LoadCase > Rigid Wall. In the Rigid Wall panel, we can select the create new object button and select 'plane' (the same process can be carried out by right-clicking the panel's interface and going through the same options).

The created rigid wall is given the following properties (with the requirement of friction of 0.1):

To understand the co-ordinates XM, YM, ZM & XM1, YM1, and ZM1,

M0 is defined by XM, YM, and ZM whereas M1 is defined by XM1, YM1, and ZM1. This helps create a normal for the rigid wall and hence orient it properly with respect to the model. The furthest point on the model, which would be on the bumper, is picked as a reference for M0. To allow a gap between the wall and the model, we can edit the x-coordinate, since the movement will be along that axis. The same concept is used to define M1, where we will use a different x-coordinate value again and that helps define the normal.

APPLICATION OF INITIAL VELOCITY

To add initial velocity to the system in Hypercrash, we need to go to LoadCase > Initial Velocity. For [Gnod_id] Support, we shall be selecting all the nodes in the model. Required velocity is 35 mph but the units are in mm/ms, which would be 15.6464 mm/ms. As discussed in the previous section, movement is along the x-axis, so this value will be entered in [Vx] X Velocity. All other velocity values would be 0.

After entering the values, we can click save at the bottom of the panel.

MASS BALANCING

The target mass of the model is supposed to be 700 kgs. We can check what the current mass is by accessing Mass > Balancing from the top toolbar in Hypercrash.

As we can see, it says the current mass is 188 kgs. It also shows where the current centre of gravity is. The above image also shows where the centre of gravity ought to be moved to, based off the full car model provided. Understandably, we need to add more mass and balance the additional weight to change these parameters. To do so, we can go to LoadCase > Added Mass. Then we can click the 'create a new object' icon in the panel to add an entity. We are to then select the 'type' of mass to be added, and we shall pic type 1 as shown. In addition to that, we are to assign a mass to this entity and select the nodes that would come under it.

I added masses to include that of the front seats and the following shows the current mass and location of the centre of gravity, which was what we were going for:

ADDING SECTIONS

Firstly, we will be creating moving frames for each of these regions. To do so, we go to the solver browser and right-click > create > frame > mov.

Doing so brings up the moving frame attribute window on the bottom. We are to define a plane basically. The origin node is going to be the node that will be part of the section that is to be defined (For node 174247, the origin node can be right-clicked and we will be given the option to enter the node ID). The next two will define the plane. They are selected as shown in the above screenshot.

After creating the moving frame, we can move on to defining the section. In the same solver browser, we are to right-click > create > sect > sect.

N1 is going to be the same as the origin node defined in the moving frame setting. N2 & N3, again, will help define the plane. Frame_ID will be the corresponding moving frame that was created earlier. grshel_id will be a selection of two rows of elements, of which the nodes are a part.

After creating the section, we can move to the model browser and right-click 'Output Blocks' > Create. With this, we shall create an output request for the sections we previously created. We can edit the output block in the entity editor on the bottom left.

For the entity IDs, we shall be selecting all the crosssections that were created (7 of them).

Screenshot with all the crosssections visible:

ADDING INTRUSIONS

The first step is to create a moving skew for these intrusions. To create a moving skew, we need to go to the solver browser, right-click > Create > Skew > Mov.

Doing so brings up the moving skew attribute window on the bottom. We are to define a plane basically. The origin node is going to be the node at which the intrusion is to be measured (nodes 66695, 66244). The next two will define the plane. They are selected as shown in the above screenshot.

Then we can switch to the model browser and create an output block for this newly created skew. Right-clicking 'Output Blocks' and selecting 'create' brings up an entity editor on the bottom left.

The entity ID is going to be the node where the intrusion is to be measured (nodes 66695, 66244) and the lskew is going to be the corresponding skew system.

ADDING ACCELEROMETERS

To create accelerometers, we are to go to the model browser, right-click > select 'create' > accelerometer. In the entity editor section, we can specify the node (at the base of the B-Pillars). Here, as we can see, the node is selected and it is marked as an accelerometer:



The next step is to create a Time History (TH) output specifically for these accelerometers. We can do this by again right-clicking in the model browser > create > output blocks. We can edit this new entity and create an output block for each of the two accelerometers. The 'entity ID' is for selecting the particular accelerometer.

PENETRATION CHECK

Then, we can run a penetration check by going to Tools > Penetration Check from the upper toolbar in Hypermesh.

We will need to click the 'Invoke Penetration Check Setup Widget' within its browser to access options for the process. With the entity type as '

SIMULATION TIME

In the model browser, we can go to cards > ENG_RUN to change the simulation time. In the entity editor, T_stop is given the value of 80ms.

Time step did not require editing since the default values were in the 0.5 to 0.1 microsecond range.

ERRORS

Finally, before carrying out the RADIOSS analysis, an error check was run on the file through Hypercrash. The model check tool can be accessed through Quality > Model Checker > Run from the upper toolbar.

The errors marked in red require immediate fixing. The 'translational joint' and 'spring' entities were deleted since they weren't involved nor required for this analysis. The remaining errors can be ignored. They can be rectified automatically by clicking the wrench icon on the top right of the model checker panel.

In addition to that, if there are any unsupported cards in the model browser, they can be deleted.

RUNNING THE ANALYSIS IN RADIOSS

Switching to Hypermesh, moving to Analysis > radioss, we can click 'save as' to save the file if it hasn't been saved yet. Care must be taken to include '_0000.rad' in the file name since it's the starter file. After that, we can check the connectors option and input '-nt 4' in the options bar before clicking 'Radioss'. This starts the Radioss simulation.

ANALYSING THE OUTPUT FILE

The next step is to carry out energy error and mass error checks and this is done by analyzing the RADIOSS engine output file. This can be accessed from the same directory as the starter and engine files and is denoted by the '.out' extension. The file in question contains '_0001.out' and can be accessed using any text editor - such as Notepad.

As we can see, the energy error is -1.1%. It is definitely acceptable due to its proximity to 0% error. In addition to that, the mass error is 0.0343, which means that a negligible quantity of mass of around 34 grams was added during the simulation, possibly for the sake of time step control/stabilization. It is a rather low amount so it's still acceptable.

Total Simulation Time: 5316.62s
No. of cycles: 80000

VIEWING THE SIMULATION

To view the simulation, we can switch to Hyperview through the client selector.

In Hyperview, we will need to import the h3d variant of the file. After importing, we can then select the 'contour' tool to switch to the Von Mises contour so we can analyze the stresses that form within the crush tube in the simulation. This is what the simulation looks like:

As we can see, after colliding with the rigid wall, the card is deflected in an upward direction, due to the lack of material in the region where the tyres would exist.

GENERATING THE PLOTS

After generating the simulation, we can then go ahead and generate the plots. Using the same client selector, we can switch to Hypergraph. In the Hypergraph client, we are asked to import the required file, which is the T01 variant of the file.

On importing, we can build the plots using different variables. We shall first look at general plots of energies and rigid wall forces generated in and by the entire BIW respectively.

Energies

The changes in kinetic and internal energies occur at the exact moment the BIW makes contact with the rigid wall. Understandably, the BIW loses kinetic energy throughout the simulation due to the obvious decrease in velocity. At the same time, it absorbs the forces, and this results in an increase in internal energies, and as a result, the deformations also occur.

Taking a look at the contact energy graph:

Contact energy is a type of energy that is formed when one element comes in contact with the other or neighbouring elements. The opposing force created by this element forms the contact energy. In this case, it increases after 5 ms, at this point the model starts deforming in such a way that penetration of nodes occurs. When certain regions of the model press on themselves, buckled elements are forced into contact.

The increase in contact energy affects the overall energy of this system, which is why there is a decrease in the total energy over the course of the simulation - it is a negligible decrease though. The magnitude of contact energy generated is much lower.

Rigid Wall Forces

Taking a look at the rigid wall forces generated:

The rigid wall forces peak at around the 18ms mark, which looks like is the point in time where the BIW had exhausted its deformation capabilities in the bumper and reinforcement regions. After that, deformation (forces) were transferred to members that house the engine and tyres. Due to the freedom given to deform in those regions, the rigid wall probably experienced a reduction in forces from there.

OUTPUT REQUESTS
Sectional Forces at node 174247

Axial forces on bumper rails

Cross-sectional forces on shotgun members

Cross-sectional forces on both A-Pillars

Acceleration curves generated by accelerometers in both B-Pillar rockers

Intrusion magnitudes at nodes 66695 and 66244 located on the dash wall

OBSERVATIONS

Generally, the outer body members in the BIW are supposed to be symmetrical about the centre. That means the plots generated in each of the cases involving either side of the same part should have been very similar in terms of shape and values but that is not the case here. The left side of the vehicle in general seems to be absorbing most of the impact force due to two possible reasons:

1. The location of the reference point on the bumper used to create the rigid wall was probably not at the exact centre of the bumper component. This resulted in the first point of impact being off the centre and invariably lead to the unequal distribution of forces

2. The locations of the sections created may not be exactly symmetrical about the centre of the BIW.

Coming to the accelerometer graphs, it seems like there is a lot of fluctuation in acceleration. This is probably the result of vibrations created during impact. If the BIW hadn't undergone the crash, there wouldn't be spikes in those plots, since in the general sense, acceleration and deceleration occur gradually. These accelerometers are pivotal in detecting these spikes and drops and helps in the functioning of safety systems, like airbags.

With regards to the intrusion plots, the panel on which the two nodes are located don't undergo much deformation locally, which explains the similar graphs.

RESULT

Frontal crash analysis was carried out on the given front half of a BIW model of the Dodge Neon as per the given requirements. The output requests were also generated after the creation of cross-sections in each of those regions. Acceleration and intrusion values were also measured at certain points of the model.

The analysis also proves the importance of the crumple zone - which is the front portion of the BIW in this case. It absorbs most of the forces generated during a frontal crash and therefore, protects the occupant(s).