Add option to keep original Atom IDs when writing PDB

[kain88-de]

Expected behaviour

When I use ag.write('foo.pdb') I expect the atom ids to be the same as in the AtomGroup

Actual behaviour

The atom ids's always start from 0.

Code to reproduce the behaviour

import MDAnalysis as mda
from MDAnalysisTests.datafiles import PDB

u = mda.Universe(PDB)
bb = u.select_atoms('backbone')
bb.write('foo.pdb')
u2 = mda.Universe('foo.pdb')
assert np.all(bb.ids == u2.atoms.ids)

Currently version of MDAnalysis:

(run python -c "import MDAnalysis as mda; print(mda.__version__)")
develop branch

[orbeckst]

One can make a case that the AtomIDs are just sequential numbers in the PDB format and a new PDB file is correctly written as long as the IDs start at 1 and are consecutively numbered (AtomIDs should also start with 1 in PDB files, not with 0). In fact, in many cases that might actually be desired behavior, e.g., if one wants to take only, say chain B of a PDB file as input for further simulations.

On the other hand, I also see use cases for wanting to remember the atomids for selections.

Perhaps the PDBWriter should get a flag, like "keep_atomids", "keep_resids", etc? Or how would you be able to get continuous numbering in a PDB if you implemented the "keep old atomids"?

[tylerjereddy]

+1 for eventually having the increased flexibility, as a heavy user of MDAnalysis for system building / topology manipulation purposes.

[kain88-de]

I can't find anything in the PDB standard that the atom numbers have to be continuous.

[orbeckst]

The PDB FAQ (from 2001) implies that serial records start at 1; it sounds to me that they should be continuous ("consecutive" as written below) but admittedly this not said anywhere.

• Q. How are models in NMR ensembles organized in PDB entries?
• A. In older NMR files the atom serial numbers were consecutive across all models in the entry. Owing to limitations in the field width for the atom serial number, this practice resulted in some ensembles being divided among multiple PDB entries. With entries processed since February 1999, the atom serial number is reset to 1 at the beginning of each model thereby allowing the full ensemble to be included within a single PDB entry.

---

You could try to run a PDB file with discontinuous serials through the PDB deposit validation server and see it if complains (although you probably also need structure factors and what not...).

Or ask an expert such as @arose .... (I asked on twitter https://twitter.com/orbeckst/status/801234933356195841 in case anyone else is interested).

[kain88-de]

Sounds like they should be numbered in serial starting from 1 if I want to create a PDB to be added to the official PDB. But for normal system building both should be fine.

[arose]

I have never seen a PDB file from the PDB archive not numbered consecutively. The serial number uniquely identifies atoms which is used in the CONNECT records to define bonds. To me the name "serial" implies that they are to be numbered consecutively but I can't find it in the spec either. Will inquire.

[arose]

So, it is a convention: files from the archive go from 1 to the number of coordinates for mmCIF files and for PDB files to restart from 1 for each model.

[orbeckst]

Thank you, much appreciated.

[kain88-de]

OK then we keep the current default of consecutive atom numbers starting at 1 but also add a new kwarg to keep the atomid if people like to do that.

[orbeckst]

Sounds Good!

…

-- Oliver Beckstein email: orbeckst@gmail.com

Am Nov 24, 2016 um 0:19 schrieb Max Linke ***@***.***>: OK then we keep the current default of consecutive atom numbers starting at 1 but also add a new kwarg to keep the atomid if people like to do that. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[dotsdl]

Yeah I think I agree with the philosophy that for writers we do whatever needs to be done with topology attributes to match the standards/customs/idiosyncracies of the format we're serializing to. This is analogous to the philosophy we use for parsing topologies, but in the reverse direction: we take what's present and try to make reasonable choices for each parser for what the contents of the file mean in terms of the MDAnalysis topology system.

If someone wants to hold on to all of the contents of their Topology as it is, they'll need to use something like JSON serialization (#643).