search

ajkerr0 / kappa

A python package to calculate thermal conductivity across molecular interfaces.
MIT License
6 stars 4 forks source link

Need to keep track of forcefields interaction(s) turning on/off #33

Closed ajkerr0 closed 8 years ago

ajkerr0 commented 8 years ago

When an interaction is turned on or off in a forcefield, it would be nice to change a state variable that indicated that the forcefield has fundamentally changed. This would be used in Molecules using ff's as attributes; if an interaction has been changed then a signal needs to go off in Molecule that new energy/gradient functions need to be built because the old ones are invalid. Then there's the problem keeping track of this for all of the molecules that use FF as an attribute.

ajkerr0 commented 8 years ago

In regards to the last sentence in the above comment: store a list of molecule instances that use that FF and change their 'ready state' when an interaction is changed?

In regards to the main point: it looks like using descriptors in an Interaction class will be the most effective way to change state variables when interactions are changed. @'property usage will be bloated if there are, say, 10 different interactions to keep track of.

ajkerr0 commented 8 years ago

At this point I like the idea of using descriptors for the Interactions, but for molecules use the @'property method to add the molecule instance (or its address in memory) to a list/dict attribute of the ff instance. I would also need a way for molecules to remove themselves from these lists if they get a different FF instance assigned to them.

This process won't be the most robust but it should work. Once any interaction of a Forcefield gets changed at all, it will trigger the state variable that says the molecule needs to configure_energy_function again (even if the FF settings get changed to the settings of the last molecule configure).

ajkerr0 commented 8 years ago

I am having second thoughts on this issue. Storing a molecule (or a reference) to its own attribute seems spaghetti-like. Why not configure the energy/gradient functions every time they will be needed? It's not like it takes a long time. That configuration can be kept separate from the structure_lists, ring_lists, id_Lists, etc which only need to be called when molecules are created/combined.

Going to revert the code and close the issue.