(j3.2006) Select Rank

[Tom Clune]

On Feb 18, 2015, at 2:55 PM, Bill Long <longb at cray.com> wrote:

> 
> On Feb 18, 2015, at 10:10 AM, Keith Bierman <khbkhb at gmail.com> wrote:
> 
>> 
>> 
>> On Wed, Feb 18, 2015 at 12:57 AM, Malcolm Cohen <malcolm at nag-j.co.jp> wrote:
>> ?...  fpp is better, but
>> even so it's not official and not 100% portable.  And doesn't solve the tool
>> problem.
>> 
>> ?Well, the fpp source code is available, and reasonably portable.  If memory serves, it does put appropriate markings in the code that some tools (many debuggers) use to get the line numbering right.
>> 
>> One hazard is on systems which don't properly supported mixed case file names, bork.F90 becomes bork.f90, and can clobber bork.F90 on line 1 of processing (got caught with this recently running Linux in a VM on a clients Windows system, where the source was in a shared folder, rather than inside the VM itself). An obvious approach would be to change the fpp processor to use .ftn and .f90 or some such?.
>> 
>> ?But I take your point, it would be cleaner to have an all Fortran solution. I'm not sure I buy "INCLUDE" as being much more pure than #include, but the rest of the processing is where both the good and bad lies ;>?
> 
> In general (my opinion) a Fortran program that requires preprocessing, or uses included files (either spelling), or has a build process that is anything beyond a simple make file is most likely poorly designed.  

Bill - making friends today are we?  :-)

It is easy to say that something is poorly designed, but another matter entirely to propose something that is superior on all fronts.  (Has to be all fronts, or someone can just repeat the accusation.)   Many applications support rather diverse requirements and as such need numerous configuration options.   One can certainly minimize the complexity, but it cannot be avoided entirely.    

Now, the climate model I mentioned earlier in the thread is indefensible in its heavy use of preprocessing, and on a good day the core developers will readily agree.  Refactoring it out of the code is very difficult, and even with a huge effort I?m not sure I could marginally shrink the issue faster than other scientists would increase it.

But even in my cleanest newest codes, I have preprocessing conditionals due to mutually incompatible compiler workarounds.   And if a code can work both in serial and with MPI, I generally use a small number of #ifdef?s to deactivate some interfaces.  Similar issues arise with the use of other optional libraries (netCDF is the next most common.)  In theory this complexity can be pushed entirely into the Makefile by using hand-crafted stubs.  Of course that just pushes ifdef?s into the Makefile, so it is not a huge win except for purists.  (As a purist, I do have an agenda to do just that, but it currently is not a high priority.  Don?t fix what ain?t broke.)

I also use preprocessors in cases where Fortran will not allow a simple interface for end users.   E.g. although my testing framework (pFUnit) can be used without a preprocessor, I provide a python script which greatly simplifies several aspects of constructing a test suite.  Essentially it inserts a considerable amount of boiler plate code.   Introspection/reflection (as available in Java and python) would eliminate most of that need, but I?m not holding my breath for Fortran to include that.

Then there is the template container library I am developing.   Here the need for a preprocessor is intrinsic to the requirement given the current Fortran standard.

Cheers,

- Tom




> 
> Cheers,
> Bill
> 
> 
> 
> 
>> _______________________________________________
>> J3 mailing list
>> J3 at mailman.j3-fortran.org
>> http://mailman.j3-fortran.org/mailman/listinfo/j3
> 
> Bill Long                                                                       longb at cray.com
> Fortran Technical Suport  &                                  voice:  651-605-9024
> Bioinformatics Software Development                     fax:  651-605-9142
> Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101
> 
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3

Thomas Clune, Ph. D. 				<Thomas.L.Clune at nasa.gov>
Head ASTG,Code 606
NASA GSFC		
MS 610.8 B33-C128
Greenbelt, MD 20771
301-286-4635









-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20150218/5b51b370/attachment-0001.html