Attachment 0-10

Ref.
Ares(2018)6645308 - 22/12/2018
D2.4 Storage platform alpha release
Work Package 2
Lead Authors (Org) Andrea Berto (GRANTA), Donna Dykeman (GRANTA)
Contributing Author(s) Nic Austin (GRANTA), Borek Patzak (CTU), Vít Šmilauer
(Org) (CTU)
Reviewers (Org)
Due Date 30-06-2018
Date 30-06-2018
Version V02
Dissemination level
PU: Public X
PP: Restricted to other programme participants
RE: Restricted to a group specified by the
consortium
CO: Confidential, only for members of the
consortium
COMPOSELECTOR H2020 Project

Funding from the European Union’s Horizon 2020 research and innovation programme under grant
agreement No 721105. | www.composelector.net Page 1
Versioning
Version Date Author Instruction
v.0.1 08.12.2017 A. Berto (GRANTA), D. Dykeman

Document creation
(GRANTA)
v.0.2 26.06.2018 A. Berto (GRANTA), D. Dykeman First draft released for
(GRANTA), N. Austin (GRANTA) partner review
v.0.3 03.07.2018 B. Patzάk (CTU), V. Šmilauer (CTU), WP2 Review
C. Kavka (ESTECO)
Acronyms
- MuPIF: Multi-Physics Integration Framework
- BDSS: Business Decision Support System
- MODA: Modelling Data Elements
- RoMM: Review of Materials Modelling
- API: Application Programming Interface
- STK: Scripting Toolkit (specific to GRANTA MI)
- EMMC: European Materials Modelling Council
- EMMO: European Materials Modelling Ontology
- IP: Intellectual Property
- OTB: Out of The Box
Disclaimer:
This document’s contents are not intended to replace consultation of any applicable legal
sources or the necessary advice of a legal expert, where appropriate. All information in
this document is provided “as is” and no guarantee or warranty is given that the information
is fit for any particular purpose. The user, therefore, uses the information at its
sole risk and liability. For the avoidance of all doubts, the European Commission has no
liability in respect of this document, which is merely representing the authors’ view.

TABLE OF CONTENT
Versioning2
Acronyms2
Disclaimer:2
1. Introduction4
2. Schema development4
3. Interoperability with business layer and simulation layer18
3.1. ORDP Requirements20
3.2. Demonstration20
4. Conclusions20

1. Introduction
COMPOSELECTOR focuses on development of a business decision support system (BDSS) which
enhances and integrates existing software codes, targets decision makers and provides them with
easy-to-use tools and procedures for choosing the right polymer-matrix composites (PMC)
processes and modelling options. The modeling part focuses on development and demonstration of
integrated solutions based on a multi-disciplinary, multi-model and multi-field approaches for
decision-making in the selection, design and fabrication of PMCs.
The purpose of this deliverable is to share the work to-date to prepare the storage platform for alpha
release to partners for use in the project for exercising and developing the use cases (database
population, interoperability with the MuPIF and business layer, decision-making).
Deliverable 2.2 introduced the perspective of end-users from manufacturing and materials industries
on the topic of data storage requirements and interoperability. The data storage requirements are
related specifically to materials and process information management, which is the core use of data
and information generated by the MuPIF framework with integrated modelling codes.
The remainder of this deliverable details specific implementation requirements for the
COMPOSELECTOR project, notably the approach to schema development and adoption of ontology
taxonomy and eventually rules (EMMO), functionality development, interoperability with the
simulation and the business layers.
2. Schema development
The scope of the deliverable is to support the storage of information, data and metadata from multi-
scale simulations. In a typical in-house materials information system, the database would also host
empirical data. The cross-over point for these two activities relevant to the project is the use of
empirical data to validate virtual experiments using materials modelling and to calibrate the models.
As a starting point, the company database is represented by a schema established to fully qualify
composite materials, from pedigree to design (as noted in D2.2). The schema represented in Figure
1, defines composite materials in terms of raw single-phase constituents, intermediates (combination
of 2 or more constituents), processes, and lay-up in the “pedigree” area/s of the database. These
areas contain full definitions of materials (e.g. batch, chemistry, treatment, storage, etc.), to ensure
replicability over time. Details and information related to primary and secondary process are similarly
stored (cycles, operators, equipment, etc.).
Empirical raw and reduced test results are stored in dedicated areas and linked to the definition of
the material being studied, to ensure full traceability. This data can then be processed to generate
statistically backed design data. As above, the resulting analyzed data (or statistical result) is linked
to the underlying data (pedigree and tests).

