> For the complete documentation index, see [llms.txt](https://tu-clausthal.gitbook.io/good-research-practice-in-md-simulations-tuc-swz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://tu-clausthal.gitbook.io/good-research-practice-in-md-simulations-tuc-swz/readme/motivation.md).

# Motivation

In simulation work, reproducibility usually becomes important at inconvenient moments: when a figure has to be regenerated after revision, when a colleague asks how a structure was prepared, when a job needs to be rerun on another machine, or when someone inherits a project months after the original author moved on. At that point, the difference between a well-kept project and a messy one is immediate.

For SWZ projects, reproducibility is mostly a matter of routine. It means keeping input files, potential files, trajectories, analysis scripts, and notes in a predictable place. It means recording which version of LAMMPS was used, which cluster or node a run was performed on, and how a published result was derived from raw output. None of this is glamorous, but it saves time and prevents avoidable confusion.

This guide treats reproducibility as part of normal research practice rather than a special extra task. The aim is to make it easier to rerun simulations, check results, prepare replication packages, and publish data in a form that other people can actually use.

## FAIR Data Principles

The FAIR principles are a useful way to think about whether data will still be usable once it leaves the original working directory or the original author's laptop. FAIR stands for **F**indability, **A**ccessibility, **I**nteroperability, and **R**eusability.

### Findable

* (Meta)data are assigned a globally unique and persistent identifier
* Data are described with rich metadata
* Metadata clearly and explicitly include the identifier of the data they describe
* (Meta)data are registered or indexed in a searchable resource (e.g., a data repository)

### Accessible

* (Meta)data are retrievable by their identifier using a standardized communications protocol (e.g., HTTP/HTTPS)
* The protocol is open, free, and universally implementable
* The protocol allows for authentication and authorization procedures where necessary
* Metadata remain accessible even when the data are no longer available

> FAIR does not mean Open: "As Open as Possible, as Closed as Necessary."

### Interoperable

* (Meta)data use a formal, accessible, shared, and broadly applicable language for knowledge representation (e.g., controlled vocabularies, ontologies, thesauri)
* (Meta)data use vocabularies that follow FAIR principles
* (Meta)data include qualified references to other (meta)data (e.g., specifying if one dataset builds on another, properly citing all datasets)

### Reusable

* (Meta)data are richly described with a plurality of accurate and relevant attributes (e.g., metadata that describes the context under which data were generated, such as simulation parameters, interatomic potentials, and software versions)
* (Meta)data are released with a clear and accessible data usage license
* (Meta)data are associated with detailed provenance

### FAIR Resources

**Learning resources:**

* [FAIR Cookbook](https://faircookbook.elixir-europe.org/) (ELIXIR)
* [FAIR in (biological) practice](https://carpentries-incubator.github.io/fair-bio-practice/) (The Carpentries Incubator)
* [How to be FAIR with your data](https://doi.org/10.5281/zenodo.6657092) (Engelhardt et al., 2022)

**How to make data FAIR:**

* [PARTHENOS Guidelines to FAIRify data management](https://zenodo.org/record/2668479)
* [Top 10 FAIR Data & Software Things](https://librarycarpentry.org/Top-10-FAIR/)

**How to assess FAIRness:**

* [How FAIR are your data? (checklist)](https://doi.org/10.5281/zenodo.1065991) (Jones and Grootveld, 2017)
* [SATIFYD: Self-Assessment Tool to Improve the FAIRness of Your Dataset](https://satifyd.dans.knaw.nl/) (DANS)

## Reproducible Data Analysis

In practice, reproducible analysis in MD projects depends on a few habits that are easy to describe and easy to forget:

* **Project organization** -- consistent directory structures and naming conventions
* **Recording computational steps** -- documenting simulation parameters, scripts, and workflows
* **Recording dependencies** -- tracking software versions, libraries, and compilers
* **Recording environments** -- capturing system configurations and module loadings
* **Policies and guidelines** -- following institutional, discipline-specific, and research group policies for research data management