PDB load_one issue with atom type CL

[BradenDKelly]

PDB load_one issue with atom type CL

[FarnazH]

@BradenDKelly I encountered the problem a few weeks ago. This happens because iodata first tries to identify the element (and atomic numbers) from columns 77-78 which is empty in your PDB (it is common for PDB files not to have this common apparently, but all the ones we tested with had this column). If not available, iodata using the atom name (columns 13-16) to identify the element by grabbing its first element. So, it wrongly interprets the CL15 atom name as a C atom. See See Overview of ATOM records.

I am not sure what is a quick fix, because we might have CD atom name in a protein, which should be interpreted as C element, but what if we have a Cadmium atom in a PDB (which would have a CD atom name as well, if I am not wrong).

[tovrstra]

I'll make a PR for this. There is some unrelated work for the PR to pass, which takes some cleaning.

[PaulWAyers]

My two cents: it's an easy fix so we should support it.

[BradenDKelly]

It is a surprising little problem that is not as easy to fix as it seems. It is unfortunate that often the last column is not present. In many ways that voids warranty. Because of the conundrum of proteins and other elements sharing the same abbrev, it makes it very difficult. Part of me certainly leans towards some kind of warning if that last column is missing with a note for the user sayimg to check it out... Kind of like how force field generating software will almost always give you parameters but sometimes the fineprint lets you know the parameters are probably better to use as random number generator seeds than as spring constants or torsion barriers.

[tovrstra]

@FarnazH To come back to this: the columns 13-16 do not necessarily say which element it is, e.g. CA can be alpha carbon, not Calcium, CD can be delta carbon, not Cadmium. There may also be weird things like XY etc. The element should be put in columns 77-78. Programs that don't follow these conventions are essentially broken. #284 fixes this as much as is reasonably possible, but there is no perfect way of dealing with broken files. I'm going to include a warning when the load function does this kind of guesswork, so users know that they should be careful, despite the fact that we try to make the best possible guess.