This project will extend the schema to support modelling and simulation, as outlined in Figure 2, for
the traceability of use cases, modelling tasks (including input and outputs), simulation workflows and
their execution. As the benefit of schema development is the creation of links between tables,
records and attributes, project specific schema will be drafted once connections between simulation
tools are fully understood (MODAs). The taxonomy of the EMMO, and eventually the rules, will be
adopted.
Figure 1 - Composites qualification database schema (MI:Composites Template by Granta Design)
Storage Area Descriptions: in the following we described the database schema for storage and
management of virtual and empirical data. The overview of the database schema is presented in
Figure 2. Figure 3 presents an overview of the virtual data schema.

Figure 2 - Database schema overview. The left part (Virtual data) represents the simulation branch while the right part
(Composites Qualification) uses an existing composites template for composites materials data management
Figure 3 - Composelector virtual data schema overview

Use cases library: storage for use-case definitions and target KPIs. KPIs defined here will be
compared against the KPIs derived from the outputs of simulation tools (WP1) and analysis tools
(WP5). Each use case will be linked to the applicable simulation tasks and workflows, and to the
database records storing the metadata and results of all related workflow runs. Typical use case
attributes to be defined on the level of Business and Technical Performance [source: EMMC-CSA
D6.2] are shared in Table 1. Specific details will be captured in the form of as Use Case record in
the database system.
Table 1: Attribute type and category for business and technical performance KPI’s
ID Type Category
2 Business Economic (market, industry risk management)
2 Business IP Management
2 Business Regulations (sustainability, safety)
2 Business Market
2 Business Supply Chain Management
3 Technical Performance Economic (material, process, product life
(Materials/Process/Product) cycle)
3 Technical Performance Technical Performance
(Materials/Process/Product) (manufacturing/operations)
3 Technical Performance Health & Safety
(Materials/Process/Product)
3 Technical Performance Environment sustainability
3 Technical Performance Social sustainability
3 Technical Performance Technical Performance (in-service)
Modelling Tasks Library: storage for modelling tasks that achieve specific use case objectives,
such as the computation of attributes needed to calculate a KPI of interest to the business. A
modelling task is characterized by a well-defined set of inputs and outputs. Because of this, a task
can have various implementation workflows. It can be implemented by a single simulation code, or
by a set of codes in a chain. Different implementations of a modelling task are stored in the modelling
task workflows library and are linked to the modelling task that they implement.
Modelling Task Workflows Library: storage for predefined simulation workflow files (orchestrating
scripts) and for all KPIs that are used in workflow comparison and down selection (time, cost,
precision, etc.). Users will be able to compare KPIs (based on the combination of attributes found in
the Modelling Task Library) for the different workflows applicable to a certain use-case and modelling
task, and select the workflow that best meets their requirements. The creation of a new modelling
task workflow can be requested by the Business Layer, as detailed in chapter 3.

Modelling task workflows are comparable by a set of attributes used to support business, technical,
modelling, and simulation performance assessment. Typical attributes to describe modelling and
simulation activities [source: EMMC-CSA D6.2] in Table 2. A typical input/output strategy for
selection of an individual modelling task is illustrated in Figure 4, and for a modelling task workflow
in Figure 5. Figures 6 is a screen shot of how modelling task workflow tables are viewed in the
Materials Layer (GRANTA MI).

Table 2 Attribute type and category for modelling and simulation
ID Type Category
4 Model Economic
(expertise/personnel,
availability)
4 Model Accuracy
4 Model Reliability
4 Model Robustness
4 Model Sensitivity
4 Model Complexity
5 Simulation Economic (computational cost,
licence cost, etc.)
5 Simulation Computational time
5 Simulation Code correctness
5 Simulation Reliability
5 Simulation Robustness
Decision Table for Model Selection
Inputs outputs Robustness Sensitivity Complexity
1. Model Robustness
2. Model Sensitivity
3. Model Complexity
Figure 4: COMPOSELECTOR Decision table based on robustness, sensitivity and complexity of a workflow

