Introduction

Modern materials engineering tasks require the consideration of a large variety of phenomena eventually determining the microstructure and thus (i) the properties of a material within a technical component, (ii) the stability of the processes during its manufacture, and (iii) its performance under operational conditions. These challenges require a modular, configurable system of numerous models and simulation tools being available in the area of integrated computational materials engineering ICME [1] and a framework allowing orchestrating workflows in such multi-model simulation scenarios—a simulation platform. A review of currently emerging and already operational platforms is compiled in [1] with only few of these platforms like OOF2 or MOOSE focusing on microstructures and none of them aiming at the integration of codes from different providers.

Focus of the present article is the Aachen (“Aix”) Virtual Platform for Materials Processing—the AixViPMaP® [2]. AixViPMaP® is a simulation platform allowing a modular plug and play–type combination of some major academic and commercial software tools for the description of microstructures and their evolution by continuum models.

An early feasibility study for the AixViPMaP® platform [3, 4] essentially allowed for the configuration of some dedicated simulation chains for steels [5,6,7], but also for polymers and composites [4]. Major limitations of this first approach were essentially due to the use of VTK [8] as communication standard, which focused on the description of 3D fields representing microstructures but did not allow to coherently include other data like statistics or metadata.

A major step towards the digital representation of 3D microstructures draws on the open source software Dream.3D [9] including its 3D microstructure representation based on hierarchical data format (HDF5) type data structures [10].

The AixViPMaP® implementation depicted in the present article is based on a pragmatic approach drawing on HDF5-type datasets as the major means for the communication amongst different microstructure models and simulation tools [11]. It also includes experimental microstructure data [12]. The nomenclature for the entries in the objects in the HDF5 file essentially follows a metadata scheme for the description of microstructures [13].

In the mid to long term, the operation of this platform shall eventually be adapted to a generic materials modeling nomenclature [14] and to a materials modeling ontology being currently under development [15]. Using this ontology allows for a future, seamless information exchange also with other domains like crystallographic data stored in cif-files [16], chemistry data in IUPAC format [17], and also with other platforms, e.g., for electronic/atomistic/mesoscopic simulations, such as Aiida [18], SimPhony [19], NanoSim [20] or MuPif [21] and eventually with emerging meta-platforms like MarketPlace [22] or VIMMP [23].

Following a detailed description of the design of the AixViPMaP®, its present structure, and its operation, three different example workflows are presented and discussed. The article concludes with an outlook on the benefits of such simulation platforms and on their future use by the materials community.

Part A: The AixViPMaP® Platform

Material scientists utilize a broad spectrum of software tools allowing accurately predicting materials behavior. Individual software tools, however, often lack proper interoperability rendering chain execution a complex, time-consuming, and error-prone task. At the same time, maintaining an entire software toolset on a single personal computer is usually not an option due to a variety of reasons, including insufficient performance. High-performance clusters, on the other hand, actually provide the necessary computational power, but usually are limited to batch execution. File exchange between a cluster and a personal computer can be tedious. To make things even more challenging, materials research and engineering typically is performed by project teams. As a result, simulation parameters and results frequently have to be exchanged and shared between different people. Even further, project partners often even do not work for the same organization.

Integrational Challenges

During the development of the AixViPMaP® platform, our team was faced with numerous integrational challenges which can broadly be categorized in seven groups. While solutions for many of those issues could be found, some are still to be considered as work in progress. A further category of integrational challenges is expected to arise in the future when integrating AixViPMaP® in a superordinate meta-platform like the MarketPlace [22]. The solution to most of these challenges is documented in the AixViPMaP® code itself, which is available for free download from GitHub.

Domain Integration

The vision of AixViPMaP® is to integrate simulation hardware and software distributed across multiple institutions, computer networks, and administrative domains into a single computer cluster (grid) in order to help different institutes in aligning their materials engineering workflows. In order to reconcile the heterogeneous simulation infrastructures, numerous technical issues had to be solved. Most of these challenges exceed the realm of materials engineering and reach into the fields of computer networking and system development/administration:

  • How to schedule simulation jobs on remote computers that are located on different networks and use different operating systems or hardware architectures?

  • How to include not only single computers but entire local batch systems?

  • How to transfer simulation data efficiently between computers across global distances?

  • How to provide interactive login on remote simulation nodes?

  • How to control or limit user access to local hardware and software?

  • How to checkpoint and backup simulation data?

  • How to establish and maintain security throughout the network?

Web Service Integration

A key goal of the AixViPMaP® is to provide a web frontend allowing users to interact with the grid infrastructure via a web browser. While there is no lack of open-source projects implementing some individual features required for AixViPMaP®, no solution covering all the requirements could be found. In summary, four different web technologies (Table 3) were used requiring some customization in order to achieve a uniform authentication procedure.

Frontend/Backend Integration

A significant amount of effort was spent for the integration of the AixViPMaP® web frontend with its grid backend:

  • How to initialize interactive login sessions on head nodes?

  • How to access and modify simulation input and output data?

  • How to map file access permissions between web interface users and local system users?

  • How to integrate trusted external identity providers?

  • How to establish a single-sign-on mechanism not only across all web interfaces but also across all grid interfaces as well as between both these groups?

Software Integration

There is no standard defining where to find and how to launch specific software on a computer, especially when taking different operating systems and software versions into account. Local administrators handle software installations differently and typical procedures reach from installing software always in the default installation paths to using a central server for all software installations. Some institutions maintain module systems to initialize software environments, while other institutions expect the users to know the installation locations. Even those institutions using module systems do not necessarily follow a uniform naming convention when labeling the modules. These and similar inconsistencies in software environments must be considered when attempting to provide a uniform way of running software applications across multiple institutions.

License Integration

