Thanks Axel
I actually kindof like the extremely spartan, bare-bones style of a LAMMPS data file.
there are not many modifications required. e.g. it would be significantly easier to parse, if it would be read strictly line oriented (read_data reads section content as a stream of words), if every Section
keyword would have an EndSection terminator or a length indicator (not unlike the dump file format), if parsing would not depend on external settings (e.g. through having column assignments in the Atoms section).
But it’s true that it is not fully self-descriptive, and it is not always possible to parse the file without knowing which input script commands will be used. (I’m just relieved it’s now possible for LAMMPS to infer the atom_style from comments in the data file. Thanks to whoever implemented that.
)
that is one of the compromises i could strike with with steve.
Andrew
PS Since you bring this up, can the latest topotools read data files with these kinds of custom sections?
no. it would require to change the parser in a way that makes the resulting code much more fragile and difficult to maintain. due to the lack of an end-tag, or a length descriptor, it is difficult to determine how far to skip. how can you know when to start parsing again?
I guess that reinforces the point you were making.
For what it’s worth, your suggestions all sound good to me, (especially if you have the stamina to implement them), and if LAMMPS could retain the ability to read the old-fashioned style data files (perhaps by passing an additional keyword to read_data).
Cool.
Andrew