# DFTK keeps a plane-wave DFT code small enough to read and change

> DFTK is a Julia implementation of plane-wave density-functional theory built in around 10k lines of code, with a model and a basis split that makes the numerics explicit rather than hidden. It suits computational chemists and physicists who want to modify the method, and it is a teaching-scale code rather than a production electronic structure suite.

**JuliaMolSim/DFTK.jl** — Density-functional toolkit

- Repository: https://github.com/JuliaMolSim/DFTK.jl
- Website: https://docs.dftk.org
- Stars: 542 · Forks: 111
- Language: Julia
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/juliamolsim-dftk-jl

## Ten thousand lines is a design decision, not a limitation

The size of the codebase is the first fact in the documentation and it is the fact that explains the rest. DFTK is a collection of Julia routines for plane-wave density-functional theory, and the documentation says that in only around 10k lines of code it already has a sizeable set of features, including GPU support or parallelisation using MPI. The stated unique feature is an emphasis on simplicity and flexibility, with the goal of facilitating algorithmic and numerical developments as well as interdisciplinary collaboration in solid-state research. Read that as a design constraint rather than a boast about missing pieces. A code base you can hold in your head is one where a graduate student can find the self-consistency loop, change an exchange-correlation functional, and know what the change did. The cost of that choice is scope, and the documentation is upfront about where the scope ends. The project also states that it agrees well with more established packages as shown on a recent verification dataset by Bosoni and co-authors, and that its performance is of the same order of magnitude as other plane-wave DFT packages, with systems of 1000 electrons routinely treatable.

## The model is the physics, the basis is the numerics, and you build both

The API is built around one separation, and it is the thing to take away from the documentation. You construct a model, which is the problem to be solved without numerical parameters, and then a basis, which holds the discretization parameters such as the energy cutoff and k-point sampling along with everything needed to specify the solution numerically. The example makes the split explicit in its own comments: the model is a standard DFT with LDA exchange-correlation, and the basis holds the discretization parameters. Once both exist you call the self-consistent field routine, and the result carries the energy, the density, the orbitals and so on. Nothing about that order is accidental. Because the model has no numbers in it, you can construct a different physical problem and reuse the same numerical machinery, and because the basis is a separate object, you can change the discretization and compare without touching the physics. That is the flexibility the project claims, expressed as two lines of code and a `;` in between.

## The silicon example is the whole API in twenty lines

The quickstart in the documentation is short enough to read in one go, which is unusual and useful. It loads DFTK and PseudoPotentialData, defines a lattice in atomic units with the comment that everything in DFTK is in atomic units and here Bohrs, defines the pseudopotential and the atomic positions as relative coordinates, builds the model, sets the basis, and runs the calculation:

```julia
model = model_DFT(lattice, atoms, positions; functionals=LDA())

# `basis` holds the discretization parameters (energy cutoff, kpoint sampling, etc)
# and everything needed to specify the solution numerically
basis = PlaneWaveBasis(model; Ecut=15, kgrid=[4, 4, 4])

scfres = self_consistent_field(basis, tol=1e-8)
```

Two details in that snippet carry real information. The pseudopotential comes from a named family, `PseudoFamily("dojo.nc.sr.lda.v0_4_1.standard.upf")`, so the exchange-correlation treatment and the pseudopotential are consistent with each other rather than mixed by hand. And the self-consistent field call takes a tolerance, `tol=1e-8`, which is the convergence criterion for the iteration, not a display setting. The `Ecut=15` and the `kgrid=[4, 4, 4]` are in Hartree and in reciprocal lattice units, following from the atomic units convention.

## Example scripts cover the questions people actually ask

The `examples/` directory is the second-best documentation and it is worth scanning before anything else. The files present include `convergence_study.jl` and `energy_cutoff_smearing.jl`, which are the two questions every new user of a plane-wave code has, `dos.jl` for the density of states, `elastic_constants.jl`, `geometry_optimization.jl`, `collinear_magnetism.jl` and `hubbard.jl` for extended models, `metallic_systems.jl` and `graphene.jl` for specific system classes, `exact_exchange.jl` for hybrid functionals, `custom_solvers.jl` and `compare_solvers.jl` for the numerical side, `arbitrary_floattype.jl` and `forwarddiff.jl` for differentiating through the calculation, `gaas_surface.jl` and `anyons.jl` for specialised physics, and `amdgpu.jl` for the GPU path. The presence of `custom_solvers.jl` is the clearest statement of the project's priorities: swapping the linear solver or the eigensolver is a documented use case, not a hack. There is also a `benchmark/` directory at the root, and the documentation links the stable docs, the dev docs, a Zulip channel and a Matrix room for the project.

## Julia 1.10 is the floor, and the package is meant to be used from a script

The installation story is short because the project is a Julia package in the ordinary sense, installed from the general registry into a project environment. The documentation does not spell out a single install command on the project page, and instead links three places to start: installation instructions, a tutorial and basic DFT examples for metallic systems, all under docs.dftk.org, with a stable version and a dev version of the documentation both published. The one hard requirement stated is that at least Julia 1.10 is required. For a developer working on the code itself, the repository layout is the guide: `src/` for the package, `test/` for the test suite, `ext/` for package extensions, `docs/` for the documentation sources, `examples/` for the scripts, `benchmark/` for the benchmarks, and `Project.toml` at the root for the environment definition. There is also an `AGENTS.md` and a `CLAUDE.md`, which tells you that the project has been set up to be worked on with coding assistants in mind, and a release notes file that holds the release notes separately from the project page.

