Unit Systems

OptiStruct runs are typically unit agnostic, that is, you do not need to explicitly specify the unit system in which the model is defined. Instead, units are incorporated indirectly within the model, for instance, using the material data and associating it with the model dimensions.

Generally, you should specify input data based on a consistent units system for an OptiStruct run. Refer to Consistent System of Units for more information.

In certain conditions, it may be necessary to explicitly specify the unit systems for the run. A few such instances are:

Multibody Component Mode Synthesis (CMSMETH with CC or CB flex body generation)
When CMS flex body generation is used to output a flexible body to be used subsequently in a different solver, like MotionSolve, then it is important to identify the units associated with the flex body. This can be done using the DTI,UNITS Bulk Data Entry or the equivalent UNITS I/O Entry.
Flexbody generation for MotionSolve
The units in which the Generation run model has been defined should be mentioned on the DTI,UNITS entry. The CMS flexbody (CC and CB options on CMSMETH Bulk Data Entry) can be output in H3D format.
The Flexbody in H3D format is always generated in the units of Kilogram, Newton, millimeter, second. Units for the flex H3D output are always fixed and if you identify the model as having units different from this on DTI,UNITS entry, then OptiStruct converts the output units from the units mentioned on DTI,UNITS to Kg,N,mm,s when generating the flex h3d file.
MotionSolve will always expect the flex h3d file to be generated with the Kg,N,mm,s units set.
Note: This unit set is not a consistent set of units.
If you specify a different set of units for the multibody model inside MotionSolve, then MotionSolve will convert the flex body h3d from Kg,N,mm,s to the user-defined units for the multibody run.
When requesting OP2 output while generating the CMS Flexible body, the output OP2 file does not have any unit conversion and is written in the same units as the Generation run model, regardless of whether the generation run model has consistent units or not. This can lead to a difference in values of both the frequency and eigenvector when comparing the H3D flexible body and the OP2 output.
Regardless of which method (CC or CB) is used, in the final step the orthogonal modes are generated and then these modes are normalized. The Orthogonal modes $A_{o r t}$ $A_{o r t}$ are normalized with respect to the mass matrix $M$ $M$ , therefore the final reduced matrices appear as:

$K_{r e d u c e d}^{f i n a l} = A_{o r t}^{T} {KA}_{o r t} = λ I$ $K_{r e d u c e d}^{f i n a l} = A_{o r t}^{T} {KA}_{o r t} = λ I$

$M_{r e d u c e d}^{f i n a l} = A_{o r t}^{T} {MA}_{o r t} = I$ $M_{r e d u c e d}^{f i n a l} = A_{o r t}^{T} {MA}_{o r t} = I$

The orthonormalized modes are input to other multi-body dynamics solvers (like MotionSolve), as modal representations of the flexible body in the subsequent analysis.
Note: OptiStruct is generally unit-agnostic, and the purpose of DTI,UNITS entry in the context of flexible body generation (CC or CB CMSMETH) is only to let the flex H3D generator know the units of the OptiStruct input file. The flex H3D is always written in the units of KG,N,MM,S.
Based on this information, the flex H3D file is written out after appropriate scaling, as required. There are certain conversions which can occur when the flexible H3D superelement is generated.
1. Scaling applied to the Eigenvalues and Eigenvectors in flex H3D due to inconsistent units:
  If the units specified on DTI,UNITS entry in OptiStruct is a set of inconsistent units, there is some scaling applied to both Eigenvalues and Eigenvectors in the flex H3D to account for the inconsistency in the units.
  Even though the flex H3D file is always in KG,N,MM,S, it is still an inconsistent set of units. For instance, even if KG,N,MM,S are the units specified on DTI,UNITS, which matches with the units in which the flex H3D file, the following scaling is applied as it is an inconsistent set of units (for example, instead of 1 MM, it is switched to 1 M (or 1000 MM), meaning the reduced stiffness matrix equation is multiplied by 1000 on both sides):
  
  $[s q r t (1000) A_{o r t}^{T}] K [(s q r t (1000)) A_{o r t}] = 1000 * λ$ $[s q r t (1000) A_{o r t}^{T}] K [(s q r t (1000)) A_{o r t}] = 1000 * λ$
  
  Therefore, a scaling of $\sqrt{1000} = 31.6$ $\sqrt{1000} = 31.6$ is applied to the eigenvectors and a scaling of 1000 is applied to the eigenvalues.
  As part of this conversion, as eigenvalues are scaled, the corresponding frequency is scaled by:
  $f_{s c a l e d} = \frac{\sqrt{(1000 * λ)}}{2 π} = \sqrt{1000} \frac{\sqrt{λ}}{2 π} = \sqrt{1000} f = 31.6 f$ $f_{s c a l e d} = \frac{\sqrt{(1000 * λ)}}{2 π} = \sqrt{1000} \frac{\sqrt{λ}}{2 π} = \sqrt{1000} f = 31.6 f$
  This scaling is illustrated in Figure 1 1(b) below, when comparing the flex H3D with the OP2 file. For mode 7, the maximum value of the eigenvector is scaled as 1.016*sqrt(1000) = 1.016*31.6 = 32.13, and the frequency is scaled as 77.72*sqrt(1000) = 77.72*31.6 = 2457.59 Hz.
