[gmx-users] compilation instructions, the gromacs wiki, documentation, and test suites

[Rossen Apostolov]

Hi,

On 12/22/10 4:39 AM, Justin A. Lemkul wrote:
>
>
> chris.neale at utoronto.ca wrote:
>> Dear Roland:
>>
>> I am not sure what my barrier is electronically, only that there is a 
>> barrier. The web site has changed since my last attempt to make 
>> modifications, but I still can not add to the site as I once could 
>> when it was simply a wiki. Currently, I have a tab labeled "[MISSING: 
>> skin.common.this-page]" and if I click on it there is an edit page 
>> option but it is commented out, even when I am logged in.
Chris: what is your username at www.gromacs.org? I couldn't find you in 
the registered users. I fixed the [missing...] label, it was due to 
unsupervised update of the mindtouch base (we're using a custom skin).


> To edit the wiki, you have to be added as a contributor by Rossen 
> after you've created your account.  This process started when the 
> Gromacs site transitioned over.
>
>> My suggestion for the documentation and the test suite is that these 
>> aspects of gromacs become part of the "vision" in the way that speed 
>> is prioritized. A while back, myself and a colleague had a gromacs 
>> pull-code extension turned down as a contribution because it would 
>> negatively impact the overall performance of gromacs in the general 
>> case. After I mulled that decision over for a while, I realized that 
>> it was actually a very good and very important decision made by the 
>> developers to keep gromacs as fast as possible over the long term 
>> even if that meant losing out on some bells and whistles in the short 
>> term. So I would suggest that this philosophy might be usefully 
>> applied to code development and that modification acceptance would be 
>> dependent on the provision of both documentation and a test suite. 
>> Not glamorous, I know, but it's my two-cents and it's why I tend to 
>> stay more than a year behind the release cycle with my important runs.
>>
>
Having a proper test suite is indeed very important. After moving to C++ 
with a different code structure it will be  easier to have unit testing 
of functionality. A speed benchmarking suite is mostly ready too.


> I tend to be the same way.  I will usually play with new features, but 
> I haven't done any production runs with any version post-4.0.7 (mostly 
> due to the fact that I prefer continuity).  I agree with this 
> assessment.  The need for a test suite that actually works has been 
> debated for a long time, usually amounting to incremental progress at 
> best, but it seems that other MD packages provide extensive tests, 
> though Gromacs does not.  I know many are willing to help develop it, 
> and I guess we're waiting on a way to effectively communicate, set 
> priorities and to-do lists, and put it all in motion.  Is the Redmine 
> infrastructure on the way?  Do we have an estimate on when that might 
> be available?  I think it would really help.
>

Actually today I set a testbed for Redmine. I could even import a 
snapshot of bugzilla so we can preserve old information. We'll probably 
freeze bugzilla in a read-only mode pretty soon and move everything to 
redmine.

Cheers,
Rossen

> -Justin
>
>> Thanks again,
>> Chris.
>>
>> -- original message --
>>
>> sorry I didn't pay attention (was in a hurry). I know that you have 
>> helped
>> with the documentation and wouldn't have suggested to you to put it 
>> on the
>> wiki if I recognized it was you. I thought it was a new user. And I 
>> didn't
>> want to criticize but only point out (to the assumed new user) that 
>> the wiki
>> can be improved by everyone.
>>
>> Do you have suggestion of how to improve the documentation or the test
>> suite? What is the barrier to the wiki?
>> I have mentioned that before (on the dev-list) but I think a monthly 
>> phone
>> conference could help to coordinate those kind of issues.
>>
>> Roland
>>
>> On Mon, Dec 20, 2010 at 10:07 PM, <chris.neale at utoronto.ca> wrote:
>>
>>> <<I have changed the topic to continue a conversation that started on
>>> "cmake --> relocation R_X86_64_32S against `a local symbol' can not 
>>> be used
>>> when making a shared object;>>
>>>
>>> Dear Roland:
>>>
>>> It is not my intention to be confrontational, your assistance was very
>>> useful, I appreciate it very much, and I realize that it's not your 
>>> job to
>>> comment everything (or even answer my questions on this mailing list).
>>> Further, I have actually contributed significantly to the gromacs 
>>> wiki in
>>> the past, but it's not a wiki anymore and the barrier to posting is 
>>> enough
>>> that I'm not the only person who has given up on it.
>>>
>>> Second, I would like to mention that as a user I am extremely 
>>> hesitant to
>>> upgrade my gromacs version due to the lack of commenting and lack of 
>>> a good
>>> test suite. Anybody who used the free energy code with TIP4P in 
>>> 2008/2009 or
>>> used the pull code in the early versions of gromacs 4 will probably 
>>> agree
>>> with me that testing and documentation are at least as important as new
>>> code.
>>>
>>> I'm not asking anybody else to add documentation or test suites. I'm 
>>> simply
>>> pointing out that gromacs is falling behind in these areas and it is 
>>> not
>>> necessarily a good thing. I think that there is a utility in simply 
>>> noting
>>> this.
>>>
>>> Sincerely,
>>> Chris.
>>>
>>>
>>
>>
>