Hi,
On Fri, 27 Mar 2009, Joe Krahn wrote:
> Scott Brozell wrote:
>>
>> 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.
Adhering to new standards, where even fortran 90 may be new,
may only produce code portable to platforms that support the new standards.
Thus the improvements come at the cost of a smaller pool of supported
platforms. Consider:
Crays - probably so rare now that we should not support them.
SGI's - once upon a time every lab had lots of SGI's with current
irix and compilers; as of a couple of years ago, many of those SGI's
had old irix and old compilers (that dont support standard C99);
workarounds for such old compilers exist in Amber and DOCK, but is it
now time to officially not support old SGI's, and thus to remove the
workarounds in pursuit of better code for platforms that do support C99 ?
Sun's - much like SGI.
IBM's - probably aix still hangs around enough to merit further support ?
So the idealistic view that standards and portability go hand in hand
does not always hold up to real world practice (especially when money
and other resources are not plentiful).
> 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.
Implicit none has been around long enough so that the idealistic view
is true: implicit none code is better period. The issue here is the
resources to cleanup the not implicit none code.
Scott
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Sun Mar 29 2009 - 01:10:40 PDT
