Dear Jason,
Many thanks for spending time to check my files.
The seh.lib was created by me with tleap (for several reason I couldn't use
xleap).
And from your comments I understood the mistakes I did in creating the library.
A)
The fragment peptide had number 12 in its pdb (because I extracted it
from the original whole pdb) and, instead of using this
command:
bond name.SEH.anum1 name.SEH.anum2 ,
I used the following:
bond name.12.anum1 name.12.anum2
thinking that it would not eventually matter for the lib file.
B)
While I was creating the bond between atoms number 3 and 4 a doubt
crossed my mind: I thought to re-create the bond but double, as they are
C and O (respectively) atoms of the carbonyl group and I assumed that
the last action with tleap would have overwritten the previous one, so that to have
a double bond between C and O (but instead the result was 1+2=3).
I am going to regenerate from scratch the seh.lib with AT 1.5 just installed in my machine though.
To this point I have three more questions:
1) Do I have to define the carbonyl bond as double or single?
2) Since my modified residue is a serine at the neutral C-terminus (i.e. with such an end -COOH),
do I have to define the "tail" anyway? And if yes, is this tail still the carbonyl C?
3) Why do you think I need a frcmod file? Probably I am missing something here, but once I
define the atom types of my modified residue as those included in ff99SBildn (and I believe I can
do that because I have only one more proton at the end that I can define as the 'HO' atom type,
like in the case of GLH or ASH), don't they already exist in the related parameters file?
As a matter of fact I had created also the coordinate and topology files of my peptide without
using the seh.lib, but just executing one by one all the needed commands in tleap and at the end
I ran "check" and all the FF parameters resulted defined.
Thank you so much for your help and clarifications.
All the best,
MP
On Aug 3, 2011, at 5:38 AM, Jason Swails wrote:
> 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
> <seh.mod.off>_______________________________________________
> 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 Wed Aug 03 2011 - 03:30:02 PDT
