Project

General

Profile

Feature #2305

Switch to dynamic number of groups in .tpr file

Added by Viacheslav Bolnykh over 1 year ago. Updated over 1 year ago.

Status:
Closed
Priority:
Normal
Category:
preprocessing (pdb2gmx,grompp)
Target version:
Difficulty:
simple
Close

Description

There are projects requiring addition of new groups to the .tpr file. In order to support that we need to update egcNR (last member of an enum in topology.h). However, it seems to be more reasonable to write the number of groups in the .tpr file right before the section containing group data. For backwards compatibility we can turn egcNR into a variable with a preset value of 10 (the current number of groups). Then if the version of the file is the one supporting dynamic number of groups - it will be read from the tpr.

History

#1 Updated by Mark Abraham over 1 year ago

  • Target version changed from 2018 to 2019

#2 Updated by Berk Hess over 1 year ago

I would suggest to simply store a completely separate group index, as for the pull groups and other special things.

#3 Updated by Viacheslav Bolnykh over 1 year ago

Berk Hess wrote:

I would suggest to simply store a completely separate group index, as for the pull groups and other special things.

But can we be sure that the amount of groups will not change in the future? The change proposed in the issue can be reasonable if we want to introduce some additional degree of freedom in respect to adding new groups to the code. If we are sure that the amount of groups stays the same - then yes it will be easier just to create a separate group. Or is it better just to add new group class every time we introduce new feature?

#4 Updated by Erik Lindahl over 1 year ago

Right now this is not possible to do (unless somebody is willing to invest large amounts of refactoring work), simply because other large parts of the code rely on getting names of group types through the fixed-size lists.

However, just as Berk writes, it should be straightforward to simply use the settings in a general QM/MM interface to specify what group you use for various things, without extending the fundamental group concept.

#5 Updated by Viacheslav Bolnykh over 1 year ago

Erik Lindahl wrote:

Right now this is not possible to do (unless somebody is willing to invest large amounts of refactoring work), simply because other large parts of the code rely on getting names of group types through the fixed-size lists.

However, just as Berk writes, it should be straightforward to simply use the settings in a general QM/MM interface to specify what group you use for various things, without extending the fundamental group concept.

I agree, in fact I have switched to using the previous QM/MM flags - so this issue can be closed (it seems that I cannot do it myself)

#6 Updated by Mark Abraham over 1 year ago

  • Status changed from New to Closed

No longer required, per Slava's request.

Also available in: Atom PDF