Dear Jason,
we've reduced the test case to having the `rest` file only contain
> &rst
> iresid = 0,
> restraint = "torsion [:70.C1, :70.O5, :70.C5, :70.C4]",
> ialtd=1,
> r1 = 35,
> r2 = 50,
> r3 = 60,
> r4 = 75,
> rk2 = 10,
> rk3 = 10,
> &end
vs.
> &rst
> iresid = 0,
> iat=1144,1146,1147,1154,
> ialtd=1,
> r1 = 35,
> r2 = 50,
> r3 = 60,
> r4 = 75,
> rk2 = 10,
> rk3 = 10,
> &end
In the first case (new syntax), sander -- as before -- crashes on the
Centos 5.7 / GCC 4.6.2 build.
In the second case (old syntax), both sanders (Ubuntu 10.04 / ICC 12.1
and Centos 5.7 / GCC 4.6.2 build) run fine.
Hence, it looks like an incompatibility between the code of the new
syntax parser and the GCC version 4.6.2 (and probably older versions, as
we've observed the problem before) and/or the build environment in use
(Centos 5.7). How should we proceed to further track the problem down?
Thanks,
Jan-Philip
On 01/27/2012 07:15 PM, Jason Swails wrote:
> On Fri, Jan 27, 2012 at 11:06 AM, Jan-Philip Gehrcke<
> jgehrcke.googlemail.com> wrote:
>
>> Jason,
>>
>> as I am still quite new to Amber, I am not sure what you mean. Could you
>> give an example? You say this old syntax is cryptic, so I would say that
>> translating the natural language to the cryptic language is not a good
>> general solution to this problem.
>>
>> I assume that trying this translation is important for debugging
>> purposes -- so, how should we start there?
>>
>
> So instead of putting something like
>
> restraint = "torsion [:70.C1, :70.O5, :70.C5, :70.C4]"
>
> put
>
> iat=140,142,144,148
>
> (where 140 is the atom number corresponding to :70.C1, 142 is the atom
> number corresponding to :70.O5, etc.). This input is detailed in chapter 6
> of the Amber manual. I suggest this because it does not depend on any kind
> of free-format parsing. I'm guessing it may be that the parser is not
> handled properly with the compiler you're trying to use or something, but
> if you can run using the "old" style NMR input format, that will help
> narrow the problem down.
>
> All the best,
> Jason
>
>
>> Cheers
>>
>>
>>
>> On 01/27/2012 04:28 PM, Jason Swails wrote:
>>> What happens if you _don't_ use the "natural language" syntax and use the
>>> rather cryptic, old Amber one instead?
>>>
>>> On Fri, Jan 27, 2012 at 8:51 AM, Jan-Philip Gehrcke<
>> jgehrcke.googlemail.com
>>>> wrote:
>>>
>>>> Huhu!
>>>>
>>>> We're using Amber 11 (including all bugfixes up to last week) and
>> observed
>>>> a compiler-dependent error while parsing a DISANG file in sander. For
>> ICC
>>>> 12.1, things work properly, while for GCC 4.6.2, sander crashes. Details
>>>> below.
>>>>
>>>> We've assembled a small test case. It is performing a minimization of
>> some
>>>> system with sander, using this input (min2.in):
>>>>
>>>> &cntrl
>>>>> imin = 1,
>>>>> maxcyc = 6000,
>>>>> ncyc = 3000,
>>>>> ntb = 1,
>>>>> ntr = 0,
>>>>> cut = 8,
>>>>> nmropt = 1,
>>>>> &end
>>>>> &wt
>>>>> type ='END',
>>>>> &end
>>>>> LISTOUT=POUT
>>>>> DISANG=../rest
>>>>>
>>>>
>>>>
>>>> The `rest` file is attached.
>>>>
>>>> I'm running the minimization using the following command:
>>>>
>>>> sander -O -i ../min2.in -o min2.out -p ../top.top -c ../min1.crd -r
>>>>> min2.rst
>>>>>
>>>>
>>>>
>>>>
>>>> Result on Amber 11 compiled with GCC 4.6.2 on CentOS 5.7
>>>> ==============================**==========================
>>>> Sander crashes "immediately".. presumably while parsing the `rest` file.
>>>> min2.out:
>>>>
>>>>> [...]
>>>>
>>>>> Here is the input file:
>>>>> [...]
>>>>> ------------------------------**------------------------------**
>>>>> --------------------
>>>>> 1. RESOURCE USE:
>>>>> ------------------------------**------------------------------**
>>>>> --------------------
>>>>>
>>>>> | Flags:
>>>>> getting new box info from bottom of inpcrd
>>>>> | INFO: Old style inpcrd file read
>>>>>
>>>>> | peek_ewald_inpcrd: Box info found
>>>>> |Largest sphere to fit in unit cell has radius = 21.977
>>>>> Error: Invalid atom or grouping specified in restraint.
>>>>> restraint = "torsion [:70.C1, :70.O5, :70.C5, :70.C4]"
>>>>>
>>>>
>>>>
>>>> Result on Amber 11 compiled with ICC 12.1 on Ubuntu 10.04
>>>> ==============================**===========================
>>>> The minimization works.
>>>>
>>>>
>>>> Final remarks
>>>> =============
>>>> I've compiled both of these Amber environments and also performed the
>>>> automatic tests in $AMBERHOME/test. As far as I remember, this problem
>> has
>>>> not been catched by an Amber test case.
>>>>
>>>> I have to add that although I cannot provide a repro, our group observed
>>>> this problem already with Amber 10 and other (older) compilers. There, I
>>>> have been told that the occurrence of the error depended on
>>>> - the operating system or
>>>> - the hardware
>>>> but definitely not on the executable, because it was always the same.
>>>>
>>>> However, with Amber 11, the sander binary created with ICC 12.1 seems to
>>>> work fine on each system I could test it on, while the sander binary
>>>> created with GCC 4.6.2 seems to fail on all of these systems.
>>>>
>>>>
>>>> I hope that this problem can be easily tracked down. If I can be of any
>>>> further help, please let me know what I can do.
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Jan-Philip
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> AMBER mailing list
>>>> AMBER.ambermd.org
>>>> http://lists.ambermd.org/mailman/listinfo/amber
>>>>
>>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> AMBER mailing list
>> AMBER.ambermd.org
>> http://lists.ambermd.org/mailman/listinfo/amber
>>
>
>
>
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Mon Jan 30 2012 - 08:30:03 PST
