The Parameter Problem

A typical VASP INCAR file for a DFT calculation has around 40 parameters. ENCUT. EDIFF. PREC. ISMEAR. SIGMA. NSW. IBRION. ISPIN. LDAU. Each one represents a choice — not a universal default, but a judgment call made by whoever ran the first calculation of that type in your lab, informed by specific knowledge of your systems, your hardware, and the failures that came before.

INCAR — VASP relaxation (MXene surface, Heinz Lab convention, Dec 2022)
SYSTEM = Ti3C2_surface_relaxation
ISTART = 0 ; ICHARG = 2
ENCUT = 550   # ← Bumped from 450 in Oct 2022 after Marcus got
               #   inconsistent forces on Ti3C2. See Slack thread
               #   #hpc-jobs 2022-10-14. DO NOT lower without testing.
EDIFF = 1E-6  # Tight convergence — required for surface energies
ISMEAR = 1 ; SIGMA = 0.1  # Methfessel-Paxton for metallic system
NSW = 100 ; IBRION = 2    # ionic relaxation, conjugate gradient
LDAU = .TRUE.             # DFT+U for Ti d-electrons
LDAUU = 3.5 0 0           # U=3.5 eV on Ti (from Kulik 2015 —
                           #   tested by Priya in 2023, confirmed)

That comment block doesn't exist. It never exists. What actually gets committed to the repository is the INCAR with the numbers and no explanation. The reasoning — the October 2022 Slack thread, the name of the postdoc who tested it, the paper reference, the fact that lowering ENCUT will silently give you wrong forces — lives in someone's head. Or lived there.

Marcus graduated two years ago.

Where Computational Knowledge Lives

Experimental labs lose knowledge when protocols go undocumented. Computational labs lose a different kind of knowledge — one that is harder to see and harder to recover. Every simulation pipeline is a stack of parameter decisions, each one compounding the ones below it. The functional choice affects which basis set is appropriate. The basis set choice affects what cutoff energy is safe. The cutoff energy affects convergence behavior. The convergence thresholds interact with the ionic relaxation scheme in ways that depend on whether the system is metallic, insulating, or frustrated.

Getting these choices right requires not just technical knowledge, but lab-specific knowledge: which potentials have been validated for your specific systems, which settings your HPC scheduler handles well, which convergence criteria have historically produced inconsistent results on structures like yours. This knowledge accumulates slowly, through failed runs and corrected mistakes, and it lives almost entirely in the people who ran those jobs.

A DFT input file is not documentation. It is the result of documentation that was never written. The parameter values encode every decision. The reasoning behind them is stored nowhere.

The Cost of Undocumented Parameters

The most immediate cost is redundancy. A new postdoc joins a computational lab and begins setting up their first DFT run on a system class the lab has studied for years. They make parameter choices based on literature defaults and basic training — reasonable choices, not the lab's validated choices. The resulting calculations are technically correct but not calibrated to the lab's specific systems. They discover this three months in when their results diverge from published lab data, and spend several weeks in convergence testing to find the discrepancy.

The senior grad student in the lab could have told them what settings to use in five minutes. But it is not obvious that she needs to be asked, because it is not obvious that the defaults are wrong. The knowledge that the defaults are wrong for this specific system class, and the settings that work instead, is not written anywhere.

The second cost is reproducibility — specifically, the lab's inability to exactly reproduce its own prior work. A paper is published. Three years later, a collaborating group asks for the exact computational parameters used in Figure 3. The corresponding author was a postdoc who left two years ago. Her INCAR files exist in an archived directory somewhere. The reasons behind the ENCUT, ISMEAR, and DFT+U choices are not in those files, and the postdoc now works in industry.

Why Input Files Are Not Documentation

The instinctive response to this problem is: put comments in your input files. And researchers do — intermittently, inconsistently, and usually only for the parameters they happen to remember are non-obvious. The INCAR has 40 parameters. A researcher might comment four of them. The other 36 look like defaults even when they aren't.

More fundamentally, a comment in an input file does not answer the question a new postdoc actually asks. She does not look up the INCAR for a 2021 calculation and read its comments. She asks: “What parameters does the lab use for surface relaxations?” or “When do we use DFT+U, and what U values?” or “Why do the perovskite runs use a different ISMEAR than the MXene runs?”

These questions cannot be answered by grep-ing a directory of INCAR files. They require retrieving the reasoning that was never written in a retrievable form — the context behind the parameters, not just the parameters themselves. The distinction between storing information and making it queryable is the core infrastructure problem.

The Reasoning Layer

The parameter problem is a specific instance of a broader pattern: the gap between what computational labs produce (input files, output files, archived data) and what they actually know (the reasoning, context, and failure history behind every significant methodological choice).

The published methods section captures what was used. It does not capture why, what was tried first, what the failure mode of the alternative was, or what lab-specific constraint drove the choice. The archived input files capture the result of every decision. They do not capture the reasoning that produced it.

This reasoning layer is where most of a computational lab's actual methodological expertise lives — and it is the first thing to evaporate when a researcher leaves. The frustrating thing is that it is not lost through negligence. Researchers typically remember it clearly and could articulate it in a five-minute conversation. It is lost because there was no infrastructure that captured it in the course of normal work, indexed it by meaning rather than filename, and made it accessible to people who were not present for the original decision.

The parameter values in a computational lab's input files are the visible tip of years of methodological learning. The iceberg — the failed convergence runs, the validated alternatives, the system-specific exceptions, the PI's evolving position on contested choices — is stored nowhere.

What Changes with Persistent Memory

The core capability requirement is straightforward: capture the context alongside the calculation, not just the calculation itself. When a researcher makes an unusual parameter choice — bumps ENCUT above the default, switches from PAW to ultrasoft potentials for a specific system, adjusts the DFT+U values after testing — the reasoning behind that choice should be indexable alongside the input file. Not as a documentation burden, but as a natural output of the discussion that produced the decision.

The Slack thread where the problem was identified. The brief note in the meeting summary where the PI confirmed the revised approach. The follow-up run that validated the new setting. These already exist in the lab's communication and collaboration tools — they are just not connected to the input file they explain, and not retrievable by the postdoc who inherits the pipeline two years later.

A system that indexes this context persistently changes what onboarding looks like. Instead of “why does this INCAR use ENCUT=550 instead of the VASP recommended 400?” returning the answer “no idea, Marcus set it up before I joined,” the question returns the October 2022 Slack thread, the failed convergence run that prompted the change, and the note from the PI confirming the revised setting. The knowledge does not evaporate when Marcus graduates. It remains in the lab's accessible history.

The parameter problem does not require better researchers. The labs running into it are running excellent science. It requires infrastructure that treats the reasoning layer of computational work as something worth preserving — not as documentation overhead, but as institutional knowledge with compounding value.