Scott,
Just like what I thought I would invite unwanted responsibility.
I never said tleap/leap/xleap is fine.
If you do not realize, we need a tool to produce prmtop to run the rest of
AMBER. We can brag about how wonderful the rest of the package is, but
without the ability to put data into it, it is not much use, other than
wasting disk space.
I did say that we need to extend it, adding more functions (e.g.
SCEE/SCNB, Thole, CMAP, etc). Before, SCEE and SCNB, (and now Thole or
even the choice of polarizable/non-polarizable code), were done in
sander/pmemd as user switches. This gives users a lot of flexibility,
including the flexibility to run simulations with wrong combinations.
Plus, it is very confusing. As such, it was decided to move SCNB/SCEE to
prmtop. So should be Thole-related choices and IPOL. How do we do that?
Just wait for the wonderful new code?
As for CMAP, do we really want to hard code CMAP to sander/pmemd as a
bunch of options? That's what had to happen without the extension of leap.
I know this was done before (e.g., various flavors of GB).
My motivation of working on tleap was out of real desperation. I was under
the impression that leap has been thrown away. So, why did we start to
work on a dead piece of code that so many professional programmers have
despised? Because NOBODY wanted to help us to code CMAP. I did ask. Should
I just wait?
For those who want to develop a new model building code, please put what
you preach into practice. Do it before you trash another piece of working
code.
yong
>I suggest that those PI's that think tleap is fine should be the ones to
>maintain it and be tasked with extending it (this set includes at least
>Yong).
>
>
>scott
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Sun Nov 06 2011 - 14:30:03 PST
