Read atom index out of bounds

[jguenole]

Read atom index out of bounds

[pierrehirel]

Hi,

As a general principle, GIGO: garbage in, garbage out.

Indeed Atomsk assumes that the input file is consistent, i.e. that the number of atoms declared at the beginning corresponds to the actual number of atoms whose positions are given afterwards. If it is not the case, it can lead to errors. So, when removing atoms manually I recommend to also modify the number of atoms declared at the beginning of the file, so as to maintain consistency. In LAMMPS data files that means also changing the index of atoms, which can be quite tedious to do by hand.

I understand that it would be useful if Atomsk could read the input file and "fix" the inconsistencies automatically, however this poses several problems. Imagine a file where the actual number of atoms is different from the declared number of atoms. I can think of at least four different reasons for that:

(1) the user added or deleted atoms in the file "by hand" (this is the one you describe);
(2) the user modified the declaration of number of atoms at the beginning, because he wants to get rid of the last atoms (because if the user messed up the file by hand, he could have modified any line, anywhere in the file);
(3) the software that wrote the file is buggy and produced the inconsistency without the user's knowledge (so, should Atomsk try to "fix" it without the user's knowledge?);
(4) the file was corrupted on the disk, because of an error during copy or network transfer (yes, hardware problems can still occur).

It is impossible to know which solution is correct, so the programmer has to make a choice. I think that the safest and most general choice, is to display a warning to tell the user that the input file is inconsistent, because the user should be made aware of such problems, instead of trying to hide them under the carpet.

By the way, this behaviour is also the one of many other softwares like LAMMPS, Ovito, VESTA etc.: if the input file does not comply to the format or contains inconsistencies, these softwares will also complain and refuse to proceed.

So, the behaviour you describe is not a bug, it's a feature ;-) And I do not think anything can be done to try and "fix" it. But I will leave this thread open for you to explain your ideas on this topic.

[jguenole]

Hi!

I see! Thanks for this detailed description!

I understand that I might be talking about a very specific case (Lammps data file in a "dirty" work pipeline). To be very precise, here was my pipline:

• lmp file created by atomsk,
• atom removed with Ovito > exported in lmp
• read and relaxed by lammps > output in *lmp format
• read by atomsk to create a solid solution: WARNING out of bounds

The out of bounds index didn't crash Lammps nor Ovito. Also, in some case, it might be interesting to have non-continuous atom index, for example to differentiate two phases (but I agree that it could be considered as "bad practice").

If you think this is too specific or/and could lead to unwanted behavior, feel free to close this "issue" :)