[Code scan] Reject unknown i-PI atom names instead of mapping them to type 0

[njzjz]

This issue comes from a Codex global scan of deepmodeling/deepmd-kit at commit 73de44b1f94471b2e3bdb6b11f57b34d7bc791bb.

Problem

The i-PI driver silently maps any atom name missing from the JSON atom_type table to DeePMD type 0.

dp_ipi reads the user-provided type table and the atom names from the XYZ file, then constructs Convert:

• deepmd-kit/source/ipi/driver.cc

  Line 74 in 73de44b

  std::map<std::string, int> name_type_map = jdata["atom_type"];

• deepmd-kit/source/ipi/driver.cc

  Lines 82 to 85 in 73de44b

  	XyzFileManager::read(coord_file, atom_name, posi, velo, forc);
  	}
  	Convert<double> cvt(atom_name, name_type_map);

Inside Convert, the lookup uses std::map::operator[]:

• deepmd-kit/source/ipi/src/Convert.cc

  Lines 12 to 14 in 73de44b

  	for (unsigned ii = 0; ii < atype.size(); ++ii) {
  	atype[ii] = name_type_map[atomname[ii]];
  	}

For std::map<std::string, int>, name_type_map[atomname[ii]] inserts a missing key with the default integer value 0. A misspelled XYZ element name or an omitted JSON entry therefore runs successfully, but the atom is evaluated as model type 0.

Impact

This can produce wrong i-PI energies and forces without any diagnostic. The failure mode is especially easy to miss because type 0 is a valid DeePMD type.

Suggested fix

Use find()/at() instead of operator[], report the unknown atom name, and fail before inference. If possible, also validate that configured type IDs are in the model's supported type range.

Add a dp_ipi regression where coord_file contains an atom name that is absent from atom_type; the driver should exit with a clear error instead of evaluating the atom as type 0.