Wei,
I agree with almost all of what you said, except, we are adding new
functions to tleap. So, it will be extended and, as of now, it is the only
one that supports our polarizable force field work.
The core part of tleap is easy to handle even for a novice like me.
It is very attractive to have a decent programming model and framework. It
is even more attractive and essential to have a working program that can
accommodate and allow new changes. So far tleap is the one that comes with
a reasonable documentation, provides reasonable explanation to the users.
yong
On 11/3/11 11:28 AM, "Wei Zhang" <zgjzweig.gmail.com> wrote:
>Hi Ben,
>
> I'll try my best to answer your questions, and Dave can add more
>
>On Thu, Nov 3, 2011 at 10:02 AM, Ben Roberts <ben.roberts.geek.nz> wrote:
>
>> I have a barrage of questions, some thoughts, and a recommendation.
>>
>> 1. Is tleap under active development? If so, who is developing it and
>> knows the code? If not, why not (not that it necessarily should be)?
>>
>
>The answer is No. tleap is not under active development any more. The
>reason is the main developer (I think is Christian ) has left AMBER
>community and is never going back. The problem is tleap was written in a
>very strange way. e.g, it was written in C but in an object-oriented
>manner, which is very awkward because C is not naturally an OO language
>(C++ has not been invented back then). Because of that, the code
>is very hard to understand, or modify or extend. That's why there are some
>functionalities which should be incorporated into tleap was
>distributed as standalone programs such as addles, chamber, etc.
>
>
>> 2. Is sleap under active development? If not, why not (not that it
>> necessarily should be)? Does anyone besides Wei know and work with the
>>code?
>>
>
>No, sleap is not under active development. The reason as I mentioned
>before
>is: The need is not clear. The more time I spent on it, the more I got
>frustrated.
>
>
>>
>> 3. Does it make sense to maintain at least one LEaP? I say yes.
>>
>
>Totally agree with you.
>
>
>>
>> 4. Does it make sense to maintain two or more independent LEaPs? I say
>>no.
>>
>
>Totally agree with you too.
>
>
>>
>> 5. If (per #3 and #4) it makes sense to maintain precisely one LEaP,
>>where
>> should we focus our efforts tleap, sleap, or neither? I say tleap, it
>> being the de facto user standard and all.
>>
>
>Again, totally agree.
>
>
>>
>> 6. Do we want to get away from xleap and towards some more modern GUI? I
>> say yes. Do we want to write our own? I say no; I think Wei's idea of
>> linking with Chimera was a good one, provided however that I don't know
>>the
>> Chimera licence and I think we should probably link to a GUI that is
>>free
>> in the sense of both speech and beer.
>>
>
>Chimera is open source and free for academic use. On the other hand,
>incorporating tleap into VMD should not be very difficult either. Both
>Chimera and VMD were written in python.
>
>
>
>> 7. If we start maintaining tleap again, should just one person be
>> responsible for it? I say no, for fear that when that person leaves or
>> can't keep up his maintenance role, we revert to the status quo in which
>> problems aren't addressed. That will be even more true if we prepare a
>>new
>> LEaP to supersede both tleap and sleap.
>>
>>
>> Thus, the recommendation:
>>
>> A number (say, three or four) of the current developers make an effort
>>to
>> learn the tleap code, fix current bugs, bring it up to speed, port over
>> good features from sleap where their implementation is broken or
>> nonexistent in tleap, and link tleap against a suitable GUI front end.
>>They
>> announce themselves, so the rest of the developers know who they are.
>>They
>> work with each other, with Wei, and with other people who know sleap or
>> tleap well (hands up please!) throughout this process. The result is
>>either
>> a "fixed" tleap, or, if a complete revamp turns out to be warranted, a
>>new
>> LEaP program (e.g., uleap, for "unified LEaP" the fact that U follows
>>S
>> and T had absolutely nothing to do with it =P). I'm willing to put my
>>hand
>> up for this, bearing in mind that I could only work on it during my
>>spare
>> time. But I don't want to do it on my own, for fear of becoming the next
>> Wei and because I know I can't contribute much time. Besides, I have
>>next
>> to no experience with GUIs, unless one counts Java front-ends, so I
>>would
>> welcome input from those who know more than me.
>>
>
> I agree with you. I still believe that it is very important that we
>have
>full control of the interface we use every day. It's just we have to do it
>in a right way. First thing is to define our goals, what do we want
>from a new leap? The following are my thoughts:
>
> 1. written in a modern language which naturally support OO, (C++, Java
>or even Python)?
>
> 2. easy to understand and add new functionalities.
>
> 3. fix existing bugs.
>
> 4. hook to an advanced GUI.
>
> but 1 an 2 are already contradicting since for many people that means one
>more language to learn.
>
> Sincerely,
>
> Wei Zhang
>
>
>
>>
>> Alternatively:
>>
>> We carry on with the status quo, accepting that sleap and tleap are what
>> they are, while fixing the occasional, easily accessible bug.
>>
>> Thoughts?
>>
>> Cheers,
>> Ben
>>
>> On 2/11/2011, at 11:30 p.m., Wei Zhang wrote:
>>
>> > Hi All,
>> >
>> > When I started to write sleap in 2005, the original goal was to use
>> it to
>> > replace tleap, but after 6 years I have to admit that I have failed
>>the
>> goal,
>> > miserably.
>> >
>> > Yes, sleap is a failed product. I hate to admit it but it is true.
>>It
>> is unstable,
>> > and does not work as expected. The most important thing is sleap does
>>not
>> > generate identical topology as tleap does, thus it is hard for user to
>> tell if
>> > the resulted topology file is correct or not which make it useless.
>> >
>> > Here I try to summarize the reasons why I have failed, maybe people
>> can
>> > benefit from my failures:
>> >
>> > The No 1. reason is: The need was unclear, i.e. why do we need a
>> replacement
>> > for tleap? tleap is a very well written piece of software, it has
>>been
>> working for
>> > decades. It surely has some bugs, but the correct solution should be
>>to
>> fix those
>> > bugs, not to write a new one.
>> >
>> > The No 2. reason is: I totally underestimated the difficulty of the
>> project. That's
>> > why even though I was not asked to do it, I did it anyway. When I
>>started
>> > writing sleap, I thought it would take me at most 2 months. It turns
>>out
>> to be much
>> > more complicated than I thought. Now I recall that Dave tried to warn
>>me
>> about
>> > the difficulty, but I was so reckless at that time that I disregarded
>> his warning.
>> >
>> > The No 3. reason is: I did not know tleap well enough. This is
>> related to
>> > reason No. 2. Because I though it was an easy job, I did not spend
>> enough time to
>> > study the tleap code and tried to understand every line of it. I just
>> started on
>> > my own.
>> >
>> > These are the lessons I learned from development of sleap. At this
>> point
>> > I am not sure what to do with it, and I would really appreciate your
>> advices.
>> > I guess the most important question is: Do we really need a
>>replacement
>> for
>> > tleap? or we just need to fix bugs of tleap?
>> >
>> >
>> >
>> > Thank you very much!
>> >
>> > Sincerely,
>> >
>> > Wei Zhang
>> >
>> >
>> > On Nov 2, 2011, at 8:32 PM, case wrote:
>> >
>> >> On Wed, Nov 02, 2011, Daniel Roe wrote:
>> >>>
>> >>> I think the only major thing sleap does that tleap doesn't do is set
>> >>> up parms for AMOEBA right?
>> >>
>> >> Please cc comments about sleap to Wei Zhang <zgjzweig.gmail.com>,
>> since he may
>> >> not always follow the mail reflector.
>> >>
>> >> Just a brief addition to Jason's post (and Wei can add more if he
>> wants):
>> >> There *was* an original intent to create a graphical interface for
>>sleap
>> >> (hence the directory name gleap, short for gtk-leap). But Wei later
>> >> decided to use Chimera as the graphical interface, and there are now
>> >> dropdown menus in Chimera that allow one to build prmtop files and
>>to do
>> >> most of the things that tleap does (and more).
>> >>
>> >> But it is the case that (a) only a few people use the Chimera
>>interface;
>> >> (b) Wei is basically the only person (maybe along with Eric
>>Pettersen)
>> who
>> >> feels comfortable in maintaining the code, so it has languished.
>>[This
>> can
>> >> be a cautionary tale to those of you (Dan, Dave C., etc.) who have
>> "your"
>> >> code: it may never really take off until/unless you make sure that
>> others
>> >> can understand it, can modify it, and actually use and "buy into"
>>it.]
>> >>
>> >> Wei will be at the meeting in January, so we can discuss this then,
>>but
>> email
>> >> information exchange prior to that is also encouraged.
>> >>
>> >> ...dac
>>
>>
>_______________________________________________
>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 Thu Nov 03 2011 - 13:00:04 PDT