A further challenge is the integration of software licenses. Different software distributors prefer different licensing solutions varying from local license files to dedicated license servers. Network license models usually provide a certain number of licenses for shared usage to all users on a given subnetwork. In many cases, individual users do not need to authenticate against license servers, making it difficult to exclude individual users from executing specific, licensed software. Accounting on a per-user basis is rendered difficult because license servers often are not designed to log detailed usage statistics in a reliable way. License agreements may not only be limited to individual networks but also to individual natural persons preventing a license transfer to external guest users. Handling of licenses will be implemented in future releases of the AixViPMaP® and is beyond the scope of the present article.

Process Integration

Coupling of simulation software requires exchange of simulation data between applications. Interfacing between different software tools is not yet standardized. A couple of approaches exist to solve this problem, but none of them provides a complete solution by now:

  • Files are commonly used as a medium for information exchange between simulation applications. Unfortunately, different software applications support different file formats. Even when focusing on the microstructure domain alone, a multitude of open and proprietary file formats coexist. For the description of microstructures, however, the HDF5 file format being basically understood by most of the tools on the AixViPMaP® seems to emerge as a suitable standard. Still physical files remain a performance bottleneck due to comparably low hard-disk access times.

  • Conversion adapters: The platform follows the strategy of a common data format (HDF5) to/from which all codes can read/write. This common data structure in principle reduces the number of necessary converters needed for n different tools from n2 to n. For software not supporting the preferred HDF5 data format by now, the necessary converters still have to be written, to be maintained and to be adapted/extended in case of data format changes with new versions. Such adapters for the AixViPMaP®, however, are seen as fallback solutions in case a software tool does not support the HDF5 standard. Current European standardization activities towards a materials and modeling ontology ([13,14,15]) indicate the path towards semantic interoperability and thus to a further significant reduction of the number of required adapters in the future.

  • Co-simulation frameworks are used for (bidirectional) information exchange between simulation processes during runtime. While having a clear performance benefit over physical files due to direct inter-process communication, co-simulation frameworks suffer from a similar fragmentation into different competing solutions each only supporting some but not all simulation software. For a co-simulation framework to support software, usually, the data model of the specific software must be specified and additional APIs have to be implemented, requiring developers to invest extra time and effort.

Workflow Integration

Meta-scheduler and workflow management systems can help individual users to execute chained simulations on a grid system. Defining and executing workflows in a team can still provide a challenge:

  • How to minimize the need for human interaction?

  • How to define reproducible workflows including changing file sources and destinations?

  • How to share simulation data between project members?

  • How to version simulation data?

  • How to organize expert consulting?

  • How to visualize or validate (intermediate) results?

The following sections provide an overview of the AixViPMaP® operations and of its features indicating how some of the above integrational challenges were tackled.

Simulation Software

AixViPMaP® provides users with a modular simulation toolkit devoted to microstructure simulations. It includes academic and commercial software applications for microstructure formation simulation during phase transformations or grain coarsening, thermal and thermo-elastic properties simulation, crystal plasticity simulation, finite element analysis, and many more. A complete list of applications currently available on the AixViPMaP® is compiled in Table 1.

Table 1 Overview of available pre-installed software applications provided with environmental modules and adapters. The entries in the demonstrators’ column indicate which of the simulation workflows presented in “Example Workflows” the corresponding software application is included
Full size table

The portfolio of software applications can be categorized as follows:

  1. 1.

    A set of common simulation software is pre-installed and maintained by local IT professionals to guarantee maximum reliability and performance.

  2. 2.

    In addition to this pre-installed software, users can include supplementary software on their own. They can add custom scripts, install missing software packages, or build software from source. For this purpose, a set of interpreters (such as for Bash and Python), a build environment, and a package repository are available [35].

  3. 3.

    Virtual containers [36] are another software source. Containers offer two main benefits. First, software can be maintained in a central registry and automatically distributed on demand. Second, the runtime environment can be isolated in a flexible way. While a central container registry is not yet available on the platform, images for some simulation tools have already been created and were made available on individual machines for testing purposes.

Simulation Hardware

AixViPMaP® not only provides a software toolkit but also the hardware infrastructure required to run simulations. Different institutes contribute a variety of hardware resources, while AixViPMaP® itself only serves as a web-portal or common service provider, Fig. 1. This distribution of tasks becomes possible by a toolset of the so-called grid middleware acting as a software framework for distributed computing. The framework allows system administrators to integrate not only individual computers into the infrastructure but even entire batch systems [37] such as LFS [38], PBS [39], or SGE [40].

Fig. 1
figure 1

Schematic representation of the AixViPMaP® infrastructure including its most relevant components and interfaces. Hardware and software owned and operated by different institutions (marked red and green in the diagram) are linked via the AixViPMaP®, its web-interface, and other services (marked blue in the diagram)

Full size image

All framework components were selected, bearing scalability and modularity in mind. In the future, this allows to add not only local institutes but also organizations and their hardware across the globe. This includes, but is not limited to, scalability in terms of the number of addressable hardware and scalability in terms of the spatial extent of the network [41,42,43,44]. Table 2 lists a number of currently available grid middleware components.

Table 2 Overview of some currently available grid middleware solutions
Full size table

User Interface

AixViPMaP® aims at offering a comprehensive ICME environment, which can fully be accessed via a web browser. For this purpose, the platform incorporates a set of web interfaces supporting many tasks materials scientists typically face on a daily basis. Such tasks may include file management/sharing/synchronization, storage management, job and workflow definition/submission/monitoring/documentation, data pre-processing/post-processing/visualization, and software management. It does not matter whether a desktop computer or a mobile device is used to access the platform because all intensive computation is done on the server side. Therefore, as a welcome side effect, all services may be used on the go, for example, in order to check the status of a running simulation, or to quickly present simulation results. Table 3 shows a list of web technologies currently used.

Table 3 Overview of the web technologies currently in use on the AixViPMaP®
Full size table

