Project

General

Profile

Bug #1297

infinite relative permittivity is incompletely implemented

Added by Mark Abraham almost 4 years ago. Updated almost 2 years ago.

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

Description

0 ir->epsilon_r[f] is supposed to signal infinite relative permittivity, i.e. fully conducting, so no electrostatic potential.

As partly reported on gmx-developers today by Mark Tianwu Zang:
  • ewald_LRcorrection, ewald_charge_correction, do_ewald and calc_verlet_buffer_size use ir->epsilon_r without checking for zero
  • solve_pme_yzx does likewise (indirectly)
  • generalized Born code does likewise (genborn.c, and all the way into the group kernels)
    So various code will divide by zero.

I think the PME, GB and ic data structures should store a multiplicative constant (as fr and ic try to do), that their init routines should all apply the same logic when using inputrec->epsilon_r[f], and that only inputrec should have members epsilon_r[f].

Because this goes everywhere, it's probably easiest to do in master branch with some tests that (0 epsilon_r[f]) => (no crash and no Coulomb) for all coulombtype and GB. I have some as-yet unpublished toys that will support doing that. Then we cherry-pick the result back.

Associated revisions

Revision af3e1a13 (diff)
Added by Erik Lindahl almost 2 years ago

Disallow infinite epsilon with PME or GB.

This leads to divide-by-zero errors, and since it just turns off
electrostatics it will be faster to use a plain cutoff, which we
now recommend instead.

Fixes #1297.

Change-Id: Ia5eba7a1d4bd3b387174c9cb4878a2d65ead2c6c

History

#1 Updated by Mark Abraham almost 4 years ago

Of course, it doesn't make much sense to trigger these code paths with 0 == epsilon_r[f] - all you do is waste time. tpbconv -zeroq supports doing a rerun that happens to have no/few electrostatic interactions, because the searching notices atoms have no charge and the kernels become an empty loop.

We can probably extend coulombtype to include None in 5.0 - a null electrostatics model might be useful for testing code, or with rerun.

The question becomes "why do we support infinite relative permittivity?"

#2 Updated by David van der Spoel almost 4 years ago

Infinite relative permittivity is the best way of using RF and related methods. Even thought RF is not great we should support it for historical reasons.

#3 Updated by Berk Hess almost 3 years ago

Infinite epsilon_rf is fully and properly supported.
Infinite epsilon_r simply completely turns off all electrostatic interactions. I don't see any need to support this with PME, GB, etc. grompp should either give a fatal_error and suggest to switch to plain cut-off with epsilon_r=0 for optimal performance.

#4 Updated by Gerrit Code Review Bot almost 2 years ago

Gerrit received a related patchset '1' for Issue #1297.
Uploader: Erik Lindahl ()
Change-Id: Ia5eba7a1d4bd3b387174c9cb4878a2d65ead2c6c
Gerrit URL: https://gerrit.gromacs.org/4747

#5 Updated by Erik Lindahl almost 2 years ago

  • Status changed from New to Fix uploaded

#6 Updated by Rossen Apostolov almost 2 years ago

  • Status changed from Fix uploaded to Closed

Also available in: Atom PDF