Project

General

Profile

Bug #328

Improvements to gmxtest package

Added by Mark Abraham over 10 years ago. Updated over 10 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Erik Lindahl
Category:
mdrun
Target version:
Affected version - extra info:
Affected version:
Difficulty:
uncategorized
Close

Description

Created an attachment (id=375)
Tarball of all fixes to gmxtest

The gmxtest package is a good idea, but has been the subject of much confusion in the hands of new users. It was also partly outdated (gmxtest-4.0.4 was still using grompp -np despite claiming to be suited for 4.0.4; .mdp files were using ns = simple and the non-existent domain_decomposition = no). So I made some improvements which I'm submitting for consideration.

.mdp files were all passed through a 4.0.5 grompp, and ns = simple in a handful of .mdp files was changed to ns = grid to suit the needs of domain decomposition. These .mdp files then passed tests.

I removed some spurious dotfiles in various subdirectories.

The distribution tarball contained some checkvir.tmp files that were probably extant from some failed tests - these should not be in the tarball.

I made numbers of improvements to gmxtest.pl itself:

1) Sometimes GROMACS program names were hardcoded, sometimes via variable lookup. setup_vars() could get called multiple times, breaking some variables because they got multiple prefixes/suffixes. I resolved the above using a named hash which only got set up once. I also permitted the user to specify a prefix and/or suffix for executable names in addition to those implied by -parallel or -double. This could be useful if a user has multiple versions to test (e.g. mdrun_404 and mdrun_405) or with Jussi Letohla's "g_pdb2gmx" prefixes.

2) The -np flag needed to precede parameters indicating actual work, if parallel processing was desired. I reworked that part of the script to use perl's eval to only do the work after all options had been parsed. Previously "gmxtest.pl all -np 2 all" might have worked, but it won't any more.

3) In the pdb2gmx tests, the lines

while ($line = <PIPE>) { printf(LOG $line); } close PIPE;

were erroneous because the printf tries to do interpolation of '%' symbols in the output. Such symbols can appear when reporting load balancing for parallel tests. Obviously, to fix, printf can be replaced with print. I actually went for the "simpler"

print LOG while <PIPE>;

4) test_systems now gives the user a list of files with numbers of errors for checking in a failed directory, rather than a generic message to check

5) Should cleandirs remove xxxx.tmp files?

On the systems I have at hand, the test suite now works on 4.0.5, except for five complex tests with only checkvir.tmp problems, and the [0-4]2[0-4] kernel tests which are testing kernels known to be buggy.

I'm happy for any of the above to be incorporated into any re-release of gmxtest. Acknowledgement would be welcome.

gmxtest-mabraham.tgz (15.1 MB) gmxtest-mabraham.tgz Tarball of all fixes to gmxtest Mark Abraham, 05/21/2009 03:36 AM

History

#1 Updated by Erik Lindahl over 10 years ago

Committed in gmxtest module of CVS, with proper crediting of Mark in the README file :-)

#2 Updated by Mark Abraham over 10 years ago

I can't see evidence of this commit. I'm not expert with CVS, but I did

cvs -z3 -d :pserver::/home/gmx/cvs login
cvs -z3 -d :pserver::/home/gmx/cvs co gmxtest

then

cvs stat gmxtest.pl

gives

===================================================================
File: gmxtest.pl Status: Up-to-date

Working revision:    1.10
Repository revision: 1.10 /home/gmx/cvs/gmxtest/gmxtest.pl,v
Sticky Tag: HEAD (revision: 1.10)
Sticky Date: (none)
Sticky Options: (none)

and

cvs log gmxtest.pl

gives

RCS file: /home/gmx/cvs/gmxtest/gmxtest.pl,v
Working file: gmxtest.pl
head: 1.10
branch:
locks: strict
access list:
symbolic names:
Version1: 1.1.1.1
David: 1.1.1
keyword substitution: kv
total revisions: 11; selected revisions: 11
description:
----------------------------
revision 1.10
date: 2009/05/25 15:53:30; author: lindahl; state: Exp; lines: +1 1
Fixed pdb2gmx tests that failed due to naming mismatches for TIP4p/TIP5p by
adding -maxwarn 1 to the grompp options.
---------------------------

revision 1.9
date: 2008/10/08 06:46:55; author: spoel; state: Exp; lines: +8 5
Added chomp($nerr_pot) as described in bugzilla 221.
---------------------------

revision 1.8
date: 2007/11/30 08:46:37; author: spoel; state: Exp; lines: +1 1
Added more checks
---------------------------

revision 1.7
date: 2007/11/30 08:45:11; author: spoel; state: Exp; lines: +16 0
Updated with error check
---------------------------

revision 1.6
date: 2007/09/17 20:19:04; author: spoel; state: Exp; lines: +1 0
Updated to latest code and compiled without optimizations, see README.
---------------------------

revision 1.5
date: 2007/09/15 20:29:31; author: spoel; state: Exp; lines: +6 5
Updated
---------------------------

revision 1.4
date: 2007/09/15 17:57:06; author: spoel; state: Exp; lines: +21 11
Updated
---------------------------

revision 1.3
date: 2007/09/15 11:39:24; author: spoel; state: Exp; lines: +125 90
Updated with use strict
---------------------------

revision 1.2
date: 2007/09/15 08:00:13; author: spoel; state: Exp; lines: +26 44
Updated
---------------------------

revision 1.1
date: 2007/09/14 18:47:40; author: spoel; state: Exp;
branches: 1.1.1;
Initial revision
----------------------------
revision 1.1.1.1
date: 2007/09/14 18:47:40; author: spoel; state: Exp; lines: +0 -0
GROMACS_3.3.2_Test_Set =============================================================================

Clearly I have a recent version that Erik's worked on to fix Justin Lemkul's vsite observations here http://www.gromacs.org/pipermail/gmx-users/2009-May/042171.html, but that version seems to have none of my improvements.

However, Justin's observations about bd-temp didn't make sense. The above CVS checkout doesn't have the bd-temp lines in pdb2gmx/em.mdp he mentions, and neither did the tarball I submitted (all the .mdp files in it had been passed through grompp for sanitization). There's something going on here that I don't understand!

#3 Updated by Erik Lindahl over 10 years ago

I have no idea why my initial commit didn't make it - must have been a conflict I missed... Anyway, it should be done now.

Also available in: Atom PDF