On Tue, Mar 31, 2009, Joe Krahn wrote:
> What is AMBER's position on the use of names longer than 31 chars? It
> violates the F95 standard, but maybe all supported compilers allow long
> names. F2003 increases the limit to 63 characters. Names longer than 31
> may sound a bit ridiculous, but it does make sense to use verbose names
> for globals. Mark just updated the charmm code using a 32-character
> name: CHARMM_ATOM_TYPE_NUMERICAL_LABEL.
I think this is easy enough for now: there are still compilers in common
use that enforce a 31-character limit, and amber should stick with that;
Mark should shorten his new variable name.
>
> Some code uses the function DFLOAT(). It is not part of Fortran95; was
> it ever standard Fortran? Code should use DBLE() instead. However,
> DFLOAT is very common. Maybe it is OK to be lenient with this sort of
> very common extension.
We should probably find the dfloat()'s and change them to dble().
>
> Complex declarations are a bit more of a problem. The Fortran Standards
> really want to push the KIND concept, and DOUBLE COMPLEX is no longer
> valid. Instead, you have to use COMPLEX(KIND=8). It still supports
> DOUBLE PRECISION. I suppose they didn't like double-complex because it
> is not as descriptive; it sounds a bit like "twice as complex".
I'm ok with using COMPLEX(KIND=8), since there is no other good
alternative. Similarly, for byte variables that Bob talked about (and
similar) we may end up with that, again because there is no very good
alternative. But for regular double-precision floats and regular
integers, where we already have code that works on many compilers, I'd
recommend not changing usage, since I don't (yet?) see a real advantage.
>
> Also, why is dprec.h in several places? Shouldn't there be a common
> AMBER include directory?
I see four:
poincare% cd amber11/src
poincare% ff dprec.h
Files matching dprec.h
./pbsa/dprec.h
./rism3d/dprec.h
./sander/dprec.h
./sqm/dprec.h
rism3d and sqm are not part of amber11 (not included in any tar files),
and people working in those directories (that would be me) get to do what
they want.
The extra dprec.h in pbsa is a genuine duplicate, and should be removed
in favor of the one in sander.
....dac
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Apr 01 2009 - 01:17:13 PDT