Characteristics
Workflow Reliability Sensitivity Complexity Cost Expertise needs
1 Medium low High High No Yes
2 High High High High Yes Yes
3 low Low low Low Yes Yes
37
Figure 5: A Decision table considering additional selection criteria like cost, expertise, etc. In this example the actual
numbers are not reported, but rather an indication or rank to facilitate selection. The ranking must be predefined to the
targets of the business.
Figure 6: Modelling task workflow decision table in GRANTA MI
Modelling Task Workflow executions: as each workflow could be run multiple times, with different
inputs and/or set-up parameters, an area to store the history of each workflow run is required. This
will link to: i) the use-case that the workflow run is trying to address; ii) the modelling task; iii) the
modelling task workflow; iv) the data inputs used in the simulation and the generated outputs. This
area will also store any set-up parameter used on a one-off basis and the metadata generated by
the run. The relationship between run and inputs/outputs is one-to-many. This database area will
represent a hub for the solution since it links to all the other major areas and provides to the user an
overview of all steps, choices, data, that led to the generation of a set of simulation results.
Inputs/Outputs: storage of data inputs used as the starting point for simulations, which may be from
physical experiments, material models, or simulations. We envisage that project end-users will want
to include their own data as inputs (in-house test data, literature information, model results, etc.).
The population of this area will be supported by Granta’s ‘out-of-the-box’ web interfaces and Excel
based tools (MI:Explore, MI:Remote Import, and Granta Excel templates) or via the GRANTA MI API
(see Figure 7, 8 and 9). Granta can also provide data review, approval, and release workflows as
appropriate for the use cases (this applies to any area in the database, not only analysis inputs).
Granta reference data modules readily support simulation input requirements, which may be used
to support the project if appropriate and not infringing IP.
Simulation outputs are also stored in the same database area as inputs to support a multiscale
approach where outputs of smaller scales can become inputs for larger ones. This “one bucket”
approach can be appreciated for its simplicity, as all simulation codes will be retrieving and writing
data in a unique database area, making data gathering and selection easy at any stage. A more
structured approach, where the relational database principles are fully applied, could still be adopted
in the future if needed. This could imply the classification, grouping, and separation of data fields
based on their nature (material pedigree, physical properties, mechanical, etc.) and on their origin
(virtual, empirical, literature, etc.). This possibility for COMPOSELECTOR will be assessed in the
future as needed and when the use-cases will be fully defined.
Figure 7 - Population of the virtual inputs database schema

Figure 8 - Download of inputs Excel form via MI:Viewer interface
Figure 9 - Web interface for data upload
Empirical test data: storage of empirical test data to validate simulation results and/or calibrate
models (represented in the “Composites Qualification” area in Figure 2). Test data input can happen
via Granta’s OTB web interfaces and Excel based tools (MI:Explore, MI:Remote Import, and Granta
Excel templates) or via GRANTA MI API.
Test data is intrinsically linked to the structural characterization of the material and/or component
being tested. Typical pedigree information is the single-phase component, filler volume fraction,
processing parameters, stacking sequences, etc. Capturing this information ensures traceability, but
also reproducibility in the long term. Granta Design recommends the adoption of the MI:Composites
Template (see schema overview in Figure 1), developed in partnership with many composites
organizations, for the storage of composites pedigree and empirical test data (see schema overview
in Figure 1).
Notice that the point of contacts between the empirical composites qualification data, use-cases, and
virtual data, have not been investigated yet. The use of the MI:Composites Template within the
Composelector project will be assessed as soon as the requirements for calibration of models and
validation of virtual results will be defined by the consortia.
Current virtual data schema

The schema has been developed accordingly to the requirements of the Composelector consortia.
It should be noted that some areas of the database are not fully defined. Despite this, GRANTA MI
is flexible, and the schema can be extended as part of project Task 2.6 (M6-M24) as soon as the
project use-cases and their requirements will be fully formalized.
Examples of the schema are presented here, in the form of screenshots taken from the GRANTA MI
data visualization interface, called MI:Viewer:
- Use-cases
Fields to look out for in this area are:

i. Links to all the relevant associated resources: modelling tasks, workflows, and
executions. (see blue hyperlinks in the screenshot above)
This area could be further extended with links from the use-case to input datasets which are
specific and fixed for the use-case. The dataset would then be easily retrievable by
downstream simulation codes.