## The verification dataset is how you judge agreement with other codes

The documentation does not claim that DFTK is more accurate than anything else, and that restraint is the point. It says the project agrees well with more established packages as shown on a recent verification dataset by Bosoni and co-authors, and links that dataset. This is the correct way to evaluate a DFT code, because a code that claims its own accuracy is asking to be trusted. The dataset approach means you can compare DFTK against reference results computed with other plane-wave codes on a defined set of systems, so the question becomes whether your workflow reproduces the reference, rather than whether you believe the author. The performance claim is deliberately modest by comparison, being of the same order of magnitude as other plane-wave DFT packages, with systems of 1000 electrons routinely treated. The topics attached to the repository reflect the same scope, with ab-initio, computational-chemistry, density-functional-theory, electronic-structure, kohn-sham, mathematical-analysis, numerical-analysis and plane-wave among them, the numerical-analysis entries being a hint that this is a code written by people who care about the discretisation.

## Academic development and a citation request shape what you can expect

The maintenance model is stated plainly in the support section: DFTK is mostly developed as part of academic research, and parts of it have also been discussed in published papers. The ask is that if you use the code in research, teaching or other activities, you cite it as appropriate, with a CITATION.bib in the repository root listing the relevant references and a specific reference paper with its own DOI badge. That combination, an academic project with a citation request, tells you two things. First, the feature roadmap is driven by research questions rather than by user requests, so a method you need may not exist and may not be prioritised. Second, the code is expected to be read and discussed in publications, which is consistent with the emphasis on simplicity. The funding list is a good indicator of the maintenance base: the Institute of Computing and Data Sciences at Sorbonne Universite, Ecole des Ponts ParisTech, the Inria Research Centre Paris, RWTH Aachen University, the Swiss National Science Foundation, the European Research Council under Horizon 2020, and the Simons Foundation. Issues are welcome by email or on the issue tracker, and contributors are asked to read CONTRIBUTING.md first.

## Where DFTK is the wrong tool

The honest boundaries come from the stated priorities rather than from a list of missing features. A production electronic structure suite for a working chemist usually carries a long tail of things DFTK does not advertise: many exchange-correlation functionals, hybrid functionals, spin-orbit coupling, and a catalogue of post-processing tools for spectroscopy and charge analysis. The project states its aim plainly, which is to facilitate algorithmic and numerical developments and interdisciplinary collaboration, so it competes on being changeable rather than on being complete. The second boundary is scale and cost. The documentation claims the same order of magnitude as other plane-wave packages and routine treatment of 1000 electron systems, which is a real capability but is not a claim about industrial workloads. The alternative to weigh against is an established plane-wave code with a decade of accumulated functionals and post-processing, where the difference in approach is that DFTK is meant to be edited while the established code is meant to be configured. If your requirement is a specific published method implemented exactly as in a paper, or a large screening campaign, an established package is the better investment. If your requirement is to understand why a method behaves as it does and then change it, DFTK is the shorter path.

## Conclusion

DFTK is a good fit for a computational physics group that wants to read its electronic structure code, change an algorithm, or teach how plane-wave DFT actually works, because the whole package is around 10k lines of Julia and the model and basis are separate objects you can inspect. It is a poor fit for someone who needs a battery of exotic functionals, hybrid functionals, spin-orbit coupling or a long tail of spectroscopy post-processing, because the project explicitly favours simplicity and flexibility over feature count, and it is a poor fit for absolute performance on very large systems, where the documentation says only that performance is of the same order of magnitude as other plane-wave packages and that systems of 1000 electrons can be routinely treated. Before adopting it, run the examples in `examples/` against a system you already know, check the verification dataset the documentation points to, and note that at least Julia 1.10 is required, with the last push to the repository on 2026-10-19 and release v0.8.0 published on 2026-08-14.

## FAQ

### What is DFTK and what does it do?

DFTK is the density-functional toolkit, a collection of Julia routines for plane-wave density-functional theory. It is built in around 10k lines of code and includes GPU support or parallelisation using MPI, and the project states that systems of 1000 electrons can be routinely treated.

### What does the model and basis split in DFTK do?

The model defines the problem to be solved without numerical parameters, such as a standard DFT with LDA exchange-correlation, while the basis holds the discretization parameters like the energy cutoff and k-point sampling. You build the model first, then the basis from it, and run the self-consistent field calculation on the basis.

### What version of Julia does DFTK require?

At least Julia 1.10 is required. The documentation links installation instructions, a tutorial and basic DFT examples for metallic systems, and the project is installed as an ordinary Julia package with a Project.toml at the repository root.

### How can I check DFTK against other DFT codes?

The documentation points to a recent verification dataset by Bosoni and co-authors, and says DFTK agrees well with more established packages as shown there. It also states that its performance is of the same order of magnitude as other plane-wave DFT packages.

## Sources

- [JuliaMolSim/DFTK.jl on GitHub](https://github.com/JuliaMolSim/DFTK.jl)
- [License: MIT](https://github.com/JuliaMolSim/DFTK.jl/blob/master/LICENSE)
- [Project website](https://docs.dftk.org)
- [README](https://github.com/JuliaMolSim/DFTK.jl/blob/master/README.md)
- [Releases](https://github.com/JuliaMolSim/DFTK.jl/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/juliamolsim-dftk-jl