So I've found your problem (but I wasn't about to dig that deep through the
tleap code to find out why it was triggering a segfault, suffice it to say
it appears as though the same memory was trying to be allocated twice).
Your seh.library file had a number of issues with it. The worst one, I
think, is that a specific bond was defined 3 times in connectivity table:
!entry.SEH.unit.connectivity table int atom1x int atom2x int flags
1 8 1
1 2 1
2 9 1
2 5 1
2 3 1
3 7 1
3 4 1
3 4 1
3 4 1
5 10 1
5 11 1
5 6 1
6 12 1
7 13 1
(It is defining the bond between atoms 3 and 4 three times). Furthermore, a
couple indices were off as well (despite the fact that it's a 1-residue
unit, SEH was assigned as the 12th residue of that unit, meaning it had no
residue 1 - 11).
This leads me to question where you got this library file from and how you
generated it. There is a problem with whatever program you used to generate
your library file. I've attached the version that I modified (seh.mod.off),
which avoids the segfault. You can take a look at the differences between
your file and this file if you're curious, but here's the output I get now
(keeping in mind that you're missing an frcmod file that has the additional
parameters missing in the existing ff99SBildn force field).
Jason-Swailss-MacBook-Pro:Downloads swails$ tleap -f leaprc.ff99SBildn
-I: Adding /Users/swails/amber/dat/leap/prep to search path.
-I: Adding /Users/swails/amber/dat/leap/lib to search path.
-I: Adding /Users/swails/amber/dat/leap/parm to search path.
-I: Adding /Users/swails/amber/dat/leap/cmd to search path.
-f: Source leaprc.ff99SBildn.
Welcome to LEaP!
(no leaprc in search path)
Sourcing: /Users/swails/amber/dat/leap/cmd/leaprc.ff99SBildn
Log file: ./leap.log
Loading parameters: /Users/swails/amber/dat/leap/parm/parm99.dat
Reading title:
PARM99 for DNA,RNA,AA, organic molecules, TIP3P wat. Polariz.& LP
incl.02/04/99
Loading parameters: /Users/swails/amber/dat/leap/parm/frcmod.ff99SBildn
Reading force field modification type file (frcmod)
Reading title:
Modification/update of parm99.dat (Hornak & Simmerling) + ILDN corrections
Loading library: /Users/swails/amber/dat/leap/lib/all_nucleic94.lib
Loading library: /Users/swails/amber/dat/leap/lib/all_amino94ildn.lib
Loading library: /Users/swails/amber/dat/leap/lib/all_aminoct94ildn.lib
Loading library: /Users/swails/amber/dat/leap/lib/all_aminont94ildn.lib
Loading library: /Users/swails/amber/dat/leap/lib/ions94.lib
Loading library: /Users/swails/amber/dat/leap/lib/solvents.lib
> loadoff seh.mod.off
Loading library: ./seh.mod.off
> pep = loadPDB peptide.pdb
Loading PDB file: ./peptide.pdb
total atoms in file: 173
> saveamberparm pep prmtop inpcrd
Checking Unit.
WARNING: The unperturbed charge of the unit: 1.000000 is not zero.
-- ignoring the warning.
Building topology.
Building atom parameters.
Building bond parameters.
Building angle parameters.
Could not find angle parameter: OH - CT - HC
Could not find angle parameter: OH - CT - HC
Building proper torsion parameters.
Building improper torsion parameters.
total 33 improper torsions applied
Building H-Bond parameters.
Parameter file was not saved.
> quit
Quit
HTH,
Jason
On Tue, Aug 2, 2011 at 11:08 PM, Jason Swails <jason.swails.gmail.com>wrote:
> Hello,
>
> I can verify your segfault, and I'm looking into it. I also know where it
> happens (line 114 of model.c), but I haven't tracked down why this memory
> wasn't allocated yet.
>
> Another thing to try is to use sleap instead (but make sure that you load
> the proper frcmod file!). sleap doesn't segfault for me.
>
> I'll report back if/when I find the cause of the bug in tleap (unless
> someone with better knowledge of the code finds it first).
>
> HTH,
> Jason
>
> On Tue, Aug 2, 2011 at 4:42 PM, Massimiliano Porrini <M.Porrini.ed.ac.uk>wrote:
>
>> Dear Jason and David,
>>
>> Many thanks for the useful hints.
>>
>> Following your advises, I decided to install AmberTools 1.5 in my local
>> machine
>> and everything seemed to work fine.
>> All the tests passed, apart from those that required the installation
>> of Amber11 (sander),
>> as you can see:
>>
>> 481 file comparisons passed
>> 2 file comparisons failed
>> 0 tests experienced errors
>> Test log file saved as logs/test_at_serial/2011-08-02_20-21-38.log
>> Test diffs file saved as logs/test_at_serial/2011-08-02_20-21-38.diff
>>
>> But unfortunately I got again segmentation fault with loadPdb in
>> executing the same
>> procedure I posted yesterday, that is:
>>
>> :~>tleap
>> >source leaprc.ff99SBildn
>> >set default PBradii mbondi2
>> >loadOff seh.lib
>> >peptide = loadPdb peptide.pdb
>>
>> This time I enclosed also the pdb file of the peptide (and my library
>> seh.library as well).
>>
>> Any kind suggestion?
>>
>> Cheers,
>>
>>
>>
>> 2011/8/1 Jason Swails <jason.swails.gmail.com>:
>> > On Mon, Aug 1, 2011 at 4:03 PM, David A Case <case.biomaps.rutgers.edu
>> >wrote:
>> >
>> >> On Mon, Aug 01, 2011, Massimiliano Porrini wrote:
>> >> >
>> >> > Since it was not me to install both Amber and AmberTools in the
>> >> > cluster I am running on, is there any way to check which version I am
>> >> using?
>> >> >
>> >> > And in case I am using the not fixed version 1.4, how can I
>> >> > patch it?
>> >>
>> >> Either (a) go to http://ambermd.org, click on "bug fixes" and follow
>> the
>> >> instructions to patch version 1.4; or (b) download AmberTools1.5 from
>> the
>> >> same
>> >> web site. I would recommend the latter.
>> >>
>> >> [I don't think there is any easy way to determine which version someone
>> >> else
>> >> installed, although Jason probably knows....]
>> >
>> >
>> > It's not nearly as good as a --version flag, but the following can help
>> tell
>> > what version you have (as long as you haven't done anything like
>> renaming
>> > directories and adding/removing files and directories):
>> >
>> > If you have AmberTools 1.2, then it unpacks into an amber10/ directory
>> and
>> > builds alongside amber10.
>> > If you have AmberTools 1.3, then it unpacks into an amber11/ directory,
>> but
>> > I don't think it can build with Amber11. In any case, it's unlikely
>> anybody
>> > is using this version. (since it was only ~6 months between 1.3 and 1.4
>> > releases IIRC)
>> > If you have AmberTools 1.4, then it unpacks into an amber11/ directory,
>> and
>> > it *can* build with Amber11. Furthermore, it has no
>> > $AMBERHOME/AmberTools/src/cpptraj/ directory or
>> $AMBERHOME/AT15_Amber11.py
>> > script.
>> > If you have AmberTools 1.5, then it unpacks into an amber11/ directory
>> and
>> > it *can* build with Amber11 as long as you run AT15_Amber11.py, and it
>> > *does* have a cpptraj directory. This is also the first release to
>> build
>> > mdgx by default, IIRC.
>> >
>> > If you're just trying to distinguish between AT 1.4 and AT 1.5, look for
>> the
>> > cpptraj and mmpbsa_py directories in $AMBERHOME/AmberTools/src and the
>> > AT15_Amber11.py script (these are only in AmberTools 1.5). (The easiest
>> > file to trace, though, is probably the configure file, if you know what
>> to
>> > look for).
>> >
>> > The only packages you can download right *now* are AmberTools 1.5 and
>> > AmberTools 1.2 (to build amber10).
>> >
>> > Looking at git logs, it appears as though Mengjuei fixed tleap's huge
>> > segfaulting issue (caused by 64-bit builds) ~6/1/2010. So it appears
>> that
>> > anything older than AmberTools 1.4 will experience frequent segfaults
>> with
>> > tleap.
>> >
>> > Perhaps we should add the AmberTools version to *something*? Each
>> package's
>> > Makefiles? Require each package to recognize a --version flag? The
>> master
>> > Makefile?
>> >
>> > Of course if you have the original tarball it says there.
>> >
>> > I don't know how helpful this is. (To Massimiliano, I suggest that you
>> > build your own AmberTools 1.5, since that's the package that will get
>> the
>> > most support. If something doesn't work in older versions, the
>> maintainer
>> > will probably just ask you to upgrade to see if the problem goes away,
>> > anyway).
>> >
>> > HTH,
>> > Jason
>> >
>> >
>> >> ....dac
>> >>
>> >>
>> >> _______________________________________________
>> >> AMBER mailing list
>> >> AMBER.ambermd.org
>> >> http://lists.ambermd.org/mailman/listinfo/amber
>> >>
>> >
>> >
>> >
>> > --
>> > Jason M. Swails
>> > Quantum Theory Project,
>> > University of Florida
>> > Ph.D. Candidate
>> > 352-392-4032
>> > _______________________________________________
>> > AMBER mailing list
>> > AMBER.ambermd.org
>> > http://lists.ambermd.org/mailman/listinfo/amber
>> >
>>
>>
>>
>> --
>> Dr Massimiliano Porrini
>> Institute for Condensed Matter and Complex Systems
>> School of Physics & Astronomy
>> The University of Edinburgh
>> James Clerk Maxwell Building
>> The King's Buildings
>> Mayfield Road
>> Edinburgh EH9 3JZ
>>
>> Tel +44-(0)131-650-5229
>>
>> E-mails : M.Porrini.ed.ac.uk
>> mozz76.gmail.com
>> maxp.iesl.forth.gr
>>
>> _______________________________________________
>> AMBER mailing list
>> AMBER.ambermd.org
>> http://lists.ambermd.org/mailman/listinfo/amber
>>
>>
>
>
> --
> Jason M. Swails
> Quantum Theory Project,
> University of Florida
> Ph.D. Candidate
> 352-392-4032
>
--
Jason M. Swails
Quantum Theory Project,
University of Florida
Ph.D. Candidate
352-392-4032
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Tue Aug 02 2011 - 22:00:03 PDT
