write_pdbfile_indexed puts TER after every atom if conect=NULL, bTerSepChains=TRUE
Summary says it all. I ran into this with a custom tool; got an output file that read like the following:
ATOM 624 HW1 SOL 3724 89.300 150.970 186.950 1.00 0.00
ATOM 1117 HW2 SOL 3888 1.250 136.700 191.910 1.00 0.00
ATOM 2653 HW2 SOL 4400 41.310 157.200 166.200 1.00 0.00
ATOM 4188 HW1 SOL 4912 145.180 144.710 189.770 1.00 0.00
ATOM 4809 HW1 SOL 5119 121.830 111.820 183.360 1.00 0.00
ATOM 9743 OW SOL 6764 43.520 63.910 170.920 1.00 0.00
ATOM 12477 HW1 SOL 7675 77.870 92.090 177.350 1.00 0.00
changing bTerSepChains=FALSE fixed the output, but it seems that this is not the desired behavior.
#2 Updated by Erik Lindahl over 9 years ago
This is not a bug, but a consequence of the feature that Berk wanted TER records after polymers too. So, you too get a small bit of the blame, Berk ;-)
The routine is being called with a whole bunch of SOL molecules, and with non-contiguous residue indices in the PDB info, which I would argue is invalid data? Residue numbers can be anything, but the indices are our internal counters and should go from 0 to nres-1.
It's of course easy to make an exception for water, but this could cause errors for other molecules too, so
Still, I've disabled TER records for polymers. For now we only write TER after Protein/DNA/RNA chains.
#4 Updated by Erik Lindahl over 9 years ago
Two different things:
If the user provides an index file with (arbitrary) numbers for atoms to write out in some order we do not control the atoms/residues can obviously be completely out of order. Having TER records between different chains is the right thing to do in general, even if we make a selection to e.g. only write out the heavy atoms in the protein.
Then there are a bunch of tools that write "completely random" collections of atoms, but in that case we should fix it in those analysis tools so they don't request their conformations to be written with chain separators.
The previous "polymer detection" was a hack that worked by checking if the residue index difference to the last TER record was >1, which can frequently be the case for user-provided indices.
It might be possible to solve it by keeping track of the first residue index in the present chain too, and only writing TER records for polymers of we actually wrote out more than one residue in that polymer, but I'm not sure if that would solve all corner cases.
By not doing the polymer check we will usually do the right for Protein/DNA/RNA (unless atoms from different such chains are indexed in random order, but in that case the analysis tool shouldn't request TER records). If anybody wants to continue to hack the polymer cases and has a bunch of good tests including analysis they're welcome, but that's a future feature enhancement and not a bug.
The classes of atoms that actually might be written completely out of order should be solvent/membrane/ions, and for those everything works fine now since they aren't protein/DNA/RNA.