Does it makes sense to have sphere and non-sphere versions of nonbonded lists (ones with and without non-zero radii)? I know there are contexts where you can get away with the latter, but it seems like we mostly want spheres and the added confusion and maintenance burden might overwhelm the advantage. Thoughts? I don't see myself using the non-sphere version.
If the radii are zero, the difference comes down to fetching a zero attribute and adding it to each radius. And making sure that each particle has such an attribute.
Daniel Russel wrote: > Does it makes sense to have sphere and non-sphere versions of > nonbonded lists (ones with and without non-zero radii)? I know there > are contexts where you can get away with the latter, but it seems like > we mostly want spheres and the added confusion and maintenance burden > might overwhelm the advantage. Thoughts? I don't see myself using the > non-sphere version.
How would you propose implementing electrostatics, implicit solvation, statistical potentials, etc. with the sphere-based list? None of these have particle radii.
Ben
Just set the radii to 0 or use a dummy radii value for the radii field (we could easily enough set the radius key to FloatKey to mean ignore the radius).
On Mar 25, 2008, at 8:53 AM, Ben Webb wrote:
> Daniel Russel wrote: >> Does it makes sense to have sphere and non-sphere versions of >> nonbonded lists (ones with and without non-zero radii)? I know there >> are contexts where you can get away with the latter, but it seems >> like >> we mostly want spheres and the added confusion and maintenance burden >> might overwhelm the advantage. Thoughts? I don't see myself using the >> non-sphere version. > > How would you propose implementing electrostatics, implicit solvation, > statistical potentials, etc. with the sphere-based list? None of these > have particle radii. > > Ben > -- > ben@salilab.org http://salilab.org/~ben/ > "It is a capital mistake to theorize before one has data." > - Sir Arthur Conan Doyle > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
Sorry, better answer: You don't care about the radii for electrostatics, so you just ignore it when you pick your maximum search distance. The radius has nothing to do with energy evaluations, just with searches for nearby pairs.
On Mar 25, 2008, at 8:53 AM, Ben Webb wrote:
> Daniel Russel wrote: >> Does it makes sense to have sphere and non-sphere versions of >> nonbonded lists (ones with and without non-zero radii)? I know there >> are contexts where you can get away with the latter, but it seems >> like >> we mostly want spheres and the added confusion and maintenance burden >> might overwhelm the advantage. Thoughts? I don't see myself using the >> non-sphere version. > > How would you propose implementing electrostatics, implicit solvation, > statistical potentials, etc. with the sphere-based list? None of these > have particle radii. > > Ben > -- > ben@salilab.org http://salilab.org/~ben/ > "It is a capital mistake to theorize before one has data." > - Sir Arthur Conan Doyle > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
Daniel Russel wrote: > Sorry, better answer: > You don't care about the radii for electrostatics, so you just ignore it > when you pick your maximum search distance. The radius has nothing to do > with energy evaluations, just with searches for nearby pairs.
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). 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").
Ben
> 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.
is the non-sphere object representing something like a cube or other geometric object in the future ?
I find confusing the term non-sphere, since it is too fuzzy (ie. it can be almost anything !)
I suggest to use sphere object as it is (which of course has a radii attribute that must be larger than zero) and to have a point object (which either by definition has a radii value of zero or it does not have such an attribute at all. In the former case, just by defining a point object, the system should immediately define a zero value for the radii attribute and we should not bother the user to enter dummy values).
I think, for completeness, we should have both type of objects (sphere and point). I do not know how to overcome the efficiency problem, but certainly we can imagine situations where a mixture of spheres and points are both components of a model that need to be optimized. Points are very generic in nature and they can be used to represent almost everything (not necessarily physical objects, they can represent average, momentum, etc in 3D space ....). Therefore, we should have them included.
Pancho.
On Mar 24, 2008, at 8:52 PM, Daniel Russel wrote:
> Does it makes sense to have sphere and non-sphere versions of > nonbonded lists (ones with and without non-zero radii)? I know there > are contexts where you can get away with the latter, but it seems like > we mostly want spheres and the added confusion and maintenance burden > might overwhelm the advantage. Thoughts? I don't see myself using the > non-sphere version. > > If the radii are zero, the difference comes down to fetching a zero > attribute and adding it to each radius. And making sure that each > particle has such an attribute. > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev >
Francisco Melo wrote: > is the non-sphere object representing something like a cube or other > geometric object in the future ?
Nonbonded lists currently come in two forms, as I understand it - one works for points (i.e. get a list of all point pairs within distance N) while the other works for spheres (i.e. get a list of all sphere pairs with surface-surface distances within N). The latter essentially takes the distance N and adds the radii of the two spheres.
> I find confusing the term non-sphere, since it is too fuzzy (ie. it > can be almost anything !)
By non-sphere in this context we mean a particle that does not have a radius, but does have xyz coordinates.
> I suggest to use sphere object as it is (which of course has a radii > attribute that must be larger than zero) and to have a point object > (which either by definition has a radii value of zero or it does not > have such an attribute at all. In the former case, just by defining a > point object, the system should immediately define a zero value for > the radii attribute and we should not bother the user to enter dummy > values).
We don't have objects since C++ is not dynamically typed, but the closest approximation to what you suggest is the XYZDecorator. Particles themselves can have any attributes you like, so you could certainly define particles to represent things which are not points or spheres. For example, we already have particles to store a protein hierarchy (residues, chains, whole proteins) and these don't have xyz coordinates or radii, of course.
Ben
Francisco Melo wrote: > is the non-sphere object representing something like a cube or other > geometric object in the future ? > > I find confusing the term non-sphere, since it is too fuzzy (ie. it > can be almost anything !) > Yeah, we probably should have "Point" in the name of the non-sphere ones. > I do not know how to overcome the efficiency > problem, but certainly we can imagine situations where a mixture of > spheres and points are both components of a model that need to be > optimized. Currently there is not much difference in the code which gets executed. There is just one less pass through the Particles for the Point version. When we figure out a way to make the implementations quite different, then it would definitely make sense to have different ScoreStates (even then, I would be a fan of handling it internally to the Nonbonded list so the user doesn't have to worry about it).
> Points are very generic in nature and they can be used to > represent almost everything (not necessarily physical objects, they > can represent average, momentum, etc in 3D space ....). Therefore, we > should have them included. > Spheres are a natural subset of points, so any structure which handles spheres would handle points without any real changes. The other way around doesn't work. And I can see people accidentally using the wrong one and wondering why the right thing is not happening.
participants (4)
-
Ben Webb -
Daniel Russel -
Daniel Russel -
Francisco Melo