#  Introduction

The Data Management Plan is the final deliverable in the Dissemination Work
Package.

In this deliverable each partner will describe how they will handle their data
sets, how they will address sensitive issues, and future ideas on how to make
the data sets as open as possible, working with the FAIR principles as set out
by the EC.

At the moment we do not foresee any issues with personal data, although then
they arise, the consortium partners will handle these data in line with the
GDPR.

The data generated within this project can contain sensitive information, in
terms of IPR. In this document we will describe what the guidelines are for
handling this kind of data.

The DMP is a deliverable that was due at Month 6. At that point in time, only
a few ESR’s had started their work, so we chose to delay the DMP until more
ESR were appointed. At this moment, we do not have a clear picture in mind on
what data can be opened up and which data will need to be kept confidential.
Therefore, we have chosen to make this DMP a living document, since we foresee
that with the progress of the project, insights into which data can be opened
up and how to apply the FAIR principles will be gained.

In Magister 15 ESR’s will receive their training at various institutions. In
Table 1 an overview of the ESR can be found and their starting dates. From
this table, it shows that at the point of writing only eight ESR’s have
started their research.

TABLE 1: OVERVIEW OF ESR'S, STARTING DATES AND CONTRIBUTION TO D7.8  
  
<table>  
<tr>  
<th>

ESR nr

</th>  
<th>

Name

</th>  
<th>

Start

</th>  
<th>

In this deliverable?

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

1

</td>  
<td>

Ushnish Sengupta

</td>  
<td>

September 1  st  , 2018

</td>  
<td>

No

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

2

</td>  
<td>

Nils Wilhelmsen

</td>  
<td>

September 1  st  , 2018

</td>  
<td>

No

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

3

</td>  
<td>

Nilam Tathawadekar

</td>  
<td>

September 1  st  , 2018

</td>  
<td>

No

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

4

</td>  
<td>

Louise da Costa Ramos

</td>  
<td>

September 1  st  , 2018

</td>  
<td>

No

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

5

</td>  
<td>

Sagar Kulkarni

</td>  
<td>

July 1  st  , 2018

</td>  
<td>

No

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

6

</td>  
<td>

Varun Shastry

</td>  
<td>

February 5  th  , 2018

</td>  
<td>

Yes

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

7

</td>  
<td>

Alireza Ghasemi Khourinia

</td>  
<td>

May 1  st  2018

</td>  
<td>

Yes

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

8

</td>  
<td>

Francesco Garita

</td>  
<td>

January 15  th  , 2018

</td>  
<td>

Yes

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

9

</td>  
<td>

Alireza Javareshkian

</td>  
<td>

March 15  th  , 2018

</td>  
<td>

Yes

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

10

</td>  
<td>

Edmond Shehadi

</td>  
<td>

April 15  th  , 2018

</td>  
<td>

Yes

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

11

</td>  
<td>

Thomas Christou

</td>  
<td>

April 15  th  , 2018

</td>  
<td>

Yes

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

12

</td>  
<td>

Sara Navarro Arredondo

</td>  
<td>

May 15  th  , 2018

</td>  
<td>

Yes

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

13

</td>  
<td>

Michael McCartney

</td>  
<td>

January 1  st  , 2018

</td>  
<td>

Yes

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

14

</td>  
<td>

Thomas Lafarge

</td>  
<td>

September 24  th  , 2018

</td>  
<td>

No

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

15

</td>  
<td>

Pasquale Agostinelli

</td>  
<td>

October 1  st  , 2018

</td>  
<td>

No

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

Each ESR has provided their own data management plan. These plans can be found
in the following chapters.

#  Objectives

The objectives of this deliverable are threefold:

  * Set out project guidelines for researchers on working with their data during their research. 

  

  * Help researchers to open their data according to the FAIR principles. This will be done in a later stage when there is more information available about what kind of data set there will be generated. 

  

  * Describe in more detail how each ESR will handle their data. In this version of the deliverable, eight ESR will give as detailed a description as possible. 

  

#  Data management guidelines

At this moment, we do not have a clear picture on which data will be generated
during the project.

Furthermore, we cannot foresee which data must be kept confidential and which
data can be stored in open repositories. Our expectation is that definitely
not all data can be stored in open repositories since the companies involved
in the project are keen on keeping their data private. Therefore this section
will be updated when more information becomes available.

For this moment, we will set out provisional guidelines for the consortium on
working with (sensitive) data in general and more specific on working with the
fair principles:

##  General guidelines

  1. First of all the data management plan should be in line with the data management policy of your host institution. 

  

  2. If you are working with (sensitive) data from (associated) companies, make sure you are aware of and following their rules on data management. This will probably include rules on storage, access, sharing, and open data. 

  

  3. Furthermore in line with EU regulations, we like to make data as openly accessible as possible. 

  

  

This means three things:

  * If you publish a paper, try to do it in open access journal (Gold or Green). But always give the consortium the opportunity to check on the information you will be publishing. 

  

  * When the research is finished, try to open up the datasets as much as possible, for other researchers to re-use. Deposit the dataset in a repository with a data seal of approval. (If you have a valid reason not to open it up, such as company policies or explicit use of personal data, keep the data securely stored and closed.) 

  

  * When opening up the data set, keep in line with the FAIR principles (read more in chapter 3.2). 

  

  4. If you are going to process personal data, ask project management about GDPR guidelines. 

  

  

(We do not expect this to happen during this project, but keep it in the back
of your mind.)

  5. Each data file should be accompanied by a data description file in which the data set and its variables are described. 

  

  6. If you are going to “clean up” your data file, make sure to describe which steps you’ve taken and how many entries you’ve adjusted. 

  

  7. At the end of an ESR’s working period, we expect a manual to be written for access to the data after ending of the ESR’s work. 

  

  8. If you want to share information within the project, there is a Box solution available at GE. Ask project management about access and rules. (To prevent security breaches, do not setup a separate (cloud) sharing solution like Dropbox on your own.) 

  

  9. If you are going to carry around sensitive information, always make sure the information carrier is encrypted and password secured. 

  

  10. Last but not least: If you have any questions concerning your data management, do not hesitate to ask your supervisor or the project management. 

  

  

