Move cvm::atom member data to synchronized vectors within cvm::atom_group

[giacomofiorin]

This issue can be broken up in multiple steps:

• Transform the atom_group class into a container for vectors of shape xxxx..., yyyy... and zzzz... for positions, velocities and total forces.
• Change the atom class into an iterator of the atom_group vectors, which implements for each property: (a) a property() accessor returning a copy of the corresponding property as a 3-vector, (b) a set_property() function that takes a 3-vector and writes it to corresponding location in the atom_group vector, and (c) an incr_property() function.
• Add pointers inside atom_group to vectors containing the gradients and fit gradients of each CVC and of each of its components (e.g. x through z for vector-valued CVCs). For CVCs that are affected by the fit, gradients and fit gradients should be requested at the same time to the atom group. For those that don't.
• Add laboratory-frame versions of the above if useful.
• Implement exceptions to the above for those CVCs like distancePairs where the number of components is prohibitive.
• Collect pointers to all of the above (positions, total forces, gradients, fit gradients) into a single class (nested in the atom_group namespace), together with a unique integer allowing a CVC to search the corresponding object in the atom group. This should allow quick access and garbage collection when a CVC is deleted but not the atom group.

[jhenin]

Another route would be moving gradients to the cvc objects - at least that seems more intuitive.

[giacomofiorin]

Yeah, but then the cvc objects have to deal with changes in frame of reference, fit gradients, and such. With no solution giving a perfect division of labor, I prefer having a lightweight CVC class and a heavy atom group class, instead of two classes that are both heavy.

[jhenin]

This means that at some point, when a CVC applies a force to an atom group, the atom group will have to look up among its stored gradients which ones are those of that particular CVC. My impression is that it would be simpler for the CVC to pass a reference to its own gradients, together with the force.

One way or another, a reference to the gradients will be needed, but I suppose it doesn't make a difference which object they are actually stored in... Except, say, when the CVC is deleted, in which case its gradients should be deleted as well. If the gradients were stored in the CVC, the atom group wouldn't need to know that a CVC has come and gone. It would just receive forces, or not. So to me the current setup seems like the atom group is doing someone else's work for them. Of course that is natural in the current situation where the atom group belongs to the CVC anyway, but not if that changes.

[giacomofiorin]

The atom group can easily store pointers to the arrays of gradients, and set a pointers to NULL when the corresponding CVC are deleted. To store atomic data (positions vs gradients) in two different classes sounds to me more complex, actually.

…

On Tue, Mar 14, 2017 at 4:25 PM, Jérôme Hénin ***@***.***> wrote: This means that at some point, when a CVC applies a force to an atom group, the atom group will have to look up among its stored gradients which ones are those of that particular CVC. My impression is that it would be simpler for the CVC to pass a reference to its own gradients, together with the force. One way or another, a reference to the gradients will be needed, but I suppose it doesn't make a difference which object they are actually stored in... Except, say, when the CVC is deleted, in which case its gradients should be deleted as well. If the gradients were stored in the CVC, the atom group wouldn't need to know that a CVC has come and gone. It would just receive forces, or not. So to me the current setup seems like the atom group is doing someone else's work for them. Of course that is natural in the current situation where the atom group belongs to the CVC anyway, but not if that changes. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#61 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AETZWWg0QClN_VRZ_ROCO_2RZbHmI68Zks5rlvefgaJpZM4IxYGN> .

-- Giacomo Fiorin Associate Professor of Research, Temple University, Philadelphia, PA Contractor, National Institutes of Health, Bethesda, MD http://goo.gl/Q3TBQU https://github.com/giacomofiorin