LESSONS LEARNED IN SOLID MODELING OF BOLTS IN …pages.mscsoftware.com/rs/mscsoftware/images/Paper_Lessons Learn… · LESSONS LEARNED IN SOLID MODELING OF BOLTS IN CONTACT ... then

SESSION TITLE – WILL BE COMPLETED BY MSC SOFTWARE

Copyright © 2013 Boeing. All rights reserved.

LESSONS LEARNED IN SOLID MODELING OF

BOLTS IN CONTACT

Authors:

Tricia Carr, Dan Mueller (The Boeing Company, USA)

Presenter:

Tricia Carr, Structural Analyst

THEME

Structures

SUMMARY

This paper outlines some of the lessons learned during a bolted joint analysis

study. Solid element bolt models created using Patran command language

(PCL) were run with contact enabled, both in Sol 101 and Sol 400. Both bolt

preload and interference fit are simulated in these models by using geometric

overlap. Preload, for example, was developed by creating a bolt head which

physically overlapped the washer; then the ERROR tolerance on the contact

table was used to force the head and washer faces into place, thereby pre-

stressing the bolt. Interference fit was done in a similar way, by modeling a

bolt with a larger diameter than the hole.

The meshing method which was used in this study generated HEX-only, highly

regular models, where nodes were exactly aligned between the master and

slave surfaces. This exposed an interesting problem, in which the bolts would

spin about the centerline. Friction and grounded CELAS connections were

tried without success. It turned out that the one-to-one correspondence of bolt

and plate nodes generated poor multi-point constraint contact equations; the

Nastran solver could not determine a good solution to the contact problem. The

answer involved activating the analytical contact option, in order to smooth the

bolt surface and create better MPC equations—a rare example of a mesh being

too perfect.

KEYWORDS

Contact, PCL commands, solid modeling

LESSONS: SOLID MODELING OF BOLTS IN CONTACT


1: Background

Bearing and bypass loads in bolted joints are especially important in composite

structure, and developing accurate loadshare models is essential. One-

dimensional closed form analysis methods are used within Boeing; for 2D and

3D models, commercial FEA codes are to be used as the analysis engines. To

that end, a way to rapidly generate FE models was created to reduce

engineering time. MSC.Nastran was used as the analysis code, and the models

were generated using Patran Command Language (PCL).

Figure 1: Example solid models of bolted joint

2: Automated modeling with PCL

An in-house tool was developed to generate the geometry of a Patran model,

using a few straightforward inputs from the user. Output from the in-house tool

is a session file containing PCL (Patran Command Language). The session file

is then run from a command line in order to generate a bulk data file and a

Patran database. Alternatively, the session file can be run from inside Patran

(this is a great deal slower, but watching the mesh being formed automatically

is entertaining).



Because of the algorithms used to generate the mesh, 3D solid bolted joint

models auto-generated in this way are extremely regular (i.e., all elements are

bricks (CHEXA), and there is a one-to-one correspondence between all contact

bodies in the model).

Figure 2: Models created by automated meshing are very regular

Contact was run in Nastran Solution 101 as well as Solution 400. As there was

no material nonlinearity, and no geometric nonlinearity aside from the contact

itself, Sol 101 was just as suitable for our models. EXO-6 (MSC Software

Corporation’s tool for reading Nastran output files) did not appear to catch

FATALs for Sol 101 contact runs, however—so a lesson learned is to be sure

to check the .f06 file for FATALs.

Interference fit was simulated by modeling the bolt shank diameter larger than

that of the hole; then, setting the distance tolerance ERROR on the contact

table to a value greater than this overlap will force the shank-hole contact pair

to mate. An alternative method is to model the parts as neat fit, and use the

parameter CINTERF to generate interference. However, we preferred to be

able to see the interference in the model on its creation.



Figure 3: Displacement plots of axial preload and interference fit in fasteners

Likewise, bolt preload was simulated by modeling the bolt length shorter than

the stackup. The ERROR parameter was set to force the washer-head contact

pair to mate, thereby simulating the preload. MSC.Patran’s separate method of

applying bolt preload was not explored in this effort.

Figure 4: Set ERROR larger than the overlap to activate contact interference



The PCL code for Sol 400 runs with contact turned out to be much more

convoluted than that for Sol 101. An example of the code (see Figure 5:)

shows, for example, that Sol 400 starts out by calling solution sequence 600.

Figure 5: PCL for Sol 400 runs proved complicated

One particular bit of Sol 400 PCL proved very trying. Normally, a Sol 400 run

with contact writes out a nonlinear property card for every PSHELL card; this

nonlinear card, PSHLN1, comes from Sol 400’s origins in MARC. However,

PSHLN1 does not work unless MID1 is equal to MID2; unless, that is, you go

on to specify MID3 as well. This was not the case for a few specialized

elements in our models, which are used to apply running loads at the edges of

the solids. The PSHLN1 needed to be removed—simple enough if commenting

out a card in the bulk data, but much harder to change in the session file. First

of all, a “small strain” component needed to be specified in element properties,

but the property had first to be created and subsequently modified in PCL.

(The PCL code in Figure 6: shows an example: “Small Strain” must specified

under elementprops_modify; if it is added under elementprops_create, it is

ignored.)



Figure 6: Turning on “Small Strain” in PCL

This and other issues with PCL for Sol 400 steered us toward directly writing

out the bulk data from the in-house tool , skipping the intermediate step of the

session file.

3: Contact

One of the most perplexing issues which came up during our studies was a

problem with bolts spinning about their axis. Figure 7: shows the

displacements for a double shear lap joint, no external loads applied, with a

single bolt held in place by contact plus a small amount of friction being

