January 8th, biweekly GROMACS developer meeting

Developers discussions
1

Dear all,

Happy new year! Next GROMACS developer meeting will be Wednesday, January 8, 2025 4:00 PM on zoom.

Any specific topics you wish to discuss, you can share it by answering to this post. So, everybody else interested can join and contribute to the discussion. :)

When 2025-01-08 at 17:00 CET

Where:
Join our Zoom Meeting (magic link)

Meeting ID: 692 7708 9234
Password: gmxdevs

Join by SIP:
69277089234@zoom.nordu.net

See you next Wednesday!

2

Suggested topic: discuss on whether we want and how to treat developer-only features, not intended for production use in reasonable circumstances but helpful for testing; ex.: Clang-CUDA or sanitizer builds. Should we differentiate them from experimental-but-useful features (e.g., NVSHMEM)? Warning at runtime? Warning at build time? Warning in the documentation? Naming? Specific decision to be made: whether we want to have a runtime or build-time or documentation warning about ACpp and DCP++ builds on NVIDIA architectures and DPC++ on AMD.

3

A kind remind. Today biweekly GROMACS developer meeting at 17:00 CET on zoom
Today agenda:

  • welcome
  • discussion how to treat developer-only features by Andrey @al42and
  • new schedule of biweekly GROMACS developer meeting @avilla

Where:
Join our Zoom Meeting (magic link)

Meeting ID: 692 7708 9234
Password: gmxdevs

See you later

4

It might be good to discuss how to approach resolving the stochastic failures in Physical validation fails (#5207) · Issues · GROMACS / GROMACS · GitLab @Michael_Shirts

5

Yes, we add it to the agenda

1 Like
6

Wrap up is here: Physical validation fails (#5207) · Issues · GROMACS / GROMACS · GitLab

7

The discussion on the developer-only features converged to the fact that extra runtime warnings are both annoying to users and cause extra maintenance to keep up-to-date (albeit to a lesser extent in the code that’s being actively worked on). In particular case of weird GPU builds, it was considered that expanding the documentation to make more clear which backend is recommended is a better solution. So, no additional warning for not-recommended backends, but I will work on improving the installation doc to make the backend choice more clear to users.

Additionally, the discussion touched upon the broader issue of “experimental” features, but it was decided to postpone it to some later meeting.