Project

General

Profile

Bug #2991

Current git (since at least Feb): all molecules renumbered as "1" in _final_ GRO file output at end of a simulation

Added by Laurence Abbott 4 months ago. Updated 10 days ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Affected version - extra info:
Affected version:
Difficulty:
uncategorized
Close

Description

I don't think this is down to anything I'm doing... After upgrading from 5.1.2 to recent-ish git (main branch) the final GRO file generated at the end of a simulation has all molecules (the 1st column of the GRO file) numbered as mol 1 instead of 1, 2, 3, etc. Consequently, viewing the output GRO in vmd has all atoms in a single molecule.

This happens with a version compiled from a git clone back in Feb and cloned again a couple of days back (to see if the issue was still there or not). It happens both with newly created TPR files as well as some created with version 5.1.2 (that gave the expected GRO files with that version of mdrun). (I've not tested witha release version of 2019 yet...)

gmx dump of the TPR input file clearly shows "#molecules = n", where n is the correct number of molecules.

I did have a bit of a dig through the source code but I'd need to get a lot more familiar with it to work out where the problem lies!

History

#1 Updated by Laurence Abbott 4 months ago

Edit: I forgot to mention that converting one of the CPT files to a GRO file does give the correct molecule numbering!

#2 Updated by Paul Bauer 4 months ago

Can you please test this with 2019.3? We fixed some bugs related to molecule indexing there that might have caught this.
Otherwise, could you upload a test case for me to reproduce this? Thanks!

#3 Updated by Laurence Abbott 4 months ago

Paul Bauer wrote:

Can you please test this with 2019.3? We fixed some bugs related to molecule indexing there that might have caught this.
Otherwise, could you upload a test case for me to reproduce this? Thanks!

I can confirm that things work fine with 2019.3 (I was thinking that git master wouldn't be that much further ahead but clearly not!).

I suspect the problem could lie with write_hconf_mtop() in fileio/groio.cpp or with AtomProxy. I'll dig further but suspect someone else with more knowledge will get to the problem quicker!

#4 Updated by Paul Bauer 4 months ago

It is just an issue that we need to merge the changes from the 2019 branch back into master.
Thanks for checking!

#5 Updated by Mark Abraham 10 days ago

  • Status changed from New to Closed
  • Target version set to 2020-beta1

Also available in: Atom PDF