- Modelling tasks
This area will be further developed by including the list of inputs/outputs involved in a
modelling task (and all its implementation workflows). These could be useful for end-users
modelling task comparison and selection.
- Modelling task workflows
Fields to look out for in this schema are:

1. Workflow status: whether the workflow, and in particular the associated script, have
been approved by the platform administrators
2. Performance indicators: these fields summarize the performance of a workflow, and
are used for workflows comparison and selection. At the moment of writing they are:
▪ Personnel experience required
▪ Time
▪ Reliability
▪ Total cost
▪ Personnel cost
▪ Computational cost
but they can be extended as required.
- Modelling task workflows executions
Fields to look out for in this schema are:

1. Metadata: these fields are used to fully characterize an execution.
As you can appreciate from the images above, every item in the database is tagged with user-friendly
IDs which will facilitate operations. The format of the IDs changes depending on the nature of the
item that the ID represents, thus allowing for a quick item’s identification. These are some examples:
UC-1 (use-cases), MT-1 (modelling tasks), MTW-1 (modelling task workflows), EXEC-1
(executions).
All items are also interlinked with any other relevant resource. For example, in the last image you
can notice that the execution record is linked to the use-case, modelling task, modelling task
workflow, inputs and outputs.
- Inputs/Outputs
A mapping activity has been performed by Granta Design and the Composelector WP1
members. The objective: creating a database schema fit for the purpose of storing models’
inputs and outputs. The results of this activity are presented here, in the form of screenshots
of sample datasets imported into GRANTA MI by the WP1 members (after tailored training
was delivered by Granta Design).

1. INSA (tool: COMSOL)
2. POLITO (tool: MUL2)

3. eXstream (tool: Digimat)
4. UNITS (tool: LAMMPS)
Notice that the database contains also the mapping for VPS (ESI’s tool) but not a sample
dataset yet. The mapping of CADRAL, LIST’s tool, will soon be carried out by Granta Design
and LIST. Granta Designs tools for environment, cost, risk, material and process selection
are intrinsically mapped.
A full description of the inputs/outputs mapping for the Composelector project’s models can
be found on the project’s cloud.

3. Interoperability with business layer and
simulation layer
An overview of the Composelector BDSS platform is presented in Figure 10:
Figure 10 - The COMPOSELECTOR platform
The Materials Layer, that is GRANTA MI, interacts with the Business Layer (ESTECO BeePMN tool)
and Interoperability Layer (Czech Technical University in Prague developed MuPIF, and simulation
codes by partners ESI, e-Xstream, University of Trieste, Politecnico di Torino, INSA-Lyon).
Interactions are performed via standardized APIs. This allows the Business Layer to consume data
stored in the database and request the generation of new data, and to steer and set/get data to the
Interoperability Layer in a consistent way.
The API for interfacing Business and Materials Layer is documented in deliverable D3.2.
The REST API developed by Granta Design allows the Business Layer to query the database and
write new data in it.
Using the REST API the Business Layer is able to interact with the Materials Layer (GRANTA MI)
by the following types of calls:
1. retrieve, compare, and select use-cases, modelling tasks, and modelling task workflows.
2. request the execution of a modelling task workflow (only if the workflow status is “approved”)
3. check the status of one or more workflow execution/s

4. retrieve the executions’ outputs (limited to simple data types)
5. request the creation of a new modelling task workflow
Interactions of type 1 and 2 are represented in Figure 11 (to be read from top to bottom) to illustrate
the most common interaction path between Business Layer, Materials Layer, and Interoperability
Layer.
In summary, the Business Layer performs a modeling task workflow selection, after which an
execution request is posted. The Business Layer request, now a record in the GRANTA MI database
system, is handled by the MI:Workflow Manager, where a technical expert reviews it, allocates to it
the necessary set of inputs, and runs it. The MI:Workflow Manager runs the simulation script (stored
in the down selected modelling task workflow record) which in turn invokes MuPIF and the simulation
apps included in the workflow.
Figure 11 – Workflow’s down selection and new execution request
Interactions 3 and 4 are much simpler and do not require a diagram. Given an execution ID, the
Materials Layer returns the status of the execution or its outputs, depending on the call performed
by the Business Layer.
Interactions of type 5 are similar to Figure 11, but simpler. The Business Layer posts a new workflow
request, a technical review takes place in the Materials Layer, supported by MI:Workflow Manager.
Only when the new workflow is finally approved in MI:Workflow Manager it becomes consumable by
the Business Layer.

