concurrently develop the applications, micro-benchmarks, software tools and
transprecision algorithms. This repository will remain private during the
first phase of development.

But, as soon as the work in the project will be mature enough to be shared
with the public community, we will create a branch for releasing a public
version of our work on GitHub openly.

Github is a web application that is perfectly well suited to allow a free FAIR
access to Software code and the following table resumes its characteristics:  
  
<table>  
<tr>  
<th>

**Fair Data**

</th>  
<th>

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

**How Data is findable**

</td>  
<td>

Github allows source code to be easily findable through a search engine as: o
Github is very well referenced on Google Search because it’s the largest host
of source code in the world for opensource and private software projects with
20 millions users and 57 millions repositories.

  * Each project page comes with a short description (metadata) that describes the project on a search engine (see fig 1). o As Github takes care of naming all releases, we do not use any naming convention other than common sense for naming all source code files and libraries. 

  

  * A list of search keywords specific to the project can be specified for each project underneath the metadata description, making the project easily findable through a search engine. 

  

  * Github has a clear version control system that records changes to a file or a set of files over time so that specific versions can be recalled later. And this can be done for nearly any type of file on a computer. Of course, the whole project team will make use of this system. 

  

  * We do not have any metadata standard, but for each file stored by the team on Github, a short textual description of the file content will be entered each time a new file will be uploaded. 

  

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

**How data is openly accessible**

</td>  
<td>

Most of the source code and its associated metadata generated during the
lifespan of the project will be on a Github repository that allows data to be
openly accessible.

The source code will be accessible by two ways:

  * A link to our OPRECOMP Github repository on our OPRECOMP website. 

  

  * By search engine when typing the right keywords. 

  

Once on our Github repository, the data can be downloaded by clicking on the
green button of the main repository page (see Fig1).

In case of any restriction, Github allows to restrict the access to some
repositories or sub-repositories to a group of people that will be invited.

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

**How data is interoperable**

</td>  
<td>

Source codes are written in well-known standard software languages (C/C++,
python, etc.) using standard libraries (STD, etc..) or open source platforms
(Tensorflow for example). Comments inside source code as well as the metadata
describing the files and the associated documents (reports, user’s manuals,
etc.) will all be written in English.

We will not force partners of this project to use a standard vocabulary for
all data types present in our data set and rely on each member common sense to
name things.

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

**How data is reusable**

</td>  
<td>

Github is structured to foster interoperability and reusability:

• On the main repository page, a longer description of the project will
explain how to install the code, use it, and contribute to the project

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

</td>  
<td>

</td>  
<td>

(see Fig 2).

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

</td>  
<td>

•

</td>  
<td>

A “contributors” widget leads to a list of project contributors

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

</td>  
<td>

•

</td>  
<td>

A “releases” widget leads to a documentation about all the different project
releases and their documentation

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

</td>  
<td>

•

</td>  
<td>

A “branch” widget leads to all the currently opened or closed branches of the
project.

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

</td>  
<td>

•

</td>  
<td>

The core of the project page lists all the folders/files of the project, with
their short description (fig 3)

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

</td>  
<td>

•

</td>  
<td>

Consortium partners will use an appropriate licensing model for their
contributions that will be hosted on GitHub. In some cases, where our
contributions are built on existing packages, we may be forced to use a
specific licensing model (i.e. additions to a GPL package, will have to remain
GPL). For contributions, where there are no limitations, the contributing
partner will chose an appropriate licensing model (GPL, LGPL, BSD, Solderpad
license).

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

</td>  
<td>

•

</td>  
<td>

During the project lifespan, we plan to deliver regular code releases and the
code will be released as soon as a release is ready (code source working for
targeted benchmarks). And in any case, the code will be released at the end of
the project. As of now, no code embargo is envisioned.

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

</td>  
<td>

•

</td>  
<td>

Source code will be reusable by third parties, just downloading the Github
repository dedicated to our project. This repository will contain the
necessary documentation to compile and run the source code on the provided
benchmarks.

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

