You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A few people, most recently @Liozou, have asked about adding and removing atoms to/from a system. This isn't easy in other MD software so could be a selling point here, opening up simulation in the grand canonical ensemble among other things.
From a quick look it seems that the simulators allow the system to change atom number between steps. The challenge then is changing System itself (with an extension to ReplicaSystem). The following properties would need to change:
atoms
coords
velocities
atoms_data
masses (derived from atoms)
Indices in specific_inter_lists
Indices in constraints
Data in topology
Neighbour finder eligible and special matrices
The idea would be to have add_atom! and/or add_atoms! that add one or more atoms and all associated data to the end of the arrays, and delete_atom! and/or delete_atoms! that remove one or more atoms at the given indices. These functions would modify the arrays and indices as appropriate.
There are lots of details, such as providing a mini eligible matrix for added atoms to allow the addition of molecules. There are caveats, like loggers that rely on specific atom indices breaking, but those can be documented. GPU performance would probably be poor with an initial implementation, since arrays would be moved to the CPU and back. Longer term, GPU kernels could be written. Visualisation functions would also need updating.
It's also possible to hack this currently, if you know the maximum number of possible atoms, by manually changing the eligible matrix in the neighbour finder to turn on/off whole rows/columns. It might be worth making an example for that.
Let me know any thoughts.
The text was updated successfully, but these errors were encountered:
Another consideration is how to make this work efficiently when doing trials in a Monte Carlo simulation. You may want to add atom(s), sample the energy, then decide to keep or remove the added atom(s).
The only reason I can think of to add this is if you want to support the grad canonical ensemble. I'm sure there's other as well, but at the moment I don't see a reason to hack the interface to add this. I think effort would be better put in making the interfaces more generic so that changes like this are easier.
A few people, most recently @Liozou, have asked about adding and removing atoms to/from a system. This isn't easy in other MD software so could be a selling point here, opening up simulation in the grand canonical ensemble among other things.
From a quick look it seems that the simulators allow the system to change atom number between steps. The challenge then is changing
System
itself (with an extension toReplicaSystem
). The following properties would need to change:atoms
coords
velocities
atoms_data
masses
(derived fromatoms
)specific_inter_lists
constraints
topology
eligible
andspecial
matricesThe idea would be to have
add_atom!
and/oradd_atoms!
that add one or more atoms and all associated data to the end of the arrays, anddelete_atom!
and/ordelete_atoms!
that remove one or more atoms at the given indices. These functions would modify the arrays and indices as appropriate.There are lots of details, such as providing a mini eligible matrix for added atoms to allow the addition of molecules. There are caveats, like loggers that rely on specific atom indices breaking, but those can be documented. GPU performance would probably be poor with an initial implementation, since arrays would be moved to the CPU and back. Longer term, GPU kernels could be written. Visualisation functions would also need updating.
It's also possible to hack this currently, if you know the maximum number of possible atoms, by manually changing the
eligible
matrix in the neighbour finder to turn on/off whole rows/columns. It might be worth making an example for that.Let me know any thoughts.
The text was updated successfully, but these errors were encountered: