# Consistent Unit Systems

I thought I’d share a cautionary tale and one of my deepest desires for Flex / Crunch. As you are probably aware, dimensions in Crunch are unitless. Thus it is 100% on the user to make sure they’re using a consistent unit system. In my experience, this is one of the most common sources of mistakes – especially in new hires who are unfamiliar with the unitless concept. I have made inconsistent unit system mistakes more times than I wish to admit, and especially in my tenderfoot days I used weight/volume enough times that I’m surprised I’m still gainfully employed.

This can be especially confusing as four of the common unit systems are

• CGS (metric)
• centimeter - gram - second
• length - mass - time
• MMTS (metric)
• milimeter - tonne (1000 kg) - second
• length - mass - time
• IPS (Imperial)
• inch - pound - second
• length - force - time
• FPS (Imperial)
• foot - pound - second
• length - force - time

Notice anything?

A big source of confusion is that you will almost always see densities given in mass/volume in metric systems and weight/volume in Imperial systems. For instance, MatWeb shows the following for SS-304L.

The metric value is already in CGS units and it’s straightforward to convert to MMTS or SI consistent unit systems. However, the English value is not in a consistent unit system. That value tells us how much a cubic inch of the material weighs on earth. You might recall that the slug is the unit mass in the Imperial system - the functional equivalent of the SI kg. However in the IPS system we actually need to use the slug-inch (aka slug or blob). Below I’ve attached a PDF I made for last fall’s “Intro to Linear Finite Elements” (CE En 507) course. Other than the first paragraph, it’s a verbatim copy of an appendix from Sandia’s Sierra User Manual (which can be found here).

You’ll note in the final paragraph that they state:

The weight per unit volume should be divided by the gravitational constant (386.4 in/s2 in this case) to obtain a mass per unit volume.

Of course, by “gravitational constant” they mean “gravitational acceleration on Earth” not the gravitational constant G. Also, you’ll find various values for this constant such as 386.0886 on Wikipedia.

This sort of leads into a feature I’d like to see in Flex / Crunch, which I’ve discussed with many of you. I’d like to see a built in unit system manager that allows entry of units (and their dimensionality) as received by the customer, as gathered from the web, or however else I wish to enter them. Then Crunch would convert them to a consistent unit system internally. Additionally, the user could request output to be in a certain unit and Crunch would embed the units in the outputs (to simplify post-processing for example).

In conclusion - be careful with units especially English units (I’m sure as a proud Frenchman, @florian would agree with this statement.)

1 Like

Greg that is why I ALWAYS ALWAYS run in metric (meters, second). There is only one exception to this rule that I know of and that is if you are doing things at a very small scale, at which point you do cm, or mm. I have never encountered a good reason to run a simulation in IPS or FPS.

Oh I agree, I do as much work in metric as possible: SI, CGS, MMTS as the situation requires. The challenge that I then impose on myself is when we have model reviews with the customer or internal peer-reviews. The customers especially work in Imperial units and I’m almost always given things in terms of inches, psi, BTU, lb, Fahrenheit etc. Additionally, the customers I work with have some requirement specified by the design agency, say: “<0.5 inch deflection at 50 lbf”. If I’ve converted to a CGS system, then my results in Abaqus come back in cm and dynes. So then I have to do extra steps to convert the results back into IPS for reporting to the customer. All told, this introduces two spots for potential errors: initial conversion into CGS, final conversion to customer’s units.

Also, sometimes we dredge up old simulations to rerun on a newer design. If there are no comments telling us what units where used, it becomes a bit of an effort. Also, old results files don’t tell you what units were used, so once again you have to do a bit of sleuthing to back out what unit system they were using.

Just make an algebra script that converts your exodus file and run it after the run. It makes the last step trivial. All my models are a in Pa and meshes always have units in the name. Thats just me.