</td>  
<td>

•

</td>  
<td>

Each development group in the project will be responsible of its own code
quality. We consider that code quality is a development issue, not a testing
issue. Thus, we are embedding testing practices inside development through an
incremental process consisting of writing some code along with its unit
testing functions, testing it, making it reviewed by some peers, check it in
along with the test functions, writing some new code, etc. . Additionally, as
soon as enough code has been developed to test our targeted benchmarks, we
will test it against it.

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

</td>  
<td>

•

</td>  
<td>

IBM and ETH are committed to keep the infrastructure for hosting the data as
well as its backups way past the end of the project.

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

**Table1:** Fair data management characteristics for Software code and
benchmarks/test benches results

**FIG1** : An example of a Github project webpage (Tensorflow project)

**FIG2:** Example of a project description with code source installation and
contribution guidelines (Tensorflow

Project)

**Fig 3:** Github web page: List of all Project folders and files (Tensorflow
Project)  
  
<table>  
<tr>  
<th>

**Other DMP components**

</th>  
<th>

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

**Allocation of resources**

</td>  
<td>

Github is free to use for public and open source projects. It would cost us
something ($9 per user/month) only if we decided to restrict access to some
part of the code.

Data Management is a task of the WP9 work package and GreenWaves Technologies
is responsible of managing this task, but IBM and ETH are responsible of the
current and long term storage of the source code.

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

**Data Security**

</td>  
<td>

ETH Zurich and IBM are responsible to make periodic backups of the OPRECOMP
Github repository and will follow the procedures in place in their
organization. Currently, the GitLab server hosted at ETH Zurich makes
snapshots every three hours. Incremental backups are made daily, and full
backups every other week. All backup data is stored in two different physical
locations

As we plan to freely release our software code on the internet, we don’t need
to encrypt the data before any transfer of it. But, for some sensitive data
that we do not want to divulge, we will encrypt it before the transfer.

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

**Ethical aspects**

</td>  
<td>

Nothing to add to the DoA

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

**Other**

</td>  
<td>

Most of the partners are already using Github for their software code
management.

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

**Table2:** Other DMP components for software code and Benchmark and test
benches results

#  2.2 Benchmarks and test benches Results

We plan to do regular runs of benchmarks or test benches during the lifespan
of the project for all work packages dedicated to scientific developments. The
format of the data generated in the log files can differ (measurements, plots,
simulation results, etc.), but they will all be stored the same way in a
GitHub repository that will be publically available. This will allow tracking
the history of the changes/improvements. The FAIR data management
characteristics are almost the same as the one described in paragraph 2.1,
table 1. Except that once the benchmarks will be defined, their specification
will include a naming convention that the different partners will be entitled
to follow.

Other DMP components will also have the same characteristics (see Table 2).  
  
<table>  
<tr>  
<th>

**Work Package**

</th>  
<th>

**Data Set Description**

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

**WP1**

</td>  
<td>

No such data

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

**WP2**

</td>  
<td>

Simulation results for the error-energy relation. The data will be presented
in form of tables and figures.

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

**WP3**

</td>  
<td>

Simulation results (time, power, energy) about different heterogeneous memory
architectures. These results are fundamental to characterize the baseline as
well as the gain due to future transprecision techniques (approximate
storage). Data will be generated in log files mostly containing tables and
figures. Regular runs of typical test benches or benchmarks are scheduled
during the project lifespan and the generated data will be compared against
previous runs to measure modeling improvements.

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

**WP4**

</td>  
<td>

Compiled results of hardware performance numbers for different implementations
and different design parameters. This data will be presented in tables and
figures.

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

**WP5**

</td>  
<td>

Micro-benchmarks

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

**WP6**

</td>  
<td>

Log files and plots from benchmarks results

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

**WP7**

</td>  
<td>

Log files and plots from benchmarks results

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

**WP8**

</td>  
<td>

Log files from benchmark results

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

**WP9**

</td>  
<td>

No benchmarks delivered

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

#  2.3 Reports

