ATLAS: Atomic Translation & Language for Automated Structures

1.1 Motivation: The Atomic Structure Bottleneck

• Atomic structures require spatial constraints that direct LLM coordinate generation does not reliably enforce, including chemical distances, periodicity, dimensionality, and interface alignment.The stated problem is how to bridge natural-language semantics and atomic-coordinate geometry.Source: §1.1 · p. 2

1.2 Current Approaches and Their Limitations

• Scripting libraries require expert coding, while visualizers rely on manual operations; direct LLM coordinates lack geometric reasoning.The three tool categories therefore lack, respectively, natural-language access, reproducibility, or native geometric reasoning.Source: §1.2 · pp. 2–3
• ATLAS combines spatial comprehension, reproducible programmability, and natural-language accessibility through a standardized intermediate representation.This representation decouples semantic interpretation from geometric execution.Source: §1.2 · p. 3

1.3 Contributions and Paper Organization

• The paper presents a complete seven-component framework for natural-language-driven atomic-structure comprehension and manipulation.Its contributions include a density-based analyzer, JSON bridge, component-algebra engine, physical validator, intent-aware scorer, and score-driven refinement methodology.Source: §1.3 · p. 3
• The density-based analyzer identifies chemical components and per-atom spatial roles, making referential requests such as changing vertex atoms executable.It also provides a complementary projection layer for view-centric features.Source: §1.3 · p. 3
• The V4 engine represents each operation as a named component in a deterministic directed acyclic graph, making build actions transparent, auditable, and reproducible.This is distinct from the earlier V3-era intent-to-atom-operation hierarchy.Source: §1.3 · p. 3
• The JSON bridge provides a machine-verifiable representation that separates LLM semantic interpretation from deterministic structure building.The contributions also include automated physical validation and iterative correction, plus prompt-aware scoring against user intent.Source: §1.3 · p. 3
• A curated test suite with known spatial assertions supports component-level failure diagnosis and targeted iterative refinement.The paper identifies this score-driven optimization methodology as a contribution.Source: §1.3 · p. 3

2 System Architecture

• C1 supplies spatial features for scoring, while C5 checks physical validity before scoring; the two components answer different questions.The analyzer addresses what a structure is and where its meaningful parts are; the validator addresses whether it is physically reasonable.Source: §2 · p. 4

3.2 3D Cloud Component Analysis (Primary Layer)

• The primary 3D layer decomposes density into formula components and assigns atoms roles, phases, coordination numbers, and defect labels.It characterizes components by stoichiometry, volume, shape, and crystal phase; surfaces and interfaces are derived from component boundaries.Source: §3.1 · pp. 4–5, §3.2 · p. 6

3.1 Design Philosophy

• Per-atom roles and precise measurements come from 3D data; multi-view projections provide a complementary lens for view-centric questions.The 2D layer supports queries such as symmetry axes, layer-depth histograms, and channel cross-sections, but does not classify atoms or measure physical bond lengths.Source: §3.1 · pp. 5–6

3.3.1 Stage 1: Multi-Directional Projection

• The projection pipeline samples multiple directions, unwraps detected molecular structures, and converts each 2D view into a Gaussian density map.Bandwidth σ controls whether the map resolves individual atomic positions or emphasizes space-filling morphology.Source: §3.3.1 · pp. 6–7, §3.3.2 · p. 7

3.3.3 Stage 3: Per-View Spatial Feature Extraction

• Per-view features capture rotational symmetry, low-density voids, density edges, and projected shape, including candidate surface atoms.Rotational symmetry is assessed from the angular power spectrum; voids are connected sub-threshold regions, while shape uses a 2D convex hull.Source: §3.3.3 · p. 7

3.3.4 Stage 4: Cross-View Consensus

• Cross-view consensus aggregates hull appearance, symmetry, and view-to-view statistics to characterize surface indicators, candidate axes, and structural anisotropy.The hull signal is secondary to the authoritative 3D role labels; symmetry axes are independently checked with spglib.Source: §3.3.4 · p. 7

3.4 Spatial Comprehension Capabilities

• Analyzer capabilities power JSON selections: surface and vertex queries use 3D role labels, coordination queries use 3D numbers, and symmetry-axis queries use 2D consensus.Table 2 presents the spatial-comprehension capabilities.Source: §3.4 · p. 8, Table 2 · p. 8

4 C2: LLM Skill — Teaching Language Models to Speak JSON

• The roughly 680-line LLM Skill instructs a model to translate natural-language prompts into JSON specifications, never directly into atomic coordinates.The skill is designed for use with any capable LLM.Source: §4 · p. 8
• Translation uses the prompt, supplied CIFs or database information, and analyzer results so the model can name components and variables from analyzed facts.The analyzer supplies component decomposition, per-atom roles, phases, and coordination numbers.Source: §4 · p. 8
• The skill documents the JSON schema, operations, defaults, annotated examples, and explicit rules, and is version-controlled with the codebase.Its examples cover thirteen build-type sections, while its explicit rules cover topics including dimensionality inference and auto-fix defaults.Source: §4 · pp. 8–9

