pdb2gmx chainsep is broken
In the course of developing tests for pdb2gmx -chainsep flag, I realized that this flag is currently broken. The tarballs for 2018.1 and 2018.2 are not affected.
After performing git bisect, the first bad commit is "Remove mols from gmx_mtop_t" 8dd3c9ae88004054b3b112c23f747d27a19d8d29
Fix pdb2gmx -chainsep
This patch makes readConfAndAtoms public and has pdb2gmx call it
directly. Previously pdb2gmx called readConfAndTopology, which
then called readConfAndAtoms and then tpx_make_chain_identifiers,
the latter of which is suspected of being broken, as documented
in the TODO added here.
#6 Updated by Joe Jordan about 1 year ago
Further testing has shown that http://redmine.gromacs.org/projects/gromacs/repository/revisions/8dd3c9ae88004054b3b112c23f747d27a19d8d29 does cause a change in behavior. Both before and after the change pdb file reading works correctly and the chainnum and chainid are read in correctly by readConfAndTopology in confio.cpp when this function is called by read_tps_conf in the same file. The function read_tps_conf is called directly by the pdb2gmx function read_pdball. Everything is the same up to when gmx_mtop_t_to_t_topology is called a few lines below readConfAndTopology. In this function, using as input a pdb file with only protein (I tried one and multiple chains and the results are the same) top.mols gets set as 0 before the change in question and as 1 after.