BUG: support for Lammps unwrapped positions flags

Problem

When using Lammps write_data command, positions are written to a file, but lammps also appends 3 flags to each line (0, 1 or -1). Those flags seemed not to be handled properly by atomman.load().

The format of the file is :

LAMMPS data file via write_data, version 12 Dec 2018, timestep = 890

2401 atoms
2 atom types

0.0000000000000000e+00 4.8753396899999997e+00 xlo xhi
0.0000000000000000e+00 1.3789543033000001e+02 ylo yhi
0.0000000000000000e+00 7.9613963819999995e+01 zlo zhi
1.2188349234708999e+00 0.0000000000000000e+00 0.0000000000000000e+00 xy xz yz

Masses
1 55.845
2 12.0107
Atoms # atomic

1 1 4.8765104789049962e+00 1.3789342338922083e+02 1.1450350660986815e-01 0 -1 0
2 1 3.6611610851732395e+00 3.4400882966388346e+00 2.0006436506550074e+00 0 0 0
3 1 4.0975803870990607e-01 2.2922423181836922e+00 1.1406317768252468e-01 0 0 0
4 1 4.1334129904729944e-01 5.7347193960639613e+00 1.9995265951218959e+00 0 0 0
5 1 4.4713841751949106e+00 1.1454753812346155e+00 2.0013169323956683e+00 0 0 0
...

For more details, see https://lammps.sandia.gov/doc/read_data.html , paragraph starting with "LAMMPS always stores atom coordinates as values which are inside the simulation box."

Steps to reproduce

The following Lammps script was used. It generated the file presented above.

units metal
atom_style atomic
boundary p p p
read_data box.lmp # this box was created and saved using atomman

mass 1 55.845000
mass 2 12.011

pair_style eam/alloy
pair_coeff * * my-pot.eam Fe C

minimize 0 1e-05 100000 100000
write_data minimized.lmp

When using atomman.load("atom_data", "minimized.lmp"), the returned System contained 29 atypes, instead of the 2 expected, meaning the file was not parsed properly.

Proposed solution

The proposed fix consists in ignoring those flags when reading the table. It's easily done by using the usecols options of pd.read_csv(). What I did for the moment is hardcode which columns are to be used for load('atom_data') with atom_style set to atomic (i.e [1, 2, 3, 4]). It is improvable to support other atom_styles. I think usecols should be set in velocities_prop_info depending on the atom_style, but I'm not sure it's the way you want to do it though. Anyway, this is a very modest contribution to try to help, it's not claimed to be merge-ready or anything ;)

Discussion

Possible limitations :

Works for atom_style set to atomic, not tested for others.
Maybe it would be better to return the unwrapped coordinates, instead of ignoring the flags ?

Thanks for your work on atomman,

Good catch! So, if I'm reading the documentation right, the x,y,z coordinates are always "wrapped" into the box, but can be "unwrapped" by applying the optional nx,ny,nz terms.

If you want to make further improvements,

dump atom_data can easily be generalized for any atom style by looking at the list of dictionaries atoms_prop_info returns. The total number of "table_name" values will be the number of fields to read not counting the nx,ny,nz terms.
Velocities sections don't have optional terms, so I'm not sure the usecols parameter is necessary there. If you do include, it can be generalized to any velocity style similarly as the atom style.
Including the unwrapped coordinates is doable, but might be a bit more complicated. Maybe count terms in the first atoms line during the first pass, then after calling load_table, call pd.read_csv on the extra columns if present?

lmhale99 / atomman