2. Scaling applied to the Eigenvectors in flex H3D due to mismatch of units between DTI,UNITS and default Flex H3D units of KG,N,MM,S:
  If the units specified on DTI,UNITS entry in OptiStruct (even if it is a consistent set) is different from the default flex H3D units of KG,N,MM,S, scaling is applied to Eigenvectors in the flex H3D to account for the mismatch in the units. For instance, even if KG,N,M,S are the units specified on DTI,UNITS, which is a consistent set of units, it does not match with the units in which the flex H3D file is written out (KG,N,MM,S). In this situation, the following scaling is applied:
  $[s q r t (1000) A_{o r t}^{T}] \frac{K}{1000} [(s q r t (1000)) A_{o r t}] = λ$ $[s q r t (1000) A_{o r t}^{T}] \frac{K}{1000} [(s q r t (1000)) A_{o r t}] = λ$
  Therefore, a scaling of $\sqrt{1000} = 31.6$ $\sqrt{1000} = 31.6$ is applied to the eigenvectors and no scaling is applied to the eigenvalues.
  This scaling is illustrated in Figure 1 1(c) below, when comparing the flex H3D with the OP2 file. For mode 7, the maximum value of the eigenvector is scaled as 1.016*sqrt(1000) = 1.016*31.6 = 32.13, and the frequency is not scaled and remains the same.
3. Visualization scaling for Flex H3D:
  Regardless of the units specified on the DTI,UNITS entry, by default, a scaling is always applied to the flex H3D file purely for visualization purposes (this is to make sure that the deformation of each mode is reasonably visible regardless of model units when the flex H3D file is imported into a post-processor like HyperView for visualization). This is purely for visualization purposes and does not affect the subsequent solution in multi-body dynamics analyses (such as in MotionSolve). The scaling is calculated as the ratio of the maximum deformation of each mode and the physical size of the model. This scaling cannot be turned off or controlled. This scaling is illustrated in Figure 1 1(a) below. Due to additional scaling on the maximum value of the eigenvector, the value changes from 32.13 to 59.73.
  
  Figure 1.
Fatigue Analysis
Fatigue analysis in OptiStruct uses the stress results coming from a preceding analysis run (for instance, Linear Static), to perform some fatigue calculations and output corresponding Fatigue Life and Damage results. There are multiple sections within the Fatigue module which requires explicit understanding of the unit system of the model:

STRESSU on FATPARM

Identifies the units of the stress tensor coming from the preceding FE analysis. This is necessary because the SN/EN curve (on FATPARM entry) may be defined in a different unit system compared to the stress coming from analysis. Therefore, the stress should be converted prior to looking up the fatigue life for a given stress level on the SN curve. If UNITS or DTI,UNITS is present, the default value of STRESSU is determined by UNITS or DTI,UNITS entry (UNITS takes precedence over DTI,UNITS). If UNITS, DTI,UNITS, and STRESSU are not provided, the default value of STRESSU is MPa. If UNITS or DTI,UNITS is present, and STRESSU is specified, but they are not consistent, then an error will be issued.

UNIT on MATFAT

Identifies the units of stress values defined on the Yield Strength (YS), Ultimate Tensile Strength (UTS), SRI1, Fatigue Limit (FL), Sf, and Kp fields on the MATFAT entry.

LENUNIT on FATPARM

This is applicable to the stress gradient effect for the GRDFKM method.

This informs the fatigue module what units the model is in and based on this, it will be able to calculated the stress gradient effect for the GRDFKM method by locating the 1 mm depth necessary for the calculations.

LENUNIT on MATFAT

This is applicable to the GRDCD method.

This informs the fatigue module the units in which the critical distance value defined on the CRTDIS field is input.

LENUNIT is based on the Stress units on FATPARM by default. If the model has MPa units for Stress, then the model is in units of mm.
Aeroelastic Trim Analysis
Accelerations are specified by default in units of gravity (g’s) on the TRIM Bulk Data Entry. These can be converted into other units (for instance, m/s²) using the PARAM, AUNITS entry.
Sound Pressure
For sound pressure level (SPL) calculations in Decibels, the reference sound pressure value is defined via the PARAM, SPLREFDB entry. The units of the reference sound pressure is specified on the UNITS I/O Options Entry.
Radiation Heat Transfer Temperature
The units of temperature for Radiation Heat Transfer is assumed to be Kelvin, and based on this default, the value of PARAM, SIGMA can be set equal to the SI unit value of the Stefan-Boltzmann constant.
Since input temperatures and SIGMA should be defined in consistent units, the PARAM, TABS can be used if the input temperatures are in Celsius or in Fahrenheit.
SIMPACK flex body generation
Similar to the discussion regarding flex body generation for MotionSolve, the DTI,UNITS entry can be used to specify the units during the creation of the SIMPACK flex body via PARAM, SIMPACK.
Aeroelastic Flutter Analysis
The velocities in Aeroelastic Flutter Analysis are divided by the value specified on PARAM, VREF. This can be used to convert the velocity units.