3.1. ORDP Requirements
The COMPOSELECTOR project fits within the remit of the Open Research Data Pilot by virtue of
the fact that it is an H2020 project. Open data is data that is free to access, reuse, repurpose, and
redistribute, and it is expected that projects deposit data in a research data repository where they
will be findable and accessible for others. The COMPOSELECTOR project has established a Data
Management Plan (DMP) to document the access to research data generated in the project.
The database used in this project, GRANTA MI, can also be used as a public facing repository,
should the need arise by the project or a client; examples exist today (e.g. ASM Medical Device
Repository). The central story for GRANTA MI in the COMPOSELECTOR project is to represent a
centralized materials information management system owned by a manufacturing organization,
extending its capabilities by reaching out to the MuPIF platform (open source software linking to
multi-scale modelling codes), and in the configuration of the project it also links with another
representation of an in-house (to the manufacturing organization) Business Layer, BEEPMN tool.
Granta Design’s data protection policy statement can be found here:
https://www.grantadesign.com/privacy.htm.
3.2. Demonstration
As appropriate and upon request, Granta will provide a video to share the progress on the
COMPOSELECTOR database for the review of the Project Monitoring Officer.
4. Conclusions
The GRANTA MI Composelector server has been set-up and an alpha version of the Composelector
database has been created to test interoperability with MuPIF and with the business decision layer,
BEEPMN. APIs have been created to interface the 3 platform components, that is Business Layer,
Materials Layer, and Interoperability Layer. The interoperability has been demonstrated at a
prototype level using MuPIF default examples.
Next steps will include:

1. Prototype delivery with interoperability to the business decision layer and MuPIF (M19-24)
on distributed computers;
2. Demonstration with project use case (M19-24);
3. Working with software tool developers and material model partners to establish the
necessary schema and workflows to enable the capture and use of input/output
information/data for the Use Case MODAs and tools in WP5 (M19-M40). Updates to API for
data/information exchange between the BDSS layers (BEEPMN, GRANTA MI, MuPIF) and
BDSS modelling tools and decision-making tools will continue as noted in D3.2 (M18, PU).


Attachment 0-10

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Attachment 0-10

Uploaded by

Copyright:

Available Formats

Ref.

D2.4 Storage platform alpha release

COMPOSELECTOR H2020 Project

Version Date Author Instruction

v.0.1 08.12.2017 A. Berto (GRANTA), D. Dykeman

COMPOSELECTOR H2020 Project

COMPOSELECTOR H2020 Project

COMPOSELECTOR H2020 Project

Figure 1 - Composites qualification database schema (MI:Composites Template by Granta Design)

COMPOSELECTOR H2020 Project

Figure 3 - Composelector virtual data schema overview

COMPOSELECTOR H2020 Project

COMPOSELECTOR H2020 Project

COMPOSELECTOR H2020 Project

Decision Table for Model Selection

Inputs outputs Robustness Sensitivity Complexity

COMPOSELECTOR H2020 Project

Workflow Reliability Sensitivity Complexity Cost Expertise needs

1 Medium low High High No Yes

2 High High High High Yes Yes

3 low Low low Low Yes Yes

Figure 6: Modelling task workflow decision table in GRANTA MI

Figure 7 - Population of the virtual inputs database schema

COMPOSELECTOR H2020 Project

Figure 9 - Web interface for data upload

Current virtual data schema

Fields to look out for in this area are:

COMPOSELECTOR H2020 Project

- Modelling task workflows

Fields to look out for in this schema are:

- Modelling task workflows executions

Fields to look out for in this schema are:

COMPOSELECTOR H2020 Project

2. POLITO (tool: MUL2)

COMPOSELECTOR H2020 Project

4. UNITS (tool: LAMMPS)

COMPOSELECTOR H2020 Project

Figure 10 - The COMPOSELECTOR platform

COMPOSELECTOR H2020 Project

Figure 11 – Workflow’s down selection and new execution request

COMPOSELECTOR H2020 Project

Next steps will include:

COMPOSELECTOR H2020 Project

You might also like