Data will be also produced in the form of a considerable number of reports
(deliverables) that will be compiled from the studies and insights gained from
the work on the different work packages. Those reports are regular documents
with text, figures and tables and currently stored in our Box repository. They
will be openly accessible from the EU website accordingly to the dissemination
level indicated in the project grant agreement.  
  
<table>  
<tr>  
<th>

**Work Package**

</th>  
<th>

**Data Set Description**

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

**WP1**

</td>  
<td>

Reports for deliverables

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

**WP2**

</td>  
<td>

Reports describing the main results obtained for each WP2 task. The data will
be presented in form of written documents containing text, tables and figures.

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

**WP3**

</td>  
<td>

Deliverable Reports

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

**WP4**

</td>  
<td>

Deliverable Reports

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

**WP5**

</td>  
<td>

Reports from the studies and insights gained from the work on WP5 package.
Written documents containing mostly tables and figures.

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

**WP6**

</td>  
<td>

Deliverable Reports

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

**WP7**

</td>  
<td>

Deliverable Reports

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

**WP8**

</td>  
<td>

Deliverable reports after testing approximate computing mathematical library

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

**WP9**

</td>  
<td>

Deliverable Reports (DPM, Website design report) and Google Analytics reports
of the website traffic every two months.

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

#  2.4 Publications

All Work packages will deliver publications. Those publications will be
written using the LaTeX document preparation system. LaTeX includes features
designed for the production of technical and scientific documentation. It’s
the de facto standard for the communication and publication of scientific
documents. LaTeX Source documents are stored in a specific format that can be
assimilated to source code. Thus, we will store those files as the software
source code in a Gitlab repository at the ETH.

Pdf versions of those documents will be publically available in our Github
repository. Additionally, they will be published on different open access
platforms (paper repositories) commonly used by researchers, such as ArXiv,
Peer Evaluation, Figshare, etc. .We will choose the ones on which we will
publish our papers later.

The FAIR data management characteristics are strictly the same as the ones
described in paragraph 2.1, table1. Other DMP components will also have the
same characteristics (see Table 2 in the paragraph 2.1)

#  2.5 Media data: Videos

During the lifespan of the project, any project member might be interviewed or
create videos for tutorials or demonstrations of benchmarks. These videos will
be registered in a YouTube channel owned by a member of the project (WP9
leader) and also embedded on the webpage “Videos” of our OPRECOMP website.

On both Youtube and OPRECOMP website, videos will be stored in different
folders depending on the nature of the video:

  * Interviews 

  

  * Tutorials 

  

  * Demonstrations 

  

They will be publically available. The Youtube account and channel for
OPRECOMP will be created as soon as we will have videos to publish on it.  
  
<table>  
<tr>  
<th>

**Fair Data**

</th>  
<th>

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

**How is data findable?**

</td>  
<td>

All videos will be openly available on the OPRECOMP Youtube channel on the
World Wide Web.

Each video will come with its corresponding metadata: a title, a description
of its content, search keywords, category (science and technology) and
accessibility level (see Fig4)

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

**How is data openly accessible?**

</td>  
<td>

All videos created during the lifespan of the project will be openly
accessible two ways:

  * Through a search engine (via metadata and search keywords) 

  

  * They will be embedded on a page of the website under the menu 

  

“videos”

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

**How is data interoperable?**

</td>  
<td>

Through Youtube

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

**How you increase data re-use?**

</td>  
<td>

The video data will be licensed under the Youtube standard license. The videos
remain re-usable as long as we let them on Youtube. And it can remain forever,
as it’s free.

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

**Other DMP components**

</th>  
<th>

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

**Allocation of resources**

</td>  
<td>

Youtube is free, so making the videos FAIR costs only the time for somebody to
put the video online and add the requested metadata and optimum search
keywords (30 minutes)

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

**Data Security**

</td>  
<td>

Videos will be first stored on Youtube that has its own security system
(basically two copies of each element stored in three different servers
located in different WWW facilities).

