#  Executive Summary

The Data Management Plan (DMP) of the ESTiMatE project describes the
management of datasets that will be generated as well as the software that
will be used during the lifetime of this project. This document is deliverable
D1.2 from the project and gathers such information. To this purpose the
following information is put forward:

  * The datasets generated during the project and their management during and after it. 

  

  * The methodologies and standards (if any) that will be applied to manage each of the datasets. 

  

  * The datasets storage during and after the project and their accessibility after the conclusion of the project. 

  

Some of the datasets generated in the project are expected to be confidential
and, in consequence, not distributable. The selection of which of them will be
public or not has still to be discussed with the Topic Manager of the project.
Any relevant change with regards to the current DMP contained in this document
will be submitted to the Commission.

#  Introduction

The ESTiMatE is a Clean Sky H2020 project aimed at developing a modelling
strategy using CFD simulations for the prediction of soot in terms of chemical
evolution and particle formation in conditions relevant to aero engine
operation. This DMP describes how data generated during the project will be
managed during and after it.

The document follows the Horizon 2020 FAIR DMP template and the FAIR data
guiding principles; i.e. data must be Findable, Accessible, Interoperable, and
Re-usable.

#  Structure of the ESTiMatE annex

As stated in the Grant Agreement (GA), in the ESTiMatE project several flame
configurations as well as the atomization process for an air-blast atomizer
will be measured and simulated, each one of them referred as a case
configuration. On one hand, experimental detailed information about velocity,
species, etc. spatial fields and soot measurements or particle size
distributions will be obtained depending on the experiment. On the other hand,
such measurements will be compared with simulations that will require High
Performance Computing (HPC) and the application of advanced combustion and
soot models.

In this way, for each case configuration several databases will be created
according to the following general structure (some of the following database
may be omitted depending on the configuration case):

  * Boundary conditions for the configuration. 

  

  * Experimental measurements of the configuration. 

  

  * Simulation set-up for the configuration (constant models, meshes, etc.). ● Simulation results for the configuration. 

  

Each configuration has a summary sheet where the main information about the
configuration is included and a second part where sheets with detailed
information about the repositories are given together with the FAIR metrics.
In addition, each code used in the project has a descriptive sheet with its
main characteristics. This information is given in the annex of this document.

In the following, the items included in each of the different sheets are
described.

##  Data summary

In this sheet a summary of the dataset related to one configuration case is
given with the following entries:  
  
<table>  
<tr>  
<th>

**Item**

</th>  
<th>

**Comments/explanation**

</th> </tr>  
<tr>  
<td>

Project

</td>  
<td>

Name of the configuration case

</td> </tr>  
<tr>  
<td>

Relevant aspects

</td>  
<td>

Aspects to be emphasized about the case configuration

</td> </tr>  
<tr>  
<td>

Codes

</td>  
<td>

Codes used for calculations

</td> </tr>  
<tr>  
<td>

WPs involved

</td>  
<td>

Project work packages involved in the configuration case

</td> </tr>  
<tr>  
<td>

Description

</td>  
<td>

Description of the activities carried out in the configuration case

</td> </tr> </table>

Table 1: list of items that describe the main characteristics of each case
configuration.  
  
<table>  
<tr>  
<th>

**Item**

</th>  
<th>

**Comments/explanation**

</th> </tr>  
<tr>  
<td>

Name

</td>  
<td>

Name of the datasets related to the configuration case

</td> </tr>  
<tr>  
<td>

Description

</td>  
<td>

Description of the datasets related to the configuration case

</td> </tr>  
<tr>  
<td>

Data category

</td>  
<td>

Data category according to table 4

</td> </tr>  
<tr>  
<td>

Repository location

</td>  
<td>

Name of the repository where datasets are located

</td> </tr>  
<tr>  
<td>

FAIR code

</td>  
<td>

Average mark for each category of the FAIR metrics

</td> </tr>  
<tr>  
<td>

References to other datasets/software

</td>  
<td>

Name of other referenced datasets/software

