search

choderalab / ambermini

A stripped-down set of just antechamber, sqm, and tleap.
Other
31 stars 19 forks source link

Update for AmberTools 15? #14

Closed jchodera closed 9 years ago

jchodera commented 9 years ago

@swails and @davidlmobley, we need to update this for AmberTools15.

What's the best way to proceed here?

davidlmobley commented 9 years ago

I have no insights and am not really connected with the AMBER community. Seems like the simplest is to just do what you did before. But ideally we'd instead get the AMBER folks to make an ambermini they maintain, or something equivalent. @swails , any insight?

swails commented 9 years ago

The best thing to do is probably just extract the new files by hand and dump them into the distribution. The Amber community doesn't have the resources, time, or need to maintain a separate ambermini distribution, so nobody here will do it.

Fortunately this isn't really that time-consuming to do by hand, and it has to be done typically once a year (incorporating patches will be even easier, if there are any). I'll try to free up some time this week to get to this.

davidlmobley commented 9 years ago

Also, what about including more force field files? I keep needing to manually download and install the 99SBildn force field files, for example.

jchodera commented 9 years ago

We can certainly pull in all the forcefield files in the latest AmberTools.

Which additional forcefields are you thinking of?

swails commented 9 years ago

@davidlmobley -- all of the force field files are already included (and have been). ff99SBildn was moved to oldff; perhaps that's what's tripping you up? For example, you need to do:

tleap -f oldff/leaprc.ff99SBildn

instead of tleap -f leaprc.ff99SBildn.

davidlmobley commented 9 years ago

Ah. But oddly, if I download the 99sbildn stuff from ambermd.org and unzip it in $AMBERHOME, the organization apparently goes back to the old way (i.e. tleap -f leaprc.ff99SBildn works again). Must be not organized consistently.

On Tue, Jun 23, 2015 at 6:30 PM, Jason Swails notifications@github.com wrote:

@davidlmobley https://github.com/davidlmobley -- all of the force field files are already included (and have been). ff99SBildn was moved to oldff; perhaps that's what's tripping you up? For example, you need to do:

tleap -f oldff/leaprc.ff99SBildn

instead of tleap -f leaprc.ff99SBildn.

— Reply to this email directly or view it on GitHub https://github.com/choderalab/ambermini/issues/14#issuecomment-114693343 .

David Mobley dmobley@gmail.com 949-385-2436

swails commented 9 years ago

You must be unpacking leaprc.ff99SBildn into a location automatically searched for by tleap. The program doing the work is actually teLeap -- tleap is just a script that sets some default search paths based on the value of $AMBERHOME:

#!/bin/sh

AMBERHOME=`dirname $0`

if [ "$AMBERHOME" ]; then

   $AMBERHOME/teLeap \
              -I$AMBERHOME/../dat/leap/prep \
              -I$AMBERHOME/../dat/leap/lib \
              -I$AMBERHOME/../dat/leap/parm \
              -I$AMBERHOME/../dat/leap/cmd \
               $*

else

   echo "Error: you must set the AMBERHOME environment variable!"
   exit 1

fi

This is the version in ambermini that I modified to make independent of $AMBERHOME. You can see that the dat/leap/{prep,lib,parm,cmd} folders are all added to the default search path (which always contains pwd). The leaprc.ff99SBildn file happens to be in $AMBERHOME/../dat/leap/cmd/oldff, which is why specifying tleap -f oldff/leaprc.ff99SBildn works, but leaving off oldff doesn't. I don't think there's any inconsistency here...

davidlmobley commented 9 years ago

Ah, I see. I hadn't realized the change about "oldff" so what happened to me was that I was running the conda version with ambermini and went looking for leaprc.ff99SBildn; when I couldn't find it, I concluded it wasn't present so I went on the website and downloaded the provided tarball, then did "cd $AMBERHOME" (which in my conda installation I'd set to point to ~/anaconda; which I THINK is correct - it results in everything else working - but maybe it should have been something else) and extracted it. This results in a copy of leaprc.ff99SBildn ending up in ~/anaconda/cmd rather than ~/anaconda/cmd/oldff.

