Re: [AMBER] Questions (and a small bug report) about SIRAH in Amber

From: Matias Machado <>
Date: Wed, 26 Aug 2020 10:07:09 -0300 (UYT)

Dear Charo,

Thanks to David and Scott's help we advanced a lot in debugging the issue...

This problem only shows up in cmake builds of AMBER Tools, while legacy builds work just fine...

Scott was observing the same odd things you are pointing in the code.

I did some tests and in fact comment lines stating with '#' are the only ones generating the buffer overflow.

This bug is not only restricted to SIRAH as the same issue will happen in AMBER ports of CUFIX.

On the other hand, comments after the parameter definition are not giving any problem, as they don't in other AMBER files.

Some fixes have been committed at both AMBER and SIRAH sides.



PS: While ago, I sent to the mailing list a reference topology based on Tutorial 5 as a control to check the correct loading of LJoff.frcmod. But I guess it got stuck awaiting for a moderator due to the file size :-(

----- Mensaje original -----
De: "Charo del Genio" <>
Para: "AMBER Mailing List" <>, "Matias Machado" <>, "david case" <>
Enviados: Miércoles, 26 de Agosto 2020 6:22:59
Asunto: Re: [AMBER] Questions (and a small bug report) about SIRAH in Amber

On 24/08/2020 15:26, Matias Machado wrote:
> We are aware of the bug you mention about "LJoff.frcmod"... so far we have only seen the issue in some MacOS, which may be your case... We are digging to fix it, I have some leads pointing either to the OS version (probably Catalina) or to the environment (perhaps Python)... but it's being hard to reproduce the error...
> I'm witting in capitals because it seems to work (no error message is reported by leap), but no LJ corrections are applied!!!
> So the generated prmtop is wrong and useless because SIRAH depends on those interactions to properly work. That explains the instabilities you see during the simulations.
> There are some technical things about leap and the frcmod format, which I won't go into detail now, but the number of blank lines is important to properly read each section... I have a workaround but it needs more testing...
> Hence, my STRONG advice at the moment is creating the topology files in Linux or in a MacOS that doesn't give any error.

Dear Matias,
        I've had a look at the source code, and it seems that the relevant lines that read the LJEDIT section are

while (segfound == 1) {
   if (fgets( sLINE, MAXSTRINGLENGTH, fIn ) == NULL) {
   iRead = sscanf( sLine, "%s %s %lf %lf %lf %lf", saStr[0], saStr[1],
                   &dRI, &dEI, &dRJ, &dEJ );
   if ( iRead <= 0 ) break;
   MESSAGE(( "Read: %s\n", sLine ));
   iParmSetAddNBEdit( psParms, saStr[0]. saStr[1]. dEI, dEJ, dRI, dRJ, "" );

which are in src/leap/src/leap/amber.c

Now, looking at the LJoff.frcmod file, it seems that what happens is that leap recognizes the LJEDIT card. Then, it passes to scan the next line. The sscanf first tries to read two strings, which, in
this case, will be "#" and "SIRAH", because it stops at the first blank character after each of them. Then it fails to read any numbers. The code doesn't break (and in fact it shouldn't) because
sscanf reads 2 objects. However, when going to set the non-bonded parameter pair changes via iParmSetAddNBEdit it crashes, because the strings read don't make sense.

So, first of all, it seems to me that eliminating these comment lines after LJEDIT is the start of a solution. However, there is another problem. Even if one eliminates all the comment lines after
LJEDIT (that is, all the "# Metallic interactions" and similar ones), some data lines still contain spurious characters. For example, the first line of the Electrolytic interactions contains two
strings ("ClW" and "X7"), four numbers, and then "# ClW - C7Nk". This will likely confuse the sscanf above, also because after that there is no function that tells leap to read to the end of the line
and disregard everything.

Thus, I believe that getting rid of all the comment lines after LJEDIT, *and of all the comments that occasionally end some lines* should actually do the job.
Alternatively, the code of leap can be changed to disregard any comment line and anything after that sscanf to the end of the line.

Does this make sense to you?



Dr. Charo I. del Genio
Senior Lecturer in Statistical Physics
Applied Mathematics Research Centre (AMRC)
Design Hub
Coventry University Technology Park
Coventry CV1 5FB
AMBER mailing list
Received on Wed Aug 26 2020 - 06:30:04 PDT
Custom Search