<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi,<div><br></div><div>It will certainly be easier to have tests with close-to-perfect conservation.</div><div><br></div><div>However, it's too late in the cycle to decide that we're not going to release anything without tests. We should still do them, but I would like to see two separate parts:</div><div><br></div><div>1) Low-level tests that specifically check the output for several sets of input for a *module*, i.e. calling routines rather than running a simulation. The point is that this will isolate errors either to a specific module, or to modules it depends on. However, when those modules too should have tests it will be a 5-min job to find what file+routine the bug is likely to be in. </div><div><br></div><div>2) Higher-level tests that check whether this feature appears to work in practice in a simulation. The point of these tests is mostly to make sure other new features don't break our module.</div><div><br></div><div>Right now we have a bit of (2), but almost no (1).</div><div><br></div><div>Cheers,</div><div><br></div><div>Erik</div><div><br></div><div><br></div><div><br></div><div><div><div>On Feb 6, 2012, at 4:17 PM, Berk Hess wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000">
Hi,<br>
<br>
I agree test sets are very important.<br>
Having good tests will make development and especially the process
of accepting contributions much easier.<br>
<br>
Now that we have the new, by default, energy conserving loops, I
realize that energy conservation<br>
is extremely useful for validation. I think that having tests that
check energy conservation and particular<br>
energy values of particular (combinations of) functionality will
catch a lot of problems.<br>
The problems is that MD is chaotic and with non energy-conserving
setups the divergence is extremely fast.<br>
With energy conservation running 20 steps with nstlist=10, checking
the conserved energy + a few terms<br>
would be enough for testing most modules, I think.<br>
We still want some more extended tests, but that could be a separate
set.<br>
<br>
So setting up a framework for the simple tests should not be too
hard.<br>
Then we need to come up with a set of tests and reference values.<br>
<br>
Cheers,<br>
<br>
Berk<br>
<br>
On 02/05/2012 04:56 AM, Roland Schulz wrote:
<blockquote cite="mid:CAO2TwbkxK+Mh0NRKkCn9OZnb1vOJBB8y2k5+BrgGJi1gtTsXZQ@mail.gmail.com" type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
Hi,
<div><br>
</div>
<div>we agreed that we would want to have a test set for 4.6 but
so far we haven't made any progress on it (as far as I know). I
want to try to get this work started by posting here a list of
questions I have about the new test set. Please add your own
questions and answer any questions you can (no need to try to
answer all questions).</div>
<div><br>
</div>
<div>- Why do the current tests fail? Is it only because of
different floating point rounding or are there other
problems? What's the best procedure to find out why a test
fails?</div>
<div>- Which tests should be part of the new test set? </div>
<div>- Should the current tests all be part of the new test set?</div>
<div>- How should the new test be implemented? Should the
comparison with the reference value be done in C (within mdrun),
ctest script, python or perl?</div>
<div>- Should the new test execute mdrun for each test? Or should
we somehow (e.g. python wrapper or within mdrun) load the binary
only once and run many test per execution?</div>
<div>- What are the requirements for the new test set? E.g. how
easy should it be to see whats wrong when a test fails? Should
the test support being run under valgrind? Other?</div>
<div>- Do we have any other bugs which have to be solved before
the test can be implemented? E.g. is the problem with shared
libraries solved? Are there any open redmine issues related to
the new test set?</div>
<div>- Should we have a policy that everyone who adds a feature
also has to provide tests covering those features?</div>
<div>- Should we have a conference call to discuss the test set?
If yes when?</div>
<div>- Should we agree that we won't release 4.6 without the test
set to give it a high priority?</div>
<div>Roland<br clear="all">
<div>
<br>
</div>
-- <br>
ORNL/UT Center for Molecular Biophysics <a moz-do-not-send="true" href="http://cmb.ornl.gov/">cmb.ornl.gov</a><br>
865-241-1537, ORNL PO BOX 2008 MS6309<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
</blockquote>
<br>
</div>
-- <br>gmx-developers mailing list<br><a href="mailto:gmx-developers@gromacs.org">gmx-developers@gromacs.org</a><br>http://lists.gromacs.org/mailman/listinfo/gmx-developers<br>Please don't post (un)subscribe requests to the list. Use the <br>www interface or send it to gmx-developers-request@gromacs.org.</blockquote></div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>--<br>Erik Lindahl <<a href="mailto:erik@kth.se">erik@kth.se</a>><br>Professor of Theoretical & Computational Biophysics<br>Department of Theoretical Physics & Swedish e-Science Research Center<br>Royal Institute of Technology, Stockholm, Sweden<br>Tel1: +46855378029 Tel2: +468164675 Cell: +46734618050</div></div></span></div></span></span>
</div>
<br></div></body></html>