Well this is me, since I wrote all of that code. I'm really overloaded
already this week so I hope it isn't urgent....
On Dec 3, 2013 6:50 PM, "Daniel Roe" <daniel.r.roe.gmail.com> wrote:
> Hi All,
>
> I've been adding LES trajectory splitting/averaging to cpptraj and have hit
> a snag. Everything works fine if I'm using a "simple" LES topology
> (something like copies of only one region). However, if I try to make a
> more complex LES topology (varying #s of copies of several regions) I get a
> topology that's not set up the way I had expected (details below). This is
> probably just a case of me not understanding how an LES topology is set up,
> so before I get into the details of my problem I was wondering are LES
> topologies are described in-depth anywhere? I searched through the website
> and GIT tree docs but was unable to find anything.
>
> This is what I currently understand the LES-related flags in the topology
> to mean:
>
> LES_NTYP: Total number of LES types.
> LES_TYPE: LES type for each atom
> LES_FAC: LES scaling factor for interaction of typeA x typeB (essentially
> an NTYP*NTYP matrix)
> LES_CNUM: LES copy # for each atom
> LES_ID: LES region ID, corresponding to the original 'spac' entries in
> addles input
>
> The stuff that's important for LES trajectory splitting is LES_CNUM; an
> atom has CNUM of 0 if its in every copy, otherwise the CNUM is what copy
> that atom belongs to. So what makes sense is that the number of 0 entries
> plus the number of any individual copy should equal the total number of
> atoms in the original (non-LES) topology. This seems to be the case for an
> LES topology with input like this:
>
> ~ 3 copies of the fragment consisting of residues 191 to 215
> spac numc=3 pick #mon 191 215 done
>
> But not for an LES topology with input like this:
>
> ~ 3 copies of the fragment consisting of residues 191 to 215
> spac numc=3 pick #mon 191 215 done
> ~ 4 copies of the fragment consisting of residues 234 to 243
> spac numc=4 pick #mon 234 243 done
> ~ 2 copies of the fragment consisting of residues 42 to 55
> spac numc=2 pick #mon 42 55 done
> ~ 3 copies of the fragment consisting of residues 55 to 60
> spac numc=3 pick #mon 55 60 done
>
> The latter input has CNUM entries that go up to 6; however the total for
> each copy does not add up to the # of atoms in the original topology (in
> this case 4049). This is how CNUM breaks down:
>
> CNUM: #_of_atoms_with_that_cnum Total
> 0: 3232
> 1: 817 4049
> 2: 817 4049
> 3: 594 3826
> 4: 140 3372
> 5: 14 3246
> 6: 14 3246
>
> The first two appear fine, but after that its strange. Note that the
> ordering of the 'spac' entries doesn't appear to affect CNUM, but does
> appear to affect the last number in POINTERS (NCOPIES I think?), which BTW
> never equals 6.
>
> Any ideas?
>
> -Dan
>
>
> --
> -------------------------
> Daniel R. Roe, PhD
> Department of Medicinal Chemistry
> University of Utah
> 30 South 2000 East, Room 201
> Salt Lake City, UT 84112-5820
> http://home.chpc.utah.edu/~cheatham/
> (801) 587-9652
> (801) 585-6208 (Fax)
> _______________________________________________
> 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 Tue Dec 03 2013 - 16:30:07 PST