applied. (External loads were applied during other portions of testing to try to

‘bias’ the friction, but this did not prevent bolt spinning.)

Several modeling methods to prevent bolt turning were attempted, including

increasing friction () and adding weak CELAS springs. However, even using

values of =0.5 or more and springs as stiff as k=1000 lb/in, did not solve the

issue.



Figure 7: Sol 400 run with contact: displacement shows bolt spinning about axis

Monitoring the location of nodes on the bolt shank showed that displacements

would change direction throughout the solution process. Consultation with

MSC Software Corporation representatives suggested that the cause of the

problem might be that the bolt was 'cogging' (turning back and forth without

finding a good solution to the contact problem), due almost entirely to the fact

that our models were so regular (see Figure 2:). Switching master/slave

definitions would not help, as the mesh density was the same (each node on the

bolt is matched exactly by a node on the hole).

The left side of 0 shows a very coarse diagram of a bolt in a hole and illustrates

this one-to-one correspondence. The right side of the figure shows that as the

bolt moves slightly under load, its nodes will contact the flat surface between

two of the plate nodes and establish contact. Nastran will push the bolt back

until it contacts the plate again. The regularity of the mesh means that the

Nastran cannot establish a good solution to contact. Incidentally, solid TET

models do not have this problem because of the essential randomness of the

placement of the nodes (there's never an exact match on both contacting

surfaces).



Figure 8: Schematic: A moving bolt contacts the side of the hole

The solution to this issue turned out to be activating the analytical contact

option on the BCBODY card, which defines a contact body. Analytical contact

creates a smoothed surface that is used in lieu of the actual mesh in order to

check for contact. In our case, smoothing (specifically splining) produces a

geometric cylinder for the hole, rather than faceted finite element model (FEM)

surface. 0 shows the effect of the smoothed surface, replacing the (very

crudely) meshed hole in the plate with a mathematical surface; now when the

bolt moves under loading, it does not make an 'artificial' contact that is really

just an artifact of the mesh.

Figure 9: Schematic: Smoothing the FEM with analytical contact



Analytical contact is activated by the variable IDSPL on the BCBODY card

(see Figure 10:); this controls splining (technically, in our 3D case, Coons

surfaces).

Figure 10: IDSPL option activates “Analytical Contact”

We used a value of -1 for IDSPL in most cases, as this requires the least input

from the analyst, while still getting the desired results. Nastran will not smooth

any angles greater than that specified by the SANGLE threshold (see card

image above) which has a default of 60°.

If IDSPL is set to +1, Nastran will only spline the areas specified with the

boundary line segments (BLSEG) card. However, this can be very time

consuming. A Lesson Learned is that if no areas are specified, then all bodies

will be smoothed, including 90° edges (such as bolt head and shank). This is

probably not what the analyst is looking for.

Although the use of analytical contact solved the problem (see Figure 11:), for

a displacement plot of a model with IDSPL set to -1, the solution seems



counterintuitive, in that smoothing the surface prevented bolt spinning rather

than allowing it.

Figure 11: Turning on analytical contact solves bolt spinning issue

In order to determine experimentally if splining the mesh surface was the

solution to the problem, we increased the circumferential mesh density in order

to more closely approximate a mathematical cylinder. As the number of

circumferential elements was increased from 16 to 144, the error from zero

rotation about the centerline-axis decreased from 15% down to 0.27% (Figure

12:). Furthermore, turning on analytical contact reduces the error from zero

rotation about the centerline-axis to 0.0006%.



Figure 12: Fastener axial rotation vs. number of circumferential elements around

shank location

All models on which we tested analytical contact were relatively small (30,000

degrees of freedom) and solved fairly quickly. Consequently, we did not make

estimations of the effect of using splining on solution time, but it may very

well be worth trying with some difficult contact problem.

Using PCL to write out a contact table was straightforward for Sol 101; finding

the right combination of lines of PCL to do the same for Sol 400 was much

more troublesome. Another Lesson Learned is that creating the table by

directly writing the NASTRAN input cards (rather than going through the

intermediate step of a session file) turned out to be more practical.

Even analysts who are not investigating automated meshing might consider

automating the creation of BCTABLE card images (by means of an Excel

macro or some other programming language), as a means of saving or

archiving a contact table (especially a complicated one). Patran cannot always

accurately read a contact table in from a bulk data file (i.e., it fails the circle

test), and we discovered that the ‘export/import’ feature on the contact table

form has problems as well.

0.0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

10 30 50 70 90 110 130 150

Fa

sten

er A

xia

l R

ota

tio

n (

deg

)

Number of Circumferential Elements Around Shank Location

Axial Rotation vs. Number of Circumferential Elements

Around Shank Location



4: Lessons Learned

A solid bolt model in contact exhibiting ‘spinning’ behavior may need

analytical contact turned on (via the IDSPL field on BCBODY). The simplest

option is to specify ‘-1’ as the IDSPL value.

Currently, there is no satisfactory way to save or archive the settings in your

contact table inside Patran: a bulk data file read into Patran will not always

reproduce the entire table. Likewise, the ‘export’ feature on the table form in

Patran saves only part of the data. Writing data using a PCL script gets rather

convoluted with Sol 400. We had better results by writing the BCTABLE out

using an Excel macro.

Go back to your roots: review the f06 file carefully if you’re running Sol 101

with contacts. EXO-6 has been known to miss the FATAL in this case, and

results read into Patran do not give any helpful clues of only a portion of the

load having been applied.

Documents

LESSONS LEARNED IN SOLID MODELING OF BOLTS IN …pages.mscsoftware.com/rs/mscsoftware/images/Paper_Lessons Learn… · LESSONS LEARNED IN SOLID MODELING OF BOLTS IN CONTACT ... then