Closed joaander closed 1 week ago
@mphoward FYI, GlobalArray
apparently disabled the check that prevented overlapping ArrayHandles
on the same GPUArray
- even when it masqueraded as GPUArray
. Expect to trigger this exception when your external components when they are built against trunk-major
(or 5.0 after release):
https://github.com/glotzerlab/hoomd-blue/blob/ec0b84cdf49987f9d6fdd5d1f6d4bfa216edbfc7/hoomd/GPUArray.h#L1172-L1176
See the individual commits on this PR for methods to avoid the exception.
Got it, thanks! I can't remember whether we are actually using GlobalArray
anywhere or if we stuck with GPUArray
, but this simplification of the codebase so we don't have to worry about that choice will be very helpful.
Got it, thanks! I can't remember whether we are actually using
GlobalArray
anywhere or if we stuck withGPUArray
, but this simplification of the codebase so we don't have to worry about that choice will be very helpful.
ParticleData
, NeighborList
, ParticleGroup
and other core classes were using GlobalArray
. If you use any of these classes in your components then you were using GlobalArray
unknowingly. There are seeming weird issues that occur, like you can't do
for (unsigned int i = 0; i < m_group->getNumMembers();
if you have a handle to the tags array above the for loop because getNumMembers
might acquire the tags array when it rebuilds the group.
If you use any of these classes in your components then you were using
GlobalArray
unknowingly.
Got it, yeah, that makes sense. I'm sure we will run into at least some of these issues then.
Description
Remove the now unused
GlobalArray
andGlobalVector
classes.Motivation and context
Unused code adds needless complication the codebase.
How has this been tested?
CI checks.
Checklist:
sphinx-doc/credits.rst
) in the pull request source branch.CHANGELOG.rst
following the established format.