I have been doing some work in the recent months regarding support for virtual sites with GPU-resident update.
I’ve broken the change up into several parts, with the tracking issue at #5613:
- Supporting triangle constraints on the GPU with LINCS (technically unrelated, but needed for the Martini use case) : !6116
- Enabling the simplest vsite types 1, 2 and 3, including all of the necessary mdrun wiring: !6119
- Adding vsite velocities: !6149
- All remaining vsite types (except vsites-N): !6150
- mdrun integration test: !6151
This is mainly an implementation effort and all of the math and most of the logic is adapted from the CPU path. That said, as was brought up in the group meeting, it would be good to have an in-depth technical review. In particular, some points worth discussing/design decisions to be taken are:
- adding backend-agnostic helper function for extra LINCS matrix expansion orders (as per this comment)
- whether we want the vsite-type switch within the kernel (meaning one global kernel launch covering all vsite types) or outside (one kernel per type)
- mdrun schedule: are vsites always in sync?
- do we want implement virtual site velocity calculation on the GPU, or is it enough to fall back to the CPU path ad hoc?
- testing & validation strategy
- other backends (see SYCL prototype by Mark at !6173)
- any other issues that come up
Who would be willing to participate, and what’s your availability?
I would suggest some time end of this week, either Thursday (any time) or Friday (preferably morning). Next week would be harder to make for me, but possible.