you are here:   / News & Insights / Engineering Advantage Blog / Tips & Tricks for Consistent FEA Units

Engineering Advantage

Tips & Tricks for Consistent FEA Units

February 14, 2017 By: Peter Barrett

As the sharing and transfer of FEA and CFD analysis data becomes more prevalent, the danger of errors caused by inconsistent units grows.  The most famous engineering units error occurred in 1999 when NASA lost a $125 million Mars orbiter because a Lockheed Martin engineering team used English units of measurement while the agency's team used the metric system for a key spacecraft operation.  While many FEA and CFD software automation tools include automated units conversions, it is still ultimately the engineer that is responsible for deploying a consistent set of units. The increase in Multiphysics simulations further increases the risk of unit conversion errors due to the transfer of data between multiple simulation software codes. Summarized below are a list of common tips and tricks in the application of units systems and conversions to help one avoid errors in the application of the finite element method under mixed unit environments.

1) Keep handy a table of consistent units to reference.

a) Table 1 provides four commonly used sets of units.  This is a guide I like to follow to assure consistent input and output results.

b) For codes that do not list the results units such as ANSYS Mechanical APDL, this reference assures that correct interpretation of stresses, for example.

Table 1 – Common Consistent Units Systems

2) Regardless of the input units provided and output units needed, convert all units into the system you have a “feel” for and review all data in these units as a sanity check.

a) For me, this is the in-lb-sec or ft-lb-sec systems since I have worked with these the most.  In spite of my college professor stating in 1977 that British units will be extinct in the next 10 years, forty years later, it is still the unit of choice for a majority of engineering analyses performed in the USA.

b) From experience, I know that steel should have a modulus of elasticity of roughly 30e6 psi and a weight density of 0.28 lb.-in^-3, while concrete has a modulus of roughly 3e6 psi and weight of 150 lb.-ft^-3.   Both steel and concrete materials have a coefficient of thermal expansion of roughly 6.e-6 in/in/Degrees F.  Mild steel yields at roughly 36,000 psi and commercial concrete crushes at roughly 3,000 psi.  So regardless of the materials, load  and results units provided and/or required, I always make it a point to compare all my data in these unit systems as a sanity check.

c) The goal here is to avoid making undetected order of magnitude errors. For example, if I were to list the density of concrete to be 4.15 kg/cubic cm, this would not set off a red flag to me even though the density is off by 12^3!  This error was caused by entering a weight of 150 lb. per cubic inch instead of 150 lb. per cubic foot.

3) Make sure you understand the “G” factor!

a) When defining mass properties, it is essential to understand the software input units and any internal conversions that might occur. Force units can easily be checked by verifying that the reaction force balances the applied load, i.e. Force = Mass * Acceleration. 

b) A simple one element static analysis test case can be used to verify the input of material properties and acceleration loading by checking that the reaction force satisfies this equilibrium equation. A word of warning though, this static check does not guarantee that subsequent dynamic analyses will be performed correctly.

c) A common error in dynamic analyses is caused by the incorrect definition of mass properties. When using inch-pound-second units, most handbooks provide density in units of lbs-inch^-3 which is the weight density. FEA codes such as ANSYS Mechanical’s Engineering Data provide fields to enter this data as input even though internally, the mass density is actually required to perform the eigenvalue analysis. To manually convert to mass density divide by the acceleration of gravity or “G”. Thus for steel the correct density is .283 lb-in^-3 / 386.4 in-sec^-2 = 7.32e-4 lb-sec^2-in^-4. A check of the actual solution input data in ANSYS’s Workbench DS.DAT file will reveal this internal conversion with the density listed in units of slinch in^-3. Slinch is a English unit of mass equal to 12 slugs (386.088 pounds-mass), that accelerates by 1 inch per second squared (1 in/s²) when a force of one pound-force (lbf) is exerted on it. As a sanity check it is very easy and always best to perform a simple validation model. For example, running a modal analysis and comparing with text book values provides validation of all aspects of the analysis setup including verifying the density units have been specified properly. 

d) Figure 1 illustrates a simple beam test case validated with empirical data from Roark’s Handbook. Excellent correlation is seen with the first fundamental model of vibration. The slight differences in the higher frequencies between the analysis and text book values are caused by fact the FEA model accounts for bending, shear and torsional stiffness while the text book is limited to bending stiffness only.  In this example, the finite element method picks up a torsional mode at 2354 Hz not captured by the simple beam equation. A bending stiffness dominated more slender beam would increase the accuracy of the comparison.

e) Table 2 provides a series of commonly used structural dynamics unit combinations along with the material properties of steel and the corresponding “G” constant that can be used to guide your input.

Figure 1 - Simple Finite Element Modal Analysis of a Cantilever Beam with Comparison to Roark Empirical Formula for Validation

Table 2 - Examples of Consistent Units for Structural Dynamic Analyses including Steel Mass and Stiffness Properties

4) Watch out for temperature units and those BTU’s!

a) Make sure that the temperature units are consistent and, where applicable, absolute units are defined. Fahrenheit and Celsius are applicable for temperature change, but when absolute temperature is required, for example when defining specific heat, make sure that you are using either degrees Rankine or Kelvin.

b) BTU is a traditional unit of heat; it is defined as the amount of heat required to raise the temperature of one pound of water by one degree Fahrenheit.

c) Convection Coefficients are typically provided in literature in units of BTU/ (hour-ft^2-F).  A simulation using a length unit of inches and time unit of seconds thus requires one to divide by 518400 (12^2*60^2) to convert the Convection loads to units of BTU/ (sec-in^2-F).

d) For simulation codes that perform Multiphysics analyses, it is important to assure that the correct work energy units are deployed.  In ANSYS Workbench Mechanical, thermal energy BTU’s will be converted internally into work energy units of inch-pounds during the solution, thus yielding some non-standard material properties with a strange conversion factor (9338 in-lb. = 1 BTU). Figure 2 illustrates a simple steady state heat transfer analysis of a bar listing the external and internal unit systems used by ANSYS.

Figure 2 - Example Illustrating Conversion between Thermal and Work Energy

What unit conversions drive you crazy?  I welcome others to add to my list of Tips & Tricks!