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
Make changes to support an "ignored" particle status that a model will essentially ignore when computing energies and forces, etc. This will make it possible to use KIM PMs in a "hybrid-mode" where they can be combined to build up the desired interactions. This will require backward-incompatible changes.
change particleContributing to contain an new extensible enumeration with three values: contributing, padding, and ignored. (This will lead to a lot of operator=() calls. We should profile the impact that this has and if it is significant consider solutions. Perhaps, move implementation to headers so inlining can be done?)
add support for compute arguments that are of type: extensible enumeration for particle class (or whatever we call it). Will need to design a good solution for this (use opaque pointers? support explicit specific extensible enumerations as needed? Probably the latter.)
change name of particleContributing argument to something more appropriate.
New definition of Neighbor Lists: as in 2.0, with the following new required behavior if there are ignored particles.
ignored particles have zero neighbors
ignored particles do not show up as neighbors of any other particles
The text was updated successfully, but these errors were encountered:
Make changes to support an "ignored" particle status that a model will essentially ignore when computing energies and forces, etc. This will make it possible to use KIM PMs in a "hybrid-mode" where they can be combined to build up the desired interactions. This will require backward-incompatible changes.
change
particleContributing
to contain an new extensible enumeration with three values:contributing
,padding
, andignored
. (This will lead to a lot ofoperator=()
calls. We should profile the impact that this has and if it is significant consider solutions. Perhaps, move implementation to headers so inlining can be done?)add support for
compute arguments
that are of type:extensible enumeration
forparticle class
(or whatever we call it). Will need to design a good solution for this (use opaque pointers? support explicit specific extensible enumerations as needed? Probably the latter.)change name of
particleContributing
argument to something more appropriate.New definition of Neighbor Lists: as in 2.0, with the following new required behavior if there are
ignored
particles.ignored
particles have zero neighborsignored
particles do not show up as neighbors of any other particlesThe text was updated successfully, but these errors were encountered: