Bug #1667
gmx convert-tpr writes wrong number of mol in output tpr
Description
I notice when i tryed to remove solvent from tpr file and write new one with gmx convert-tpr that output file always contain all molecules merged, so effective number of mols are 1. However in this case output should contain 10 mols (9 proteins and 1 rna)
gmx convert-tpr -s hk_162_39_ring9_rna.md_npt.tpr -nsteps -1 -o tmp.tpr -n index.ndx
GROMACS: gmx convert-tpr, VERSION 5.0.4
Executable: /usr/bin/gmx
Library dir: /usr/share/gromacs/top
Command line:
gmx convert-tpr -s hk_162_39_ring9_rna.md_npt.tpr -nsteps -1 -o tmp.tpr -n index.ndx
Reading toplogy and stuff from hk_162_39_ring9_rna.md_npt.tpr
Reading file hk_162_39_ring9_rna.md_npt.tpr, VERSION 5.1-dev-20140712-06ff230-dirty-unknown (single precision)
Setting nsteps to -1
Group 0 ( System) has 644440 elements
Group 1 ( Protein) has 70200 elements
Group 2 ( Protein-H) has 35289 elements
Group 3 ( C-alpha) has 4482 elements
Group 4 ( Backbone) has 13446 elements
Group 5 ( MainChain) has 17937 elements
Group 6 ( MainChain+Cb) has 22050 elements
Group 7 ( MainChain+H) has 22275 elements
Group 8 ( SideChain) has 47925 elements
Group 9 ( SideChain-H) has 17352 elements
Group 10 ( Prot-Masses) has 70200 elements
Group 11 ( non-Protein) has 574240 elements
Group 12 ( RNA) has 5579 elements
Group 13 ( NA) has 272 elements
Group 14 ( CL) has 195 elements
Group 15 ( Water) has 568194 elements
Group 16 ( SOL) has 568194 elements
Group 17 ( non-Water) has 76246 elements
Group 18 ( Ion) has 467 elements
Group 19 ( NA) has 272 elements
Group 20 ( CL) has 195 elements
Group 21 ( Water_and_ions) has 568661 elements
Group 22 ( Protein_RNA) has 75779 elements
Select a group: 22
Selected 22: 'Protein_RNA'
Will write subset Protein_RNA of original tpx containing 75779 atoms
Reduced block cgs from 644440 to 75779 index-, 644440 to 75779 a-entries
Reduced block mols from 189875 to 10 index-, 644440 to 75779 a-entries
Reduced block excls from 644440 to 75779 index-, 2605914 to 900865 a-entries
Reduced ilist ANGLES from 138078 to 138078 entries
Reduced ilist PDIHS from 208589 to 208589 entries
Reduced ilist PIDIHS from 15444 to 15444 entries
Reduced ilist LJ14 from 197721 to 197721 entries
Reduced ilist CONSTR from 76744 to 76744 entries
Reduced ilist SETTLE from 189398 to 0 entries
Writing statusfile with starting step 0 and length -1 steps...
time 0.000 and length -0.002 ps
alexxy@mdstore ~/Models/np/hk_162_39_ring9_rna/312K $ gmxcheck -s1 tmp.tpr -m /tmp/
GROMACS: gmx check, VERSION 5.0.4
Executable: /usr/bin/gmx
Library dir: /usr/share/gromacs/top
Command line:
gmxcheck -s1 tmp.tpr -m /tmp/
Reading file tmp.tpr, VERSION 5.0.4 (single precision)
Back Off! I just backed up /tmp/.tex to /tmp/#.tex.2#
gcq#147: "I'm An Oakman" (Pulp Fiction)
alexxy@mdstore ~/Models/np/hk_162_39_ring9_rna/312K $ cat /tmp/.tex
\section{Methods}
\subsection{Simulation system}
A system of 1 molecules (75779 atoms) was simulated.
\subsection{Simulation settings}
A total of -2e-06 ns were simulated with a time step of 2 fs.
Neighbor searching was performed every 500 steps.
The PME algorithm was used for electrostatic interactions.
with a cut-off of 1.2 nm.
A reciprocal grid of 216 x 216 x 96 cells was used with 4th order B-spline interpolation.
A single cut-off of 2.485 was used for Van der Waals interactions.
Temperature coupling was done with the Nose-Hoover algorithm.
Pressure coupling was done with the Parrinello-Rahman algorithm.
Related issues
History
#1 Updated by Justin Lemkul about 5 years ago
- Priority changed from Normal to Low
Does this affect anything other than the methods output? Since you're manipulating the .tpr anyway, whatever -m produces is probably useless, anyway.
#2 Updated by Alexey Shvetsov about 5 years ago
Its just an example. Actualy selections like mol_cog, mol_com and so on dont works with reduced topology
#3 Updated by Justin Lemkul about 5 years ago
- Priority changed from Low to Normal
OK, so there is a substantive problem in interfacing the subset .tpr file with other tools like gmx select - that is a much more informative report, because it distinguishes it from being some trivial output bug to something that impacts further analysis.
#4 Updated by Alexey Shvetsov about 5 years ago
i'm preparing patch for convert-tpr to correctly copy molblock info
#5 Updated by Mark Abraham about 5 years ago
- Description updated (diff)
#6 Updated by Peter Kasson over 4 years ago
Quick ping: Alexey, do you have a patch here? It sounds like you've thought about how to fix this...if you don't have a patch but do have a quick pointer to the code and/or files reproduce, I can try to push something out.
#7 Updated by Alexey Shvetsov over 4 years ago
I dont have correctly working solution for this issue. Seems like to solve it its better to recreate trp
Easy steps to reproduece it
1. Get tpr of multimeric system (e.g two proteins in a box with water)
2. Create index group (also default Protein will work)
3. Use convert-tpr to reduce tpr file with Protein index group
4. Try to use any new tool with dynamic selections (if you'll try to use mol_com for example you will see only one mol)
Resulting tpr will have only one molblock (however in case of two protein it shoud have at least 2), I didnt find correct and easy way to reduce tpr system with selected index group (so it will have right number of molblocks and right contents for them) =\
#8 Updated by Alexey Shvetsov over 4 years ago
Partialy working patch.. however it doesnt fully fix issue
I may also upload it to gerrit
#9 Updated by Berk Hess over 4 years ago
Do you have a strong need for this functionality?
This is ancient functionality that we would rather remove.
#10 Updated by Alexey Shvetsov over 4 years ago
Its good question. Its only needed for new tools (with dynamic selections) and reduced trajectory (e.g. with dropped solvent). For example if full trajectory quite large (e.g. 500+Gb) its very usefull. Otherwise its not needed.
#11 Updated by Peter Kasson over 4 years ago
Does convert-tpr work properly if System is selected and only fail if an index specifying less than the full system is used?
#12 Updated by David van der Spoel about 4 years ago
- Assignee set to David van der Spoel
I will try to fix it. It can be convenient for analysis.
#13 Updated by Gerrit Code Review Bot about 4 years ago
Gerrit received a related patchset '1' for Issue #1667.
Uploader: David van der Spoel (davidvanderspoel@gmail.com)
Change-Id: I15450b734fe96710eee0744f34b5bdae919c632c
Gerrit URL: https://gerrit.gromacs.org/5377
#14 Updated by Berk Hess about 4 years ago
I didn't realize people work working on fixing this.
I think it would be a far better solution to remove this tool that produces buggy topologies and allow the new analysis framework to use a full tpr with a partial xtc file. It could even check that the xtc file atom count matches that of the xtc group in the tpr.
Teemu, how much work would that be?
#15 Updated by David van der Spoel about 4 years ago
Since we do not have atom information in xtc files it would be creating new problems too.
I've recently used this tool for mdrun -rerun, setting specific charges to zero.
Now I would like to take all-atom simulations, remove the hydrogens from the tpr and trr file and analyze them (and the patch in gerrit makes this possible).
#16 Updated by Teemu Murtola about 4 years ago
I think it should be straightforward, even if quite a bit of work, to add support for specifying the index group for the atoms that are contained in the trajectory for the new framework. Most of the work is in the selection code, in particular in various consistency checks. And I don't think this would create any problems that aren't already there: the user now needs, and would still need, keep track of what atoms there are in the trajectory.
#17 Updated by Teemu Murtola about 4 years ago
The option to clear charges from a tpr should be trivial to put in grompp, and is not really in any way related to this issue.
Getting rid of t_topology is a massive amount of work, with probably 50+ tools, all selection code, and probably a lot of analysys utility code depending on it...
I think Berk's suggestion of supporting a trajectory with an arbitrary subset of atoms in the tools, without touching the topology, would probably be simplest for most problems.
#18 Updated by David van der Spoel about 4 years ago
The latter could be fixed in tng if we store original atom numbers. That does not guarantee that the tpr matches the tng files but it would be an improvement.
#19 Updated by Teemu Murtola about 4 years ago
David van der Spoel wrote:
The latter could be fixed in tng if we store original atom numbers. That does not guarantee that the tpr matches the tng files but it would be an improvement.
Sure, that would help, and would simplify the use of tools that would support such an subset. But not much has happened with the tng support after it was hastily introduced just before 5.0.
#20 Updated by David van der Spoel about 4 years ago
I guess that should be the topic of another redmine, but apparently one can not store velocities to tng during mdrun, and energies would be nice too.
#21 Updated by Berk Hess about 4 years ago
Related to #1861
#22 Updated by Berk Hess about 4 years ago
- Related to Feature #1861: Add support for trajectories of part of the system to new analysis framework added
#23 Updated by Mark Abraham over 3 years ago
- Related to Feature #1864: write tng files with energies added
#24 Updated by Mark Abraham over 3 years ago
- Target version deleted (
5.x)