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. Band structures are plotted along the high-symmetry path your deck names, with the standard labels (Γ, X, W, …) at their exact positions; a convergence study (for example, comparing k-point meshes) concludes with a total-energy convergence figure rather than a list of numbers.

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.

  • Continuations that remember. A follow-up request rarely restates what the project is about, and it does not have to: “Add a Seebeck coefficient calculation to this project” inherits the device, the material and the settings named in the request the project was founded on, adds only the missing steps (here the transmission spectrum the Seebeck coefficient is integrated from), and reuses every calculation that has already converged. A follow-up that does name something new — another material, a different energy window — takes precedence for that turn.

  • 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 called metallic only on the evidence. If the material is a known semiconductor or insulator whose gap simply closed under PBE, the step is flagged as unverified, its computed gap is kept as a lower bound, and the report 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.

  • Continuing a finished project. A finished run does not block its own project: you can keep adding steps — “add a DOS calculation” — turn after turn, and each one reuses the converged results already on disk. Questions and approval prompts belong to the turn that raised them; they never resurface on a later request or in a new project.

  • The same figures on every platform. Where RESCU’s built-in plotting is unavailable (for example, managed cloud environments without a MATLAB runtime), LatticeMind renders the same canonical figures itself and the report says so in a note — the results and plots are complete either way. On such machines, turn the built-in plotter off with /rescu-plotting off (saved with your settings) so it is never attempted at all.

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