File Storage and Management

AixViPMaP® gives users the ability to store all simulation data in a central online storage, where the data can be managed via a user-friendly file management interface [27], (Fig. 2). At the same time, simulations launched by the user can be empowered to access the central online storage in order to read input files from or write output files [49].

Fig. 2
figure 2

File manager—The screenshot shows a user’s online storage. The navigation bar (a) allows navigation between different interface extensions. The main panel (b) shows a list of files and folders, as well as the persons (c) with whom individual files and folders are shared

Full size image

.

In addition to common file operations such as creating, moving, or deleting of files, the file management interface also provides features focusing on collaboration, productivity, and interoperability.

Collaboration: Files can be shared with other users or can be published online. Obviously, these options are useful when simulation data needs to be exchanged amongst project partners or between lecturers and students.

Productivity: There are synchronization clients available for all major operating systems enabling two-way synchronization between the online storage and a personal computer. Without having to upload and/or download files manually, users can effortlessly transfer files in large numbers and sizes. This eventually makes it possible to utilize local software applications for pre-processing or post-processing of simulation data when necessary or beneficial.

Interoperability: With little effort, users can include external storage providers to their AixViPMaP® online storage. In this way, advantages of popular storage solutions such as Sciebo [50] or Google Drive [51] can be exploited

Jobs and Workflow Management for Distributed Computing

A key feature of the AixViPMaP® platform is its capacity to run simulations on a distributed computer network. For managing and monitoring of simulation jobs, users may choose between GUI and CLI interfaces depending on their skills and preferences. Figures 3 and 4 show the so-called Dashboard, a graphical user interface for displaying dynamic status information on active processes—i.e., jobs and workflows—and on available resources—i.e., software and hardware.

Fig. 3
figure 3

Dashboard view of a running simulation job including status information (a) and control buttons (b)

Full size image
Fig. 4
figure 4

Dashboard view of a completed simulation chain including charts (a) and a list of related individual simulations (b)

Full size image

Simulation tools can either be started individually or combined with each other in order to emulate process chains. For this purpose, users are free to couple simulation resources of different organizations (provided having the necessary authorization/licenses to do so). To pair multiple simulation tools, users must define the dependency relationships, and then, they can either chose a meta-scheduler [52] or a workload management system [48] to automatically spawn the entire process chain on their behalf. A standard module system will ensure that software environments are initialized in a uniform way across the network. Therefore, users do not need to include any host-specific configuration to their job descriptions nor do they need to have any knowledge of how software environments are organized in different institutes.

Currently, individual simulation applications are paired using adapters relying on files as a medium for information interchange. An adapter translates an output file from a preceding simulation application to an input file for a subsequent simulation application. In the future, a co-simulation framework [53] will be offered as an alternative. The framework is supposed to enable a direct coupling of individual simulation applications using API calls or direct process-to-process communication.

Interactive Computing

AixViPMaP® is not limited to processing of batch jobs on distributed systems alone. An interactive computational environment [26] is also available offering users a powerful general-purpose command-line interface [54]. This makes it possible to perform many day-to-day routines that require a high level of user interactivity including tasks such as data pre- and post-processing, building custom software, or accessing simulations at runtime. Figure 5 shows another typical use case where the console interface is used to access a remote simulation computer in order to analyze a local simulation process.

Fig. 5
figure 5

Terminal—The user first determines the ID of a running simulation (a). The ID is then used to establish an SSH connection with the corresponding simulation host (b). Finally, the content of the local working directory is listed (c)

Full size image

Job and Workflow Reproducibility

Once defined, simulation jobs and workflows can easily be reproduced as often as needed or be adapted to similar topics. Job and workflow definitions can either be described in static configuration files or in a dynamic program code. Thanks to file sharing, these plain text files can quickly and easily be shared with other users. Furthermore, notebooks offer a convenient way to save not only the instructions, but also the intermediate and final results of a workflow, Fig. 6.

Fig. 6
figure 6

Example on how a notebook can be used to plan and perform a phase field simulation and visualize its results

Full size image

Authentication, Authorization, and Security

Users log in to AixViPMaP® through a single-sign-on service [24]. Currently, a local user database serves as an identity provider. A future aim is to support also a superordinate authentication system [55] so that users can connect to the platform with their existing credentials provided by an organization they are associated with.

During the login procedure, a so-called proxy [47] is generated serving as a server-side ticket, which is automatically invoked whenever a user action requires authentication. Typical actions requiring authentication are submitting a simulation job, accessing the online storage, or connecting to a remote simulation host. Figure 7 illustrates the individual steps taking place during login in more detail.

Fig. 7
figure 7

Login method—After client-side authentication (not shown in this diagram), the user connects to the central JuypterHub server (1). The JuypterHub server authenticates against the central MyProxy server (2). The JupyterHub server then sends a job to the HTCondor scheduler of a previously selected institute (3). The job is delegated to a computer, which in turn pulls up a JuypterLab server (4). Finally, the central JupyterHub server forwards the user to this JuypterLab server. As long as the session does not end, the HTCondor scheduler updates the user’s proxy certificate to keep the session alive (6)

Full size image

Authorization is handled locally. Each organization decides independently which users are granted access to which of their hardware and their software. The access control permissions are currently configured on the service nodes. In the future, this temporary setup will be replaced by a central server solution [56].

All software components of the core system run in virtual containers in order to achieve maximum security by isolating the runtime environments [36]. Furthermore, all data transfer is performed in an encrypted way. This includes, in particular, all data transfers between the user’s computer and the platform as well as between the platform and the different institutes [45].

Further Information

All public source code of AixViPMaP® is available in a GitHub repository, while a further, private portion is hosted on a RWTH Aachen GitLab server, Table 4.

Table 4 AixViPMaP®-related links
Full size table