</td> </tr> </table>

Table 2: list of items that describe the datasets for each configuration.

##  Dataset sheet

The following information is included for each dataset sheet related to a
configuration case:  
  
<table>  
<tr>  
<th>

**Item**

</th>  
<th>

**Comments/explanation**

</th> </tr>  
<tr>  
<td>

Name

</td>  
<td>

Descriptive name to identify the dataset

</td> </tr>  
<tr>  
<td>

Data category

</td>  
<td>

Data category code (see Table Data Category for the corresponding codes)

</td> </tr>  
<tr>  
<td>

Licence

</td>  
<td>

Chosen among the most appropriate ones

</td> </tr>  
<tr>  
<td>

Repository location

</td>  
<td>

Institutional or public repository name and URL, if available

</td> </tr>  
<tr>  
<td>

Author

</td>  
<td>

Data author(s) name(s)

</td> </tr>  
<tr>  
<td>

Naming

Conventions

</td>  
<td>

File names structure and conventions

</td> </tr>  
<tr>  
<td>

Versioning

</td>  
<td>

How and where the version of the dataset can be found

</td> </tr>  
<tr>  
<td>

Format

</td>  
<td>

Standard formats and content standards, definitions, ontologies, etc. Link to
description of format document. General or specific format - libraries or
parsing code

</td> </tr>  
<tr>  
<td>

Size

</td>  
<td>

Estimation of total files size

</td> </tr>  
<tr>  
<td>

Storage

</td>  
<td>

Physical support

</td> </tr>  
<tr>  
<td>

Archive path

</td>  
<td>

Folders structure

</td> </tr>  
<tr>  
<td>

Associated metadata

</td>  
<td>

Reference to metadata standards

</td> </tr>  
<tr>  
<td>

Provenance

</td>  
<td>

Structured dataset origin information

</td> </tr>  
<tr>  
<td>

Backups needs

</td>  
<td>

Periodicity, subsets backup needs analysis, etc.

</td> </tr>  
<tr>  
<td>

Access permissions

</td>  
<td>

Lifecycle dependency: only specific groups of collaborators, all partners,
whole community…

</td> </tr>  
<tr>  
<td>

Legal/ethical restrictions

</td>  
<td>

Privacy and security issues

</td> </tr>  
<tr>  
<td>

Reproducibility

</td>  
<td>

If yes: connection to code and environment

</td> </tr>  
<tr>  
<td>

Data transfer needs

</td>  
<td>

Replicas and periodic transfers to/from other repositories

</td> </tr>  
<tr>  
<td>

Long term preservation

</td>  
<td>

Needs at 3-5-7-10 years (if any)

</td> </tr>  
<tr>  
<td>

Metadata management

</td>  
<td>

Way to access metadata when data are not available

</td> </tr>  
<tr>  
<td>

Resources need

</td>  
<td>

Analysis of resources needs at each step of data lifecycle

</td> </tr>  
<tr>  
<td>

References to other datasets

</td>  
<td>

Name of other referenced datasets

</td> </tr> </table>

Table 3: list of items in the dataset sheet and their definition.

The list of the data category is given here.  
  
<table>  
<tr>  
<th>

**Data category**

</th>  
<th>

**Code**

</th>  
<th>

**Name**

</th>  
<th>

**Comments**

</th> </tr>  
<tr>  
<td>

Scientific data

</td>  
<td>

1.1

</td>  
<td>

Models

</td>  
<td>

Data generated by the application of models

</td> </tr>  
<tr>  
<td>

1.2

</td>  
<td>

Experimental

</td>  
<td>

Data coming from observation, measurements or produced by

detectors/sensors or by any other experimental device and or activity

</td> </tr>  
<tr>  
<td>

1.3

</td>  
<td>

Synthetic

</td>  
<td>

Data generated by a simulation and/or are not obtained by direct measurement

</td> </tr>  
<tr>  
<td>

1.4

</td>  
<td>

Test

</td>  
<td>

Datasets (experimental or synthetical) used to validate models

</td> </tr>  
<tr>  
<td>

Software

</td>  
<td>

2.1

</td>  
<td>

Libraries

</td>  
<td>

Implementation of libraries

</td> </tr>  
<tr>  
<td>

2.2

</td>  
<td>

Applications

</td>  
<td>

Development of applications

</td> </tr>  
<tr>  
<td>

2.3

</td>  
<td>

Services

</td>  
<td>

Services provided

</td> </tr>  
<tr>  
<td>

2.4

</td>  
<td>

APIs

</td>  
<td>

Creation of application programming interfaces

</td> </tr>  
<tr>  
<td>

Administrative documents

</td>  
<td>

3.1

</td>  
<td>

Documents

</td>  
<td>

Any documentation, either public or private, such as code documentation,
technical notes, etc., not directly mentioned

in the project deliverable list.

</td> </tr>  
<tr>  
<td>

3.2

</td>  
<td>

Internal reports

</td>  
<td>

Meeting minutes, internal notes to document the evolution of the project, such
as

</td> </tr>  
<tr>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

calendar, resources management, mailing lists, etc.

</td> </tr>  
<tr>  
<td>

3.3

</td>  
<td>

Deliverables

</td>  
<td>

Project output documents

</td> </tr>  
<tr>  
<td>

Other

</td>  
<td>

4.1

</td>  
<td>

Metadata

</td>  
<td>

Any data describing data properties. If they contain scientific information,
they can also be classified as scientific data

</td> </tr> </table>

Table 4: summary of the different data categories.

##  Software sheet

In a similar way to the dataset sheet, the software sheet contains a detailed
description of the codes used in the simulations according to the following
table:  
  
<table>  
<tr>  
<th>

**Item**

</th>  
<th>

**Comments**

</th> </tr>  
<tr>  
<td>

Reference name of the program or workflow

</td>  
<td>

Name of the code

</td> </tr>  
<tr>  
<td>

Description

</td>  
<td>

Brief description of the functionality and applicability of the software

</td> </tr>  
<tr>  
<td>

Author

</td>  
<td>

Authors of the software

</td> </tr>  
<tr>  
<td>

Programming language

</td>  
<td>

Programming language(s) used for code implementation

</td> </tr>  
<tr>  
<td>

Rules and best coding practices

</td>  
<td>

Conventions for filenames, link to an external manual, if exists (ex: PEP8,
etc.)

</td> </tr>  
<tr>  
<td>

Access permissions and license

</td>  
<td>

Lifecycle dependency: groups of collaborators, all partners, whole community,
etc.

</td> </tr>  
<tr>  
<td>

Code size

</td>  
<td>

Code size

</td> </tr>  
<tr>  
<td>

Repository type

</td>  
<td>

GitHub, GitLab, Bitbucket, SourceForge...

</td> </tr>  
<tr>  
<td>

Repository structure

</td>  
<td>

Branches, tags, etc.

</td> </tr>  
<tr>  
<td>

Provenance information

</td>  
<td>

Containers, virtual environments

</td> </tr>  
<tr>  
<td>

Backup and archiving needs

</td>  
<td>

If any

</td> </tr>  
<tr>  
<td>

Legal/ethical restrictions

</td>  
<td>

If any

</td> </tr>  
<tr>  
<td>

Versioning control and rules/workflows managing

</td>  
<td>

Specify the repository

</td> </tr>  
<tr>  
<td>

Code transfer needs and security

</td>  
<td>

If any

</td> </tr>  
<tr>  
<td>

Long term preservation needs

</td>  
<td>

Only if applies to a given official release version

</td> </tr>  
<tr>  
<td>

Documentation and inline comments rules

</td>  
<td>

If any

</td> </tr>  
<tr>  
<td>

Metadata management

</td>  
<td>

Available even when the software is not

</td> </tr>  
<tr>  
<td>

Resources need

</td>  
<td>

Requirements for software at each step of the life cycle (access to
repository, computational needs, accessibilities, permissions, ...)

</td> </tr> </table>

