Do sander & pmemd need more of the amber source tree than the executables to run? I don't think a link would work in any case, certainly not over the nfs mount -- not unless the link location is also visible. But, I could make a copy of the tree. Our folks frequently recompile amber for this or that reason, so it really isn't feasible to put the main tree somewhere else -- if I did, they'd just copy it back. But, to copy it temporarily for a test could work.
I know you'd have to rewrite a couple hundred tests to have them send output to a different location -- and then to have diff go look in the other location. I wouldn't want to have to rewrite all that.
I'll see what I can do. Thanks.
:-) Lachele
--
B. Lachele Foley, PhD '92,'02
Assistant Research Scientist
Complex Carbohydrate Research Center, UGA
706-542-0263
lfoley.ccrc.uga.edu
----- Original Message -----
From: David A. Case
[mailto:case.scripps.edu]
To: amber-developers.scripps.edu
Sent: Tue, 01 Apr
2008 01:54:01 -0400
Subject: Re: amber-developers: latest tarballs for
AmberTools and Amber10
> On Mon, Mar 31, 2008, Lachele Foley wrote:
>
> >
> > We put our common-area executables in a directory that is not writable by
> > the compute nodes. This is important to us since we're likely to have
> > homemade programs running about, and wish to minimize unintended
> overwrites.
> > So... while $AMBERHOME is visible to all the nodes, any test that requires
> a
> > node writing to $AMBERHOME/anything will fail for us, and the diff will be
> > against an empty file. Programs that merely send output to the scheduler
> > will work.
>
> Why not just make a link between your (local) AMBERHOME/exe and the
> common-area executables directory? Then you could write to $AMBERHOME, yet
> still run jobs from the common area.
>
> Just a thought...might not work. But the tests are run in the amber10/test
> tree, and it's not easy to imagine how this can very easily be made into a
> read-only location.
>
> ...dac
>
>
Received on Fri Apr 18 2008 - 21:15:53 PDT