Part B: Example Workflows

Using the computational infrastructure of the AixViPMaP® depicted in the preceding section, the following section exemplarily describes its application and operation for three different simulation chains:

  • Anisotropic grain growth in synthetic 3D microstructures (“Aix_001”)

  • Macroscopic deformation of steel components with local recrystallization (“Aix_002”)

  • Deformation simulation of an experimental 3D microstructure (“Aix_003”)

An overview of the workflow of each simulation setting is graphically depicted according to the modeling data scheme “MODA” [57].

Jupyter notebooks being generated for each workflow contain all information about the tools being used in the workflow and also make reference to the driving files/conditions for each of the individual simulation tools in the chain. The full set of result and input data is stored in the file directory of each example workflow. Any simulation can thus easily be reproduced and automatically be re-performed just by starting the notebook. Simple scripts then allow for automatic parameter variations in the driving files of each of the individual simulations and for re-running the entire workflow using these new parameters.

All examples in this section draw on the term Representative Volume Element “RVE.” An RVE in general is defined is a volume being sufficiently large to be representative for a specific property of the material. The size of an RVE may even be different for different properties of the same material. The AixViPMaP® basically allows for any user-defined size of the simulation domain, which can thus be selected to be representative for a desired specific property. The property “microstructure” essentially can be characterized by statistical values like phase-fractions, average grain sizes, texture, and more. The size of the volume to be representative for a microstructure thus should match such statistics, i.e., it should be a statistically equivalent RVE “SERVE.” The virtual microstructure in Aix_003 contains a specific number of grains which is comparable to that of an RVE as used by [58].

As the size of the simulation domain can be adapted to match the requirement of being representative for any desired property and the purpose of this work is to demonstrate the capacity of the platform for a typical workflow, the term RVE is used in general throughout the entire article.

Example Aix_001: Anisotropic Grain Growth in Synthetic 3D Microstructures

Scope of the workflow in this example is the generation of a synthetic polycrystalline single-phase 3D microstructure by Dream.3D [9] and its subsequent use as an initial microstructure for a phase-field based grain growth simulation in MICRESS® [33]. The workflow essentially is based on available examples in both Dream.3D and MICRESS®. However, the individual parts of the workflow are generic enough to work with any grain structure being defined on a structured, equally spaced grid and being stored in the HDF5 file format.

The example mimics grain coarsening in a textured polycrystalline microstructure with a high fraction of low-angle grain boundaries (LAGB) and takes into account the different grain boundary energies and mobilities of low- and high-angle boundaries (HAGB). The corresponding texture components and the misorientation distribution function (MDF) are constructed using the microstructure generation algorithm implemented in Dream.3D. The simulation scenario is similar to the one discussed by Wang et al. [59], meaning that the microstructure can be interpreted as a subcell arrangement in a single grain after deformation and thus allows studying the probability of abnormal subgrain growth (AsGG). The probability of AsGG depends on the ratio between LAGB’s and HAGB’s and is one of the possible mechanisms leading to “nucleation” during recrystallization. Wang et al. have used a Monte Carlo Potts model for their simulations facing the inherent difficulty of aligning the time scale of the modeling with measurable physical quantities. The multiphase-field model used in the present example is formulated in measurable physical quantities and thus enables a direct comparison with experimental results. The material parameters used in this example are identical to those in example Aix_002. Both examples can thus be combined towards a multiscale simulation setting to study static recrystallization.

The workflow demonstrates interoperability between the software tools Dream.3D and MICRESS® on the AixViPMaP® platform. The individual steps of the workflow scheme being depicted in Fig. 8 are explained in more detail in the following.

Fig. 8
figure 8

Workflow of the example Aix_001 according to the MODA formalism [57]

Full size image

Aix_1.1: Synthesis of an Initial Anisotropic Grain Structure: Job Name “Synthesize”

Dream.3D provides numerous options to configure individual workflows/pipelines to generate or analyze 3D microstructures from experimental data, see e.g., Diehl et al. [58] and example Aix_003 in the present article, or to synthesize microstructures from user defined statistics. The workflow example Aix_001 bases on a preconfigured pipeline available in Dream.3D (pipeline “Single Cubic Phase Equiaxed”) which creates a polycrystalline 3D grain structure including predefined grain orientations and their phase/symmetry. In addition, the following modifications have been introduced compared to the standard example: (i) the ODF parameters in the “StatsGenerator” filter have been set to (Euler1 0, Euler2 40, Euler3 45, Weight 500,000, sigma 4), (ii) “primary rolled with a C/A ratio 0.5” was set instead of “equiaxed” in the “Preset Statistics Model” filter, (iii) the dimensions were set to (dimensions 360, 360, 360 and resolution 0.1 0.1 0.1) in the “Initialize Synthetic Volume” filter, and eventually (iv) “Periodic Boundaries” were switched on in “Pack Primary Phases.” The Dream.3D pipeline generates a Dream.3D output file in HDF5 format [10] and an XDMF file supporting visualization in Paraview [60]. The pipeline definition itself is stored in a JSON format. The pipeline can be executed on the AixViPMaP® platform using the “pipeline runner” tool provided by Dream.3D. This tool takes a pipeline definition file as a parameter and runs it automatically without a graphical user interface.

Visualization of the files generated in Aix_1.1 is immediately possible by downloading the Dream.3D and XDMF file and opening the XDMF file in Paraview. A Paraview viewer with restricted functionality is integrated in the platform, but the complete Paraview application is recommended to exploit the full functionality for visualizing grain structures.

Aix_1.2: Preparing a Grain Growth Simulation

The simulation of grain growth is then done by MICRESS® [33] and is based on the standard grain growth example T028_GrainGrowth3D. The information needed to run the MICRESS® simulation is (i) the driving file and (ii) the initial microstructure. The standard MICRESS® example draws on a randomly generated initial microstructure, which in the present example is replaced by the statistically well-defined microstructure being synthesized by Dream.3D and stored in HDF5 in step Aix_1.1. As Dream.3D can also handle and store digital microstructures originating from experiments, this workflow scheme has a very generic character and offers a wide range of future applications.

Information in MICRESS® is discretized on cubic voxel grids, while Dream.3D additionally allows for rectangular grids. To reach compatibility, the domain definition in the Dream.3D pipeline thus has to be restricted a regular voxel type grid. To prepare the initial microstructure for the grain growth simulation in MICRESS®, besides the grain structure, the phase and the orientation of each grain are needed.

Aix_1.3: Converting Data (Job Name: “D3DtoMIC”)

A configurable converter script “hdf2mic.py” is used in Aix_1.3 to convert the DREAM.3D output to MICRESS® input. The input section of the converter configuration JSON file contains the knowledge to address the data of interest in the HDF5 file. Functionalities for data conversions, e.g., cleaning data, rotating axis system, or type casting, transform the data into content suitable for a MICRESS® simulation. The output section defines resulting file names, field names, and data types.

The necessary information, e.g., internal container names, attributes, and data types defined in the HDF5 files by Dream.3D, is extracted by a manual inspection using an HDF5 browser [61]. This allows for identification and allocation of the container paths and names relevant for MICRESS®. This procedure is the most flexible way to address general HDF5 files generated by arbitrary software packages without knowing the details of the nomenclature in advance.

Once the converter “hdf2mic.py” is manually configured for Dream.3D type HDF5 files, running the script is done by a further job called “D3DtoMIC.” This job creates (i) a VTK file with the initial grain structure and (ii) a property file with the phase and orientation information for each of the grains (in ZXZ Euler angle notation). The MICRESS® driving file template then is automatically enriched with the names of these two files and accordingly with the geometry information.

Visualization and inspection of the VTK files can again proceed with Paraview.

Aix_1.4: Grain Growth Simulations and Parameter Variations (Job Name: “GrainGrowth”)

The job “GrainGrowth” runs the grain growth simulation. The preconfigured workflow automatically orchestrates the entire simulation chain from microstructure synthesis to grain growth simulations. The benefit of the platform operation is the ease of automatic parameter variations, i.e., re-performing the same simulation with different settings. For a given microstructure, variations of the parameters in the phase-field calculations like energies and mobilities for low- and high-angle grain boundaries are done easily in a semiautomatic manner. Alternatively—or additionally—other initial microstructures with well-defined texture can be investigated by re-performing the entire workflow from the beginning.

Aix_1.5: Converting Data (Job Name: “MICtoD3D”)

The conversion of the results of interest is done by a second configurable converter script “mic2hdf.py.” The configuration is set up analogous to Aix_1.3—D3DtoMIC. The resulting HDF5 file can be imported in Dream.3D, locally or in a follow-up workflow step. This allows data exploitation by the full spectrum of statistic tools being available in the Dream.3D pipelines.

Additionally, the results of the MICRESS® simulation can be examined locally without conversion using the free MICRESS® visualization and post-processing tool DP_MICRESS® [62].

Aix_1.6: Results and Discussion

The initial grain structure for example Aix_001 with 9499 grains as generated by Dream.3D is shown in Fig. 9a together with the corresponding pole figures in Fig. 9b which reveal the pronounced texture. However, the slight deformation of the grains in z-direction generated by the “primary rolled” feature in Dream.3D is hardly visible in the grain shapes. The total representative volume element (RVE) size is 363 μm3 with a numerical grid cell size of 0.1 μm × 0.1 μm × 0.1 μm. The average initial grain radius is 1.05 μm and thus comparable to a typical size of subgrains after deformation.

Fig. 9
figure 9

a Initial grain structure. The color represents the grain ID. b Corresponding pole figures generated by Dream.3D. The spread of the individual diffraction spots is governed by the sigma-parameter in the StatsGenerator. The pole figure legend refers to the intensity in multiples of random

Full size image

The dynamics of the grain size evolution as simulated by the multiphase field model is fully determined by the temperature and misorientation-dependent grain boundary energies and mobilities, the values are user input in the MICRESS® driving file. Misorientation-dependent grain boundary energies of LAGBs are described by the Read-Shockley model [63] and the corresponding mobilities by the model proposed by Humphreys [64]. The particular values and the temperature-time history are the same as given in the example on recrystallization (Aix_002, Table 6 below).

Figure 10 shows simulation results for the evolution of the average grain radius as a function of time and the grain structure at an intermediate and the final time step. Subgrain coarsening starts as soon as the temperature is high enough to lead to a sufficiently large interface mobility. Then, after an initial transient period, the average grain size increases from an initial value of 〈r〉 = 1.05 μm to a final value of 〈r〉 = 3.60 μm. The coarsening suddenly stops and the average grain size remains constant when the temperature drops down again.

Fig. 10
figure 10

a Evolving grain structure at 120 s and 350 s. Colors represent the grain ID. b Average grain radius (solid line) and temperature (dashed line) versus time

Full size image

This example demonstrates how a combination of Dream.3D, used for the generation of a synthetic grain structure with predefined properties, and the multiphase-field software MICRESS® leads to a simulation scenario for the investigation of grain coarsening in a subgrain network.

Future work is dedicated to the question whether a single set of grain boundary properties is sufficient for a consistent description of recrystallization on the length scale of subgrains and on the grain scale, respectively.

Example Aix_002: Macroscopic Deformation of Steel Components with Local Recrystallization

The example Aix_002 demonstrates a workflow linking a process scale simulation of cold rolling and heat treatment of a component to the mesoscopic scale of its materials microstructure. Scope is to model static recrystallization and crystallographic texture evolution at different positions (“RVEs”) in the component dependent on the local temperature-time history and the local deformation state.

