The C++ wrapper helps the EikoTwin software to automatically correlate ABAQUS simulation data with measured data.

Do you want to automatically execute the correlation between Abaqus simulation models and measurements? Do you want to achieve this by developing a Python script, using the C++ API, or by developing a parser for our software? To implement this functionality, we conducted extensive experiments on the read and write formats of the data that need to be correlated when developing the parser, such as displacement fields or deformation field data, strain gauge or load cell measurement results. Next, we will describe specific cases to understand the advantages of our parser in correlating Abaqus simulation models with measurements.

First, let's discuss the research requirements.

Unlike many researchers, our interaction with Abaqus is not through the CAE interface, but directly using the command line solver with INP files generated by external scripts. Our work began in 2009, achieving a perfect match between measurements and simulations, and we need to start fromCorreli-Q4Software creation.Global image correlation mesh.Creating these Abaqus models, and then we determine the position of the tip by identifying the simulation that is closest to the measurement results.

In this framework, we did not use inverse methods for identification, and the specific implementation process is described as follows:

• Using Matlab/Python to create a series of models in the INP file, thanks to the basic parameters: initial image correlation mesh, cracks represented by simple openings or cohesive elements. The position of the tip is configurable. Managing the connection table is a real challenge, especially if you want to stretch the three-dimensional mesh!
• Start the calculation from the command line;
• Extract the displacement field from ODB using a Python script;
• Compare the measurement field and the simulation field to determine the crack tip.

Later, due to the use of unstructured meshes in image correlation, we will start reading the mesh from the INP file and add a feedback loop for material property identification. This is our transition to finite element mesh parsing, with few exceptions, as all our INP files are exported from Abaqus CAE and written in a very similar way.

Adapt to industrial cases.

Why are customers reluctant to spend time developing integration features themselves to handle finite element data? Because creating a universal connector is much more complex than laboratory work for the following reasons:

• Industrial demands are more diverse, covering many functions of Abaqus. In the laboratory, we do not need to integrate material laws in the form of UMAT, material orientation, singular element types, boundary conditions... but these demands in industry force us to prioritize development.
• INP files can be exported through other pre/post tools outside of Abaqus CAE. Abaqus is very open to other forms of syntax for these files (for example, according to the definition order of PART/INSTANCES), and the universal connector must be able to parse these format variants itself or decide to impose a unique syntax on our customers, which would even mean requiring them to rewrite INP files. This is a tough choice!
• We not only need to read INP files, but we also have to rewrite them into an "enhanced" version through DIGITAL TWIN. This means that many functions that do not need to be explained for measurement requirements must still be retained to allow for rewriting in the correct position in the output INP file. For those blocks that are interpreted in the model and need to be replaced, we also need to be able to identify the blocks in the INP file that need to be replaced and write in the new blocks generated by the EikoTwin software suite.

So, what do we choose to do?

Given the previous considerations and our past experiences, we believe that the use of Python scripts does not seem suitable for sufficiently general integration.

• The API provided in the Abaqus software distribution allows us to use two options, either the Python API or the C++ API. We naturally chose the C++ API because our software code is also written in C++, and of course, for performance reasons.
• To meet the needs of the EikoTwin software suite, which is to perform the correlation with the Abaqus simulation model, we must be able to: read the INP input file, finite element mesh, material orientations assigned to each element, so that we can express the deformation in that local reference frame, boundary conditions, materials, and computation steps;
• Rewrite the modified INP file;
• Read the simulation results contained in the ODB file;
• Rewrite an ODB file.

First, the fact that we must read the input and result files means we must be able to assign these results to the nodes and elements of the internal mesh format used in our software. Therefore, it is crucial to maintain the information of the original node and element numbering read from the NPI.

Second, the model must be modified and rewritten, which requires storing the structure and information of the input file. For this, we used a storage tree that allows us to modify the nodes of the tree and simply rewrite the unmodified content.

This adds additional technical requirements, especially that we need to be able to:

• Distribute our software suite without explicitly linking it to Abaqus, but ultimately allowing the client to use our C++ API to cover their Abaqus installation;
• Manage different versions of Abaqus present on the client site;
• Later manage other solvers (especially specific formats linked to Hyperworks, Samcef...).

The benefit of using the C++ wrapper we wrote is that we can compile a static library for each version of Abaqus. This allows us to determine at runtime which version of Abaqus the client is using and utilize the DLL they have installed.

What are the results?

After years of development and extensive coding practice, our integration with Abaqus through its API and parser is very seamless, and we have resolved many customer cases. In the latest developments, the sensitivity study in Abaqus allows users to use the solver as a "black box" and estimate which model parameters can be identified in a given test. The following figure summarizes the connections that have already been made possible.

Our next goal is: connecting to the simulation server and fully utilizing shell elements for DIC and test/simulation comparisons, which is crucial for large structure simulations. But we will also face a challenge: the connection to the simulation server is often under Linux, while our software is only available for Windows.