Re: [AMBER-Developers] Compilation of AMBER Tools

From: Ross Walker <>
Date: Thu, 9 Jun 2011 18:51:38 -0700

> I guess the real question is: are we ready to say that Amber requires
> at least
> some of the F2003 features? (It is now 2011, at least according to the
> calendar program on my iPad....)

Indeed and I would totally agree here IF compilers produced in 2007 actually
supported F2003 but they don't. So I think unless we have a solid argument
for why F2003 is beneficial for a given problem we should avoid using it and
deliberately breaking older compilers.

> For gcc, version 4.1.2 (spring 2007) is more than four years old, and
> has some
> bugs that bite Amber unrelated to the F2003 change. Version 4.4 (from
> summer
> 2009) seems fine; don't know about the 4.2 or 4.3 releases.

Yes, using the latest stuff is all well and good until you try to convince
someone running a cluster or HPC machine to install it for you. RHEL5.5
ships with GCC 4.1.2 and this means that is what a lot of 'public' machines
will have installed. Getting 4.4 installed means bureaucracy and work which
we could all do with less of. Hence it would be nice if we didn't break
older compilers until we really had too.

Now, don't get me even started on the fact we have to try to build a chunk
of this on IBM Power 7 machines with XLF90. Ugh!!!

> For Intel, I'm not sure what the earliest version would be that would
> accept
> allocatables inside a struct. Does anyone have info here?

I think Intel has actually been pretty good. I found the issue originally
because I was using 10.0.019 and that allowed it but g95 did not so I think
Intel has supported, at least some of, F2003 since version 10.

> Also not sure about PGI, etc. I guess now we have to worry about
> Windows
> compilers as well (not for sander, but for pmemd, and having a common
> coding
> requirement is probably advisable).

Yes, I think we should try to get out of the mantra that the only compilers
that exist are the VERY latest GNU and Intel. This might be true on
someone's desktop but it certainly isn't when you move to centrally managed
machines, many that are run for 4 years+ and stay loaded with the version of
linux that was stable when they were built.

> A salutary effect of specifying minimum requirements would be to limit
> the
> number of compiler versions we are claiming to support. The downside
> is that
> there are probably still lots of 4.1.2 installations out there. But
> can't
> most such users type 'sudo apt-get install gcc44' (and maybe
> gcc_select)?
> Comments on what is best here are hereby solicted.

Yes except I think by trying to support more compiler versions we ultimately
make simpler code. Do we really need all the new features or can we get away
with a subset?

Wow... I sound like you and I swapped places in our ideals... LOL!!!

All the best

|\oss Walker

| Assistant Research Professor |
| San Diego Supercomputer Center |
| Adjunct Assistant Professor |
| Dept. of Chemistry and Biochemistry |
| University of California San Diego |
| NVIDIA Fellow |
| | |
| Tel: +1 858 822 0854 | EMail:- |

Note: Electronic Mail is not secure, has no guarantee of delivery, may not
be read every day, and should not be used for urgent or sensitive issues.

AMBER-Developers mailing list
Received on Thu Jun 09 2011 - 19:00:02 PDT
Custom Search