The material is an isotropic, “non-oriented” electric steel. Non-oriented electric steels are used in rotating cores of electrical machinery. The optimization of their texture helps to improve their magnetic properties and performance.

The overall workflow demonstrates a link between a macroscopic simulation of metal forming and a subsequent simulation of the recrystallization on the scale of the material grain structure, Fig. 11. A similar, but manually configured approach has already been applied to a single RVE of a high-manganese steel [65]. The macroscopic simulation is based on a finite element crystal plasticity framework [66] whereas recrystallization is modeled by a multiphase-field approach. In particular, the following software tools are used: Abaqus [28], MATLAB [32], MICRESS® [33], Neper [34], DAMASK [29], MTEX [67], and ParaView [60]. The idea of generating a workflow within AixViPMaP® is to allow for improvements of individual modules of the entire simulation chain while keeping the possibility to re-run the full simulation chain under varying conditions.

Fig. 11
figure 11

Data flow for macro- and micro-rolling models in the example Aix_002 according to the MODA formalism [57]

Full size image

At the component scale, a three pass rolling process is simulated using Abaqus/standard FEM. The input to this model is an FEM mesh consisting of roll and workpiece geometry, as well as the material properties for both roll and workpiece. As a result, a macroscopic deformation gradient FM is extracted and used as input to the microscopic deformation model. A python script named “extract_Coordinates.py” extracts the coordinates and the ID of a selected element along with its time history during the rolling process. These coordinates allow calculating the local deformation gradient using the Matlab script “F_Calc3.m.” The calculated local deformation gradient is shown in previous work [68, 69].

The input for the micro model DAMASK is a 2D RVE microstructure with 300 grains being generated using the polycrystal generation and meshing software Neper. A python script “Generate_PBC.py” reads this mesh geometry and generates periodic boundary conditions (PBC), along with the auxiliary nodes where the macroscopic FM applies. Texture evolution in the polycrystalline structure is modeled using the phenomenological Crystal Plasticity Finite Element (CPFE) material model being implemented in DAMASK. The initial texture for the 300 grains is derived from the Orientation Distribution Function (ODF) being determined by XRD measurements performed prior to rolling [68, 70]. The discretization of the crystallographic texture is performed using the MATLAB toolbox MTEX.

The crystal plasticity simulation provides the Euler angles of the deformed grain structure. Local dislocation densities in the deformed grains, which depend on material constants and strain measure, are computed based on the Bergström constitutive equation [71] using the python script “DislocationDensity_perGrain.py.” The CPFEM material parameters and the material constants for the Bergström constitutive equation are taken from previous works [68, 69] and are summarized in Table 5.

Table 5 CPFEM and Bergström material parameters
Full size table

Mapping of the Euler angles and dislocation densities of the deformed structure onto a new RVE then is performed on a new RVE generated from Neper, now being based on elongated grains. This step is mandatory, as the subsequent recrystallization simulations in MICRESS® require an RVE model with a structured grid. The RVE used in the micro CPFE simulation and the RVE with elongated grains being created by Neper have the same grain order and structure. Based on the grain numbering, the dislocation densities obtained from the CPFE simulation are averaged per grain and then mapped onto the grains of the new RVE model. To map the orientations, an ODF is fitted from the Euler angles extracted from the DAMASK CPFE simulation. Then, 300 discrete orientations are extracted from the ODF using the discrete sample function in MTEX.

The orientations are mapped onto the new RVE with elongated grains. The final RVE, comprising the deformed grain structure, the dislocation densities after deformation, and the Euler angles, is stored as a HDF5 file and transferred to the simulation of static recrystallization.

The procedure of shifting between a statistical representation and a limited, discretized 2D representation of the microstructure may lead to errors regarding the predicted texture. The authors are aware that 300 orientations are inadequate statistics for a reasonable texture prediction. This paper, however, is not intended to accurately predict texture, but rather to develop a simulation environment in which individual modules and assumptions can later be replaced or improved to achieve results with a higher accuracy. The special focus is automation of a workflow between macro-micro scale simulations to investigate recrystallization texture.

Static recrystallization is simulated using the multiphase-field model implemented in the software MICRESS®. The RVE-related information is directly read from the HDF5 file (see also example Aix_001 in the present article). A typically deformed 2D grain structure is depicted in Fig. 12. A number of such RVEs selected from different positions in the component are subject to different degrees of local deformation as computed by Abaqus. Evaluating all these RVEs using the procedure described in this example results in different average dislocation densities at different locations in the workpiece/component.

Fig. 12
figure 12

a Grain structure of the RVE after deformation. The colors indicate grains by a misorientation angle with respect to the global coordinate system. b Dislocation density for 50% deformation

Full size image

The 2D microstructure shown in Fig. 12 consists of 307 × 93 cubic cells (cell edge length of 7.65 μm) resulting in a RVE size of 2.350 mm × 0.712 mm. It comprises 300 grains with an average grain size of 75 μm. Figure 12b shows the corresponding dislocation density after averaging per grain.

The model for static recrystallization (“SRX”) and its application as it is implemented in MICRESS® is outlined, e.g., in [66]. The grain structure, the crystallographic orientations of the individual grains, and the dislocation density field serve as initial microstructure for the SRX simulation. The recrystallization model in MICRESS® assumes a constant dislocation density within each single grain, and the dislocation density field thus has been averaged per grain as described before. In addition, the temperature-time history for each RVE is specified by (T,t) values read from an ASCII-table with linear interpolation between subsequent time steps. The recrystallization model requires a set of material parameters, given in Table 6.

Table 6 Material parameters for the simulation of static recrystallization
Full size table

