Open Data Formats in Commercial FEA Software

This paper was produced for the 2019 NAFEMS World Congress in Quebec Canada

Resource Abstract

Over the years, commercial finite element software has generally provided an open system that allows users to integrate unique requirements or downstream processes with their FEA software and files. Examples include user subroutines to define nonstandard material behavior (constitutive models), element libraries, environmental conditions (loads or boundary conditions), and integration to third party applications (for co-simulation). These are generally done with industry standard tools (FORTRAN, C, C++, FMI, and OpenFSI).



One area that has not been addressed is the interface to results. Output from commercial FEA programs is typically provided in two formats: 1) ASCII text formatted for printing and 2) a binary results file. Binary files have advantages over text files: smaller size and faster access. However, most also use a proprietary (and unique) format and structure. As a result, accessing data in these files requires the vendor’s proprietary API, and it can be difficult for the “typical user” to work with them.



For these reasons, many customers create programs or scripts to extract data from the text output file. While text parsers are easier to code and verify, this method has downsides in regards to maintenance and performance.



By comparison, noncommercial FEA software has leveraged open systems for at least two decades. For example, Sandia Labs’s SEACUS system uses the Exodus II database across all of its solvers, and is built on netCDF and HDF.



For all of the reasons above, users gain meaningful benefits when FEA vendors implement open data systems.



One open system to store very large datasets is HDF5 from the HDF Group. It is much easier for the “typical user” to work with results in an HDF5 file. First, the data can be view without writing any software. When custom software is required, the HDF5 API has several advantages: 1) it is a general purpose interface (not vendor specific), 2) a wide variety of languages are supported, and 3) it is not dependent on FEA vendor maintenance (the vendor simply documents the data schema).



One example of a HDF5 implementation in commercial FEA software was done by MSC Software. This paper presents details regarding that implementation for 3 FEA products: MSC Nastran, Patran and MSC Apex. It covers motivation, user benefits, and deployment details. In addition, examples of customization use cases are presented.