Bob,
Thank you for your detailed explanation.
I think we once again talk about two completely different things. I
understand the NATEX format (and used it before). It has not been changed
since 80's when I first tried to play with it.
Let me re-iterate. In some occasions, Sander re-builds the excluded name
list and completely ignors the one in prmtop. Never mind ...... Thanks,
though.
yong
-----Original Message-----
From: owner-amber-developers.scripps.edu
[mailto:owner-amber-developers.scripps.edu] On Behalf Of Robert Duke
Sent: Friday, November 11, 2005 11:25 AM
To: amber-developers.scripps.edu
Subject: Re: amber-developers: Excluded list ?
Yong -
Not sure I understand, but I gather you are asking what the prmtop format
for the excluded atom list is.
It is documented, in a not crystal-clear manner in
amber.scripps.edu/formats.html; the relevant fields
you have to get right, per description are:
NEXT : number of excluded atoms
FORMAT(12I6) (NATEX(i), i=1,NEXT)
NATEX : the excluded atom list. To get the excluded list for atom
"i" you need to traverse the NUMEX list, adding up all
the previous NUMEX values, since NUMEX(i) holds the number
of excluded atoms for atom "i", not the index into the
NATEX list. Let IEXCL = SUM(NUMEX(j), j=1,i-1), then
excluded atoms are NATEX(IEXCL) to NATEX(IEXCL+NUMEX(i)).
FORMAT(12I6) (NUMEX(i), i=1,NATOM)
NUMEX : total number of excluded atoms for atom "i". See
NATEX below.
So, for each atom exclusion added you increment NEXT, and for the pair
added, if i is less than j, you add
atom j to atom i's excluded list. So the excluded atom list for atom i
always contains numbers greater than i.
The above description is actually the old format prmtop; the new format
prmtop proceeds the data segments
with the following flags, and uses the indicated formatting:
For natex they are:
%FLAG NUMBER_EXCLUDED_ATOMS
%FORMAT(10I8)
For numex they are:
%FLAG EXCLUDED_ATOMS_LIST
%FORMAT(10I8)
Sorry if I misunderstood the question.
Regards - Bob
----- Original Message -----
From: "Yong Duan" < <mailto:duan.ucdavis.edu> duan.ucdavis.edu>
To: < <mailto:amber-developers.scripps.edu> amber-developers.scripps.edu>
Sent: Friday, November 11, 2005 12:45 PM
Subject: RE: amber-developers: Excluded list ?
>
> Thanks, Bob, that's really insightful. Tell me how can I add a few more
atom
> pairs to the excluded atom list and hope it is taken by the code?
>
>
> yong
>
>
> -----Original Message-----
> From: <mailto:owner-amber-developers.scripps.edu>
owner-amber-developers.scripps.edu
> [mailto:owner-amber-developers.scripps.edu] On Behalf Of Robert Duke
> Sent: Friday, November 11, 2005 8:44 AM
> To: <mailto:amber-developers.scripps.edu> amber-developers.scripps.edu
> Subject: Re: amber-developers: Excluded list ?
>
>
> Okay, my 2 cents on this particular issue. I think it is actually
> preferable to have minimal representations of the critical system
> information in the prmtop. Why? It makes for smaller prmtops, less
> duplication of data, and in some senses an easier to understand prmtop.
I
> think Tom is right in that the excluded list in the prmtop has a
"processed
> in order" assumption, whereby it is assumed that the lower atom will
always
> have the higher atom in it's excluded pairlist but not vice versa (I may
> have it backward, but you get the basic idea - you end up without
> redundancies, but with a processing order assumption that should be
> documented). I also think that changes to the prmtop should not be done
> except when absolutely required. It creates total and utter chaos for
both
> us and the user community. Every time you change the prmtop or inpcrd,
you
> create a situation where old code won't work with stuff produced by
later
> versions of xleap. We should be versioning the prmtops/inpcrds (I think
now
>
> at least we do version the prmtop) and we should also be identifying the
> used forcefield in the prmtop. These two pieces of info can be used
> hopefully to keep all future s/w out of trouble in terms of version and
> forcefield mismatches. I think with the new prmtop format, we can add a
> flag without breaking old code? If so, that means that additive
processes
> are nondestructive, but subtractive processes are potentially very
> destructive (translation - you should think long and hard about removing
or
> changing anything that is already in the prmtop - you will break
everything
> in sight).
> Is there any status on the future of tleap/xleap? Seems to me what is
> really needed is a graphical topology generator that can generate
> prmtop/inpcrd based on a forcefield selection, and that the forcefield
> information input should be table driven. That way, you could "load up"
> parameters for forcefields and extend them without touching the icky
> graphical code, whether it is the current stuff that apparently nobody
> understands, python, java, or what have you. This implies that you have
to
> be very careful to exclude forcefield-specific info from the graphical
code
> itself, though. It must derive everything from the forcefield input.
Then
> ff developers just describe their ff in text. Obviously, you have to
think
> carefully about how to do this, and some code extension may be necessary
> (especially if you screw up in the original design ;-). Okay, not sure
that
>
> I limit myself to one rant per week, but this is all outside my
baliwick,
> and my immediate concern is that I don't want people blowing up my code
by
> trashing the existing prmtop/inpcrd formats without at least telling me
> about it in advance of the release :-).
> Best Regards - Bob
> ----- Original Message -----
> From: "darden" < <mailto:darden.gamera.niehs.nih.gov>
darden.gamera.niehs.nih.gov>
> To: < <mailto:amber-developers.scripps.edu>
amber-developers.scripps.edu>
> Sent: Friday, November 11, 2005 11:02 AM
> Subject: RE: amber-developers: Excluded list ?
>
>
>> yong
>> --one other thing
>> I think we doubled up the excluded atom list so that it atom i can
exclude
>
>> atoms j with j<i . this is because the grid based list builders destroy
>> the old logic where atoms are processed serially
>>
>> I should have put the re-build of excluded atom list into leap---BUT
leap
>> should have been written in fortran and be batch oriented instead of
>> interactive. we really don't need a fancy compsci solution to the basic
>> problem of building prmtop and inpcrd files. we need something that all
>> the developers can easily understand and work with
>>
>> there's my rant for the week td
>> On Fri, 11 Nov 2005, Yong Duan wrote:
>>
>>>
>>> Sorry, my message was not clear. I was rather surprised myself. Yes, I
>>> meant
>>> sander actually ignores the excluded atom list and re-builds it,
>>> apparently
>>> from bond, angle and dihedral lists. I think this is done when extra
>>> points
>>> are turned on. Looks like the LES code is gone when you turn on extra
>>> points
>>> (hopefully, nobody has tried this combination yet). I think the code
was
>>> changed since amber 7. I am pretty sure the exluded list was used in
>>> amber5/6. Yes, GB code deals with this "correctly".
>>>
>>> I can understand the need to change the excluded atom list with extra
>>> points. But I thought it should be done in things like Leap, perhaps
add
>>> an
>>> extra line in prep file to indicate which part is special and needs to
>>> be
>>> dealt with in Leap. Minor modification within sander targeted
>>> exclusively to
>>> extra points is understandable (and perhaps acceptable). Now, it
>>> actually
>>> affects the whole excluded list logic. This seems a bit unusual.
>>>
>>>
>>> yong
>>>
>>> -----Original Message-----
>>> From: <mailto:owner-amber-developers.scripps.edu>
owner-amber-developers.scripps.edu
>>> [mailto:owner-amber-developers.scripps.edu] On Behalf Of Carlos
>>> Simmerling
>>> Sent: Thursday, November 10, 2005 5:43 PM
>>> To: <mailto:amber-developers.scripps.edu>
amber-developers.scripps.edu
>>> Subject: Re: amber-developers: Excluded list ?
>>>
>>>
>>> are you saying that sander ignores the exlusion list in the prmtop?
>>> if so, I think that is not a good idea and should have been widely
>>> discussed before being done. It would break a few things that
>>> I have done. Where is that code?
>>> carlos
>>>
>>> Yong Duan wrote:
>>>
>>>> Just realized that sander actually re-constitutes the excluded list
>>> from
>>>> bond, angle, dihedral lists. Any insightful comments why it has to be
>>> done
>>>> this way? What will happen if I disable this (i.e., remove the code)?
I
>>> need
>>>> some flexibility in the excluded list but don't like to break too
many
>>>> things :(.
>>>>
>>>>
>>>> yong
>>>>
>>>>
>>>>
>>>
>>
>
>
>
Received on Wed Apr 05 2006 - 23:49:49 PDT