Thanks.

On Wed, Jun 24, 2015 at 5:32 AM, Jason Swails notifications@github.com wrote:

You must be unpacking leaprc.ff99SBildn into a location automatically searched for by tleap. The program doing the work is actually teLeap -- tleap is just a script that sets some default search paths based on the value of $AMBERHOME:

!/bin/sh

AMBERHOME=dirname $0 if [ "$AMBERHOME" ]; then

$AMBERHOME/teLeap \ -I$AMBERHOME/../dat/leap/prep \ -I$AMBERHOME/../dat/leap/lib \ -I$AMBERHOME/../dat/leap/parm \ -I$AMBERHOME/../dat/leap/cmd \ $* else

echo "Error: you must set the AMBERHOME environment variable!" exit 1 fi

This is the version in ambermini that I modified to make independent of $AMBERHOME. You can see that the dat/leap/{prep,lib,parm,cmd} folders are all added to the default search path (which always contains pwd). The leaprc.ff99SBildn file happens to be in $AMBERHOME/../dat/leap/cmd/oldff, which is why specifying tleap -f oldff/leaprc.ff99SBildn works, but leaving off oldff doesn't. I don't think there's any inconsistency here...

— Reply to this email directly or view it on GitHub https://github.com/choderalab/ambermini/issues/14#issuecomment-114850724 .

David Mobley dmobley@gmail.com 949-385-2436

swails commented 9 years ago

This is done, yes?

davidlmobley commented 9 years ago

Somewhat relatedly, I just had a good conversation with Dave Case and it sounds like he's fairly committed to making AmberTools stand-alone and (likely) available via GitHub, at least long-term.

jchodera commented 9 years ago

That would be great!

If we could get @swails involved in making this transition, we can also set up modern testing and conda deployment for all of AmberTools.

davidlmobley commented 9 years ago

Yes. We discussed that as well and he seemed enthusiastic. One selling point was how easy it was for me to get my class up and running with the tools (incl. ambermini) using conda, even on Windows (even for people with no background in scientific computing). He was asking how it even worked and I basically said "I don't even have to know!" It just works. He saw this might have a place in workshops, where it then might not be necessary to have to distribute a virtual machine to everyone (i.e. there can be benefits to people being able to run the software directly rather than in a VM).

On Wed, Jul 8, 2015 at 11:08 AM, John Chodera notifications@github.com wrote:

That would be great!

If we could get @swails https://github.com/swails involved in making this transition, we can also set up modern testing and conda deployment for all of AmberTools.

— Reply to this email directly or view it on GitHub https://github.com/choderalab/ambermini/issues/14#issuecomment-119666086 .

David Mobley dmobley@gmail.com 949-385-2436

jchodera commented 9 years ago

Also, reproducibility! I'm not sure if you saw how easy it is to reproduce the data in my recent manuscript: https://github.com/choderalab/automatic-equilibration-detection/blob/master/examples/liquid-argon-density/reproduce.sh

swails commented 9 years ago

I've had conversations with Dave about this before (and if this is the direction he wants to go, I will almost certainly be involved unless a new job takes me away from the community or the field). There are a lot of barriers to putting AmberTools on Github:

Honestly, I can't suggest Github as a hosting solution for AmberTools as-is. [1] Official Amber conda packages can still happen, and it's on my radar, but I just don't see Amber coming to Github. The only thing that would really make it worthwhile for the project is to get more people involved, and there's no guarantee that would even happen. [2] It's a very high cost for potentially little payback for Amber, and we just don't have the resources.

[1] The way I see this happening is to split each program out as a separate repo via git subtree and then set up a "complete" repository using submodules to keep the size of the repos manageable. There's still a huge shift in the development model that would have to come as a result and a big change in the way people currently do development.

[2] This only applies to people that would contribute if it's on Github, but either refuse to contribute through Amber's git server or don't know to ask. If you want to contribute, all you have to do is ask.