As a follow up, it seems the problem lies with addles, rather than ptraj - addles changes round the lesfac entries in the prmtop when the first atom is included as part of the LES region, e.g.:
(Atoms 2-72 LES region)
%FLAG LES_FAC
%FORMAT(5E16.8)
0.10000000E+01 0.10000000E+01 0.10000000E+01 0.40000000E+01
(Atom 1 LES region)
%FLAG LES_FAC
%FORMAT(5E16.8)
0.40000000E+01 0.10000000E+01 0.10000000E+01 0.10000000E+01
(Also reported here:
http://structbio.vanderbilt.edu/archives/amber-archive/2007/4244.php )
This results in both the 'split' and 'average' functions in ptraj only recognising the first LES copy. The ptraj_les test cases pass (I assume) because looking at it there is only one lesfac entry in the test prmtop.
As a workaround, simply swapping the lesfac entries the opposite way round seems to fix the problem with ptraj. Sander.LES accepts the prmtops with either lesfac ordering, I'm not sure if this has any effects though?
Thanks!
Richard
On 11/10/2010 13:08, "Richard Bradshaw" <Richard.Bradshaw08.imperial.ac.uk> wrote:
Dear all,
I've been having some problems using the 'les split' functionality in ptraj. I've been running a number of LES simulations and using ptraj to split the copies both into separate trajectories and into a series of restarts.
I noticed that where my LES region includes the very first (N-terminal) residue in the complex, ptraj does not split the trajectory properly, and instead only spits out the co-ordinates of the first LES copy. If the first residue is excluded from the LES region, the 'split' works fine and co-ordinates of all copies are printed out separately.
I tried narrowing this down further and it seems that the problem lies with including the very first atom (i.e. Atom ID 1 in the PDB) in the LES region. Picking the sidechain only of the N-terminal residue results in the correct splitting of trajectories. Equally, picking the N-teminal residue of the ligand in the complex (i.e. with atom IDs > 1) also results in correct splitting.
When including the first atom, ptraj doesn't quit with any errors, it simply processes the trajectory as normal but only the co-ordinates of the first copy are printed. I've tried looking through the ptraj.c code (and others) to see why this might be the case but am by no means an expert and can't see anything obvious...
I'm running Amber 10/Ambertools 1.3 on Mac OSX 10.5.8, gcc compiled but have also tested this on our Linux-based HPC cluster (Amber 10/Ambertools 1.3, icc compiled) and seen exactly the same results. Ptraj passes all test cases on both systems.
Any advice?
Thanks for your help,
Richard
--
Richard Bradshaw
PhD Student, Institute of Chemical Biology
Room 537, Chemistry C1
Imperial College London
South Kensington Campus
SW7 2AZ
_______________________________________________
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 Oct 13 2010 - 07:00:03 PDT