We plan also to keep the videos in a repository of our Github’s account, which
will be also regularly backed by ETH or IBM staff members.

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

**Ethical aspects**

</td>  
<td>

Nothing to add to the DoA

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

**Other**

</td>  
<td>

Most of the partners are already using Github for their software code
management.

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

**Fig4:** Shows the video manager editor of Youtube with Video Title,
Description, search keywords, and accessibility level (Public here).

#  OPRECOMP Website: the core of our data management system

The OPRECOMP website is part of the WP9 package and is hosted by WPengine, a
worldwide sophisticated Wordpress hosting platform that handles the website
security and regular backups and comes with a bulletproof customer service in
English.

The website has been designed by GreenWaves Technologies, using the #1 selling
theme AVADA whose particularity is to have a Page editor with 50 short codes
with 100+ options that are controlled easily with a Fusion Builder’s drag and
drop system that doesn’t require any coding knowledge.

This website design architecture is thus well suited to be accessible by
anyone in the OPRECOMP team to write its own web pages or posts.

The website will be regularly updated with information about the OPRECOMP
development and links to the Data resources described in the previous
paragraphs, making it the primary platform to access our data system.

Of course, finding our website through a search engine is of primary
importance. Thus, we have put in place the following things to increase our
SEO (search engine optimization) ranking.

  * We’ve referenced our OPRECOMP website from all partners websites and from our twitter account. 

  

  * We’ve added to this website the YOAST SEO plugin for analyzing and optimizing web pages content on different criteria. 

  

  * We’ve linked our website to Google Analytics for tracking its traffic and improve our website visibility on the Internet. 

  

##  Yoast SEO Plugin

While this YOAST SEO plugin goes the extra mile to take care of all the
technical optimization, it first and foremost helps us write better content
and make sure the content we write is optimized to be easily findable by
search engines.

The first focus is the readability of the content and Yoast displays a
readability report of the website content with points to optimize (see red
points on Fig5):

**Fig5:** Yoast SEO readability report for the OPRECOMP landing page before
optimization

Yoast also provides help to edit/preview the website snippet (how the website
will look like in the search results):

**Fig6**

:

Snippet Editor/Viewer

This way, the Yoast plugin will help us not only increase rankings but also
increase the click through rate for organic search results.

This plugin also performs some page analysis by checking if the page has
images, whether there is an alt tag containing the focus keyword of the page,
whether a post is long enough, whether a meta description has been written, if
subheadings have been used, etc. .

Following is the SEO result analysis of OPRECOMP landing page:

**Fig7**

:

SEO analysis for OPRECOMP landing page

Some improvement still has to be done, but the overall rating of the page is
green already:

**Fig8:** overall Readability and SEO rating of the OPRECOMP landing page

##  Google Analytics

All along the project, we will track the website traffic and the behavior of
our visitors within the website and make the necessary corrections to improve
the visibility and usability of our website, trying to provide the best
possible information about our project.

As an example, Fig9 represents the Audience Overview of the OPRECOMP website
for the period of June 8-22, 2017. We already can see that the part of new
visitors is 67% and that our site has been visited by people in the EU
community (Switzerland, France, Italy, etc.) but also by foreigners in Canada
(24%), USA (2.7%) and India (1.35%). We can also see that visitors spent an
average of 3:40 minutes on the website, which is already pretty good.

**Fig9:** OPRECOMP Website Audience Overview given by Google Analytics

#  Conclusions

Thanks to modern and popular data management tools (Github for source code and
benchmarks, Youtube for videos, WPEngine and Wordpress for the website posts
and news, and Open Access Platforms for the publications) that are all in the
cloud and accessible through an internet connection, all European partners of
this project can use the same data management system, which is the clue to an
easy and FAIR delivery of our common work to the public and potential
contributors.

Additionally, we will take great care of our visibility on the internet
through an SEO optimization of any page or news post published on our website
via the Yoast SEO plugin and we will closely monitor the website traffic and
its visitors behavior using Google Analytics, the web analytics service of
Google.

#  Deviations from work plan

None