Project

General

Profile

Bug #699

strange behaviour of double precision grompp with amber ff

Added by michal kolar over 8 years ago. Updated over 8 years ago.

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

Description

i've experienced a buggy behavior of the double precision compiled grompp.

for the protein topology, where is no apparent b state for alchemical mutation defined, the double precision grompp gives "Note: State B has non-zero total charge". single precision grompp does not give this note.

i use gmx 4.5.3 compiled with icc 11.0.081, 64 bit.

the topology is created with pdb2gmx and ff03 amber force field . i use gbsa solvent. i've not tried any other ff.

up to now, the only difference i've discovered is that the double precision tpr file contains two more functypes than single prec one.

log.single (5.15 KB) log.single single prec grompp console output michal kolar, 02/10/2011 09:24 AM
log.double (5.23 KB) log.double double prec grompp console output michal kolar, 02/10/2011 09:24 AM
topol.single.tpr (1.58 MB) topol.single.tpr single precision tpr file michal kolar, 02/10/2011 09:24 AM
topol.double.tpr (1.77 MB) topol.double.tpr double precision tpr file michal kolar, 02/10/2011 09:24 AM
processed.top (1.3 MB) processed.top processed top file michal kolar, 02/10/2011 09:24 AM
mdout.mdp (10 KB) mdout.mdp processed mdp file michal kolar, 02/10/2011 09:24 AM
protein.gro (212 KB) protein.gro protein structure michal kolar, 02/10/2011 09:24 AM

Associated revisions

Revision 71e85377 (diff)
Added by Mark Abraham over 8 years ago

Fixed erroneous floating-point comparison

IssueID #699

Revision 462e5c17 (diff)
Added by Mark Abraham over 8 years ago

Added workaround for F_GB13 duplicates

Under some conditions, identical reference bond lengths could lead to
different computed 1-3 lengths (using icc 11 and double precision, at
least). These then failed the memcmp() test that removes duplicate
parameter lists, which led to near-duplicates in the
function-parameters lists. In theory, we shouldn't test for
floating-point equality with memcmp(), but in theory the test should
work, too!

Instead of memcmp(), for F_GB13 only, tests with
gmx_within_tol(a,b,1e-6) are now used. That should be an acceptable
compromise between expected function, numerical accuracy and grompp
execution time.

IssueID #699

History

#1 Updated by Mark Abraham over 8 years ago

  • Category changed from 6 to mdrun
  • Status changed from New to 3
  • Assignee changed from Erik Lindahl to Mark Abraham
  • Target version set to git master

Thanks for the report. There are two issues here, neither of which I think is a problem for your simulation. I have committed work-arounds for both to the git repository.

1) The warning about non-zero charge and construction of the two states precedes the detection of whether FEP is actually going on. That's a bit awkward, but not actually a problem except that the check for non-zero charge was doing an explicit comparison of two floating-point numbers. Normally, that's a bad idea because floating-point algebra doesn't obey the rules of normal algebra, but here the sums of the total charge should be over the same partial charges in the same order, so the comparison should have worked... Perhaps icc is doing something exotic (my icc 11.1 replicated the OP results; I didn't compare with gcc).

2) The extra functypes are F_GB13, which are duplicates of previous functypes (within the precision of the input data), but which fail a memcmp() test for (drumroll...) comparison of floating-point numbers, and so the duplicates get inserted in the list. The work-around I have committed is specific for F_GB13.

#2 Updated by Berk Hess over 8 years ago

  • Status changed from 3 to Closed

Also available in: Atom PDF