GMXLIB can double list of forcefields in pdb2gmx, making -ff flag not work
In gromacs version 5.1.2, the effect of GMXLIB on the behaviour of pdb2gmx has changed since v4.6.7. Now, defining GMXLIB can cause the -ff flag not to work. Also, an empty GMXLIB gives an error, which I would expect to not be the case since gromacs should fall back to the compiled location (I presume GMXLIB is still a colon delimited list of paths).
######## 1: desired behaviour is obtained when GMXLIB is not set: $ unset GMXLIB $ gmx pdb2gmx ... Select the Force Field: From '/nh/nest/u/cneale/exe/GROMACS/exec/gromacs-5.1.2/serial/share/gromacs/top': 1: AMBER03 protein, nucleic AMBER94 (Duan et al., J. Comp. Chem. 24, 1999-2012, 2003) 2: AMBER94 force field (Cornell et al., JACS 117, 5179-5197, 1995) 3: AMBER96 protein, nucleic AMBER94 (Kollman et al., Acc. Chem. Res. 29, 461-469, 1996) ... ######## 2: explicitly setting GMXLIB to the compile directory gives two copies of everything: $ echo $GMXLIB /nh/nest/u/cneale/exe/GROMACS/exec/gromacs-5.1.2/serial/share/gromacs/top $ gmx pdb2gmx ... Select the Force Field: From '/nh/nest/u/cneale/exe/GROMACS/exec/gromacs-5.1.2/serial/share/gromacs/top': 1: AMBER03 protein, nucleic AMBER94 (Duan et al., J. Comp. Chem. 24, 1999-2012, 2003) 2: AMBER03 protein, nucleic AMBER94 (Duan et al., J. Comp. Chem. 24, 1999-2012, 2003) 3: AMBER94 force field (Cornell et al., JACS 117, 5179-5197, 1995) 4: AMBER94 force field (Cornell et al., JACS 117, 5179-5197, 1995) 5: AMBER96 protein, nucleic AMBER94 (Kollman et al., Acc. Chem. Res. 29, 461-469, 1996) 6: AMBER96 protein, nucleic AMBER94 (Kollman et al., Acc. Chem. Res. 29, 461-469, 1996) ...
NOTE: this causes a problem when combined with -ff flag to pdb2gmx:
Program: gmx pdb2gmx, VERSION 5.1.2 Source file: src/gromacs/gmxpreprocess/pdb2top.cpp (line 199) Function: void choose_ff_impl(const char*, char*, int, char*, int) Inconsistency in user input: Force field 'amber03' occurs in 2 places, but not in the current directory. Run without the -ff switch and select the force field interactively. ######## 3: setting an empty string for GMXLIB gives an error: $ GMXLIB="" $ gmx pdb2gmx ... Program: gmx pdb2gmx, VERSION 5.1.2 Source file: src/gromacs/utility/directoryenumerator.cpp (line 279) Function: gmx::DirectoryEnumerator::DirectoryEnumerator(const char*, bool) Assertion failed: Condition: dirname != NULL && dirname != '\0' Attempted to open empty/null directory path
Ignore empty GMXLIB
If the GMXLIB env.var. was set, but empty, it triggered an assert
(at least) in pdb2gmx. Now this case is silently handled as if
the variable wasn't set at all.
Part of #1928.
#2 Updated by Teemu Murtola over 4 years ago
The error from an empty GMXLIB is addressed in the linked change.
The change in 5.1 compared to earlier releases is that GMXLIB adds search directories instead of overriding the default for everything. This allows you to just put your own forcefield somewhere and point GMXLIB to it, without duplicating the whole share/top/ directory everywhere where you want to have forcefields. The side effect of course is that you will always see the default force fields in pdb2gmx, which by itself shouldn't be any problem.
We could possibly make -ff prefer directories from GMXLIB, but other than that, I think the new behavior is more reasonable.
#3 Updated by Chris Neale over 4 years ago
Or maybe throw an error if multiple versions are found with the same name? I discourage colleagues from piping numbers into pdb2gmx in their scripts since then one may get an undesired outcome if something has changed in the listing, but it remains a common usage and now maybe another source of related issues is caused?
#5 Updated by Teemu Murtola over 4 years ago
I just now took a look at the exact text in the description. For this particular case that you set GMXLIB to the path that is already the default, we could possibly add some filtering that ignores duplicates in GMXLIB and/or duplication with the default data directory, but the workaround for these is really easy: just remove the duplicates manually. So I'm not sure how much effort is warranted here, although this will be relatively easy. The question is just whether those duplicates should be ignored silently, with some noise, or with a fatal error...The case where it is less clear what is the desired behavior if you set GMXLIB to a path where you have forcefields by the same name as in the Gromacs installation. Options:
- Current behavior: -ff refuses to select any, interactive selection only allows you to select the ones from your custom folder.
- Make this unconditionally a fatal error. This might be too much of a limitation. In particular, if people have earlier just copied a full forcefield and then did their own additions/modifications there, this would render those unusable before they are renamed.
- Make -ff prefer forcefields from GMXLIB, and allow it to be used if a unique match is found in GMXLIB. Leave interactive behavior as it is.
- Add a -no-default-ff option that explicitly ignores the default force fields, so that -ff would work the same as above when this is specified, and the interactive behavior would also change.
#6 Updated by Erik Lindahl over 2 years ago
- Status changed from New to Closed
The present code now handles this, but only in the sense that we detect multiple identical names and refuse to proceed - unfortunately not until you have selected it, though. The main reason for this is another shortcoming in different library code where we would always try to read from the first such-names directory (of all the GMX library and GMXLIB ones), rather than carrying along a full directory path.
We will make this more flexible in a future replacement to pdb2gmx, but in the interest of not creating other bugs we won't do it here, so I'll close this.