5 C3: JSON Component Algebra — The Bridge Language

• The JSON bridge decouples semantic interpretation from geometric execution through a machine-verifiable, human-readable specification executed deterministically by the Build Engine.The engine produces pymatgen Structure objects.Source: §5 · p. 9

5.1 Component Algebra (V4)

• V4 builds are directed acyclic graphs of named structures or analytic spaces, with operations consuming earlier components and producing named intermediates.Operations include replication, transforms, box resizing, and union, subtraction, or intersection; named variables resolve quantities such as box centers, adsorption sites, and stack heights at execution time.Source: §5.1 · pp. 9–10
• Box resizing either preserves Cartesian positions for vacuum padding or preserves fractional positions for lattice strain; unlike supercell, neither changes atom count.Cartesian resizing recenters material and warns when a periodic axis is scaled; fractional resizing preserves periodicity in every axis.Source: §5.1 · pp. 9–10

5.1.1 Surfaces and Heterojunctions

• Surface and heterojunction builds reorient lattices, match in-plane supercells within a strain cap, then stack components; system-specific checks govern acceptance and repair.When no alignment direction is given, the engine searches for the smallest commensurate box within the strain cap; checks cover bonds, coordination, vacuum, composition, separation, cavity clearance, overlap, and isolated atoms.Source: §5.1.1 · pp. 11–12

5.2 Legacy Formats and Format Terminology

• V2 arrangement shorthand and V3 ordered-operation specs remain accepted on legacy paths, while new builds use the V4 component algebra.The earlier formats are not converted into V4, though their constructs have V4 equivalents.Source: §5.2 · p. 12

5.3 Design Principles

• V4 references components by name, defines each operation as a named output, resolves named variables at execution, and declares constraints separately from their enforcement.The validator enforces the declarative check list.Source: §5.3 · p. 12

6 C4: Build Engine — Deterministic JSON Execution

• The Build Engine executes JSON specifications deterministically, so identical inputs produce identical structure outputs.It executes specifications into pymatgen Structure objects.Source: §6 · p. 13

6.1 The V3-Era Engine Model

• The V3-era engine decomposes builds into intent, selection, set operation, and atom operation, with Boolean selection algebra and spatial modifiers.This hierarchy remains implemented for V2/V3 legacy formats; V4 replaces it with named components and unary or binary operations evaluated as a DAG.Source: §6.1 · p. 13

6.2 Execution Pipeline

• V4 execution evaluates the component graph, confirms system-dependent checks, then invokes C5 auto-fix for repairable violations.Legacy V2/V3 execution instead loads components, applies operations, performs any arrangement, and runs auto-fix.Source: §6.2 · p. 13

6.3 Key Architectural Decisions

• Operations return new structures, and embedding preserves the host lattice vectors exactly for subsequent DFT calculations.Interactive 2D clicks can also resolve depth by ray-sphere intersection, using the front-hemisphere solution by default.Source: §6.3 · p. 14

7.1 Validation Checks

• Overlaps below 0.5 Å and bond lengths outside element-specific ranges by more than 20% are flagged as errors.Bonded pairs are identified within 1.25 times the sum of covalent radii and checked against crystallographic ranges.Source: §7.1 · p. 14
• Vacuum and periodic directions are checked against dimensionality-specific atom-span, gap, and empty-space thresholds.Periodic spans must cover at least 88% of the cell in 3D or 80% in 2D/1D, with inter-atom gaps below 20%; vacuum limits are 3 Å for 3D and 5 Å for 2D.Source: §7.1 · p. 14
• Each atom’s coordination is compared with element-specific expected ranges, with under-coordination producing a warning.Examples include C: 2–4, Si: 3–6, and Pt: 1–12; passivation can address under-coordination.Source: §7.1 · p. 14
• Isolated atoms and atoms inside fullerene or molecular-cage interiors are also checked.The guest-cavity check detects atoms within 0.7 times the cage radius; for C60 this is approximately 2.5 Å.Source: §7.1 · p. 14

7.2 Dimensional Classification

• Dimensionality is inferred from fractional-coordinate spans and wrap-around gaps, then checked against the target inferred from build type and prompt keywords.An axis is classified as periodic when span exceeds 70% and its maximum gap is below 30%; the number of periodic axes determines dimensionality.Source: §7.2 · p. 15

7.3 Auto-Fix Loop

• The priority-ordered auto-fix loop addresses overlaps, isolated atoms, cage intruders, and excess vacuum, then revalidates the structure.It stops when the structure is clean or after five iterations, while respecting minimum box sizes, preserved vacuum axes, and protected atom indices.Source: §7.3 · p. 15

8 C6: Scorer — Prompt-Structure Matching via Spatial Comprehension

• The Scorer evaluates the built structure against the original prompt rather than the intermediate JSON specification.The JSON may itself contain errors if the LLM misinterpreted the prompt.Source: §8 · p. 15

