I think we should have a new class of object, which I am, for the time being calling a ParticleRefiner to handle hierarchical collision detection and generation of particles on the fly. I am currently using it to generate particles to cover the edges of my unstructured chains in order to better preserve excluded volume. The interface looks more or less like:
ParticleRefiner { // return a bunch of particles which refines p Particles refine(Particle p) // clean up the particles which refined p if needed cleanup(Particle p, Particles); };
And the methods must be called as a pair with the result of the first method passed as the second argument to the second method.
To use this I currently have a PairScore which I apply to the nonbonded pairs and a ParticleRefine which covers each bond with a set of particles chosen to conserve volume. The PairScore then applies another pair score to all pairs of refined particles. For that particle refined, "refine" creates new particles and "cleanup" destroys them (it probably makes sense to cache particles later).
ParticleRefines could also simply move down in a hierarchy, allowing hierarchical collision detection and such. Then cleanup wouldn't do anything at all.
Do other people have related use cases they are interested in?
Daniel Russel wrote: > I think we should have a new class of object, which I am, for the time > being calling a ParticleRefiner to handle hierarchical collision > detection and generation of particles on the fly. I am currently using > it to generate particles to cover the edges of my unstructured chains in > order to better preserve excluded volume. The interface looks more or > less like: > > ParticleRefiner { > // return a bunch of particles which refines p > Particles refine(Particle p) > // clean up the particles which refined p if needed > cleanup(Particle p, Particles); > }; > > And the methods must be called as a pair with the result of the first > method passed as the second argument to the second method.
Sounds reasonable to me. But what if the user passes a different list to cleanup? What sort of bad things would happen? Why couldn't the Refiner just keep its own list of particles?
Also, it seems like there's some overlap between this and CoverBondsScoreState.
Ben
On Jun 6, 2008, at 3:49 PM, Ben Webb wrote:
> Daniel Russel wrote: >> I think we should have a new class of object, which I am, for the >> time being calling a ParticleRefiner to handle hierarchical >> collision detection and generation of particles on the fly. I am >> currently using it to generate particles to cover the edges of my >> unstructured chains in order to better preserve excluded volume. >> The interface looks more or less like: >> ParticleRefiner { >> // return a bunch of particles which refines p >> Particles refine(Particle p) >> // clean up the particles which refined p if needed >> cleanup(Particle p, Particles); >> }; >> And the methods must be called as a pair with the result of the >> first method passed as the second argument to the second method. > > Sounds reasonable to me. But what if the user passes a different > list to cleanup? It could be hard to check, true.
> What sort of bad things would happen? Why couldn't the Refiner just > keep its own list of particles? I need to be able to refine two particles (for example when doing collision detection) using the same refiner (or pass two identical copies of the refiner). As a result, the refiner would have to maintain a map internally, which seems a bit heavy since the external user has the lists already.
> Also, it seems like there's some overlap between this and > CoverBondsScoreState. Yeah, the logic from that would move into such a class.
participants (2)
-
Ben Webb -
Daniel Russel