[Code scan] LAMMPS atom-style parsing misreads neutral charge and dipole data

[njzjz]

This issue is part of a Codex global repository code scan.

The LAMMPS data parser has two atom-style issues:

1. atom_style="auto" misdetects 6-column neutral charge style without an Atoms # charge comment, because zero charges look integer-like and the heuristic chooses bond.
2. get_spins() treats any Atoms row with at least 8 columns as spin data. For atom_style="dipole", those columns are dipole fields, so the parser registers bogus spins.

Affected code:

dpdata/dpdata/formats/lammps/lmp.py

Lines 55 to 85 in a7a50bf

	# If no explicit style found, try to infer from first data line
	if atom_lines:
	first_line = atom_lines[0].split()
	num_cols = len(first_line)
	# Try to match based on number of columns and content patterns
	# This is a heuristic approach
	if num_cols == 5:
	# Could be atomic style: atom-ID atom-type x y z
	return "atomic"
	elif num_cols == 6:
	# Could be charge or bond/molecular style
	# Try to determine if column 2 (index 2) looks like a charge (float) or type (int)
	try:
	val = float(first_line[2])
	# If it's a small float, likely a charge
	if abs(val) < 10 and val != int(val):
	return "charge"
	else:
	# Likely molecule ID (integer), so bond/molecular style
	return "bond"
	except ValueError:
	return "atomic" # fallback
	elif num_cols == 7:
	# Could be full style: atom-ID molecule-ID atom-type charge x y z
	return "full"
	elif num_cols >= 8:
	# Could be dipole or sphere style
	# For now, default to dipole if we have enough columns
	return "dipole"

dpdata/dpdata/formats/lammps/lmp.py

Lines 329 to 339 in a7a50bf

	def get_spins(lines: list[str], atom_style: str = "atomic") -> np.ndarray | None:
	atom_lines = get_atoms(lines)
	if len(atom_lines[0].split()) < 8:
	return None
	spins_ori = []
	spins_norm = []
	for ii in atom_lines:
	iis = ii.split()
	spins_ori.append([float(jj) for jj in iis[5:8]])
	spins_norm.append([float(iis[-1])])
	return np.array(spins_ori) * np.array(spins_norm)

dpdata/dpdata/formats/lammps/lmp.py

Lines 409 to 416 in a7a50bf

	# Add charges if the atom style supports them
	charges = get_charges(lines, atom_style=atom_style)
	if charges is not None:
	system["charges"] = np.array([charges])
	spins = get_spins(lines, atom_style=atom_style)
	if spins is not None:
	system["spins"] = np.array([spins])

Neutral charge-style reproducer:

import tempfile
import dpdata

content = """2 atoms
2 atom types
0.0 2.0 xlo xhi
0.0 2.0 ylo yhi
0.0 2.0 zlo zhi

Atoms

1 1 0.0 0.0 0.0 0.0
2 2 0.0 1.0 1.0 1.0
"""

with tempfile.NamedTemporaryFile("w", suffix=".lmp") as f:
    f.write(content)
    f.flush()
    dpdata.System(f.name, fmt="lammps/lmp", type_map=["O", "H"])

Current behavior:

ValueError: invalid literal for int() with base 10: '0.0'

Dipole-style reproducer:

content = """1 atoms
1 atom types
0.0 10.0 xlo xhi
0.0 10.0 ylo yhi
0.0 10.0 zlo zhi

Atoms # dipole

1 1 0.0 1.0 2.0 3.0 0.1 0.2 0.3
"""

Loading this with atom_style="dipole" currently produces both charges and a bogus spins array. Dipole fields should not be registered as spins.

[dosubot]

Both issues trace back to the detect_atom_style() heuristic and the get_spins() function in lmp.py [1].

Issue 1 — Neutral charge misdetection:

The 6-column heuristic uses val != int(val) to distinguish charge from bond style [2]. In Python, 0.0 != int(0.0) evaluates to False, so any system where the first atom's charge is an integer-valued float (like 0.0) falls through to the "bond" branch. A fix could check the string representation for a decimal point (e.g., "." in first_line[2]) instead of relying on float-to-int comparison, since LAMMPS molecule IDs are always written as bare integers while charges are floats.

Issue 2 — get_spins() false positive on dipole style:

get_spins() accepts an atom_style parameter but never uses it — it simply checks len(columns) >= 8 and unconditionally reads columns 5–7 + the last column as spin data [3]. For a dipole-style row (atom-ID atom-type q x y z mux muy muz), those columns contain the dipole vector, not spins. The fix should gate spin extraction behind an atom-style check — e.g., only proceed when atom_style is explicitly "spin" (or an appropriate spin-related style), rather than using a column-count heuristic alone.

Both bugs were introduced during the atom-style refactor in PR #867 [4] and the earlier spin support in PR #728 [5].

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.