An example of using cuda within plumed: the COORDINATION

[Iximiel]

Description

I implemented a basic version of the Coordination with cuda.
It is not perfect, but showcase an approach to the problem using cuda.

I do not know if it is possible to run any GPU code on the nodes, as now there is no CI integration.

The plug in is set up like the pycv one.

I am adding a comment some graphs with the performance difference between the CPU and the cuda versions (run on Leonardo).

Target release

I would like my code to appear in release 2.10

Type of contribution

• changes to code or doc authored by PLUMED developers, or additions of code in the core or within the default modules
• changes to a module not authored by you
• new module contribution or edit of a module authored by you

Copyright

• I agree to transfer the copyright of the code I have written to the PLUMED developers or to the author of the code I am modifying.

• the module I added or modified contains a COPYRIGHT file with the correct license information. Code should be released under an open source license. I also used the command cd src && ./header.sh mymodulename in order to make sure the headers of the module are correct.

Tests

• I added a new regtest or modified an existing regtest to validate my changes.
• I verified that all regtests are passed successfully on GitHub Actions.

[Iximiel]

These images show how the time scales with nat= 108, 1944, 2916, 5832, 11664, 31104, 40500 atoms in the system.
The box is orthorombic and the atoms are arranged by tiling in xyz the space with the 6x6 box of 108 atoms that is used in the various coordination regexps.

The time axis is logarithmic.

single group (self)

between two groups

between two groups, but with the PAIR flag

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 70.28112% with 74 lines in your changes are missing coverage. Please review.

Project coverage is 84.18%. Comparing base (ed060dd) to head (d4c759f).
Report is 84 commits behind head on master.

❗ Current head d4c759f differs from pull request most recent head aabbcc2. Consider uploading reports for the commit aabbcc2 to get more accurate results

Files	Patch %	Lines
src/cltools/Benchmark.cpp	19.69%	53 Missing ⚠️
src/tools/PlumedHandle.cpp	30.76%	9 Missing ⚠️
src/core/PlumedMain.cpp	92.00%	2 Missing ⚠️
src/core/TargetDist.cpp	0.00%	2 Missing ⚠️
src/core/WithCmd.h	71.42%	2 Missing ⚠️
src/core/ActionWithValue.cpp	50.00%	1 Missing ⚠️
src/core/CLToolMain.cpp	66.66%	1 Missing ⚠️
src/core/GREX.cpp	75.00%	1 Missing ⚠️
src/tools/Pbc.cpp	96.15%	1 Missing ⚠️
src/tools/Pbc.h	75.00%	1 Missing ⚠️
... and 1 more

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@           Coverage Diff            @@
##           master    #1028    +/-   ##
========================================
  Coverage   84.18%   84.18%            
========================================
  Files         612      614     +2     
  Lines       56497    56669   +172     
========================================
+ Hits        47563    47709   +146     
- Misses       8934     8960    +26     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[GiovanniBussi]

@Iximiel I see that this is fully in the plugin directory, so merging should nor hurt anything.

As for python stuff, I see some potential redundancy in the way you arranged regtests. Probably the best is to merge this as well and then check if we can factorize some script.

Some additional comments:

• I noticed that your regtests have a single snapshot in the trajectory. Could this be a weakness in testing? I have no idea how the code works, but would it be more robust to check that you can run through multiple steps without overwriting memory or so? Adding frames should be easy. I like that you always make the test against the CPU, which should result in diff=0.0. This means you can manipulate the trajectory as you like and you will always know what's the expected result. If you only test the difference, you might also generate the trajectory on the fly (with awk, there's some other examples in the regtests) and only check that diff=0.0
• The absence of CI is a bit scaring. I would suggest that you prepare a script somewhere so that you can easily submit tests on leonardo on a given commit. The code is quite decoupled from the rest though, so I don't expect problems.
• This calculation is without neighbor lists right? (all neighbors)

Then if you think it's ok I can just click merge

[Iximiel]

• I noticed that your regtests have a single snapshot in the trajectory. Could this be a weakness in testing? I have no idea how the code works, but would it be more robust to check that you can run through multiple steps without overwriting memory or so? A

Now that I think it, the test are more or less all weak because I'm just using the cube of 108 atoms repeatedly, so if I am not loading the atoms correctly I might use the same, not changed atoms.

• The absence of CI is a bit scaring.

I agree. Is this a "me problem" or a "future me problem"? Maybe can be solved with the device emulation, but i need to dig further

I would suggest that you prepare a script somewhere so that you can easily submit tests on leonardo on a given commit.

Because of the 2FA I think that will need a manual run, but the script should not be a problem

• This calculation is without neighbor lists right? (all neighbors)

Yes.
Do you think this should be measured also against the CPU with the NL activated? It might be a fairer comparison.

Let me update a little the tests and then I think this can be accepted

[GiovanniBussi]

Maybe can be solved with the device emulation, but i need to dig further
This would be amazing

plugins/cudaCoord/regtest/trajectories/traj-orthoBig.xyz

Maybe can we reduce a bit the footprint by generating this with awk before running the test?

[Iximiel]

plugins/cudaCoord/regtest/trajectories/traj-orthoBig.xyz

Maybe can we reduce a bit the footprint by generating this with awk before running the test?

I collapsed both the pbc and the non-pbc trajectories in 10 frames

If you merge-squash we do not track the part with all the trajectories multiplied, and that would leave a lighter footprint

[GiovanniBussi]

OK let me know what it's ready for merge!

[Iximiel]

I think is ready to be merged as is.

I have no idea how much time would take to set up the CI for the GPU code