On Thu, May 11, 2017, Jason Swails wrote:
> Low-hanging fruit:
>
My view: we should only add addtional submodules where there is someone
willing to take charge of it, and where there is a reasonable prospect that
a non-AmberTools user would make use of it. We should weigh adding
new submodules vs. incorporating some stuff into existing submodules. And
I don't want to undercut AmberTools.
Some top-of-my head comments:
> 1. cphstats (there's already a repository for this in github.com/amber-md)
> 2. mdgx/pymdgx
Should not be ported. pymdgx should probably be abandoned. mgdx is
really just an experimental playground for Dave Cerutti
> 3. FEW
> 4. mmpbsa_py
> 5. mm_pbsa
Should be incorporated into FEW (already made that way in the manual).
> 6. saxs
> 7. xtalutil
My medium-term goal is to incorporate saxs and xtalutil into cpptraj
> 8. pymsmt (already on GitHub, I think)
> 9. gbnsr6
> 10. etc (the tools inside there)
> 11. pysander
Seems to tightly integrated with sander itself(?)
> 12. paramfit
>
> Medium-hanging fruit:
>
> 1. pbsa
> 2. rism
pbsa and rism are both tightly integrated with sander and nab
> 3. quick
my favorite, but depends on what Gerald wants to do
> 4. amberlite
>
> Harder to do due to data files scattered and tight integration:
>
> 1. antechamber
> 2. tleap
> 3. sander
> 4. nab/sff
>
> > 3. Next step: cmake(!)
> >
>
> I would get this work merged in before you start splitting off more
> submodules. It's already probably going to be a little of a pain to manage
> migrating the cmake work that was done in the directories we just moved to
> submodules. Probably worth not putting the person doing that work (Jamie
> Smith?) out that much more.
Agreed. I'm going to check with Jamie/Andreas to see what they recommend.
....dac
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Fri May 12 2017 - 05:30:04 PDT
