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: 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: 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" <darden.gamera.niehs.nih.gov>
To: <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: 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: 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
