> Of course - but the radius attribute is used for both purposes. It seems > weird to require the user to specify a dummy radius attribute for > electrostatics (which, as you say, isn't needed for the actual energy > evaluation) just to make the nonbonded list work. Plus, I imagine the > nonbonded list can be made more efficient if it knows that all "spheres" > are the same (e.g. have zero radius). From my experience so far, I don't see that it makes a significant difference in terms of the amount of code that gets evaluated in the inner loop. The only difference is you have to inspect the radii (or lack there of) when you build the list.
> So either we keep both sphere and > non-sphere nonbonded lists, or the implementation can be asked to ignore > the radii (not sure what your earlier email meant, but perhaps taking a > FloatKey* and having NULL mean "ignore radius") FloatKey() is well defined and can act as a NULL value.