Understanding the UFF File Format

A practical guide to the Universal File Format for engineers working with modal analysis, vibration testing, and structural dynamics data.

If you've ever exported data from a vibration test system, run a modal analysis, or tried to share frequency response data between software packages, chances are you've encountered a .uff file. Despite being one of the most widely used formats in experimental structural dynamics, the Universal File Format remains poorly documented online. Most engineers learn about it through trial and error, passing around tribal knowledge from colleagues or digging through decades-old specification documents.

This guide aims to change that. Whether you're a test engineer encountering UFF files for the first time or someone who has worked with them for years but never fully understood what's inside, this article breaks down the format in plain terms.

What Is the Universal File Format?

The Universal File Format (UFF) is a standardized ASCII text format for exchanging test and analysis data between computer-aided design (CAD), computer-aided test (CAT), and finite element analysis (FEA) software. It was originally developed by the Structural Dynamics Research Corporation (SDRC), which later became part of Siemens through a series of acquisitions (SDRC → EDS → UGS → Siemens PLM).

The format goes by several names and file extensions depending on who you ask. You might see it referred to as Universal File Format, UFF, or UNV (Universal). Common file extensions include .uff, .unv, and .asc. Despite the different names, they all refer to the same underlying format specification.

The core idea behind UFF is simple: provide a vendor-neutral way to move structural dynamics data between different software systems. Before UFF, every test and analysis package used its own proprietary format, making it incredibly painful to share data between, say, a test lab running one acquisition system and an analysis team using different FEA software. UFF solved this by defining a common structure that any compliant software could read and write.

How UFF Files Are Structured

A UFF file is a plain ASCII text file, which means you can open it in any text editor and actually read the contents (though making sense of them is another matter). The file is organized into datasets, where each dataset contains a specific type of information.

Every dataset follows the same basic pattern. It begins with a delimiter line containing -1 (the number negative one, right-justified in columns 1 through 6). The next line contains the dataset number, also right-justified in columns 1 through 6. Then comes the actual data content for that dataset, which varies depending on the dataset type. Finally, another -1 delimiter line marks the end of the dataset.

A single UFF file can contain multiple datasets of different types, stacked one after another. Think of it like a container that holds various kinds of information — geometry, measurement data, metadata — all in one file.

The fixed-field structure of UFF is a relic of its origins in the era of FORTRAN punch cards. Each line is 80 characters wide, and data fields occupy specific column positions. This makes parsing predictable but also means the format is strict about alignment and spacing.

Common Dataset Types

The UFF specification defines dozens of dataset types, each identified by a number. In practice, most engineers encounter only a handful of them regularly. Here are the ones that matter most:

Dataset 15 — Nodes (Coordinate Data). This dataset defines the geometry of your test or analysis model by listing node numbers and their X, Y, Z coordinates. If you ran a modal test with accelerometers at 50 locations, Dataset 15 would describe where each of those measurement points sits in 3D space.

Dataset 55 — Data at Nodes. This dataset stores modal data — specifically, mode shapes expressed as displacement values at each node. When you perform a modal analysis (either experimental or computational) and extract mode shapes, this is typically where that data ends up.

Dataset 58 — Function at Nodal DOF. This is by far the most commonly encountered dataset type. It stores frequency-domain and time-domain measurement data: frequency response functions (FRFs), power spectral densities, time histories, auto-spectra, cross-spectra, and more. If you're exporting data from a vibration test, an impact hammer test, or a shaker test, Dataset 58 is almost certainly what you're working with.

Dataset 58 is complex enough that it deserves additional explanation. Each Dataset 58 block contains a header section (records 1 through 11) followed by the actual data values (record 12). The header carries critical metadata: what the function represents (FRF, time history, PSD, etc.), which node and direction the measurement corresponds to, the response and reference DOF identifiers, and technical parameters like the frequency spacing and number of data points.

Dataset 58b — Binary Function at Nodal DOF. This is a binary variant of Dataset 58 developed to address the limitations of ASCII storage for large datasets. The structure is conceptually the same, but the data is stored in binary rather than text, resulting in smaller files and faster read times. Not all software supports 58b, but it's becoming more common as test datasets grow larger.

Dataset 82 — Trace Lines. This dataset defines how nodes are connected visually — essentially the wireframe drawing of your test structure. It's used for geometry visualization rather than analysis data.

Dataset 151 — Header. This is a file-level metadata dataset containing information about who created the file, when it was created, the model name, and other administrative details.

Dataset 164 — Units. This dataset specifies the unit system used in the file (SI metric, British, or user-defined). This is important because getting units wrong when importing UFF data can lead to results that are off by orders of magnitude — a classic and frustrating mistake.

Datasets 2411–2467 — I-deas Format Geometry. These are an extended set of geometry datasets originally defined for the I-deas software package (another SDRC product). Dataset 2411 defines nodes, 2412 defines elements, 2414 stores analysis data results, 2420 defines coordinate systems, and 2429/2467 define groups. You'll encounter these when working with data from I-deas or software that adopted the I-deas conventions.