The driving force for grain boundary movement of recrystallized grains results from the reduction of the dislocation density. The recrystallization kinetics is mainly governed by the grain boundary mobility, a quantity which is material-sensitive and may depend also on solute drag or particle pinning. Respective values are not known for the material under consideration, and the simulated kinetics should not be considered as a quantitative prediction. A quantitative simulation of the recrystallization kinetics would require calibration of the interface mobility by comparison with experimental data which has not yet been done.

The grain boundary energy and mobility models discriminate between low-angle (LAGBs) and high-angle grain boundaries (HAGBs) in the same manner as described in the example Aix_001, i.e., following the Read-Shockley model for the energy and Humphreys model for the mobility.

Critical for a quantitative recrystallization prediction—in particular for texture evolution—are nucleation criteria for new, recrystallized grains. Physically, nucleating grains emerge from abnormal subgrain growth at a length scale not being resolved by the present simulation setting. For this reason, the following phenomenological nucleation rules are used: (i) potential nucleation sites are the grain boundaries, (ii) nuclei appear at temperatures above Tnuc with a predefined frequency fnuc at boundaries where the local dislocation density exceeds a critical value Ndcrit, (iii) a minimum distance dmin exists between two neighboring nucleation events/nucleation sites, (iv) a nucleus is set with a radius rnuc which mimics the abnormal subgrain leading to a recrystallized grain.

Three different classes of nuclei have been defined in terms of above parameters, given in Table 7. The orientation of the new grains is assigned to be similar to the orientation of the “parent grain” allowing for a random rotation between 2.5 and 5° around the (111)-axis of the grain from which the nucleus emerges.

Table 7 Model parameters for nucleation during recrystallization
Full size table

In Fig. 13, a single result for this set of model parameter is represented. On the left (Fig. 13a), the grain structure after complete recrystallization is shown, in particular the grains exhibit a different, more irregular shape compared with the “input” structure shown in Fig. 12a. The transformation kinetic, i.e., the recrystallized fraction versus time, is represented in Fig. 13b. Recrystallization starts as soon as the temperature exceeds 1123 K and the first recrystallized grains nucleate. The whole recrystallization is finished within approx. 20 s. A reduced set of simulation parameters was used in order to demonstrate the principle of the presented procedure. The method can be extended to further parameters in the future to obtain quantitative results.

Fig. 13
figure 13

a Grain structure of the RVE after complete recrystallization. The colors represent grains by a misorientation angle with respect to the global coordinate system. b Recrystallized fraction (solid line) and temperature (dashed line) versus time

Full size image

The evolution of the simulated crystallographic texture during the three stages of this workflow is summarized as orientation distribution functions (ODF) and compared with experimental ODFs given in Fig. 14.

Fig. 14
figure 14

Experimental (top) and simulated (bottom) texture (a) before cold rolling (b) after cold rolling and 50% height reduction (c) after static recrystallization—(note: figures (a), (b), (c) are the φ2 = 45° sections of the Euler space). The ODF legend refers to the intensity in multiples of random

Full size image

The simulation of texture after cold rolling shown in the present example in 2D can be further improved when using a 3D RVE instead of a 2D RVE [68]. Better results are expected, when using a 3D RVE to simulate the deformation texture in the rolling process and also for the recrystallization simulations with MICRESS®. Once a simulation chain has been designed and implemented by an expert or a group of experts, reusable simulation templates can be provided to application engineers. Even if not being familiar with most software components, these domain experts can use these simulation workflow templates to run fine-tuned simulations or to perform parameter variations. The simulation workflow templates usually include customizable Python scripts, Jupyter notebooks, and HDF5 databases.

Example Aix_003: Deformation Simulation of an Experimental Microstructure

In the third example Aix_003, a virtual laboratory was constructed and used to investigate the deformation behavior of a twinning-induced plasticity (TWIP) steel with a specific focus on the mechanical properties under uniaxial tensile deformation condition, as has previously been described in [72]. Artificial microstructures were synthesized using the Dream.3D software [30] under consideration of statistics extracted from experimental data, such as grain morphology and crystallographic texture. Specifically, three RVEs were generated representing the material after cold rolling with thickness reduction of 30%, 40%, and 50% and additional recrystallization annealing. The RVEs were then subjected to uniaxial tension using the dislocation-based crystal plasticity constitutive model from the DAMASK software package [29], which has been proven to be suitable for capturing the deformation mechanisms of the investigated material [73].

The following steps were performed to execute the present example workflow, Fig. 15:

Fig. 15
figure 15

Schematic workflow diagram for the example “deformation simulation of an experimental microstructure”

Full size image

Experiment:

  • Retrieve grain morphology including grain size distribution and aspect rations from electron-backscatter diffraction (EBSD) results

  • Retrieve orientation distribution functions from x-ray diffraction (XRD) pole figure measurements (more detailed information can be found in [72, 74])

Pre-processing of experimental data:

  • Use MATLAB MTEX to retrieve texture data from experimental data

  • Process texture data in Dream.3D to generate RVEs

Simulation:

  • Process-generated RVEs in DAMASK spectral solver to simulate plastic deformation during tensile testing

Post-processing of simulation data:

  • Use DAMASK post-processing unit to export DAMASK spectral solver output to VTK and ASCII data tables

  • Use DAMASK GUI to export DAMASK spectral solver standard output stream to JSON file format

Visualization:

  • Process VTK files in ParaView to visualize simulation data in 3D space including dislocation densities and twin densities

  • Process ASCII data tables in MATLAB MTEX toolbox to generate pole figures

  • Process JSON files in Python to plot simulation data, for instance, stress/strain curves

