Re: [AMBER-Developers] Goals for AMBER code format/style?

From: Joe Krahn <>
Date: Thu, 26 Mar 2009 22:25:39 +0000

David A. Case wrote:
> On Thu, Mar 26, 2009, Joe Krahn wrote:
>> What do people think about replacing the _REAL_ cpp macro with a real
>> KIND parameter? It allows you to write typed literals without needing to
>> define a parameter.
> Can you give an example? I guess I don't understand what you mean by
> "use a typed literal without needing to define a parameter".
> I've always viewed KIND attributes with distaste -- do we want something
> other than double precision real variables? What is wrong with "1.0d0"
> if that is what is desired? It can be dangerous to assume that
> compilers will do the correct things with any non-standard KIND
> attribute.
The bad part of KIND values is that they are not standardized, even
though the common convention is to use the byte size.

The advantage is a typed literal that varies with some configuration
parameter. The reason for having _REAL_ is to allow single-precision
builds. Nothing is wrong with "1.0d0", but it will still be
double-precision with a single-precision config. If "RK_" is a kind
parameter, then you can write "1.0_rk_", and it's precision will match
the config precision. Otherwise, I need to use a parameter to create
constant of the right kind:

_REAL_, parameter :: ONE = 1.0d0

So, I agree that the KIND spec is a bit ugly, but it has some advantages
if you want a precision defined in a config file.

>> Is AMBER still working towards implicit-none in all source files?
> Slowly, slowly.
>> Is there any reason not to convert all of the common-block .h files into
>> module files? It would be trivial to do a quick conversion by wrapping
>> the existing header code, leaving the common blocks as they are, and
>> working on removing them later.
> Is there any reason *to* make such a conversion? I've thought that
> unless the code were improved, just wrapping common blocks in modules
> didn't really gain us much.
Yes. When including a common-block header, you get definitions for 100
variable names, when I may only want to access one or two. Modules make
it easy to define sensible variable names that don't have to be globally

>> At least for Gnu make, it is useful to use $(MAKE) instead of 'make',
>> partly because it allows a parallel-make, giving much faster build times
>> on multi-processor machines. For example, replace:
>> cd dir; make xyz
>> with:
>> $(MAKE) -C dir xyz
>> However, I don't know if $(MAKE) and the '-C' flag are standard for BSD
>> make as well.
> I thought Ross had already done this(?)
Oops... I think you are right.


AMBER-Developers mailing list
Received on Fri Mar 27 2009 - 01:17:57 PDT
Custom Search