<div dir="ltr">Hi,<div><br></div><div>1) Both regressiontests and unit-tests are important. Unit tests won't be able to find bugs which are in the interplay of different modules. Unit tests make it *much* easier to narrow down an issue and run many tests quickly. Thus even if we have a way to run the verlet tests as unit-tests (which would be awesome) we still needed a regressiontest framework.</div><div><br></div><div>2) There are multiple serialization frameworks for C++. The issue has a lot of overlap with how to communicate complex data structures over MPI. And also a bit with how to offload those data structures to an accelerator. Thus it might make sense that we use the same framework for unit tests and MPI. See <a href="http://redmine.gromacs.org/issues/996">http://redmine.gromacs.org/issues/996</a>.</div><div><br></div><div>3) I don't think we should move tests from <a href="http://gmxtest.pl">gmxtest.pl</a> to the mdrun-integrationtests until the later is at least as functional (i.e. compares output values). And we should decide which way we go sooner rather than later. I don't think the perl approach is inherently bad. If we rewrite it partly to make it more extensible it might be a nice long-term solution.</div><div><br></div><div>Roland </div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 30, 2014 at 3:50 PM, Szilárd Páll <span dir="ltr"><<a href="mailto:pall.szilard@gmail.com" target="_blank">pall.szilard@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
As we aim at removing the group kernels for the next release and<br>
making the Verlet kernels the only feature-complete non-bonded<br>
implementation, we will need some form of extensive testing of all<br>
Verlet kernels. We've discussed things offline today and I'd like to<br>
summarize some of the conclusions and hopefully get some input on<br>
which way should we be heading.<br>
<br>
* Build unit tests around the kernels.<br>
This is probably the most sound way of testing the kernels, but it<br>
likely requires a lot of work; in particular, with the current code it<br>
seems to be quite difficult to set up all data structures required for<br>
search and kernels without calling the entire mdrun and based on<br>
Mark's experience serializing the data structures will be a pain too<br>
(although for calling just the kernels only interaction_const_t,<br>
nbnxn_atomdata_t, nbnxn_pairlist_set_t is needed).<br>
<br>
<br>
* Use the mdrun integration test harness<br>
Can't say much about it as I have admittedly not used it myself.<br>
However, what's sure is that compared to proper unit tests it requires<br>
giving up lightweight-ness. The hardness executes the full mdrun<br>
without the ability to test just a specific kernel but, just like with<br>
the gmxtest-based kernel tests, a specially crafted tpr and quite<br>
likely supporting code changes will be required to exercise only some<br>
code-paths and kernel versions/flavors.<br>
<br>
<br>
* Update gmxtest with Verlet kernel tests<br>
At the moment a most of the (group) kernel testing functionality is in<br>
gmxtest. While gmxtest is getting more and more outdated, for the next<br>
release the regression test suite will surely require a considerable<br>
amount of attention to at least remove group scheme tests. Having done<br>
that, not much will be left, which bring up a couple of weakly related<br>
questions:<br>
- Will (all) current tests will be migrated to Verlet setup?<br>
- Will they be kept in gmxtest?<br>
- ...or most/all will moved all these into some other form of testing?<br>
If there will, what will that be?<br>
If gmxtest is kept and tests will get simply migrated from group to<br>
Verlet setup, it may as well be the least amount of effort to adopt<br>
the kernel testing procedure used for the group kernels. Of course,<br>
this will just prolong the life of <a href="http://gmxtest.pl" target="_blank">gmxtest.pl</a>, but it may still be the<br>
most feasible approach and I believe there has been no consensus on<br>
whether all testing will be moved into the mdrun integration test<br>
harness.<br>
<br>
Cheers,<br>
--<br>
Szilárd<br>
<span class="HOEnZb"><font color="#888888">--<br>
Gromacs Developers mailing list<br>
<br>
* Please search the archive at <a href="http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List" target="_blank">http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List</a> before posting!<br>
<br>
* Can't post? Read <a href="http://www.gromacs.org/Support/Mailing_Lists" target="_blank">http://www.gromacs.org/Support/Mailing_Lists</a><br>
<br>
* For (un)subscribe requests visit<br>
<a href="https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers" target="_blank">https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers</a> or send a mail to <a href="mailto:gmx-developers-request@gromacs.org">gmx-developers-request@gromacs.org</a>.</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>ORNL/UT Center for Molecular Biophysics <a href="http://cmb.ornl.gov">cmb.ornl.gov</a><br>865-241-1537, ORNL PO BOX 2008 MS6309
</div>