I remember having to
chown -R someuser:staff $AMBERHOME/test
before I could successfully get the tests to run.
You might try something along those lines with the short name of the test user in lieu of "someuser", and see how that works out for you.
On Jan 21, 2011, at 11:46 AM, Gustaf Olsson wrote:
> Thank you Jason!
>
> I should have been a bit more detailed with my question.
>> Small comment here: use bin rather than exe, since the use of exe is being phased out.
>
>
> Usually I use /bin. I just tried /exe to see if it made a difference, forgot to change back.
>
>> No. AMBERHOME and PATH are different environment variables. Put the following in your .profile or .bashrc:
>>
>> export AMBERHOME=/usr/local/amber11
>> export PATH=$AMBERHOME/bin:$PATH
>>
>> and retry.
>
> This is what I have in my .profile and have also tried in .bashrc as well as global profile and bashrc
>
> export AMBERHOME=/usr/local/amber11
> export PATH=${AMBERHOME}/bin:$PATH
>
> Tried the suggestion without {}, but it did not make a difference!
>
> I just don't understand, I've tried exporting in all profiles on the mac and nothing solves this problem. I might also add that we've compiled AmberTools successfully in three iMac:s running Snow Leopard, and they all break during the "tests" with the same error.
>
> Anything else anyone suggests I should try before starting to dissect the code?
>
> Best regards
> // Gustaf
>
> On Jan 21, 2011, at 5:48 PM, Jason Swails wrote:
>
>> Hello,
>>
>> On Jan 21, 2011, at 10:33 AM, Gustaf Olsson <gustaf.olsson.lnu.se> wrote:
>>
>>> Hello everyone
>>>
>>> We are experiencing some frustrating problems when installing AmberTools 1.4 and Amber11 in Mac OS X 10.6.X (snow leopard), not when compiling but when applying bugfix:es and making tests.
>>>
>>> On mac, users can specify shell profiles by creating .profile, .bashrc and so on in the users local directory. There are also system wide profiles stored under the root directory. Now to the problem...
>>>
>>> Compilation works just fine by exporting amberhome to PATH in you local profile, it works just as well when setting amberhome in the global profile.
>>>
>>> echo $PATH returns:
>>> /usr/local/packmol:/usr/local/amber11/exe:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin
>>
>> Small comment here: use bin rather than exe, since the use of exe is being phased out.
>>
>>>
>>> in both cases. So the PATH variables seems to work just fine. You can run xleap, ptraj, sander and so forth....
>>>
>>> Here's the issue. When trying to apply the bugfix script for amber11 apply_bugfix.x it complains that $AMBERHOME needs to be defined to /usr/local/amber11. It already is, isn't it?
>>
>> No. AMBERHOME and PATH are different environment variables. Put the following in your .profile or .bashrc:
>>
>> export AMBERHOME=/usr/local/amber11
>> export PATH=$AMBERHOME/bin:$PATH
>>
>> and retry.
>>
>>>
>>> However, if AmberTools and Amber11 bugfix is applied through: patch -p0 -N < bugfix.all
>>> Everything runs smoothly with no complaints!
>>
>> Because paths uses relative file paths and doesn't explicitly use AMBERHOME
>>
>>>
>>> Now, after compilation we cd into test for both AmberTools 1.4 and Amber11, try to run "make test", and this is the response:
>>>
>>> (find . -name '*.dif' -o -name 'profile_mpi' | \
>>> while read dif ;\
>>> do \
>>> rm -f $dif ;\
>>> done ;\
>>> )
>>> rm -f TEST_FAILURES.diff
>>> Error: AMBERHOME should be defined or else some tests will fail !
>>> make: *** [is_amberhome_defined] Error 2
>>>
>>> It does not matter in which profile (global/local, profile/bashrc/cshrc) we export $AMBERHOME, the result is always the same. It does not change if we set $AMBERHOME directly to:
>>
>> Don't export $AMBERHOME, export AMBERHOME.
>>
>>>
>>> /usr/local/amber11
>>>
>>> echo $PATH returns:
>>> usr/local/packmol:/usr/local/amber11:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin
>>>
>>> Manual export/setenv does not change the response either.
>>>
>>> Has anyone experienced the same issue and has a workaround for this so that we can run the tests?
>>
>> This error should not crop up if the environment variables are properly set. You can disable the check, but I'd suggest against it.
>>
>> Good luck!
>> Jason
>>
>>>
>>> Best regards
>>> // Gustaf
>>>
>>>
>>> _______________________________________________
>>> AMBER mailing list
>>> AMBER.ambermd.org
>>> http://lists.ambermd.org/mailman/listinfo/amber
>>
>> --
>> Jason Swails
>> Quantum Theory Project,
>> University of Florida
>> Ph.D. Graduate Student
>> 352-392-4032
>> _______________________________________________
>> AMBER mailing list
>> AMBER.ambermd.org
>> http://lists.ambermd.org/mailman/listinfo/amber
>
>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Fri Jan 21 2011 - 10:30:05 PST