##  Fair principles and opening up the data

###  3.2.1 General

We intend to use the data specialists that are working at the partners within
the consortium, since at researchers level we foresee a lack of specialized
knowledge on the FAIR principles. At the UT, the library and archiving
department can provide specialized support on data management, including Open
Access, Open Data, and Archiving.

###  3.2.2 Findable

Each dataset will get a unique Digital Object Identifier (DOI).

Within the project, naming conventions will be used to cooperate on research
and to make dataset as easily findable as possible. When storing the dataset
in a trusted repository, the name might be adapted for better findability.

Appropriate keywords will be used in line with the field of research and the
content of the datasets.

###  3.2.3 Accessible

Our intention is to make as much data openly accessible as possible, within
the boundaries of company confidentiality, IPR, and ethical issues as covered
by the consortium agreement and in the ethics deliverables. Data will be
stored in a trusted repository, this can be either at the partner or for
example in DANS or 4TU data Centre as long as the repository has a data seal
of approval.

In case access will need to be limited, a repository will be used in which
restricted access can be provided. If a dataset is going to be stored with
restricted access, a Data Access Committee will be set up in the final stages
of the project. They may decide on a case to case basis if access will be
granted and for which period.

###  3.2.4 Interoperability

Metadata will be used to enhance the interoperability. At the moment we are
looking into Datacite and Dublin Core. Depending on specific fields of
research additional meta data standards can be used.

###  3.2.5 Re-use

Data sets will be licensed under and Open Access License as much as possible,
to enhance re-use for third parties. This will however depend on the company
policies, IPR, and ethical issues involved. If a dataset contains IPR or other
exploitable results, an embargo period might be set.

All data sets will have a clear naming convention, will be cleared of bad
records, and appropriate meta data and keywords will be added.

#  Data per partner

Each ESR will describe how they will handle their data in the following table.

##  ESR 6: Varun Shastry (CERFACS)  
  
<table>  
<tr>  
<th>

1\. Data summary

</th>  
<th>

1\.

</th>  
<th>

State the purpose of the data collection/generation

_Data collection, generation for validating and developing models related to
spray dynamics and spray combustion._

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

</td>  
<td>

2\.

</td>  
<td>

Explain the relation to the objectives of the project

_The main objective of the PhD thesis is to study thermoacoustics in spray
flames, hence the data as answered previously._

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

</td>  
<td>

3\.

</td>  
<td>

Specify the types and formats of data generated/collected

_Data related to experimental setups, conditions and experimental results._

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

</td>  
<td>

4\.

</td>  
<td>

Specify if existing data is being re-used (if any) _No pre-existing data is
being used currently._

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

</td>  
<td>

5\.

</td>  
<td>

Specify the origin of the data

_Not applicable as of now because of previous answer._

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

</td>  
<td>

6\.

</td>  
<td>

State the expected size of the data (if known) _Not applicable as data is not
finalised._

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

</td>  
<td>

7\.

</td>  
<td>

Outline the data utility: to whom will it be useful

_If made available, will be useful to other ESRs working in similar areas._

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

2\. Allocation of resources

</td>  
<td>

1\.

</td>  
<td>

Estimate the costs for making your data FAIR. Describe how you intend to cover
these costs

_Costs estimates have not been discussed and will be done at a later stage._

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

</td>  
<td>

2\.

</td>  
<td>

Clearly identify responsibilities for data management in your project

_General data handling guidelines of CERFACS apply. Additional
responsibilities will be added as the project moves forward._

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

</td>  
<td>

3\.

</td>  
<td>

Describe costs and potential value of long term preservation

_Cost estimates for long term will be discussed at the end of the project._

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

3\. Data security

</th>  
<th>

1\.

</th>  
<th>

Address data recovery as well as secure storage and transfer of sensitive data

_Data will be stored based on CERFACS guidelines._

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

4\. Ethical aspects

</td>  
<td>

1\.

</td>  
<td>

To be covered in the context of the ethics review, ethics section of DoA and
ethics deliverables. Include references and related technical aspects if not
covered by the former.

_Not applicable as of now._

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

  5. FAIR Data 

  

  

5.1. Making data findable, including provisions for metadata

</td>  
<td>

1\.

2\.

3\.

</td>  
<td>

Outline the discoverability of data (metadata provision)

Outline the identifiability of data and refer to standard identification
mechanism. Do you make use of persistent and unique identifiers such as
Digital Object Identifiers?

Outline which naming conventions will be used

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

</td>  
<td>

4\.

</td>  
<td>

Outline the approach towards search keyword

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

</td>  
<td>

5\.

</td>  
<td>

Outline the approach for clear versioning

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

</td>  
<td>

6\.

</td>  
<td>

Specify standards for metadata creation (if any). If there are no standards in
your discipline describe what type of metadata will be created and how

_All above questions are not relevant at present moment. Will be updated
later._

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

5.2 Making data openly accessible

</td>  
<td>

1\.

</td>  
<td>

Specify which data will be made openly available? If some data is kept closed
provide rationale for doing so

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

</td>  
<td>

2\.

</td>  
<td>

Specify how the data will be made available

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

</td>  
<td>

3\.

</td>  
<td>

Specify what methods or software tools are needed to access the data? Is
documentation about the software needed to access the data included? Is it
possible to include the relevant software (e.g. in open source code)?

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

</td>  
<td>

4\.

</td>  
<td>

Specify where the data and associated metadata, documentation and code are
deposited

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

</td>  
<td>

5\.

</td>  
<td>

Specify how access will be provided in case there are any restrictions

_All above questions are not relevant at present moment. Will be updated
later._

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

5.3. Making data interoperable

</td>  
<td>

1\.

</td>  
<td>

Assess the interoperability of your data. Specify what data and metadata
vocabularies, standards or methodologies you will follow to facilitate
interoperability.

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

</td>  
<td>

2\.

</td>  
<td>

Specify whether you will be using standard vocabulary for all data types
present in your data set, to allow inter-disciplinary

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

</td>  
<td>

