Charles Greenberg

An alternative is to just adapt the existing GaussianKernel so that if the particle is a core::Gaussian, use its covariance directly. I like that better.

Hmm. I don't want to reproduce functionality from algebra::get_rasterized() which makes a density map out of a bunch of Gaussian3Ds. It works slightly differently because you only want to calculate...

Right, well, this is a feature not a bug :) The idea here is that passing PMI objects is the way to use PMI restraints and other classes. So if...

We should probably change the return value for BuildSystem.execute_macro() to give the PMI System instead of the root hierarchy though.

Possibly it could be functionally implemented within the atom::Copy decorator - just store the hierarchy it is a "copy of" and allow it to check if it's still good.

Yeah, I like that, traverse the hierarchy in a well-defined order and make sure that children have the same attributes. Could be a requirement for setting up a general Symmetric...

Those assumptions sound reasonable. Do you have to input torque for restraints or is that calculated automatically?

How's the outlook on this issue?

While we're at it, why not also try OpenCL?

For the GaussianKernel, we could rewrite the internal_resample loop to calculate the kernel at each voxel plane and just multiply them. But the SphereKernel isn't separable - at the corners...