Gromacs

General guidelines

     

    This is firstly a "note-to-self" page, that I believe it could help out somebody approaching GROMACS as a developer willing to contribute to the main release distribution! 

    When bug fixing or implementing new features in GROMACS there are a bunch of items in your checklist that you want to do before you push your commit for review in Gerrit.

    [This page is still WIP.]

    Check your code contribution

    You should always check your new code contribution before you consider submitting it for reviewing. Code reviewers are often very busy folks, who are most likely taking care of reviewing several other contributions at the same time, on the top of additional tasks. Overloading them would result in an overall slowdown of the development process: definitely not a good idea.

    Fortunately, there is a lot you can do about it!

    Check that your code compiles without warnings

    By policy, GROMACS admits no compilation warnings. Compilation warnings are often dangerous when compiling the code on very different hardware platforms and generate unwanted behavior of the program. Moreover, compiler warnings are often highlighting that the computer is not really sure that it "understood" what you meant with the code that you wrote.

    If you want to be sure to catch all the warnings, enable the flags -Wall and -Werror in the gcc compiler (you can do it by adding those flags in the matching CMAKE fields). The -Wall option will show all compiler warnings, while the -Werror option will transform all warnings in errors, so the compilation process will be forced to stop if warnings are present.

    Check that all the tests are passed

    If you won't do it, Jenkins will do that for you by issuing nasty comments in Gerrit. You don't want to upset Jenkins. It bites!

    Be sure you set your REGRESSIONTESTS_DOWNLOAD=ON in cmake. To do so you can type in the build root:

    $ cmake -DREGRESSIONTESTS_DOWNLOAD=ON .

    Once you downloaded the tests, you can proceed to compile and run them!

    The easiest way is to issue a:

    $ make check -j nprocs

    command (substitute nprocs with the number of cores you intend to use for parallel compilation) after your compilation completed successfully.

    Sometimes bugs can be very nasty and reside inside the testing script. For this you should never trust the output of this command blindly. Use it for starters.

    If make check worked, now you can then try:

    $ make check -j nprocs VERBOSE=1
    

    This will produce a more verbose output from which you can read the command lines issued to run the tests.

    The main command used to run tests is /usr/bin/ctest. The make process will run it in quiet mode, producing verbose output only on test failure.

    This process may return false positives, hence it is a good practice to rerun it manually from the build root with the verbose output option:

    $ ctest -V
    

    At this level of verbosity you will likely be able to verify that tests are truly passed, and eventually get more insight in some possible anomalous output that you may want to check, if you believe it could be connected with the changes you introduced in the code.

     

    --- TODO

    Test-drive your code!

    Be kind, rewind!

    Let the git commit!

    Uncrustify, my friend!

    Ready!

    Page last modified 17:02, 7 Oct 2015 by metere