handbook / Resources

Toolkit

Our default tools and practices, by area. Deviate if you have a good reason, but default here first so we can help each other.

Compute

At the moment we mainly have CPU-based workstations. CPU/GPU workstations are coming in the near future. Until then, also use NIIDSA (the CSIR central facility) for anything that doesn’t fit on the local machines.

First-principles calculations

We stick to open-source codes unless there’s a strong reason not to.

• FHI-aims and GPAW — periodic (and molecular) calculations. FHI-aims for ease of access to development; GPAW because it’s fully Python-based and integrates cleanly with ASE.
• Quantum ESPRESSO — periodic calculations, especially useful given its interfaces with many-body perturbation theory codes (Yambo, BerkeleyGW, West).
• ORCA and PySCF — molecular calculations.
• LAMMPS and GROMACS — classical MD.

Workflow managers

Submitting, monitoring, and rerunning calculations by hand on the cluster is repetitive and error-prone. Automate it wherever you can.

For simple cases, custom submission/monitoring scripts are fine (ask around the group for examples people already have). But once you’re running more than a handful of related calculations, especially anything resembling a high-throughput study, use a proper workflow manager instead of reinventing one. It will save you real time and give you a record of what was actually run. A few options, roughly from lighter to heavier:

• Jobflow — defines workflows as Python functions; pairs with FireWorks or jobflow-remote to actually execute them on HPC. Used in the Materials Project ecosystem.
• FireWorks — a dynamic, database-backed workflow engine originally built for high-throughput DFT; still widely used to execute Jobflow/Atomate workflows.
• AiiDA — heavier-weight, with strong emphasis on full data provenance (every input, output, and intermediate step is tracked in a queryable database). Worth it if reproducibility/provenance really matters for the project.
• Snakemake — general-purpose, not materials-specific, but a solid lightweight option if you just want reproducible, dependency-aware pipelines without adopting a whole ecosystem.

Coding environment

• Editors/IDEs: VS Code is the group default, mainly for its remote-SSH extension (edit code on the cluster as if it were local) and Python/Jupyter support. PyCharm is a solid alternative if you prefer a more batteries-included IDE. If you already live in the terminal, Neovim works well too, particularly for quick edits directly on the HPC login node.
• Notebooks: Jupyter for exploratory analysis and figure prototyping. Treat notebooks as scratch space, not the final home for code that others will reuse; once something stabilizes, move it into a proper script or package.
• Python/environment management: conda or mamba (a much faster drop-in replacement for conda) for managing environments with non-Python dependencies. For pure-Python projects, uv is worth trying — it’s considerably faster than pip/conda for installing and locking dependencies.
• Containers: for anything that needs to run identically on your laptop and on the cluster, or that you plan to share so others can reproduce your results, consider Apptainer (formerly Singularity) rather than Docker, since it’s the container runtime most HPC systems actually support.

Presentations

• Slides: Beamer (LaTeX) if your talk is figure- and equation-heavy and you’re already used to LaTeX. PowerPoint, Keynote, or Google Slides otherwise; use whichever you’re fastest in, group meetings don’t need to be uniform on this.
• Posters: LaTeX (beamerposter or tikzposter) or PowerPoint both work fine; Illustrator/Inkscape if you want full layout control.
• If you’re building a presentation from data you’re actively analyzing (e.g. iterating on a plot right before a talk), it’s worth generating figures directly from your analysis script so the slide updates when the data does, rather than re-exporting and re-pasting images by hand each time.

Writing

Papers: Overleaf by default, since it makes sharing and simultaneous editing with co-authors much easier. If you’d rather work from a local LaTeX installation, that’s fine too, just make sure it’s set up to share (e.g. via git). If a project has very large files (big datasets, many figures) that make Overleaf sync slow, consider a local setup, or a lighter markup alternative such as Typst, which compiles faster and handles large documents more gracefully than LaTeX.

Everything else: Markdown.

This website

See the README.md in the website repository for how to edit this Hugo site.

Reference management

If you’re writing in Overleaf, use biblatex. Otherwise, use whatever reference manager you like (Zotero, Mendeley, etc., see the Literature Study page for options) — I’ll adapt to whatever .bib file you export.

Version control

GitLab (or GitHub) with git. During a project, it’s fine to keep everything in your own local or private repository. But once a project is ready for publication, especially if it involves a workflow, package, or any other reusable code, move it to the group’s GitLab so the rest of the group can access it easily.

A few habits worth keeping regardless of where the repo lives:

• Write meaningful commit messages, not just update or fix.
• Commit in small, logical chunks rather than one giant commit at the end.
• Add a short README.md explaining what the repo does and how to run it, so it’s usable by someone who wasn’t involved in writing it.

Data and code sharing

Beyond the group’s GitLab, some journals and funders now expect (or strongly encourage) you to deposit the underlying data and workflow alongside the paper. A few field-standard places to do that:

• Materials Cloud — open-access repository built specifically for computational materials science; if your workflow is built with AiiDA, it can archive the full provenance graph, not just the final numbers, so someone else can retrace exactly how a result was produced.
• NOMAD — large FAIR data repository for computational materials science, code-agnostic (accepts input/output files from most major DFT/MD codes).
• Zenodo — general-purpose, good for archiving a specific code release or dataset and getting a DOI to cite in the paper.