ASCII vs. Binary UFF

The original UFF specification was entirely ASCII-based. Every number, every header field, every data point is written as human-readable text in fixed-width columns. This has clear advantages: the files are portable, you can inspect them with a text editor, and there are no byte-ordering or platform-compatibility issues.

The downside is size and speed. A vibration test that captures millions of data points produces enormous ASCII files, and parsing all that text is slow. This led to the development of binary UFF (notably Dataset 58b), which stores the same metadata headers in ASCII but writes the data values in binary. The result is files that are significantly smaller and much faster to read, at the cost of no longer being fully human-readable.

When choosing between ASCII and binary UFF, the tradeoff comes down to your workflow. ASCII is better for archival, debugging, and interoperability with older systems. Binary is better when you're dealing with large datasets and need performance.

Where UFF Files Come From

In practice, UFF files are generated by a wide range of test and analysis systems. Common sources include Siemens Simcenter Testlab (formerly LMS Test.Lab), Brüel & Kjær PULSE, Dewesoft, m+p international, and various other data acquisition and modal analysis packages. On the FEA side, tools like Simcenter Nastran, ANSYS, and Abaqus can export results in UFF format.

Many engineers inherit UFF files from legacy test campaigns — sometimes decades old — and need to extract the data for reanalysis, reporting, or comparison with new test results. The format's longevity is both a strength (your old data is still readable) and a challenge (you need tools that understand the format's quirks).

Working with UFF Files in Practice

Opening a UFF file in a text editor is educational but not practical for actual work. The fixed-width ASCII format makes it tedious to extract specific measurements, and the sheer size of many UFF files makes manual inspection impractical.

There are several approaches engineers commonly use to work with UFF data.

(For a full method-by-method comparison with pros, cons, and workflow recommendations, see our companion guide on how to convert UFF files to Excel.)

Specialized test and analysis software like Simcenter Testlab, ME'scope, or ARTeMIS Modal can import UFF files natively. This is the most feature-complete option, but these are expensive, specialized tools — and sometimes you just need to get data into a spreadsheet.

Python scripting is a popular option in the engineering community. Libraries exist for reading UFF files programmatically, but they require coding knowledge, can struggle with edge cases in the format, and don't handle binary 58b files universally.

MATLAB has similar capabilities through community-contributed functions, with the same limitations around edge cases and binary formats.

Dedicated converter tools offer a middle ground: they handle the parsing complexity for you and output data in universally accessible formats like Excel or CSV. This is the approach we took when building UFF Converter Pro, which reads both ASCII and binary UFF files and exports them to Excel (with optional Bode and Nyquist charts) or CSV for use in any analysis tool. We built it specifically because we saw how much time engineers waste wrestling with UFF parsing scripts.

Common Pitfalls

Working with UFF files long enough, you'll inevitably run into a few recurring issues.

Unit mismatches are the most dangerous. If a UFF file was created in one unit system and imported assuming another, your FRF magnitudes, frequencies, or mode shapes will be wrong — and often by an amount that's plausible enough to not immediately look like an error. Always check Dataset 164 (Units) when it's present, and verify units independently when it's not.

Truncated or malformed files happen more often than you'd expect, especially with files that have been transferred between systems, emailed, or extracted from old archives. A missing delimiter line or a field that's shifted by one column can cause entire datasets to fail to parse.

Mixed dataset types can be confusing if you're not expecting them. A single UFF file might contain geometry (Dataset 15), mode shapes (Dataset 55), and FRFs (Dataset 58) all together. Some importing tools only look for specific dataset types and silently ignore the rest.

Large file handling is a practical concern. ASCII UFF files from modern high-channel-count test campaigns can easily reach gigabytes. Not all tools handle this gracefully — memory limits, slow processing, or outright crashes are common with very large files.

The Future of UFF

The UFF format has been around for decades and remains the lingua franca of structural dynamics data exchange. While newer formats like ASAM ODS and HDF5 are gaining traction in some communities, UFF's installed base is enormous. Millions of archived test files exist in UFF format, and major software packages continue to support it.

The format isn't going away anytime soon, but the trend is clearly toward binary variants for new data (addressing the size/speed limitations of ASCII) and toward easier-to-use conversion tools for getting legacy data into modern analysis workflows.

Summary

The Universal File Format is deceptively simple in concept — an ASCII text file organized into numbered datasets — but understanding its structure and quirks is essential for anyone working in vibration testing, modal analysis, or structural dynamics. The key dataset types to know are 58 (measurement data), 15 (nodes), 55 (mode shapes), and 151/164 (metadata and units). Be vigilant about unit systems, be prepared for format inconsistencies in real-world files, and invest in reliable parsing tools rather than trying to read these files by hand.

If you're working with UFF files and need to get the data into Excel or CSV for analysis, reporting, or sharing with colleagues, take a look at UFF Converter Pro — we built it to handle exactly this problem, including the tricky binary 58b format and files with millions of rows.