The initial RVEs with mean grain sizes of 10.04 μm (30%), 4.78 μm (40%), and 3.80 μm (50%) are presented in Fig. 16 using color-coding according to the inverse pole figure (IPF). The results of the tensile tests performed in the virtual laboratory using the respective RVEs are shown in Fig. 17a. With decreasing grain size, higher stresses are developed, i.e., the 50% deformed material showed highest strength, whereas the 30% deformed material revealed the lowest strength. The same trend has been determined with respect to the work-hardening rate (Fig. 17b). This result is in well agreement with the experimental results [74,75,76]. In order to understand the differences in work-hardening behavior between the various states, the evolution of the microstructural constituents is required, i.e., orientation-dependent dislocation density and twin volume fraction. While it is difficult to retrieve this information from experiments, crystal plasticity simulations provide realistic approximations. Using the DAMASK code, orientation-dependent dislocation density and twin volume fraction can be extracted for each strain increment. The evolution of the mean twin fraction and dislocation density is illustrated in Fig. 18. In the strain regime from 0.1 to 0.35, the 50% deformed material developed the highest twin volume fraction, which originated from the highest resolved shear stresses in this alloy as compared to the 40% and 30% states. However, in this regime, the twin fractions developed in the different states show marginal variation. Contrarily, clear differences were obtained with respect to the accumulated dislocation densities. With decreasing initial grain size, higher dislocation densities developed. The results in Fig. 18 allow the conclusion that the contribution of work-hardening, i.e., formation and interaction of dislocations, dominates over the dynamic Hall-Petch effect due to the increase in twin fraction.

Fig. 16
figure 16

RVEs of the initial conditions tested in the virtual laboratory. The RVEs represent the condition after 30%, 40%, and 50% thickness reduction by cold rolling and additional recrystallization annealing

Full size image
Fig. 17
figure 17

Simulated stress-strain (a) and work-hardening rate (b) curves of the material in the three different conditions

Full size image
Fig. 18
figure 18

Simulated evolution of (a) deformation twin fraction and (b) dislocation density during uniaxial tension

Full size image

Additionally, influence of the initial texture, which results from prior processing by cold rolling and annealing, on the deformation behavior and texture evolution was investigated. Therefore, the three RVEs were subjected to tension along rolling direction (RD), transverse direction (TD), and normal direction (ND), respectively. The simulated stress-strain curves and φ2 = 45° sections of the ODF are illustrated in Figs. 17a and 19. Although, straining in ND promoted the formation of highest stresses in all states, the anisotropy of the mechanical properties is rather negligible. This results from both the homogeneous grain structure consisting of globular grains as well as the very weak textures, which typically are formed in high-manganese steels during recrystallization [77]. On the other hand, appreciable differences in the tensile textures can be recognized. In addition to the main texture component between A (φ1 = 55°, Φ = 90, φ2 = 45) and Brass (55, 90, 45), a minor cube texture component (45, 0, 45) is developed. Furthermore, pronounced texture components at (0, 45, 45) and (90, 45, 45) were formed during straining along ND. These texture components were of much weaker intensity after virtual tensile testing along RD and TD.

Fig. 19
figure 19

φ2 = 45° sections of the orientation distribution function of the 50% cold-rolled and recrystallized material after (a) 0% strain, (b) 48% strain along RD, (c) 49% strain along TD, and (d) 48% strain along ND. The ODF legend refers to the intensity in multiples of random

Full size image

In summary, the performance of a high-manganese TWIP steel has been assessed computationally using a virtual laboratory. Creation of RVEs using Dream.3D fed with statistical description of the microstructure and deformation simulation using physics-based crystal plasticity laws in DAMASK allowed for the evaluation of the mechanical behavior of the material. This example of an ICME-based approach enables to drastically reduce the number of physical experiments, to perform testing under conditions that are difficult to realize in reality (e.g., tensile testing along ND), and to extract relevant microstructure information (e.g., twin fraction, dislocation density). The present example may be extended towards through-process simulations, e.g., thermo-mechanical treatment, by coupling DAMASK (e.g., to simulate cold rolling) and cellular automaton predictions (e.g., for primary recrystallization), as has been performed in [78]. The resulting microstructures can then serve as a basis for selecting material states with tailored work-hardening properties, such as for application in energy-absorbing structural components [79].

Conclusion and Outlook

The implementation of a web-based simulation platform for modeling microstructures—the AixViPMaP®—has been described, and its operation has been demonstrated based on three examples.

These examples—although being specific—can readily be transferred to other materials or to similar processes. The major simulation tools used in the workflows—Dream.3D, DAMASK, and MICRESS®—are all generic and thus applicable to a wide range of metals and technical alloys. They cover all the major aspects of materials development like analytics (e.g., reading microstructure from serial sectioning EBSD data in Dream.3D), synthesis of artificial microstructures with predetermined statistics and texture (Dream.3D), deformation of microstructures (DAMASK), recrystallization, and grain growth (MICRESS®).

The workflows presented in this article do not yet contain any information about the thermodynamics and the chemical composition within the materials. The implementation of respective models and simulation tools to describe chemical inhomogeneities (“segregation”) are subject of ongoing work of the ICMEaix team at the RWTH Aachen [80].

The AixViPMaP® platform framework being introduced in the current article opens up the possibility of flowcharts [81] and offers options for automatic parameter studies for a single RVE. Such parameter studies, which are beyond the scope of the present article, are most interesting with respect to uncertainties emerging and propagating along a simulation chain, their impact on the final materials properties, the evolution of these properties along the life cycle of the components, and on the robustness of the manufacturing processes along the real production chain.

Further options are simultaneous simulations of microstructure evolution at multiple positions (“RVE”) in a single component as indicated in example Aix_002, where static recrystallization and crystallographic texture evolution at different positions in the component were targeted. Effective properties of these individual RVEs (being representative for that particular property) can be extracted from the simulated microstructures by suitable methods like mathematical homogenization or virtual testing [82]. The results of such local properties can then be interpolated towards a description of the properties of the entire component.

The AixViPMaP® platform framework is made freely available to the public [83], and also the examples will be published electronically along with the article.