"Honestly, I'm convinced that leap should try to do at all."
er... badly sentence... again to try:
I think it might be best if leap does not try to do it.
:-) Lachele
Dr. B. Lachele Foley
Complex Carbohydrate Research Center
The University of Georgia
Athens, GA USA
lfoley.uga.edu
http://glycam.ccrc.uga.edu
________________________________________
From: B. Lachele Foley [lfoley.uga.edu]
Sent: Wednesday, January 19, 2011 11:45 PM
To: AMBER Developers Mailing List
Subject: Re: [AMBER-Developers] Amber test concerns
Actually... the issue isn't sleap, particularly.
The problem is the leap input file. It's trying to do something that leap has never (that we've known of) been able to do in any reliable manner. Honestly, I'm convinced that leap should try to do at all. If the build is done carefully, sleap works (I just checked). The relevant bits of the manual instruct people to do the build the safer way.
For those who want more info:
The leap input file says to do this:
n = sequence { 6LB VLB VLB 3GB 0GB }
b = sequence { 3LB 0GB }
set n tail n.2.O6
n = sequence { n b }
The trouble is that there are two branch points "VLB" in that first linear sequence. Leap tries to guess the connection point based on the structure of the prep file. People usually guess the connection point based on the number parts of the atom names. In many cases, due to prep file build constraints, leap and the human have different ideas how to make connections. So, it is always best to be very explicit with leap when building with multiple branch points.
Here is a safer way to do it:
n = sequence { 6LB VLB }
set n tail n.2.O3
n = sequence { n VLB }
set n tail n.3.O3
n = sequence { n 3GB 0GB }
set n tail n.2.O6
n = sequence { n 3LB 0GB }
The file builds fine if you use the second sequence of commands.
The big issue is stopping users from doing it the shorter way. Maybe if sleap finds multiple open valences, it should just fail with an error message about not knowing how to connect things.
:-) Lachele
Dr. B. Lachele Foley
Complex Carbohydrate Research Center
The University of Georgia
Athens, GA USA
lfoley.uga.edu
http://glycam.ccrc.uga.edu
________________________________________
From: B. Lachele Foley [lfoley.uga.edu]
Sent: Wednesday, January 19, 2011 10:44 PM
To: amber-developers.ambermd.org
Subject: Re: [AMBER-Developers] Amber test concerns
The test failed. Thanks for pointing it out.
It's not so much a new hydrogen as one in the wrong place. There are two making third bonds to an oxygen. And that's just the beginning of the problems. I'll write Wei.
:-) Lachele
Dr. B. Lachele Foley
Complex Carbohydrate Research Center
The University of Georgia
Athens, GA USA
lfoley.uga.edu
http://glycam.ccrc.uga.edu
________________________________________
From: B. Lachele Foley
Sent: Wednesday, January 19, 2011 8:24 PM
To: AMBER Developers Mailing List
Subject: RE: [AMBER-Developers] Amber test concerns
There have been a number of major changes lately with sleap. The tests might not be keeping up. Our group is testing the changes now. So far, they're looking good. As soon as we lay off Wei for a day or two, he'll probably fix the tests. I'll be sure to give that test a thorough check, tho. Is this behavior different on x86_64 than elsewhere?
:-) Lachele
Dr. B. Lachele Foley
Complex Carbohydrate Research Center
The University of Georgia
Athens, GA USA
lfoley.uga.edu
http://glycam.ccrc.uga.edu
________________________________________
From: Jason Swails [jason.swails.gmail.com]
Sent: Wednesday, January 19, 2011 6:12 PM
To: AMBER Developers Mailing List
Subject: [AMBER-Developers] Amber test concerns
Hello,
I've tested both Amber and AmberTools from a recent git checkout and I've
summarized what I think the major issues are below:
Linux x86_64:
AmberTools (serial):
sleap/glycam && ./Run.test1 -- n.pdb is completely different now, and
there's another proton attached somewhere as well. Is this an intentional
change?
Amber (serial):
sander_pbsa_ipb2 && ./Run.110D.min -- some numbers are significantly
different, but it may be benign
rism3d/ala && ./Run.ala.hnc && ./Run.ala.pse1 -- exits in error with sander
printing the message [ ERROR> solvcut must > 0. ]
Amber (parallel, 2 threads):
All sander.RISM.MPI tests failed with the message [ Fatal error in
MPI_Comm_rank: Invalid communicator, error stack: ]
All EVB tests failed with the error messages:
rank 1 in job 616 Batman_45773 caused collective abort of all ranks
exit status of rank 1: killed by signal 11
rank 0 in job 616 Batman_45773 caused collective abort of all ranks
exit status of rank 0: killed by signal 9
(This has been happening for a long time with the EVB tests -- even with the
Amber 11 release)
I'll follow up with relevant (different) Mac OS X failures later.
All the best,
Jason
--
Jason M. Swails
Quantum Theory Project,
University of Florida
Ph.D. Graduate Student
352-392-4032
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Jan 19 2011 - 21:00:03 PST
