Closed joaander closed 8 years ago
Original comment by Michael Howard (Bitbucket: mphoward, GitHub: mphoward).
Any thoughts / opinions on if this task should be done? On the one hand, it is convenient not to have to make a neighbor list for simple pair potentials. On the other hand, it is only a one-liner to create a neighbor list, and it forces the user to think carefully about how to use their neighbor lists effectively. If I am updating the neighbor list documentation (#141), it probably makes sense for me to also take care of this task at the same time, and then remove the discussion related to the global neighbor list wrappers from the docs (which are somewhat cumbersome anyway).
explicit is better than implicit. I say we go ahead with this plan.
I'm trying to make the time to get the sphinx docs up and running, but keep getting sidetracked by administrative tasks and travel. Hopefully tomorrow I can make enough forward progress on that so that I no longer hold you up.
Sphinx documentation is now fully in place on the 2.0 branch. To build the docs:
Update python unit tests to proposed API
refs #105
Remove global neighbor list and wrappers
refs #105
Update python unit tests to proposed API
refs #105
Remove global neighbor list and wrappers
refs #105
Merged in mphoward/hoomd-blue/remove_global_nlist (pull request #173)
fixes #105
Remove global neighbor list
Original report by Michael Howard (Bitbucket: mphoward, GitHub: mphoward).
The documentation says that default global neighbor lists may be removed in favor of the new explicit specification of neighbor list style. If this is the case, the things that would need to be cleaned up are:
Remove the following:
Update all pair potentials to remove nlist=None as an option and remove any references to the default global neighbor list. There is probably a spot in charge.pppm that also needs this.