interoperability? If not, will you provide mapping to more commonly used
ontologies?

_All above questions are not relevant at present moment. Will be updated
later._

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

5.4. Increase data reuse (through clarifying licences)

</td>  
<td>

  1. Specify how the data will be licenced to permit the widest reuse possible 

  

  2. Specify when the data will be made available for re-use. If applicable, specify why and for what period a data embargo is needed 

  

  3. Specify whether the data produced and/or used in the project is useable by third parties, in particular after the end of the project? If the re-use of some data is restricted, explain why 

  

  4. Describe data quality assurance processes 

  

  5. Specify the length of time for which the data will remain re-usable 

  

  

_All above questions are not relevant at present moment. Will be updated
later._

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

6\. Other

</td>  
<td>

Refer to other national/funder/sectorial/departmental procedures for data
management that you are using (if any)

_CERFACS rules for data management will be the primary set of guidelines to be
followed._

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

##  ESR 7: Alireza Ghasemi Khourinia (UT)  
  
<table>  
<tr>  
<th>

1\. Data summary

</th>  
<th>

1\.

</th>  
<th>

State the purpose of the data collection/generation

_Flow simulation results to be stored for further post processing and the
verification and validation process._

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

</td>  
<td>

2\.

</td>  
<td>

Explain the relation to the objectives of the project

_Simulation results are to be analysed and used to draw conclusions_

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

</td>  
<td>

3\.

</td>  
<td>

Specify the types and formats of data generated/collected _raw data in ASCI
format. Documents in pdf. Media files generated as movies and pictures._

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

</td>  
<td>

4\.

</td>  
<td>

Specify if existing data is being re-used (if any)

_Source code of SU2 as available through Github_

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

</td>  
<td>

5\.

</td>  
<td>

Specify the origin of the data

_Data is mainly generated in house_

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

</td>  
<td>

6\.

</td>  
<td>

State the expected size of the data (if known) _in the order of terabytes_

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

</td>  
<td>

7\.

</td>  
<td>

Outline the data utility: to whom will it be useful _researchers in the field
of CFD and combustion_

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

2\. Allocation of resources

</td>  
<td>

1\.

</td>  
<td>

Estimate the costs for making your data FAIR. Describe how you intend to cover
these costs _TBD_

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

</td>  
<td>

2\.

</td>  
<td>

Clearly identify responsibilities for data management in your project

_responsibilities are on ESR7 to manage the data in collaboration with his
supervisor and under the data management of UT_

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

</td>  
<td>

3\.

</td>  
<td>

Describe costs and potential value of long term preservation _external hard
drive and use of cloud storage should we choose to use it_

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

3\. Data security

</td>  
<td>

1\.

</td>  
<td>

Address data recovery as well as secure storage and transfer of sensitive data
_redundant backups to be made of the data._

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

4\. Ethical aspects

</td>  
<td>

1\.

</td>  
<td>

To be covered in the context of the ethics review, ethics section of DoA and
ethics deliverables. Include references and related technical aspects if not
covered by the former.

_decided based on Magister project policies and UT data management policies_

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

  5. FAIR Data 

  

  

5.1. Making data findable, including

</td>  
<td>

1\.

</td>  
<td>

Outline the discoverability of data (metadata provision) _decided based on
Magister project policies and UT data management policies_

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

</td>  
<td>

2\.

</td>  
<td>

Outline the identifiability of data and refer to standard identification
mechanism. Do you make use of persistent and

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

provisions for metadata

</th>  
<th>

</th>  
<th>

unique identifiers such as Digital Object Identifiers?

_doi will be used for publications only_

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

</td>  
<td>

3\.

</td>  
<td>

Outline which naming conventions will be used

_the format will be chosen to reflect the content and date of data generation_

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

</td>  
<td>

4\.

</td>  
<td>

Outline the approach towards search keyword _will be provided within
publications only_

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

</td>  
<td>

5\.

</td>  
<td>

Outline the approach for clear versioning

_Integer whole number versions with decimal points for iterative changes_

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

</td>  
<td>

6\.

</td>  
<td>

Specify standards for metadata creation (if any). If there are no standards in
your discipline describe what type of metadata will be created and how

_readme files might be included for better clarifications_

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

5.2 Making data openly accessible

</td>  
<td>

1\.

</td>  
<td>

Specify which data will be made openly available? If some data is kept closed
provide rationale for doing so

_the data will be made available to whom it might be of interest upon contact.
decided based on Magister project policies and UT data management policies_

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

</td>  
<td>

2\.

</td>  
<td>

Specify how the data will be made available

_available upon request in forms of hard copy and cloud storage if possible.
Decided based on Magister project policies and UT data management policies._

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

</td>  
<td>

3\.

</td>  
<td>

Specify what methods or software tools are needed to access the data? Is
documentation about the software needed to access the data included? Is it
possible to include the relevant software (e.g.

in open source code)?

_The data is mostly accessible in .vtk format as well as SU2 binaries._

_SU2 is an open source code available to public via GitHub._

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

</td>  
<td>

4\.

</td>  
<td>

Specify where the data and associated metadata, documentation and code are
deposited

_stored in external hard disks as well as a secondary redundant backup_

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

</td>  
<td>

5\.

</td>  
<td>

Specify how access will be provided in case there are any restrictions

_the data will be made available to individuals or organizations interested
upon contact should the sharing process is aligned with the policies of the
Magister project and UT. decided based on Magister project policies and UT
data management policies_

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

5.3. Making data interoperable

</td>  
<td>

1\.

</td>  
<td>

Assess the interoperability of your data. Specify what data and metadata
vocabularies, standards or methodologies you will follow to facilitate
interoperability.

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

</td>  
<td>

</td>  
<td>

_Data is readable through open source means. Proper naming schemes and readme
files will assist further interoperability_

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

</td>  
<td>

2\.

</td>  
<td>

Specify whether you will be using standard vocabulary for all data types
present in your data set, to allow inter-disciplinary interoperability? If
not, will you provide mapping to more commonly used ontologies?

_data is readable through open source means_

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

5.4. Increase data reuse (through clarifying licences)

</td>  
<td>

1\.

</td>  
<td>

Specify how the data will be licenced to permit the widest reuse possible

_decided based on Magister project policies and UT data management policies_

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

</td>  
<td>

2\.

</td>  
<td>

Specify when the data will be made available for re-use. If applicable,
specify why and for what period a data embargo is needed

_decided based on Magister project policies and UT data management policies_

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

</td>  
<td>

3\.

</td>  
<td>

Specify whether the data produced and/or used in the project is useable by
third parties, in particular after the end of the project? If the re-use of
some data is restricted, explain why _decided based on Magister project
policies and UT data management policies_

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

</td>  
<td>

4\.

</td>  
<td>

Describe data quality assurance processes

_redundant backups are to be made of the data for further assurance_

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

</td>  
<td>

5\.

</td>  
<td>

Specify the length of time for which the data will remain re-usable _decided
based on Magister project policies and UT data management policies_

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

6\. Other

</td>  
<td>

Refer to other national/funder/sectorial/departmental procedures for data
management that you are using (if any) _In alignment with data policies of UT_

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

##  ESR 8: Francesco Garita (University of Cambridge)  
  
<table>  
<tr>  
<th>

1\. Data summary

</th>  
<th>

1\.

</th>  
<th>

Data collection/generation is a fundamental aspect of research, especially in
engineering. A deep understanding of physical phenomena is based on data
production/acquisition.

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

</td>  
<td>

2\.

</td>  
<td>

The aim of the project is to improve our understanding on thermoacoustic
instabilities in gas turbines. This can only be achieved by combining low-
order models and numerical simulations with experimental data. Thus, data
collection/generation is a fundamental aspect of this project.

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

</td>  
<td>

3\.

</td>  
<td>

At the moment, the raw data that have been produced are simply text files with
“.dat” extension.

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

</td>  
<td>

4\.

</td>  
<td>

At the moment, no existing data have been re-used.

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

</td>  
<td>

5\.

</td>  
<td>

The data produced so far come from experiments carried out on a laboratory rig
installed in the Engineering Department. At a later stage, data will be
acquired also from other sources (e.g. Rolls Royce, etc.). Details will be
provided at a later stage.

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

</td>  
<td>

6\.

</td>  
<td>

The data produced so far are not larger than 1 GB. This number will of course
change over time, therefore it is not possible to provide at the moment an
expected size for the data produced at the end of the project.

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

</td>  
<td>

7\.

</td>  
<td>

The data produced during this project will be used to publish papers. In
addition to this, some people working in the Engineering Department of the
Cambridge University may use them for their purposes – in this case a
collaboration will be established. Eventually, other MAGISTER ESRs may benefit
from these data as well, even though at the moment no partnership has been
established.

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

2\. Allocation of resources

</td>  
<td>

1\.

</td>  
<td>

At the moments I do not expect any cost for making my data FAIR. This will
become relevant only at a later stage when/if very large datasets will be
produced.

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

</td>  
<td>

2\.

</td>  
<td>

I (Francesco Garita) will be the main person responsible for data management.
Following me, my supervisor (Prof. Matthew Juniper) and, more in general, the
University of Cambridge will have responsibilities as well.

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

</td>  
<td>

3\.

</td>  
<td>

Again, this will be a relevant problem only for very large datasets. At the
moment, I do not consider this to be a problem. My supervisor (Prof. Matthew
Juniper) has offered his personal website for data storage. Alternatively, the
official UCAM’s data server can be used (  _www.data.cam.ac.uk_ )  . In either
case, this will not have any cost in my opinion, unless we deal with very
large datasets.

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

3\. Data security

</th>  
<th>

1\.

</th>  
<th>

Once the project data will be stored on a proper data server (e.g. UCAM’s data
server), we will make sure that these data can be easily accessed and that
they cannot be overwritten or modified by any users. We will also make sure to
have a copy of these data on physical storage devices to avoid any hacking
attack. If sensitive data will be stored, the storage will be made secure
through encryption.

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

4\. Ethical aspects

</td>  
<td>

1\.

</td>  
<td>

Nothing to report at the moment. .

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

  5. FAIR Data 

  

  

5.1. Making data findable, including provisions for metadata

</td>  
<td>

1\.

2\.

</td>  
<td>

Each dataset, that will be made available at the end of the project, will be
thoroughly described using “README” text files.

Each dataset, that will be made available at the end of the project, will be
identified using a unique DOI. The way of structuring these data will be
discussed with the project management at the end of the project.

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

</td>  
<td>

3\.

</td>  
<td>

This will be discussed with the project management towards the end of the
project. At the moment I can only say that the name of each file should
contain the number each ESR is associated to (in my case 8).

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

</td>  
<td>

4\.

</td>  
<td>

The name of each file should contain specific keywords in order to ease the
search of a file by a general user.

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

</td>  
<td>

5\.

</td>  
<td>

At the end of the project, only latest (i.e. most updated) data versions will
be made available. In case more than one version is needed, then it will be
made clear the order in which the different versions have been produced.

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

</td>  
<td>

6\.

</td>  
<td>

For each dataset, I will create specific “README” text files with the goal of
appropriately describe the dataset (variables, etc.). This in order to ease
the comprehension by the final user.

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

5.2 Making data openly accessible

</td>  
<td>

1\.

</td>  
<td>

My supervisor and I are completely available to share the data that I will
produce during the project. Only some of these data may not be made open-
access. These will be data collected during my industrial secondment at Rolls
Royce. The decision of making these data open-access will be entirely taken by
Rolls Royce, not by me.

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

</td>  
<td>

2\.

</td>  
<td>

The data will be made available through the personal website of my supervisor

