strange behaviour of double precision grompp with amber ff
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.
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
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
#1 Updated by Mark Abraham almost 9 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.