<br><br><div class="gmail_quote">On Sat, Feb 11, 2012 at 11:31 AM, Shirts, Michael (mrs5pt) <span dir="ltr"><<a href="mailto:mrs5pt@eservices.virginia.edu">mrs5pt@eservices.virginia.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">> 1) Low-level tests that specifically check the output for several sets of<br>
> input for a *module*, i.e. calling routines rather than running a simulation.<br>
> The point is that this will isolate errors either to a specific module, or to<br>
> modules it depends on. However, when those modules too should have tests it<br>
> will be a 5-min job to find what file+routine the bug is likely to be in.<br>
<br>
</div>I'm not exactly sure how this works. If we test modules, we have to be<br>
writing a bunch of new code that interacts with the modules directly, and so<br>
we may miss things that happen in actual simulation cases. I sort of favor<br>
just actually running grompp and mdrun, because the errors that occur will<br>
be the errors that people actually see. I haven't found an error yet that is<br>
particularly hard to isolate to a given file pretty quickly once it is<br>
identified. Perhaps for particular aspects things (testing that dozens of<br>
inner loops give consistent numbers) this makes sense, but I'm not sure it<br>
makes sense for everything. I'm not sure how you _just_ test pressure<br>
control, for example.<br></blockquote><div>One could read virial values from a data file and pass it to the pressure control. And then check that the pressure control is behaving as it should. </div><div><br></div><div>I think unit tests would be very useful for the planned conversion to C++. We will have to convert individual modules one at a time and I assume that the overall program will be broken often. In that case unit tests might enable us to test individual modules without the overall programming working. </div>
<div><br></div><div>Roland</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
Best,<br>
~~~~~~~~~~~~<br>
Michael Shirts<br>
Assistant Professor<br>
Department of Chemical Engineering<br>
University of Virginia<br>
<a href="mailto:michael.shirts@virginia.edu">michael.shirts@virginia.edu</a><br>
<a href="tel:%28434%29-243-1821" value="+14342431821">(434)-243-1821</a><br>
<br>
<br>
<br>
--<br>
gmx-developers mailing list<br>
<a href="mailto:gmx-developers@gromacs.org">gmx-developers@gromacs.org</a><br>
<a href="http://lists.gromacs.org/mailman/listinfo/gmx-developers" target="_blank">http://lists.gromacs.org/mailman/listinfo/gmx-developers</a><br>
Please don't post (un)subscribe requests to the list. Use the<br>
www interface or send it to <a href="mailto:gmx-developers-request@gromacs.org">gmx-developers-request@gromacs.org</a>.<br>
<br>
<br>
<br>
<br>
</div></div></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<br>