Flexcom > Theory > Fundamentals > Units Systems

Overview

Since Flexcom 8.4, it is possible to specify explicitly that a keyword file is in either the Standard Metric or Standard Imperial unit system. This is done by naming the file with the .KEYXM (Metric) or .KEYXI (Imperial) extension, as required.

There are several benefits to doing this. Because the program now knows with certainty what your inputs are, it can report units across the program with confidence and allow you to work with non-standards units in an entirely new and extremely flexible way.

One of the consequences of starting to work with explicit units is that you must have consistency along your restart chain. For example, if your initial static file is .KEYXM (Metric), then all subsequent restarts from this analysis must also be .KEYXM.

Base Units

By default, all entries in the keyword file, when entered numerically, are still in unscaled base or derived units. This means that you don’t have try to remember if diameter is specified in millimetres, centimetres or meters. If it’s a length, it’s meters. This also means, if your existing files employ user-based units, but conform to either the Standard Metric or Standard Imperial system, only a name-change is required to convert them.

To illustrate, consider this geometric properties specification from a Metric file:

*GEOMETRIC SETS
OPTION=FLEXIBLE
SET=mat_Production
114000, 114000, 1.3e+007, 1.8e+009, 171, 1, 0.254, 0.3456, 0,3456, 0

Convenient Units

What however if you have a keyword file, and you’d like to specify diameter in millimetres? That’s easily done. A new syntax has been developed, which works equally in the keyword editor or in the table view. Here’s an equivalent specification where EA is specified in Meganewtons and all diameters are specified in millimetres:

*GEOMETRIC SETS
OPTION=FLEXIBLE
SET=mat_Production
114000, 114000, 1.3e+007, <1800MN>, 171, 1, <254mm>, <345.6mm>, <345.6mm>, 0

You can see how the <value-unit suffix> syntax can be used to specify a different unit to that expected. This system is highly flexible and understands most commonly used units.

Unit Suffixes

When it comes to suffix, the system accepts a very wide range of variation, so you should be able to type values in naturally without worrying about what the program wants. Variations such as plurals, spacing and even alternative spellings (meter/metre) are accommodated.

For examples of this, take a look at this equally valid specification:

*GEOMETRIC SETS
OPTION=FLEXIBLE
SET=mat_Production
114000, 114000, 1.3e+007, <1800 MN>, 171, 1, <254mm>, <345.6millimetre>, <345.6millimeters>, 0

You need not worry about making a mistake. If you type in something which the software does not recognise, the relevant input will be highlighted, and you will receive a warning message in the Keyword Syntax Issues window.

Unit_Suffixes

Mixing Unit Systems

The more eagle-eyed reader may have noticed that the first diameter specification looks like it has been converted from an imperial value (254mm = 10inches), and indeed it is. Here is where the system becomes even more useful. You can use Imperial units in a Metric file and vice versa. Here is the example specification again:

*GEOMETRIC SETS
OPTION=FLEXIBLE
SET=mat_Production
114000, 114000, 1.3e+007, <1800 MN>, 171, 1, <10">, <13.6in>, <13.6inch>, 0

Now all diameters have been specified directly in inches. Furthermore they’ve been specified with three equally valid suffixes to further emphasise the system’s flexibility.

Being able to enter values exactly as you’ve received them eliminates a potential source of error in your model, especially when a conversion between unit systems was previously required.

Parameters and Equations

Some consideration needs to be given to the use of parameters and equations in a file with explicit units. Numerical parameters defined using the *PARAMETERS keyword do not have any units associated with them, and you should be mindful of this when using them later in the file.

Let’s consider an example where the inner diameter, intended to be in inches, is specified as a parameter

*PARAMETERS
Di, <10in>

In this case, the value <10in> is recognised as a length and automatically converted to the appropriate base unit of length, metres in this instance. So the value of Di is 0.254.

If we are to use that value directly in the *GEOMETRIC SETS keyword thus:

*GEOMETRIC SETS
OPTION=FLEXIBLE
SET=mat_Production
114000, 114000, 1.3e+007, 1.8e+009, 171, 1, =[Di], 0.3456, 0,3456, 0

This will be correct, because the program will consider this the same as typing the value 0.254 directly into that keyword.

However if we were using this value to set something else, such as the name of the analysis:

*NAME

=["Analysis " + Do + " inch Pipe"]

That would resolve to “Analysis 0.254 inch Pipe” which is not what is intended, so you must be mindful of this.

An alternative approach, equally valid, is to specify 10 as a number, with no units:

*PARAMETERS
Di, 10

And then specify the conversion at the point of use:

*GEOMETRIC SETS
OPTION=FLEXIBLE
SET=mat_Production
114000, 114000, 1.3e+007, 1.8e+009, 171, 1, <=[Di]in>, 0.3456, 0,3456, 0

If we took this approach then, the analysis name would also be constructed correctly:

*NAME

=["Analysis " + Do + " inch Pipe"]

That would resolve to “Analysis 10 inch Pipe” which is consistent with requirements.

In theory both approaches are valid. However the first approach is strongly recommended. Where the relevant units are identified at source, any potential for error in subsequent data specification is greatly reduced (in the second approach, you have to remember to insert the correct units every time the parameter is referenced). Further information is also provided in Adding Units to Parameters.

Generic Unit Conversions

All of the examples considered up to this point are intrinsic conversions, where Flexcom automatically converts a user-defined value into the base units for that parameter type in the relevant standard unit system. For example, if you are using a metric file, then <1kN> is automatically converted to 1000N. Similarly, <1kip> would be automatically converted to 4448.2N.

For complete flexibility, Flexcom also provides a Generic Conversion Function which allows you to convert a user-defined value into any other acceptable unit type for that parameter, which need not necessarily correspond to the base unit for that parameter. For example, you could convert a value from kN to kips, as follows:

$PREPROCESSOR

*PARAMETERS

Tension, =[convert(1,"kN","kips")]

Postprocessing

Another very useful feature is the ability to postprocess results into any desired units, regardless of the unit system used for the actual analysis. For example, if a system was modelled by an engineer in the US using imperial units, a colleague in the UK can still take those results and examine tension in Kilonewtons and stress in Megapascals.

For illustrative purposes, the keywords shown below are used to request two snapshot plots of effective tension, the first in Kilonewtons (kN) and the second in Kilo Pounds Force (kips).

$DATABASE POSTPROCESSING

*SNAPSHOT

TYPE=FORCE, SET=All

7, 1, 1.0, , UNITS=kN

TITLE=Effective Tension (kN)