[gmx-developers] Verlet kernel testing in 5.1

Szilárd Páll pall.szilard at gmail.com
Tue Sep 30 21:50:09 CEST 2014


As we aim at removing the group kernels for the next release and
making the Verlet kernels the only feature-complete non-bonded
implementation, we will need some form of extensive testing of all
Verlet kernels. We've discussed things offline today and I'd like to
summarize some of the conclusions and hopefully get some input on
which way should we be heading.

* Build unit tests around the kernels.
This is probably the most sound way of testing the kernels, but it
likely requires a lot of work; in particular, with the current code it
seems to be quite difficult to set up all data structures required for
search and kernels without calling the entire mdrun and based on
Mark's experience serializing the data structures will be a pain too
(although for calling just the kernels only interaction_const_t,
nbnxn_atomdata_t, nbnxn_pairlist_set_t is needed).

* Use the mdrun integration test harness
Can't say much about it as I have admittedly not used it myself.
However, what's sure is that compared to proper unit tests it requires
giving up  lightweight-ness. The hardness executes the full mdrun
without the ability to test just a specific kernel but, just like with
the gmxtest-based kernel tests, a specially crafted tpr and quite
likely supporting code changes will be required to exercise only some
code-paths and kernel versions/flavors.

* Update gmxtest with Verlet kernel tests
At the moment a most of the (group) kernel testing functionality is in
gmxtest. While gmxtest is getting more and more outdated, for the next
release the regression test suite will surely require a considerable
amount of attention to at least remove group scheme tests. Having done
that, not much will be left, which bring up a couple of weakly related
- Will (all) current tests will be migrated to Verlet setup?
- Will they be kept in gmxtest?
- ...or most/all will moved all these into some other form of testing?
If there will, what will that be?
If gmxtest is kept and tests will get simply migrated from group to
Verlet setup, it may as well be the least amount of effort to adopt
the kernel testing procedure used for the group kernels. Of course,
this will just prolong the life of gmxtest.pl, but it may still be the
most feasible approach and I believe there has been no consensus on
whether all testing will be moved into the mdrun integration test


More information about the gromacs.org_gmx-developers mailing list