Table 5: list of items in the software sheet.

#  FAIR data

The FAIR Guiding Principles (Wilkinson et al.; 2016; DOI:

10.1038/sdata.2016.18) describe distinct considerations for contemporary data
publishing environments with respect to supporting both manual and automated
deposition, exploration, sharing and reuse. A metric to quantify the degree of
“FAIRness” of each dataset in ESTiMatE has been defined. It results on a
normalized value (between 0 and 1) for each of the 4 FAIR components. In turn,
this (0,1) value results from assigning a flag value again between 0 and 1 to
each of the FAIR subcomponents defined by Wilkinson et al. (2016) and listed
in Table 6\.  
  
<table>  
<tr>  
<th>

**F**

</th>  
<th>

**FINDABLE**

</th>  
<th>

</th> </tr>  
<tr>  
<td>

F.1

</td>  
<td>

Persistent Identifiers (PDI)

</td>  
<td>

(Meta)data are assigned a globally unique and persistent identifier

</td> </tr>  
<tr>  
<td>

F.2

</td>  
<td>

Rich metadata

</td>  
<td>

Data are described with rich

metadata (defined by subcomponent R.1 below)

</td> </tr>  
<tr>  
<td>

F.3

</td>  
<td>

Metadata specifies the PDI

</td>  
<td>

Metadata clearly and explicitly include the identifier of the data it
describes

</td> </tr>  
<tr>  
<td>

F.4

</td>  
<td>

Data registered in searchable resources

</td>  
<td>

(Meta)data are registered or indexed in a searchable resource

</td> </tr>  
<tr>  
<td>

**A**

</td>  
<td>

**ACCESSIBLE**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

A.1

</td>  
<td>

Retrievable by the PDI with a standardized protocol

</td>  
<td>

(Meta)data are retrievable by their identifier using a standardized
communications protocol.

</td> </tr>  
<tr>  
<td>

A.1.2

</td>  
<td>

Open, free protocol

</td>  
<td>

The protocol is open, free and universally implementable

</td> </tr>  
<tr>  
<td>

A.1.3

</td>  
<td>

Authentication and authorization

</td>  
<td>

The protocol allows for an authentication and authorization procedure, where
necessary

</td> </tr>  
<tr>  
<td>

A.2

</td>  
<td>

Metadata availability

</td>  
<td>

Metadata are accessible beyond the data availability

</td> </tr>  
<tr>  
<td>

**I**

</td>  
<td>

**INTEROPERABLE**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

I.1

</td>  
<td>

Formal, accessible, shared and applicable language

</td>  
<td>

(Meta)data use a formal, accessible, shared and broadly applicable language
for knowledge

representation

</td> </tr>  
<tr>  
<td>

I.2

</td>  
<td>

FAIR vocabulary

</td>  
<td>

(Meta)data use vocabularies that follow FAIR principles

</td> </tr>  
<tr>  
<td>

I.3

</td>  
<td>

Metadata references

</td>  
<td>

Metadata includes qualified references to other metadata

</td> </tr>  
<tr>  
<td>

**R**

</td>  
<td>

**REUSABLE**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

R.1

</td>  
<td>

Relevant metadata

</td>  
<td>

(Meta)data have plurality of accurate and relevant attributes

</td> </tr>  
<tr>  
<td>

R.1.1

</td>  
<td>

Usage license

</td>  
<td>

(Meta)data are released with a clear and accessible data usage license

</td> </tr>  
<tr>  
<td>

R.1.2

</td>  
<td>

Provenance

</td>  
<td>

(Meta)data are associated with detailed provenance

</td> </tr>  
<tr>  
<td>

R.1.3

</td>  
<td>

Community standards

</td>  
<td>

(Meta)data meet domain-relevant community standards

</td> </tr> </table>

Table 6: definition of the different FAIR components used to quantify the
degree of fairness of each dataset.

##  Making ESTiMatE data Findable

