4. Coordinate systems and units

When results from multiple solvers are harmonized, the two most common sources of silent error are not mesh quality or solver convergence — they are coordinate system mismatches and unit inconsistencies. A displacement field that looks plausible in a contour plot can be wrong by a factor of 1000 if one solver exported meters and another exported millimeters. Likewise, a stress tensor rotated into the wrong reference frame will produce principal stresses that appear physically reasonable but are assigned to the wrong material directions. This section covers how to detect the coordinate and unit conventions used by each solver output, how to convert them into a common reference, and how to verify consistency before any comparison is trusted.

Why Coordinate and Unit Metadata Is Frequently Lost

Most solvers write results in formats such as .rst (ANSYS), .odb (Abaqus), .op2 (Nastran), .unv, .vtk, or neutral formats like .csv and .json. The problem is that the coordinate system definition and unit system are often stored in solver-specific headers, in separate documentation, or not at all. A .csv export of nodal displacements typically contains only numbers. The analyst must therefore detect the convention from context, convert it explicitly, and check that the conversion is correct.

Three distinct coordinate concepts must be separated:

• Global coordinate system (GCS): the assembly-level frame in which node coordinates are defined.
• Local coordinate systems (LCS): element, material, or result-specific frames (e.g., cylindrical for a pressure vessel, or a material frame for orthotropic composites).
• Result component frame: the frame in which tensor or vector components are reported — this may differ from the GCS even when node coordinates are global.

Units add a second layer: length, force, mass, time, temperature, and angle units must all be consistent. A solver using mm–N–MPa–t and another using m–N–Pa–kg will produce numerically different but physically identical results. Without explicit conversion, comparison is meaningless.

Detection: Reading the Convention from the Output

Detection begins with the file header and metadata. For example, an Abaqus .odb accessed through the Python API exposes odb.userUnits and the assembly coordinate system. A Nastran .op2 file carries the CSID (coordinate system ID) per result block. A VTK file may carry VECTORS and TENSORS arrays whose component order and frame are defined by the writer.

When metadata is absent, detection relies on physical reasoning. Consider a cantilever beam of length 1.0 m with a tip load of 100 N. If the exported tip deflection is 2.5e-3, the length unit is almost certainly meters. If it is 2.5, the length unit is likely millimeters. This kind of sanity check is not a substitute for explicit metadata, but it is a reliable fallback.

For coordinate systems, the most common detection method is to inspect the node coordinates of a known feature. If a hole center is expected at (0.05, 0.0, 0.0) in the global frame but appears at (0.05, 0.0, 0.0) in a cylindrical frame with axis along Z, the radial coordinate is 0.05 and the angular coordinate is 0. The same physical point has different coordinate triples. Comparing raw coordinate arrays without accounting for this will produce false mismatches.

Conversion: Building a Common Reference Frame

Conversion between coordinate systems is a rigid-body transformation. For a point p expressed in a local frame with origin O and orthonormal basis vectors e1, e2, e3, the global coordinates are:

p_global = O + [e1 e2 e3] * p_local

For tensor results such as stress or strain, the transformation is a similarity transform:

sigma_global = R * sigma_local * R^T

where R is the rotation matrix whose columns are the local basis vectors expressed in the global frame. For vector results such as displacement or velocity, the transformation is simply v_global = R * v_local.

Unit conversion is a scalar multiplication applied after the coordinate transformation. A consistent conversion pipeline is:

1. Read the raw result and its declared or detected coordinate frame and unit system.
2. Transform coordinates and tensor/vector components into the common global frame.
3. Apply unit scale factors to length, force, stress, and any derived quantities.
4. Write the harmonized result with explicit metadata recording the frame and units.

For example, converting a stress tensor from MPa to Pa requires multiplying all six components by 1e6. Converting a displacement from mm to m requires multiplying by 1e-3. If the coordinate transformation and unit conversion are applied in the wrong order, the result is still wrong — order matters only when the transformation matrix itself has units, which is rare but possible in scaled coordinate systems.

Consistency Checks Before Comparison

After conversion, three checks should be performed before any solver-to-solver comparison:

A useful quantitative check is to compute the norm of the difference between two converted result fields at matching nodes. If the norm is large but the fields are visually similar, the likely cause is a unit or frame mismatch. If the norm is small but the fields look different, the likely cause is a sign convention or node-ordering issue.

Worked Example: Harmonizing Two Solver Outputs

Suppose Solver A exports nodal displacements in mm in a global Cartesian frame, and Solver B exports the same field in m in a cylindrical frame with axis along Z. The common frame is global Cartesian in meters.

For a node at global position (0.1, 0.0, 0.0) m, Solver B reports (r, theta, z) = (0.1, 0, 0) m. The conversion to global Cartesian is x = r cos(theta) = 0.1, y = r sin(theta) = 0.0, z = 0.0. Solver A reports (100, 0, 0) mm, which converts to (0.1, 0.0, 0.0) m. The two are consistent.

If instead Solver A reported (100, 0, 0) and Solver B reported (0.1, 0, 0) but the analyst forgot to convert Solver A from mm to m, the difference would be 99.9 m — a factor of 1000 error that would be immediately visible in a contour plot but could be missed in a tabular comparison if the analyst only checks relative differences.

Practical Checklist for Cross-Solver Harmonization

The following checklist can be applied to any pair of solver outputs before comparison:

• Confirm the coordinate frame of node coordinates and result components for each solver.
• Confirm the unit system for length, force, stress, time, and temperature.
• Identify any local coordinate systems used for material or element results.
• Transform all results into a single declared global frame.
• Apply unit scale factors to all quantities, including derived ones.
• Verify sign conventions for shear stresses, normal vectors, and tensor components.
• Compare probe-node values after conversion; investigate any difference exceeding a tolerance such as 1e-6 relative.
• Record the final frame and unit metadata alongside the harmonized dataset.

When these steps are followed, the remaining differences between solvers reflect genuine modeling or numerical differences rather than bookkeeping errors. That is the precondition for any meaningful comparison of multi-solver CAE results.