AMBER Archive (2008)

Subject: Re: AMBER: Install problems

From: Mark Williamson (mjw_at_sdsc.edu)
Date: Tue Sep 09 2008 - 13:16:38 CDT


David A. Case wrote:
> On Mon, Sep 08, 2008, Mark Williamson wrote:
>> Reading the mailing list over the past few years, I think generally new
>> AMBER users fall down on:
>>
>> a) Not having other bits of software that AMBER needs to build installed.
>> b) Installation of 3rd party compilers (such as ifort) that support
>> the Fortran 95 (F95) standard since the "free" GNU compilers do not
>> support this yet...

>
> Just a note: current versions of the free GNU compilers (both gfortran and
> g95) work fine for Amber (at least in my hands). The code they generate is
> not quite as fast as that from ifort, but that only becomes important when
> doing long calculations.

Just digging through some old notes, older versions of gfortran had
issues with namelists and this was causing the noesy test on AMBER 9 to
fail:

...blah....
  Namelist reports error in reading noeexp
  -- Subscript out of range implies dimensioning problem
  -- (see nmr.h)

This was also seen and reported here:
http://amber.ch.ic.ac.uk/dev_archive/all/0044.html

The bug in gfortran that was causing this was fixed in PR24459:
http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00757.html and made its way
into the 4.1.2 gfortran release. Hence the take home message is that
gfortran >= 4.1.2 is needed for AMBER-9 and 10. On the 29/01/07, RedHat
updated the gcc-* with FC5 (Fedora Core 5) to a pre 4.1.2 form with this
bug fixed: gcc version 4.1.1 20070105 (Red Hat 4.1.1-51).

As a brief indication of relative performance between gfortran and
ifort, I also dug out some mini (read: to be taken with some salt)
benchmarks that I did at that point on my desktop (mjw P4 2.8GHz 512MB
FC5):

         gcc version 4.1.1 20070105 (Red Hat 4.1.1-51)
         ./configure -p4 gfortran
         964.47, 999.28 (two identical runs, time in seconds)

         Ifort l_fc_c_9.0.033
         ./configure -p4 ifort_ia32
         769.70, 770.44

Hence ifort is ~20% faster.

As for G95, I never did much testing with it.
>
> My general recommendation for "new AMBER users" (which is what Mark is
> suggesting as well) is to use gfortran, which is simple to install and
> configure. If you later find that Amber suits your needs, and want to run
> long simulations, then you can consider installing other compilers. At that
> point, you will (a) have more experience, which often makes tracking down
> problems easier; (b) have a reference working installation, so that you can
> more easily check the new compiles.
Yup, David has parsed this in a much more clearer way than I was
attempting to... :)

>> 9) There is an issue with the MOPAC wrapper script that will cause it to
>> fail with Ubuntu's default /bin/sh (dash). Fix it by telling it to use bash:
>
> ??? Do you know what the problem is with dash? This is about as simple
> a shell script as one could come across, so what is failing?
The testcase problem appears as this:

cd antechamber/tp && ./Run.tp
   ./Run.tp: Program error
make: *** [test.antechamber.hasG77] Error 1

Looking into the Run.tp and executing line by line, it is the following
that causes the problem:

amber10/test/antechamber/tp$ ../../../exe/antechamber -i tp.pdb -fi pdb
-o tp.mol2 -fo mol2 -c bcc

Total number of electrons: 58; net charge: 0

Running: /home/mjw/code/AMBER/amber10/bin/mopac.sh
ln: creating hard link `FOR005': File exists
/home/mjw/code/AMBER/amber10/bin/mopac.sh: 12: Syntax error: Bad fd number
Error: cannot run "/home/mjw/code/AMBER/amber10/bin/mopac.sh" of bcc()
in charge.c properly, exit

Running the mopac.sh on it's own also triggers the issue:

  /home/mjw/code/AMBER/amber10/bin/mopac.sh
ln: accessing `mopac.in': No such file or directory
/home/mjw/code/AMBER/amber10/bin/mopac.sh: 12: Syntax error: Bad fd number

Line 12 of mopac.sh is as follows:

/home/mjw/code/AMBER/amber10/bin/mopac >& FOR006

Now, Ubuntu uses /bin/dash (Debian Almquist shell) as it's /bin/sh. I
think this was because this is faster than bash and hence speeds up boot
times with respect to initialization scripts. There is more information
on the reasoning behind this policy at:

https://wiki.ubuntu.com/DashAsBinSh

Returning to line 12; I'm not sure if " >& " is a bash specific
extension or there is an issue with dash. All I know at this moment is
that changing the first line of the mopac.sh script to use bash resolves
this issue for me. I recall Ross mentioning that was a fix in CVS for it
already where it has been changed to ".../bin/mopac > mopac.out"

regards,

Mark
-----------------------------------------------------------------------
The AMBER Mail Reflector
To post, send mail to amber_at_scripps.edu
To unsubscribe, send "unsubscribe amber" (in the *body* of the email)
      to majordomo_at_scripps.edu