NAFEMS Americas and Digital Engineering (DE) teamed up (once again) to present CAASE, the (now Virtual) Conference on Advancing Analysis & Simulation in Engineering, on June 16-18, 2020!

CAASE20 brought together the leading visionaries, developers, and practitioners of CAE-related technologies in an open forum, unlike any other, to share experiences, discuss relevant trends, discover common themes, and explore future issues, including:
-What is the future for engineering analysis and simulation?
-Where will it lead us in the next decade?
-How can designers and engineers realize its full potential?
What are the business, technological, and human enablers that will take past successful developments to new levels in the next ten years?

Resource Abstract

In general, commercial finite element software provides custom methods that allows users to support unique requirements with their FEA software and files. Examples include user subroutines to define nonstandard material behavior (constitutive models), element libraries, environmental conditions (loads/bcs), and integration of FEA results to downstream processes or 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 results data and the associated interface. 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 two primary advantages over text files: smaller size and faster access. However, most binary files also use a proprietary format and interface. Accessing data in these files requires knowledge of the vendor’s proprietary API. As a result, it can be difficult for the “typical user” to work with them. For these reasons, many customers often write 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 complexity, 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 providers 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 4 FEA products: MSC Nastran, Patran, MSC Apex and Marc. It will cover motivation, user benefits, and deployment details. In addition, examples of customization use cases will be presented.