This was a piece of code in src/RDINP/ffsort.f90 which is causing duplicate source atoms to get removed. Normally the code should fail on duplicate atoms, but there is a loop that "makes a smaller list of atoms from a big one". I'm not quite sure what the original intention of this block was, but changing from
to
fixes the issue. Alternatively you could just set the condition to "greater than zero" to entirely avoid this problem. Dr. Kas hypothesized that this code might be a left over way of simulating vibrational effects by having multiple source atoms all very close together.
The input file which initially brought this bug to light had this code block for ATOMS
where the Fe.1 atoms are too close to the absorbing Fe to be physical. This input file was most likely created using some automated tool like Web Atoms, where the coordinates for the Fe were not defined properly.
The header at the top of the input file reads
It should be noted that the x, y, and z coordinates should be 0.3 (repeating), 0.6 (repeating, and 0.75, but they are cut off after only two digits. Putting this into Web Atoms, we get the same input file
but this can be fixed by using fractional coordinates (Web Atoms automatically converts 1/3 to 0.33333333333333 (up to machine precision))
And we see that the two duplicate source atoms that were 0.02 Angstroms away no longer appear. The key takeaway here is to always make sure the structure you have defined is indeed what you want to calculated. Try looking at your structure in a molecular viewer, and whenever possible, use high precision or fractional coordinates when defining atomic coordinates.
This was a piece of code in src/RDINP/ffsort.f90 which is causing duplicate source atoms to get removed. Normally the code should fail on duplicate atoms, but there is a loop that "makes a smaller list of atoms from a big one". I'm not quite sure what the original intention of this block was, but changing from
to
fixes the issue. Alternatively you could just set the condition to "greater than zero" to entirely avoid this problem. Dr. Kas hypothesized that this code might be a left over way of simulating vibrational effects by having multiple source atoms all very close together.
The input file which initially brought this bug to light had this code block for ATOMS
where the Fe.1 atoms are too close to the absorbing Fe to be physical. This input file was most likely created using some automated tool like Web Atoms, where the coordinates for the Fe were not defined properly.
The header at the top of the input file reads
It should be noted that the x, y, and z coordinates should be 0.3 (repeating), 0.6 (repeating, and 0.75, but they are cut off after only two digits. Putting this into Web Atoms, we get the same input file
but this can be fixed by using fractional coordinates (Web Atoms automatically converts 1/3 to 0.33333333333333 (up to machine precision))
And we see that the two duplicate source atoms that were 0.02 Angstroms away no longer appear. The key takeaway here is to always make sure the structure you have defined is indeed what you want to calculated. Try looking at your structure in a molecular viewer, and whenever possible, use high precision or fractional coordinates when defining atomic coordinates.