Re: [AMBER-Developers] updating Fortran files to .F/.F90

From: Crowley, Michael <>
Date: Mon, 17 Oct 2011 16:27:39 -0600

Hi Guys,
Mike Garrahan works for Charlie Brooks and came up with a way to have the
tracebacks refer back to the original non-preprocessed code in charmm. It
is really really nice. All the references in the .o files refer back to
the original files. We donšt have to keep the intermediate files for
debugging anymore.
Are you interested?

Michael F. Crowley, Ph.D.
Principal Scientist, Biomolecular Sciences Division
National Renewable Energy Laboratory
1617 Cole Blvd.
Golden, CO 80401
303-384-6345 office
303-887=0149 cell
On 10/14/11 8:59 PM, "Scott Brozell" <> wrote:
>On Fri, Oct 14, 2011 at 05:56:09PM -0400, Tyler Luchko wrote:
>> On 2011-10-13, at 2:52 PM, Scott Brozell wrote:
>> > I think the Fortran standard is still vague on preprocessor details,
>> > but #ifdef, etc all work in practice.
>> There is a preprocessor as part of the f95 standard that is
>>incompatible with cpp and the different fpps
>Yes, the story on fortran preprocessing doesn't inspire
>confidence, but the vendors keep their feet on the ground:
>> > I did the COLUMBUS conversion using simple unix commands,
>> > and it was simple and error free.
>> > But your (1) has never bothered me, and I doubt that (2) has
>> > much gain (is it even measurable ?).  (3) might be true, but
>> > are we planning that change ?
>> As for the various motivations:
>One could classify this as incremental progress.
>I certainly have no objection and expect to hardly notice.
>Probably the best argument for it is that you are gung ho.
>> 1) Looking up the line numbers in intermediate files does bother me and
>>a few other people I have talked to.  I don't spend a lot of time doing
>>this but when I do it really takes all of the joy and wonder out of
>> 2) As for the extra _*.f files, measuring clutter is somewhat
>>subjective, but several hundred intermediate files are created in place
>>which makes operations, like grepping, a pain.  This is the biggest
>>issue for me. Disk space is only a couple tens of MB and the build time
>>difference is bare measurable but every millisecond counts, right :)
>> 3) I should probably divide this into two parts.
>>   a) Updating to a universal convention does mean that the code will
>>play nice with modern tools.  As Ben mentioned, this includes things
>>like syntax aware text editors properly identifying the files.  Also, it
>>is one less idiosyncrasy for new developers or users trying to edit the
>>   b) Switching to a new build method is an idea for the future and is
>>not a primary motivation for switch the Fortran file suffixes.  However,
>>I'll still briefly plug the idea by pointing out that switching to cmake
>>in particular will decrease build time measurably, simplify the build
>>scripts and should allow those who want to to use a variety of IDEs with
>>their associated performance/debugging tools.
>> Overall, the benefits are to better integrate with the tools we
>>currently use and simplifying the distribution by using a modern,
>>universal convention.  They are not huge gains but implementing the
>>change is not difficult.
>AMBER-Developers mailing list
AMBER-Developers mailing list
Received on Mon Oct 17 2011 - 15:30:04 PDT
Custom Search