ESTiMatE datasets suited for publication will be easily citable and easily
findable with the assignation of Persistent Identifiers.

  * The codes will be stored in repositories which permit versioning and tags for the identification of official releases and the connection with their outputs. 

  

  * Whenever possible, a rich metadata model and the register in disciplinary repositories will be used to allow other scientists to find the datasets produced by the project. 

  

  * Given the variety of the data of the project, the specific solutions and data models adopted for each dataset and software will be found in the corresponding sheet of this DMP. 

  

##  Making ESTiMatE data openly Accessible

Datasets access will depend on the different case and will be described in the
corresponding dataset sheet. Restriction of access will be guaranteed in cases
confidential data from the Topic Manager is used or generated. Metadata will
be made available in the web, independently on the accessibility of data.

##  Making ESTiMatE data Interoperable

The choice of metadata standards and the way to access the data is still under
discussion between the consortium members. Metadata standards will be chosen
to guarantee the maximum interoperability.

##  Increase ESTiMatE data Re-use

The ESTiMatE open-datasets will be licensed under some Creative Commons data
licensing (see Table 7).  
  
<table>  
<tr>  
<th>

</th>  
<th>

Allowed

</th> </tr>  
<tr>  
<td>

**Creative**

**Commons**

</td>  
<td>

**Description**

</td>  
<td>

**Modification of the content**

</td>  
<td>

**Commercial Use**

</td>  
<td>

**Free cultural works**

</td>  
<td>

**Open**

**definition**

</td> </tr>  
<tr>  
<td>

CC0

</td>  
<td>

Free content, no restrictions

</td>  
<td>

Yes

</td>  
<td>

Yes

</td>  
<td>

Yes

</td>  
<td>

Yes

</td> </tr>  
<tr>  
<td>

BY

</td>  
<td>

Attribution

</td>  
<td>

Yes

</td>  
<td>

Yes

</td>  
<td>

Yes

</td>  
<td>

Yes

</td> </tr>  
<tr>  
<td>

BY-SA

</td>  
<td>

Attribution+ ShareAlike

</td>  
<td>

Yes

</td>  
<td>

Yes

</td>  
<td>

Yes

</td>  
<td>

Yes

</td> </tr>  
<tr>  
<td>

BY-NC

</td>  
<td>

NonCommercial

</td>  
<td>

Yes

</td>  
<td>

No

</td>  
<td>

No

</td>  
<td>

No

</td> </tr>  
<tr>  
<td>

BY-ND

</td>  
<td>

NoDerivatives

</td>  
<td>

No

</td>  
<td>

Yes

</td>  
<td>

No

</td>  
<td>

No

</td> </tr>  
<tr>  
<td>

BY-NC-SA

</td>  
<td>

</td>  
<td>

Yes

</td>  
<td>

No

</td>  
<td>

No

</td>  
<td>

No

</td> </tr>  
<tr>  
<td>

BY-NC-ND

</td>  
<td>

</td>  
<td>

No

</td>  
<td>

No

</td>  
<td>

No

</td>  
<td>

No

</td> </tr> </table>

Table 7: data licensing options.

#  Allocation of resources

There is no additional cost for making the ESTiMatE datasets FAIR:

  * The code performance evaluation datasets of the open source codes of the project will be maintained at BSC facilities and could be included in publications. 

  

  * The rest of the open-data will be stored at the project site for at least three years after the end of the project. The infrastructure and personnel funds granted from the European Community will cover the storage, hardware and staff time to manage the servers on which the data will be stored. 

  

#  Data security

Each dataset will be evaluated separately and exceptional security measures
will be identified and applied. Regular backups for preventing loss of
information will be used.

#  Engagement with EUDAT

Solutions for data management and movement will be provided. In particular,
the use of EUDAT services to store and publish research data (B2SHARE),
distribute and store large volumes of data based on data policies (B2SAFE) and
transfer data between data resources and external computational facilities
(B2STAGE), exploiting data citation (B2HANDLE), that for EUDAT hosted data is
managed through Persistent Identifiers (PIDs), and metadata enrichment
(B2NOTE), will be fostered.