8.1 Scoring Dimensions

• The score is divided among composition, dimensionality, connectivity, constraints, and quality.These five dimensions form a 100-point scale.Source: §8.1 · p. 15
• Composition and dimensionality use analyzer JSON, connectivity uses validator results, and constraints and quality draw on both layers.Source: §8.1 · p. 15
• 70/100 is the acceptance threshold, and lower scores trigger the optimization loop.Source: §8.1 · p. 15
• When the analyzer is unavailable, composition and dimensionality fall back to geometric detectors, and the report notes that status.The 2D projection layer does not contribute to scoring.Source: §8.1 · p. 15

8.2 Integration with the Optimization Loop

• The score breakdown identifies failed dimensions and guides corrective action.Source: §8.2 · p. 15

• When dimensionality is wrong, identify the likely responsible component: C2 may have produced the wrong dimensionality in JSON, or C5 may have over-corrected during auto-fix.Source: §1 · p. 16
• Possible causes include C2 producing incorrect dimensionality in the JSON or C5 auto-fix over-correcting.Source: §1 · p. 16
• Corrections can revise JSON parameters, retry with an adjusted supercell size, or flag a pattern for C2 skill improvement.Source: §1 · p. 16

• Patterns with scores of at least 70 are recorded in a persistent experience store.Source: §4 · p. 16
• For a new prompt, the system retrieves the most similar past prompt by keyword overlap and build type and seeds the LLM with its successful JSON.Source: §4 · p. 16
• This reuse implements a form of few-shot learning that improves with usage.Source: §4 · p. 16

9 C7: Web Interface

• The Dash interface supports exploratory analysis of uploaded structures, interactive natural-language building, and export for downstream computation.The interface provides access to all seven ATLAS components.Source: §9 · p. 16

9.1 Multi-Structure Management

• Users can load arbitrary CIFs or common library structures as named components and switch the active analysis target.The 3D viewer and 2D analysis panel provide complementary views; per-atom classifications come from the 3D analyzer, not the 2D panel.Source: §9.1 · p. 16, §9.2 · p. 16

9.3 Build Panel

• The Build panel previews a V4 JSON spec for review, then executes the component graph, validation with auto-fix, and analyzer-backed scoring.Built structures can be downloaded in CIF, POSCAR, or XYZ; intents without a V4 recipe fall back to the legacy builder with an explicit note.Source: §9.3 · pp. 16–17

10.1 Test Suite Design

• A curated suite of prompts spanning core build types checks expected dimensionality, composition, spatial properties, and constraints.Its assertions include guest separation, cavity clearance, and interface-gap tolerances.Source: §10.1 · p. 17

10.2 Failure Diagnosis and Component Attribution

• Failure diagnosis traces scoring symptoms through the scoring dimensions to identify the component responsible for each failing test.The curated test suite supplies the cases used for this diagnosis.Source: §10.2 · p. 17, §10.1 · p. 17

10.3 Two-Level Optimization

• When a build scores below 70, online optimization revises its JSON, rebuilds, and rescoring can repeat for up to three iterations; offline runs aggregate suite failures to find systematic weaknesses.The online loop is visible in the build log.Source: §10.3 · p. 18

10.4 Feedback Loops

• The scheme feeds score and validation patterns back into skill examples, spatial classifiers, build recipes, and schema or operation parameters.The paper describes these as feedback cycles across C1, C2, C3, and C4.Source: §10.4 · p. 18

11 Code Organization

• The codebase comprises 30 source modules totaling approximately 11,600 lines of Python, alongside a roughly 5,100-line analyzer package and a roughly 680-line LLM skill file.The code is organized by component and architectural layer.Source: §11 · p. 18
• Foundation modules provide measurement, atom selection, and geometric transforms, while shape-operation and multi-structure modules implement domain-specific manipulations.The analyzer exposes its document to the rest of the pipeline and the scorer; 2D projection modules provide view-centric features.Source: §11 · p. 18
• The V4 component-graph engine and JSON executor compose operations into workflows, while the web app orchestrates builds and the fallback intent front end converts parsed requests to V4 specs.Source: §11 · p. 19

12 Conclusion

• ATLAS addresses the gap between LLM-generated calculation parameters and geometrically valid atomic structures with tools for structure comprehension and manipulation.Its analyzer identifies spatial features such as surfaces, vertices, and interfaces, while a named-component DAG supports auditable build sequences.Source: §12 · p. 19
• The architecture couples 3D density-based roles and components with a V4 component-algebra engine, JSON bridge, system-dependent checks, dimensional classification, auto-fix, and prompt-aware scoring.A curated test suite supports systematic diagnosis and refinement across components.Source: §12 · p. 19
• The component algebra covers named structure and space components, geometric operations, named variables, and automatic dimensional classification across nine core build categories.The JSON schema, LLM skill file, and web interface support programmatic and interactive use; the improvement scheme provides a pathway for data-driven refinement.Source: §12 · p. 19