Scott Brozell wrote:
> Hi,
>
> The underlying issue with most of these code improvements is
> platform support. Despite the large platform exposure of the
> Amber developer community, there are always problems on some weird
> platform X discovered during testing, during the push for a release,
> or after release by users.
>
> The main tradeoff is thus large platform support versus easier
> maintenance and mostly not major code improvements.
> In my opinion the balance we have now is ok.
> However, spring cleaning season is upon us.
> No doubt there is deadwood, and it sometimes manifests itself with
> preprocessor names associated with old platforms.
I sort of disagree, but I don't have experience with the actual
platform-specific bugs found in AMBER. I am more interested in code
improvements that reduce bugs, especially for a collaborative project,
and adhere more strictly to standards, which improves portability.
With my own code, I always enforce "implicit none" and enable as many
warning and strictness flags that I can. By adhering strictly to
standards, it avoids sloppy constructs that are likely to be portability
problems, or are really just bugs.
I would like to use the following flags in ifort:
-stand f95 -warn all
For debug builds, I also use:
-check bounds -check uninit
The 'uninit' check helps with using uninitialized values that happen to
be zero most of the time, but may not always be, especially for multiple
SANDER invocations.
The bounds check is a lot more useful without so many '(*)' dimensions.
Joe
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Sun Mar 29 2009 - 01:10:24 PDT
