Re: [AMBER] Technical problems with running steered MD

From: Sergey Samsonov <sergeys.biotec.tu-dresden.de>
Date: Fri, 26 Aug 2011 09:20:31 +0200

David and Jason, thank you very much for the suggestions and help!

The problem was really the compiler, below is the output. Now we found
out what was the difference between the compilations and it works now
without problems.

Cheers,

Sergey

----------------------
das OS ist Rocks 5.3 (Centos 5.6)

gfortran -v:

Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada
--enable-java-awt=gtk --disable-dssi --disable-plugin
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
--with-cpu=generic --host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.2 20080704 (Red Hat 4.1.2-50)

gcc -v :
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada
--enable-java-awt=gtk --disable-dssi --disable-plugin
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
--with-cpu=generic --host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.2 20080704 (Red Hat 4.1.2-50)
-----------------------------



On 08/25/2011 05:22 PM, David A Case wrote:
> On Thu, Aug 25, 2011, Sergey Samsonov wrote:
>
>> now I put all the values for r1, r2, r3 and r4 explicitly as they are in
>> the "correct" run, still all of them are assigned to be 115 (which is
>> r2+100).
>> So it is really puzzling, why it doesn't work properly. The only
>> difference we have in different machines for AMBER is that in one case
>> (when everything works) it is SUSE Linux, and in another case it is Red
>> Hat.
>>
> I vaguely remember seeing a problem like this before, but I don't know how
> to find it in the archives. Can you tell us what compilers you are using
> on the machine that fails (output from "gcc -v" and "gfortran -v" if you are
> using GNU compilers)? Also, which version of Red Hat is it? Is this a serial
> run? Are there lots of restaints (and this is the only bad one), or is what
> you show the only restraint?
>
> Maybe someone else on the list has a better memory than I do. (OK, I *know*
> lots of people have better memories in general -- maybe someone will recognize
> this symptom.)
>
> ...dac
>
> Original problem report below:
>
>
>>
>> On 08/25/2011 04:21 PM, David A Case wrote:
>>
>>> On Thu, Aug 25, 2011, Sergey Samsonov wrote:
>>>
>>>
>>>> I've been running steered MD with AMBER 10 and I'm facing a kind of
>>>> weird problem. I use the same version of AMBER on 4 different
>>>> architectures. On 3 of them everything works fine, on the last one the
>>>> same input files yield very weird output in what is related to
>>>> restraints part. Here are these parts of the outputs:
>>>> 1. Normal run:
>>>> R1 = -85.000 R2 = 15.000 R3 = 15.000 R4 = 115.000 RK2 = 100.000 RK3 =
>>>> 100.000
>>>> R1A= -45.000 R2A= 55.000 R3A= 55.000 R4A= 155.000 RK2A= 100.000 RK3A=
>>>> 100.000
>>>> Rcurr: 14.989 Rcurr-(R2+R3)/2: 0.011 MIN(Rcurr-R2,Rcurr-R3): 0.011
>>>>
>>>> -----------------------
>>>>
>>>> 2. "Weird output":
>>>>
>>>> R1 = 115.000 R2 = 115.000 R3 = 115.000 R4 = 115.000 RK2 = 100.000 RK3 =
>>>> 100.000
>>>> R1A= -45.000 R2A= 55.000 R3A= 55.000 R4A= 155.000 RK2A= 100.000 RK3A=
>>>> 100.000
>>>> Rcurr: 14.989 Rcurr-(R2+R3)/2: 100.011 MIN(Rcurr-R2,Rcurr-R3): 100.011
>>>>
>>>> -----------------------
>>>>
>>>> Here is my restraints file, which is the same for both as well as input
>>>> file is the same:
>>>> ------------------------
>>>> # Restraints for the centers of mass
>>>> &rst iat=-1,-1, r2=15.00, rk2=100, r2a=55.00, ir6=0, igr1=1095 ,
>>>> igr2=2115,2134,2144,2171,2177,2192,2213,2234,2241,2256,2270,2289,2301,2311,2330,2354,2366,2376,2395,2409,2416,
>>>> &end
>>>> In first case the given r2 in input is read correctly and r1, r3, r4 are
>>>> calculated automatically.
>>>> In the second case all r1, r2, r3 and r4 are wrongly assigned to the
>>>> value, which is equal to the r2 in input +100.
>>>>
>>>>
>>> The values of r1,r2,r3,r4 are "sticky" if you don't specify them explicitly,
>>> they are not "calculated automatically"; rather, they take the values they had
>>> in the previous rst namelist. If there is no previous rst namelist, you may
>>> well get undefined behavior.
>>>
>>> See if you can fix the problem by explicitly setting all the variables to the
>>> values you want them to have.
>>>
>>>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
>


-- 
Sergey A. Samsonov
Postdoctoral researcher
Structural Bioinformatics
Biotechnology Center
Tatzberg 47-51
01307 Dresden, Germany
Tel: (+49) 351 463 400 83
Fax:   (+49) 351 463 402 87 
E-mail: sergey.samsonov.biotec.tu-dresden.de
Webpage: www.biotec.tu-dresden.de
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Fri Aug 26 2011 - 00:30:02 PDT
Custom Search