5. How LatticeMind works

You do not need to know LatticeMind’s internals to use it. A picture of what happens between your request and the answer will help you write good requests, read the progress lines and decide when to step in.

5.1. The conversation loop

Every request goes around the same loop, shown in Fig. 5.1.1.

The LatticeMind conversation loop.

Fig. 5.1.1 You describe the calculation, LatticeMind prepares and checks, you approve, the solver runs here or on a remote machine, and LatticeMind reads the results and answers.

You describe

Say what you want in plain words: the material, the calculation, anything you care about (a functional, a k-grid, a lattice constant). Attach a paper or a structure file if you have one.

LatticeMind prepares and checks

LatticeMind first looks at what is already in the folder, so a follow-up builds on earlier work rather than repeating it. It then builds the structure, chooses the settings and writes the solver inputs. Each input is checked before it is written: a keyword the solver does not accept, a missing pseudopotential or a band calculation without its SCF parent is caught here, and LatticeMind fixes it or tells you what is missing.

You approve

Before any solver runs, LatticeMind shows what will run and where — the calculation, the machine and the folder — and asks:

1. yes   2. yes, always   3. no

Answer with the number or in words (yes, go ahead, run it, or no, cancel). Nothing is launched until you do. A request to build, set up or run a calculation ends at this question; to stop earlier, say “prepare the inputs but do not run anything”.

The solver runs

The calculation runs on this machine or on a remote workstation you chose with /remote. The solver’s own output — RESCU’s iteration log, NanoDCAL’s output, VASP’s OSZICAR — streams into the conversation as it is written.

LatticeMind reads the results and answers

When the run finishes, LatticeMind reads the solver’s output files, draws the figures and answers in prose. Every number in the answer is tied to a recorded result. The terminal folds the evidence into one line; /report writes the full evidence report under results/.

5.2. Letting routine work go ahead

By default you answer every permission question. /approve-for-me on hands routine requests to a fixed set of rules for the rest of the session:

  • Goes ahead: a prepared solver run of low or medium estimated cost, on this machine or on a saved remote profile, one run or a batch; creating folders or empty files inside the project.

  • Still asks: moving, copying or deleting files, writing into a file, reorganising the folder, running a program or analysis script, a high-cost run on this machine, and a run whose size cannot be estimated.

After twelve runs or twenty folder creations since your last message, the next request asks you again. /approvals-log lists every automatic approval, and /approve-for-me off returns to asking. See Interactive commands for details.

5.3. Steering while it works

While a turn runs, one status line shows the elapsed time and what LatticeMind is doing, and a line marked > below it takes your typing. A message you send is read at the next step, so “use 8x8x8 instead” lands before the next input is written. ctrl-c offers to stop, to leave the work running, or to keep watching.

Tip

If what LatticeMind is preparing is not what you meant, say so — “use a denser k-grid”, “add a DOS step”, “relax the structure first” — and it revises the plan before asking to run anything.

5.4. One project, one solver

A project is bound to one solver (RESCU, NanoDCAL or VASP). To compare solvers, use separate projects. The solver comes from your request (“Using NanoDCAL, …”) or from the solver you configured; RESCU is the default.

5.5. What you can rely on

  • Correct multi-step chaining. A band structure or DOS reads the density of its own SCF parent, and a calculation after a relaxation uses the relaxed geometry, without coordinates being retyped.

  • Follow-ups that build on what exists. “Now add a DOS” reuses the converged SCF already in the folder and runs only the new step.

  • Current results, clearly marked. When a calculation is redone, the older run is marked as superseded by the newer one, so an old number is not mistaken for the current one.

  • The structure you asked for. Naming a Materials Project identifier (for example mp-149) builds from that published cell; otherwise LatticeMind uses its curated crystal reference table. A structure file you attach or paste is used as given.

  • Standard band paths. High-symmetry paths come from the lattice by a fixed table, so the same structure always gets the same path. Rectangular and square monolayers get Γ–X–S–Y–Γ. Standard bulk paths need a primitive cell; for a conventional cell, ask for an explicit path.

  • Honest classification. A metal is reported as a metal and a state inside the smearing window is reported as such, not as a gap.

  • Missing inputs found early. Missing pseudopotential coverage for the requested functional is reported before the launch, not as a solver error part-way through.

  • Nothing lost when you leave. Closing the terminal loses nothing. A running solver keeps running, and latticemind in the same folder reopens the conversation. A conversation started under an earlier version continues after an upgrade.

A successful run and a converged answer are different claims. LatticeMind reports electronic convergence, k-point convergence and agreement with experiment separately, and says which ones a result supports.

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