I agree with Scott. sleap's failure does not mean that tleap is
perfect. tleap need to be
rewritten in a modern language (maybe C++) since it is very hard to extend.
We just need
to do it smarter.
(BTW, I could be wrong here about tleap being hard to extend. It looks
like Yong is having
no problem adding things to tleap, and someone from Ben's group also added
1-4 scaling
to tleap. If this is the case, I say we leave tleap as is.)
If we are going to rewrite tleap I would suggest to do a line by line
translation of it to
be sure the exact same algorithm being used and the exact same result to be
produced, and people have to start using it. and we go from there.
The kernel code (not including the X11 stuff) is consisted of 81 files,
in total 63385
lines of code, part of it are utility functions which are already included
in STL, such
as string and vector. If we can get 3 or 4 people working on it and each
process one
file a day, we can do it in a month.
I can surely contribute my time, but I do not want to be the only one
on this.
I think we need 3 or 4 people on this so that one left would not affect the
whole project.
Any thoughts?
Sincerely,
Wei Zhang
On Fri, Nov 4, 2011 at 7:47 PM, Scott Brozell <sbrozell.rci.rutgers.edu>wrote:
> Hi,
>
> On Thu, Nov 03, 2011 at 02:45:44PM -0700, Ross Walker wrote:
> > Look at the example we have here. We have a working code, tleap / xleap
> that
> > had some problems and needed some extra stuff adding etc. But instead of
> > people trying to fix stuff we get a whole new version written from
> scratch
> > which has its own problems. Why oh why are we making yet another
> imperfect
> > square wheel?
>
> Your analysis is not on the mark:
> First there was fixing of tleap; i know since i did some of it.
>
> Second, my opinion as a professional computer programmer was and is that
> tleap needed to be thrown away and rewritten. [ tleap was a great
> success, but much better software development tools have come along. ]
>
> Third, the sleap rewrite used a far too generic tool/approach IMHO;
> the main problem with tleap is that there is a lot of code to do
> things that are non-trivial in C but are simple in C++;
> the main problem with sleap is that there is a lot of code to do
> things in a far too generic way; a focused C++ rewrite based on
> the STL could produce a far better product than either tleap or sleap.
>
> Fourth -- on what to do now -- throw them both away; rewrite tleap in
> C++ using the STL by starting small and proceeding incrementally.
> We have the talent to do this. The apparently agreed upon failure
> of sleap was a failure of the Amber development community. sleap
> didn't get used soon enough; leadership, ie Dave, did say to use;
> so this time some initial features should be ones not in tleap to
> guarantee a user base. We may have a kernel of the aleap (Amber LEaP)
> in cpptraj, maybe we can start there. Once the ball is rolling we can
> rework parts from tleap/sleap. Go team go :)
>
> scott
>
>
> _______________________________________________
> 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 Fri Nov 04 2011 - 19:00:03 PDT
