4. How LatticeMind works

You do not need to understand LatticeMind’s internals to use it — but a mental model of what happens between your prompt and your results will help you write better prompts, read the live progress, and understand why a step was repaired or blocked.

4.1. The pipeline

Every project flows through the same stages, shown in Fig. 4.1.1. Each stage reads the output of the previous one and either proceeds or requests a repair.

The LatticeMind pipeline.

Fig. 4.1.1 The stages of a LatticeMind project, from prompt to report.

Planner

Reads your request and writes an explicit plan: the ordered list of calculations, each with a type (SCF, DOS, band structure, …) and its dependencies. This is what everything else is built from.

Structure builder

Builds the crystal or two-probe device geometry — seeding from known lattice parameters, constructing supercells, alloys, or defects as requested — and verifies the result is physically reasonable before continuing.

Parameterizer

Selects the numerical parameters for each calculation from a curated, solver-specific vocabulary: k-point grids, real-space resolution, smearing, exchange–correlation functional, Hubbard U, electric fields, q-paths, and so on.

Build inputs

Renders the concrete solver input decks (e.g. inputs/scf_main.input) and automatically wires the hand-offs between steps — pointing a band-structure run at the converged density of its SCF parent, for example.

Validator

Runs deterministic and AI checks on the rendered inputs. A blocking failure names the exact file, field, or keyword at fault (a missing structure, a duplicate output path, a missing density hand-off). If the plan cannot be executed as written, the project is sent back to be re-planned — this is the self-healing loop.

Execution

Runs the validated inputs, locally or by bundling a self-contained job and submitting it to a remote workstation or Slurm cluster, then collecting the results.

Reporter

Post-processes the raw output — extracting band gaps, generating plots, integrating densities — and writes a readable report.

4.2. Self-healing and human-in-the-loop

Two design choices make LatticeMind trustworthy:

It validates before it runs. Nothing is executed until the validator agrees the inputs are launch-ready. When validation fails, LatticeMind archives the current attempt, revises the plan, and tries again — rather than launching a doomed calculation and failing hours later.

It asks before expensive or irreversible actions. LatticeMind previews the exact commands, inputs, and (for remote runs) the job script and resources before launching. You can inspect cost with /cost and the full plan with /launch-preview. Execution is off until you turn it on.

Tip

Because the plan is explicit, you can steer it. If LatticeMind’s plan is not what you wanted, just say so in plain language — “use a denser k-grid”, “add a DOS step”, “relax the structure first” — and it re-plans.

4.3. One project, one solver

A single project is bound to one solver (RESCU, NanoDCAL, or VASP). LatticeMind does not mix solver vocabularies within a project. To compare solvers, create separate projects. The solver is inferred from your prompt (for example, “Using NanoDCAL, …”) or set explicitly.

4.4. What you can rely on

  • Correct multi-step chaining. Densities and wavefunctions flow from one step to the next automatically, each with a unique result path.

  • Reproducibility. Every decision is recorded in the project’s event log and diagnostics, so a project can be resumed, inspected, or shared.

  • Restart safety. Continuing an interrupted calculation reuses the same inputs and save paths; changing an input marks downstream steps as stale so they are recomputed correctly. A calculation released with --detach can be picked up in a later session — see Releasing a long calculation.

  • The structure you asked for. Naming a Materials Project identifier — for example scf + bs + dos for Si: mp-149 — builds from that exact published cell. A request that names no identifier uses LatticeMind’s curated crystal reference table instead, so the two can give slightly different numbers for the same material; that difference is the difference between the two cells.

  • Deterministic band paths. High-symmetry k-point paths are chosen from the lattice by a fixed table rather than being improvised per run, so the same structure always yields the same path.

  • Honest classification. A step is described as metallic on the evidence, but never for a material known experimentally to be a semiconductor or insulator whose gap merely closed under PBE. Such a step is reported as unverified, keeps its computed gap as a lower bound, and notes that a hybrid functional is needed for a quantitative answer.

  • Preflight on the environment. Missing pseudopotential coverage for the requested functional is reported before launch rather than surfacing as a solver error part-way through.

Next, see where all of this lands on disk in Projects & the workspace.