Consistent Units

Units are, in my honest opinion, one of the most fundamental aspects of modelling in FEA and the understanding of such is critical to the success of any simulation engineer. If the units aren’t correct, then there’s almost zero value to the simulation. As such, I always ensure every attendee has understood this concept when I am delivering the Introduction to Abaqus training course and will not progress until each attendee has confirmed that they understand. Even as a seasoned simulation engineer I will occasionally look up a consistent unit table myself to check my working.

In this post I will go into more depth about the subject, provide my own consistent unit table and share the main piece of advice I give to all attendees of our training courses.

Units of measurement

Units of measurement are a critical aspect to all engineering disciplines, simulation or otherwise. Units convey information and give context to measured values. Without units, it would be impossible to design, test, build or evaluate any engineering component. In other words, they’re not something that can be ignored.

Units of measurement come in several different forms and can be grouped together in a system of units. The popularity of these system of units have changed throughout history, but the two main systems in use today are the International System of Units (referred to as SI units, or the metric system) and Imperial or US customary units (Imperial and US customary actually differ, but only in volume).

As there is widespread use of more than one system of units you may find yourself in a situation where data may be provided using a different system to what you’re familiar with. Even within a single system, differing prefixes means that there’s potentially still confusion. To further confuse matters there’s also non-standard units of measurement that have widespread use – for example medical devices manufacturers may use mmHg for pressure in place of Pa or MPa.

Abaqus has no units

In addition to the above complication, Abaqus does not have any unit convention, nor can you tell it what units to use. That is to say, you cannot specify anywhere in the interface what the units are for the values you’ve supplied. The solution to Abaqus’ lack of units is to use consistent units. This means that all parameters defined by the user (and reported by Abaqus) are of the same system of units and derived from the same set of base units.

However, be warned that Abaqus does not have any internal checking process to determine whether your units are consistent. Nor is there any warning message highlighting if there’s an unusual contrast in magnitudes between defined data. So if the information is poorly defined, then the model will be wrong before it even gets to the solver.

Consistent units

The table below outlines the consistent units for the four main systems of units in use today. Each set is derived from four base units; length, mass, time and temperature. We’re yet to see widespread use of a decimal time, so seconds are uniform across all unit systems and units of temperature are consistent within the metric/imperial systems. Therefore, the main drivers for the difference in derived units, between each system, are the base units for length and mass. Each system is typically defined by the length unit, whether millimetres, meters, inches or feet. For example, a system using millimetres as the base unit is referred to as SI (mm), and inches as US Unit (in).

For simplicity I’ve stuck to base-units for specific heat/conductivity etc. in the below table. I acknowledge that in America it is common to report thermal energy as British thermal units (BTU) however, mixing simulation and BTU’s adds a level of complexity which is best to be avoided.

My advice

The main piece of advice I give when teaching this concept to new users is to use a single unit set for every simulation, especially to begin with when you’re still learning.

This way you get a ballpark feel for what the values should be. For example, I typically work in SI (mm) however I appreciate that defining densities in tonne/mm3 isn’t exactly intuitive. Yet through experience, I know that the density of a metal is typically of the order 10-9, so if my converted value isn’t close I can immediately tell something is off. On the other hand, if I were to define a density in slug/ft3 I could be several orders of magnitude out without knowing it.

A common pushback to this advice may be that you have a customer which works in a non-preferred unit set and you need to present data in a format they will understand. This is easily solved in Abaqus as it’s possible to scale the results values to convert from one unit set to another, and a quick google will provide the appropriate scale factor. 

In summary

It is the responsibility of the user to check that all data defined within Abaqus is correct. Having a colleague double-check your inputs can be helpful, but ultimately, you’re on your own. So some knowledge on units and a robust method for verifying outputs, even at a very basic level, is essential. The concept may feel daunting at first, but I’ve found that - with experience - it will become second nature.