> 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/workflows.md).

# Workflows

Most simulation projects at SWZ follow the same broad pattern even when the scientific question changes. A structure is prepared, one or more input scripts are tested locally, production runs move to the cluster or to HLRN, analysis scripts are refined as results come in, and eventually the material has to be assembled into something another person can understand. This section is about keeping that process tidy enough that the project still makes sense later.

A useful project starts with a directory layout that reflects the actual work. Input files, potentials, raw output, analysis scripts, figures, and notes should live in places that are predictable to someone other than the original author. File names do not need to be elegant, but they should say what the file is and how it fits into the run history. If a script generates a figure used in a paper, it should be possible to locate both without detective work.

The software side is similar. Small scripts become important surprisingly quickly, especially once they are reused across several runs or passed to another person. A short comment at the top, sensible function names, and a note about dependencies are usually enough to make code maintainable. What matters most is that the script still makes sense when it is reopened after a few months. If the analysis depends on a particular Python package, an OVITO version, or a certain LAMMPS output format, that should be recorded where the next reader will actually find it.

Collaboration adds another layer. A project that involves several people needs one place that explains what the project contains, who is responsible for it, how results are checked, and how data is shared. That can be a README, an ELN entry, or a project page in GitLab, but it should exist early rather than at publication time. The same applies to licenses, citation information, and any restrictions on access to data or code.

Electronic lab notebooks fit naturally into this workflow because they capture the decisions that are easy to lose elsewhere. They are useful not only for documenting experiments, but also for noting why a simulation setup changed, which structure generator was used, which path on the NAS contains the raw data, and what still needs to be checked before a run can be trusted. In other words, they connect the files on disk with the reasoning behind them.