(http://www2.eng.cam.ac.uk/~mpj1001/MJ_biography.html) and/or through the
UCAM’s data server (  _www.data.cam.ac.uk_ )  .

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

</td>  
<td>

3\.

</td>  
<td>

At the moment, I do not foresee the need of specific softwares to access the
data, as the ones produced so far are simply text files in “.dat” format.

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

</td>  
<td>

4\.

</td>  
<td>

See point 2.

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

</td>  
<td>

5\.

</td>  
<td>

In case of restrictions we could create encripted data so that for example
only MAGISTER ESRs can access them. In this case, a username and a password
will be assigned to each ESR.

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

5.3. Making data interoperable

</td>  
<td>

1\.

</td>  
<td>

During the 3-years project, data will be shared using the online toolbox
provided by GE. This toolbox has been created on purpose by GE, and only
members of the MAGISTER project will be able to access it. By creating on this
toolbox folders related to each of the 15 ESRs, it will become easy and clear
to identify which data belong to who.

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

</td>  
<td>

2\.

</td>  
<td>

I will adopt standard vocabularies for all data types present in my datasets
in order to ease the comprehension by the final user.

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

5.4. Increase data reuse (through clarifying licences)

</td>  
<td>

1\.

</td>  
<td>

The data produced by me will not specifically need a license as far as I know.
The data produced at Rolls Royce will instead require a license. This will be
discussed at a later stage with the company itself.

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

</td>  
<td>

2\.

</td>  
<td>

The final data will be made available at the end of the project. Partial data
will be made available through the GE toolbox when other ESRs need them.

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

</td>  
<td>

3\.

</td>  
<td>

As already explained, my supervisor and I are completely in favour of sharing
data. Possible restrictions may be related to the data produced during the
industrial secondment at Rolls Royce.

However, these will be a small portion.

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

</td>  
<td>

4\.

</td>  
<td>

Usually my approach is to ask one of my colleagues to take a look at my data
to see whether they can be understood. This generally guarantees that other
users will find the description of my data clear enough.

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

</td>  
<td>

5\.

</td>  
<td>

The length of time for which the data will remain re-usable (i.e. available
online) depends on the university in case we will use the UCAM’s data server.
If instead we use my supervisor’s website, these data can stay theoretically
there forever.

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

6\. Other

</td>  
<td>

</td>  
<td>

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

##  ESR 9: Alireza Javareshkian (TUM)  
  
<table>  
<tr>  
<th>

1\. Data summary

</th>  
<th>

1\.

</th>  
<th>

State the purpose of the data collection/generation The data should be
generated in accordance with the project master plan. _The already generated
data will be aggregated and sorted to extract the useful data and finally
useful data will be collected and stored._

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

</td>  
<td>

_2._

</td>  
<td>

Explain the relation to the objectives of the project

_Through the experimental and numerical phases of the project, the data will
be generated, among which, useful data will be extracted._

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

</td>  
<td>

_3._

</td>  
<td>

Specify the types and formats of data generated/collected _Not yet specified_

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

</td>  
<td>

4\.

</td>  
<td>

Specify if existing data is being re-used (if any) _Not yet specified_

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

</td>  
<td>

5\.

</td>  
<td>

Specify the origin of the data _The data will be generated via measurement
techniques through experimental phase or CFD simulations through numerical
phase of the project._

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

</td>  
<td>

6\.

</td>  
<td>

State the expected size of the data (if known) _Not yet estimated_

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

</td>  
<td>

7\.

</td>  
<td>

Outline the data utility: to whom will it be useful _The already collected
data, will be stored and permanent access will be allocated to the Chair of
Thermodynamics at TUM._

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

2\. Allocation of resources

</td>  
<td>

1\.

</td>  
<td>

Estimate the costs for making your data FAIR. Describe how you intend to cover
these costs _Not yet estimated._

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

</td>  
<td>

2\.

</td>  
<td>

Clearly identify responsibilities for data management in your project _Not yet
assigned._

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

</td>  
<td>

3\.

</td>  
<td>

Describe costs and potential value of long term preservation _Not yet
estimated._

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

3\. Data security

</td>  
<td>

1\.

</td>  
<td>

Address data recovery as well as secure storage and transfer of

sensitive data _The useful data will be stored on LeibnizRechenzentrum cloud
and will be routinely backed up._

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

4\. Ethical aspects

</td>  
<td>

1\.

</td>  
<td>

To be covered in the context of the ethics review, ethics section of DoA and
ethics deliverables. Include references and related technical aspects if not
covered by the former.

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

  5. FAIR Data 

  

  

5.1. Making data findable, including provisions for metadata

</td>  
<td>

1\.

2\.

</td>  
<td>

Outline the discoverability of data (metadata provision) _A manual will be
prepared in which accessing to the datasets is outlined_

Outline the identifiability of data and refer to standard identification
mechanism. Do you make use of persistent and unique identifiers such as
Digital Object Identifiers? _Not yet specified_

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

</th>  
<th>

_3._

</th>  
<th>

Outline which naming conventions will be used _Will be specified over the
course of time._

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

</td>  
<td>

4\.

</td>  
<td>

Outline the approach towards search keyword _Will be specified_

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

</td>  
<td>

5\.

</td>  
<td>

Outline the approach for clear versioning _Will be specified_

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

</td>  
<td>

6\.

</td>  
<td>

Specify standards for metadata creation (if any). If there are no standards in
your discipline describe what type of metadata will be created and how _Not
specified yet_ .

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

5.2 Making data openly accessible

</td>  
<td>

1\.

</td>  
<td>

Specify which data will be made openly available? _If some data is kept closed
provide rationale for doing so Not clear yet_ .

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

</td>  
<td>

2\.

</td>  
<td>

Specify how the data will be made available _Not clear yet._

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

</td>  
<td>

_3._

</td>  
<td>

Specify what methods or software tools are needed to access the data? Is
documentation about the software needed to access the data included? Is it
possible to include the relevant software (e.g. in open source code)? _Will be
specified upon having decided about the prior issues._

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

</td>  
<td>

4\.

</td>  
<td>

Specify where the data and associated metadata, documentation and code are
deposited _So far, the Leibniz-Rechenzetrum is considered as the main
repository._

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

</td>  
<td>

5\.

</td>  
<td>

Specify how access will be provided in case there are any restrictions
_Permanent access will be granted to Chair of Thermodynamics at TUM._

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

5.3. Making data interoperable

</td>  
<td>

1\.

</td>  
<td>

Assess the interoperability of your data. Specify what data and metadata
vocabularies, standards or methodologies you will follow to facilitate
interoperability. _Will be characterized_

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

</td>  
<td>

2\.

</td>  
<td>

Specify whether you will be using standard vocabulary for all data types
present in your data set, to allow inter-disciplinary interoperability? If
not, will you provide mapping to more commonly used ontologies? _Will be
specified_ .

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

5.4. Increase data reuse (through clarifying licences)

</td>  
<td>

1\.

2\.

</td>  
<td>

Specify how the data will be licenced to permit the widest reuse possible _Not
specified yet._

Specify when the data will be made available for re-use. If applicable,
specify why and for what period a data embargo is needed _Not specified yet._

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

</td>  
<td>

_3._

</td>  
<td>

Specify whether the data produced and/or used in the project is useable by
third parties, in particular after the end of the project? If the re-use of
some data is restricted, explain why _Not specified yet._

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

</td>  
<td>

4\.

</td>  
<td>

Describe data quality assurance processes QA processes will be specified.

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

</td>  
<td>

5\. Specify the length of time for which the data will remain re-usable

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

6\. Other

</td>  
<td>

Refer to other national/funder/sectorial/departmental procedures for data
management that you are using (if any)

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

</td>  
<td>

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

##  ESR 10: Edmond Shehadi (UT)

Due to the stringent emission regulations and international climate
agreements, aircraft engine technology needs to improve. Of the most important
aspects considered to address this situation
aremoreefficientcombustionbymeansofhighercompressionratiosaswellasacleanercombustion
process altogether. As part of 15 early-stage researchers within the EU, the
MAGISTER project aims to address this problem through the use of machine
learning (ML). Such ML algorithms would help better autonomously adapt the
thermoacoustics from lower to higher technology readiness levels (TRL). In
turn, this will allow for a better, more efficient engine design procedure
that takes into consideration the thermoacoustic disturbances generated
therein.

The aim of this PhD project is a two-fold. First, it will further develop the
open-source CFD code SU2  1  by extending high-order discretization methods,
particularly, the discontinuous Galerkin (dG) method, in order to achieve
high-fidelity simulations in combuster liner and dilution holes. This
procedure is performed using large-eddy simulation (LES) and by implementing,
as well as comparing, different subgrid-scale (SGS) models. Second, utilize
the dG method, in conjunction with LES, on compressible turbulent flow within
the SU2 framework in order to study the acoustic behavior inside such engine
regions. This, in turn, will give rise to relatively more accurate results via
high-order numerical – both spatial and temporal – simulations.

Eventually, provided everything works out, such work will assist other
scientists and engineers to better understand how the acoustics induced by
mechanical and thermal vibrations effect the performance of jet engines.
Accordingly, such a deliverable will help better design and optimize existing
products that are subject to high acoustic instabilities and turbulence, in a
relatively more accurate manner.  
  
<table>  
<tr>  
<th>

1\. Data summary

</th>  
<th>

Simulations about a confined geometry involving compressible turbulent flow
are done and the resulting statistics are gathered for post-processing. Such
simulations assist in validating the open-source dG solver and provide for a
better, more accurate acoustical representation in combustor liner and
dilution holes.

Existing data from such simulations might be re-used for reproducibility
and/or additional correlations that give better insight about the overall
performance of the numerical procedure. All data are generated from the SU2
open-source code and use the .su2 format.

The amount of data for the simulations can easily be 100s of Gb, given the
many simulations that are carried out. However, the instantaneous solution is
deleted, due to its size, after extracting the necessary temporally- and/or
spatially-averaged statistical quantities. For a large number of files, these
averaged data are saved in CGNS format.

All entire simulations mentioned will utilize the dG solver in SU2, which is
being developed to tackle such flows. Hence, part of the data is also involved
in contributing to the SU2 framework in .cpp and .h format and on its main
Github  2  repository. Thus, the output of the data is a twofold: extend the
open-source SU2 code such that it is able to simulate such

</th> </tr> </table>

  1. _https://su2code.github.io/_

  

  2. _https://github.com/_

  

  
  
<table>  
<tr>  
<th>

</th>  
<th>

physics and eventually both validate and study the acoustics in jet engines
using such a tool. Such results are useful for researchers, both at academia
and industry, interested in better understanding how acoustics from turbulence
are generated and to what role they play, using relatively lesser
computational resources than the current state-of-the-art.

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

2\. Allocation of resources

</td>  
<td>

The extension of the SU2 code is done on its Github repository. This allows
anyone interested in using such a tool, or further improving on it, to do so
free of charge – hence open-source.

The data generated using such a code will include the required statistics
only. In the likelihood of the need to repeat certain simulations, the mesh
file as well as the input .cfg files used in SU2 will be provided. These files
may be stored at the 4TU data center, provided it has a data seal of approval.
Costs for these statistics is negligible, since they reduce to a few gigabytes
worth of information. Up until this point, no need for long-term preservation
of any data is discussed.

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

3\. Data security

</td>  
<td>

The data are collected from the cluster at the University of Twente (EFD
department) and are stored on the local workstation of the host. Backups are
done in a regular manner using external (portable) hard drives.

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

4\. Ethical aspects

</td>  
<td>

To be covered in the context of the ethics review, ethics section of DoA and
ethics deliverables. Include references and related technical aspects if not
covered by the former.

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

  5. FAIR Data 

  

  

5.1. Making data findable, including provisions for metadata

</td>  
<td>

The data used in the SU2 code is available on the public Github repository. As
for the simulation data, the MAGISTER consortium has to approve which is
suitable for public exposure.

The naming convention used is based on the following model:
physics_Model_Time_SimNumber, whereby “physics” refers to the actual physics
(e.g. acoustics), “model” is the turbulence model used in LES,

“Time” denotes the fine time-step used in the simulation and “SimNumber” is a
lexicographic numbering applied on different simulations.

Some of the search keywords are: turbulence, LES, dG, computational acoustics,
non-reflective boundary conditions.

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

5.2 Making data openly accessible

</td>  
<td>

The code, by definition of open-source, is publicly accessible for use and
modifications. The data obtained from using such a code in different
simulations need to be agreed upon by the MAGISTER project consortium before
sharing outside of the involved partners.

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

5.3. Making data interoperable

</td>  
<td>

When contributing to the SU2 code, the main developers’

recommendations are heeded; this includes variable naming conventions, certain
programming styles, separation of source and header files, source code
compliance with the C++ ISO/ANSI standard… etc.

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

5.4. Increase data reuse (through clarifying licences)

</td>  
<td>

License for use of SU2 is given under the GNU Lesser General Public License,
version 2.1.

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

6\. Other

</td>  
<td>

\--

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

##  ESR 11: Thomas Christou (KIT)  
  
<table>  
<tr>  
<th>

1\. Data summary

</th>  
<th>

1\.

</th>  
<th>

The data includes the local velocities in two directions and the local droplet
size distribution. With the expected data, the influence of oscillating flow
on spray quality shall be investigated and quantified.

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

</td>  
<td>

2\.

</td>  
<td>

The time-dependent data will be analysed in frequency space in order to
investigate the impact of flow oscillation on the droplet size distribution.

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

</td>  
<td>

3\.

</td>  
<td>

Text format, pictures

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

</td>  
<td>

4\.

</td>  
<td>

No existing data is being re-used

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

</td>  
<td>

5\.

</td>  
<td>

Phase-Doppler-Anemometry measurements, camera

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

</td>  
<td>

6\.

</td>  
<td>

Expected size of the data: 10GB

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

</td>  
<td>

7\.

</td>  
<td>

The data will be used within the project in WP4.

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

2\. Allocation of resources

</td>  
<td>

1\.

</td>  
<td>

The data will be allocated at servers of the KIT. The preservation of data has
usually a life-time of 10 years, however a prolongation can be requested. The
preservation costs are paid by a yearly budget of the KIT.

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

3\. Data security

</td>  
<td>

1\.

</td>  
<td>

The KIT is subject to the legal data protection regulations of the European
Union (General Data Protection Regulation, GDPR) and the Landesdatenschutz of
Baden-Württemberg (from 20.06.2018).

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

</td>  
<td>

2\.

</td>  
<td>

The backup of the project-related data and its long-term use is ensured by a
subject-specific folder and filing system as well as by securing the raw and
result data. The data archiving takes place via a mass memory and a tape
drive. These are secured by emergency power supply and CO  2  fire
extinguishing. Hard disks are

automatically mirrored. There is an access security. For the transfer of
sensitive data, the state Baden-Württemberg of Germany provides a secured
share platform (bwSync&Share) for their universities.

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

4\. Ethical aspects

</td>  
<td>

1\.

</td>  
<td>

No ethical violation are to be expected with the targeted data and the
produced data will be in accordance to the ethics section of the DoA.

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

  5. FAIR Data 

  

  

5.1. Making data findable, including provisions for metadata

</td>  
<td>

1\.

</td>  
<td>

The FAIR data management plan will be specified in a later stage in
coordination with the partners.

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

5.2 Making data openly accessible

</td>  
<td>

</td>  
<td>

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

5.3. Making data interoperable

</td>  
<td>

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

5.4. Increase data reuse (through clarifying licences)

</td>  
<td>

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

6\. Other

</td>  
<td>

bwSync&Share

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

</td>  
<td>

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

##  ESR 12: Sara Navarro Arredondo (UT)  
  
<table>  
<tr>  
<th>

1\. Data summary

</th>  
<th>

1\.

</th>  
<th>

State the purpose of the data collection/generation

_The purpose of the data generated is to make a characterization of
acoustically forced and unforced kerosene spray flames at elevated pressure
and preheated air, to generate a base data that can contribute to the machine
learning generation._

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

</td>  
<td>

2\.

</td>  
<td>

Explain the relation to the objectives of the project

_To collect experimental data of the acoustics of the combustion of aircraft
fuels and to compared it with modelling data._

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

</td>  
<td>

3\.

</td>  
<td>

Specify the types and formats of data generated/collected

_Model parameter values (.cvs file), model imput data (.csv file), model
scripts (.mgf, .csv), model output (.csv, .text file), manuscripts (word),
others (adobe, word, excel)_

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

</td>  
<td>

4\.

</td>  
<td>

Specify if existing data is being re-used (if any)

_Operating parameters from previous research work related to the DESIRE
combustor at CWT UT._

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

</td>  
<td>

5\.

</td>  
<td>

Specify the origin of the data

_Research PhD projects of Jaap van Kampen and Mehmet Kapucu, at the CWT UT._

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

</td>  
<td>

6\.

</td>  
<td>

State the expected size of the data (if known)

_About 20 GB of research data (gross estimation)_

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

</td>  
<td>

7\.

</td>  
<td>

Outline the data utility: to whom will it be useful

_The data generated will be useful within the other member of the_

_MAGISTER project, particularly with ESR11 and ESR06_

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

2\. Allocation of resources

</td>  
<td>

1\.

</td>  
<td>

Estimate the costs for making your data FAIR. Describe how you intend to cover
these costs

_TBD_

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

</td>  
<td>

2\.

</td>  
<td>

Clearly identify responsibilities for data management in your project

_I am responsible for collecting and managing the data used in my research, in
consultation with my supervisor_

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

</td>  
<td>

3\.

</td>  
<td>

Describe costs and potential value of long term preservation

_TBD_

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

3\. Data security

</td>  
<td>

1\.

</td>  
<td>

Address data recovery as well as secure storage and transfer of sensitive data

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

</th>  
<th>

</th>  
<th>

_At the end of the project, data will be made publically available under the
restricted ruled by UT and the supervisor will receive a full copy of the
data._

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

4\. Ethical aspects

</td>  
<td>

1\.

</td>  
<td>

To be covered in the context of the ethics review, ethics section of DoA and
ethics deliverables. Include references and related technical aspects if not
covered by the former.

_No additional points._

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

  5. FAIR Data 

  

  

5.1. Making data findable, including provisions for metadata

</td>  
<td>

1\.

</td>  
<td>

Outline the discoverability of data (metadata provision)

_For all input data, one document containing all metadata will be created,
specifying at least source, time period, measurement method, type of data,
unit of measurement, access rights, date downloaded. All data will be checked
for consistency, and any changes made to input data will be documented._

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

</td>  
<td>

2\.

</td>  
<td>

Outline the identifiability of data and refer to standard identification
mechanism. Do you make use of persistent and unique identifiers such as
Digital Object Identifiers?

_Yes._

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

</td>  
<td>

3\.

</td>  
<td>

Outline which naming conventions will be used _To be specified later._

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

</td>  
<td>

4\.

</td>  
<td>

Outline the approach towards search keyword

_Combustion, atomization, fuel atomization, kerosene combustion, acoustic
oscillation, acoustic instabilities in combustion, machine learning_

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

</td>  
<td>

5\.

</td>  
<td>

Outline the approach for clear versioning

_Going for articles published in recognized and specialized magazines_

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

</td>  
<td>

6\.

</td>  
<td>

Specify standards for metadata creation (if any). If there are no standards in
your discipline describe what type of metadata will be created and how

_By specifying at least source, time period, measurement method, type of data,
unit of measurement, access rights, date downloaded. All data will be checked
for consistency, and any changes made to input data will be documented._

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

5.2 Making data openly accessible

</td>  
<td>

1\.

</td>  
<td>

Specify which data will be made openly available? If some data is kept closed
provide rationale for doing so

_Data obtained is expect to be accessible to others that may use it to further
experimentations and it is intended to make these publically available._

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

</th>  
<th>

2\.

</th>  
<th>

Specify how the data will be made available

_By publishing results and methodology in divulgation journals and at the UT
catalogue._

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

</td>  
<td>

3\.

</td>  
<td>

Specify what methods or software tools are needed to access the data? Is
documentation about the software needed to access the data included? Is it
possible to include the relevant software (e.g. in open source code)?

_TBD_

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

</td>  
<td>

4\.

</td>  
<td>

Specify where the data and associated metadata, documentation and code are
deposited

_The data will be storage in the local hard disk of my laptop._

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

</td>  
<td>

5\.

</td>  
<td>

Specify how access will be provided in case there are any restrictions

_TBD_

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

5.3. Making data interoperable

</td>  
<td>

1\.

</td>  
<td>

Assess the interoperability of your data. Specify what data and metadata
vocabularies, standards or methodologies you will follow to facilitate
interoperability.

_A methodology will be delivered to make easy access of the data obtained._

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

</td>  
<td>

2\.

</td>  
<td>

Specify whether you will be using standard vocabulary for all data types
present in your data set, to allow inter-disciplinary interoperability? If
not, will you provide mapping to more commonly used ontologies?

_Standard vocabulary will be mainly used. If necessary a mapping of the terms
will be delivered._

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

5.4. Increase data reuse (through clarifying licences)

</td>  
<td>

1\.

</td>  
<td>

Specify how the data will be licenced to permit the widest reuse possible

_TBD_

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

</td>  
<td>

2\.

</td>  
<td>

Specify when the data will be made available for re-use. If applicable,
specify why and for what period a data embargo is needed _TBD_

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

</td>  
<td>

3\.

</td>  
<td>

Specify whether the data produced and/or used in the project is useable by
third parties, in particular after the end of the project? If the re-use of
some data is restricted, explain why

_TBD_

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

</td>  
<td>

4\.

</td>  
<td>

Describe data quality assurance processes

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

</td>  
<td>

_TBD_

5\. Specify the length of time for which the data will remain re-usable _TBD_

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

6\. Other

</td>  
<td>

Refer to other national/funder/sectorial/departmental procedures for data
management that you are using (if any)

_Not applicable_

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

</td>  
<td>

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

##  ESR 13: Michael McCartney (GEDE)  
  
<table>  
<tr>  
<th>

1\. Data summary

</th>  
<th>

1\.

</th>  
<th>

Data will be generated to describe the ability of ML algorithms to extrapolate
data sets and predict onset of combustion instabilities.

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

</td>  
<td>

2\.

</td>  
<td>

Data generated will be stored in .csv format

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

</td>  
<td>

3\.

</td>  
<td>

Existing data from GE combustor tests will be used

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

</td>  
<td>

4\.

</td>  
<td>

Size of data generated is not currently known

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

</td>  
<td>

5\.

</td>  
<td>

Conclusions and summary statistics of data generated will be useful to GEDE
and the combustion community. The data itself will only be of use to GEDE.

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

2\. Allocation of resources

</td>  
<td>

1\.

</td>  
<td>

Data generated will be confidential to GEDE and so costs associated with long
term preservation will be carried by them.

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

</td>  
<td>

2\.

</td>  
<td>

Data management will be carried out by ESR13 in line with GEDE data management
practices.

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

3\. Data security

</td>  
<td>

1\.

</td>  
<td>

Data storage and transfer will be managed in line with GEDE data management
practices and will make use of the GE Box cloud solution and GE Github that
provide sercure storage and recovery.

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

4\. Ethical aspects

</td>  
<td>

1\.

</td>  
<td>

N/A

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

  5. FAIR Data 

  

  

5.1. Making data findable, including provisions for metadata

</td>  
<td>

1\.

</td>  
<td>

Metadata and DOIs will be generated in line with general guidelines in the
DMP.

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

5.2 Making data openly accessible

</td>  
<td>

1\.

</td>  
<td>

Conclusions and summary statistics of data generated will be made openly
available. The data itself will be confidential to GEDE and so will not be
shared.

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

</td>  
<td>

2\.

</td>  
<td>

Relevant data will be made available through journal articles and in the
trusted repository defined in the DMP.

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

5.3. Making data interoperable

</td>  
<td>

1\.

</td>  
<td>

Metadata and DOIs will be generated in line with general guidelines in the DMP

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

5.4. Increase data reuse (through clarifying licences)

</td>  
<td>

1\.

</td>  
<td>

Conclusions and summary statistics of data generated will be made openly
available. The data itself will be confidential to GEDE and so will not be
shared.

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

6\. Other

</td>  
<td>

Internal GE processes on data management, IP protection and confidentiality
still apply.

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