From jwagener@ionet.net Fri Mar 7 17:14:10 1997 Received: from mail.ionet.net (ultra2.ionet.net [206.41.128.42]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id RAA03570 for ; Fri, 7 Mar 1997 17:14:05 +0100 Received: from Zvyvogs (tulnas2-07.ionet.net [207.204.119.67]) by mail.ionet.net (8.8.4/8.7.3) with SMTP id KAA20859; Fri, 7 Mar 1997 10:11:05 -0600 (CST) X-Mailer: InterCon tcpCONNECT4 4.0 (Macintosh) MIME-Version: 1.0 Message-Id: <9703071021.AA54382@Zvyvogs> Date: Fri, 7 Mar 1997 10:21:54 -0600 From: "Jerrold L. Wagener" To: mitchellb@crd.GE.COM Cc: holmes@crd.GE.COM, sc22wg5@dkuug.dk Subject: Re: Fortran 2000 Content-Type: Text/Plain; charset=US-ASCII Content-Disposition: Inline Brian, thank you for your very thoughtful note. There probably is nothing more important to language standards groups than to have constructive, detailed input from real users, such as you provide below; I wish that we had received this input several months ago, before the F2000 requirements had been "finalized". By copy of this reply I will distribute your suggestions to both X3J3 and SC22/WG5. Perhaps you have this information already, but as for allocatable components, that work is finished and ready for incorporation in Fortran 2000; the relevant paper is WG5/N1230. Similarly, lower bounds for pointers is finished (X3J3/96-154), as is floating point exception handling (WG5/N1231). The work on procedure pointers is progressing well, and a motion for the exact syntax (X3J3/97-147) is currently on the table. The puzzling one (to me) is your comment on common compiler directives. This was discussed at last month's meeting, but not included in the final set of F2000 requirements. Unless I misunderstand your comment, I'm puzzled as to why you think we have that on our slate at the moment. Your really interesting, and valuable, comment is the one on a WITH construct. The bad news is that a WITH construct, as such, is not among the "final" requirements for F2000; the good news is that the functionality you request may be provided, depending on how the "object oriented" requirements come out; those are not adequately far along for me to know now for sure how they might address the need you identify, but your comments will be invaluable in helping the committee to sort it all out. In "object oriented" languages such as C++, procedures can be class (or in Fortran terms, type) components. This functionality will be provided in F2000, by allowing procedure pointers (or procedure variables) of some sort to be components in a derived type definition. Let us say you include such a (argument-less) subroutine, named WITH (though you probably would want to name it something else), in your type definition for block_element; the body of subroutine WITH would be exactly what you show below as your preferred way of writing the computation. You would execute this with the statement: call block(ib)%WITH Any unqualified component names in WITH implicitly refer to those of the block(ib) object. Now I can't guarantee that the "object oriented" stuff will ultimately come out this way, but if it does then I think that the functionality you request will be satisfied, albeit with slightly different syntax. So let me ask you: would you be happy with such a solution? If so, then your comments will be very helpful to the committee in thrashing out the details. Please let me know if there is more information that I can provide you at this time. And thanks again for your time and assistance in helping us construct a Fortran 2000 that best serves the Fortran user community. Jerry Wagener jwagener@ionet.net http://www.ionet.net/~jwagener ======================================== > Jerry Wagner > Chair X3J3 > jwagener@ionet.net > > March 6, 1997 > > Jerry, > > I am researcher at General Electric's Research and Development > Center in upstate New York. Along with my collegue, Graham Holmes, > we have been developing a 72K+ line Fortran 90 code in the field > of Computational Fluid Dynamics (CFD). This is GE's first experience > with Fortran 90 and our generally favorable impression is leading > others in the research group to use Fortran 90 features in > existing Fortran 77 codes. > > Recently, we recieved a summary of proposed features for the > Fortran 2000 standard. I wanted to write to you, to express our > support for five of the proposed changes and to *strongly* suggest a > sixth. > > In order to motivate my comments, let me briefly explain the main > data structure used in our CFD code. Our code solves the fluid > mechanics equations using a multi-block grid topology in conjuction > with the multi-grid method. As a result, the flow solution exists on > a series of grid blocks. The logical way to represent this idea in > terms of a data structure is something like: > > module block_define > > type block_element > integer :: mgl ! the multigrid level > real, allocatable :: X(:,:,:) ! the grid real, > allocatable :: Q(:,:,:) ! solution varaibles > ............... > end type block_element > > type(block_element) :: block(ngbmax) > > end module block_define > > Unfortunately, components of user define types can not be allocatable > so we are forced to use pointers. This leads to serious > performance issues since the compiler is forced to generate > more conservative code under the assumption the the pointers may > overlap (which they don't in our case.) Thus we heartily support > the notion that components of user defined data types be allowed to > be allocatable. > > My second comment on the proposed changes allows deals with the > above example and points to a simple feature that is not in the > proposed changes. Altougth the data type defined above captures > the mathematical idea clearly, it leads to long (and thus hard to > read) code. Using the data structure above, code looks like > > block(ib)%Q(i1,i2,i3,1) =(block(ib)%Q(i1,i2,i3,1)**2 & +block(ib)%Q(i1,i2,i3,2)**2 & +block(ib)%Q(i1,i2,i3,3)**2)**(0.5) & *block(ib)%Q(i1,i2,i3,4)/gamma & +block(ib)% p(i1,i2,i3) & /block(ib)%rho(i1,i2,i3) > > In other words, there is tremendous syntactical overhead from having > to write "block(ib)%" in front of every variable. The language > PASCAL offered a very elegent solution to this problem. PASCAL had > a "with" statement which would allow the the previous statement to > be written as: > > WITH (block(ib)) DO > Q(i1,i2,i3,1) = (Q(i1,i2,i3)**2+Q(i1,i2,i3,2)**2 & +Q(i1,i2,i3,3)**2)**(0.5)*Q(i1,i2,i3,4)/gamma & +p(i1,i2,i3)/rho(i1,i2,i3) > END WITH > > While the advantage of this may not seem clear when only a > single statement is considered, it is quite dramatic when a > whole subroutine is considered. Thus, we would like to see a form of > the PASCAL with statement in future version of Fortran. > > My third comment is in support of specifying lower bounds for > pointers. It turns out that the Q variable is dimensioned Q(0,n1:0: > n2,0:n3,5) and the first element of Q, i.e. Q(:,:,:,1) is the density. > It is convienent to define a local pointer to the density, i.e. > > real, pointer :: rho(:,:,:) > > rho => Q(:,:,:,1) > > The problem is that > > rho(1,1,1) = Q(0,0,0,1) > > which really makes the code confusing. Fortunatly, every compiler we > have used allows us to get away with > > rho => Q(1:,1:,1:,1) > > which lets > > rho(0,0,0) = Q(0,0,0,1) > > Thus we support having user specifed lower bounds on pointers. > > Although not as important, we also support the addition of floating > point exception handling and procedure pointers. We also support > the notion of having a common set of performance related > compiler directives. > > In summary, the changes to Fotran that we would find most > useful/essensial are: > > (1) Allocatable components in user defined data types (2) > Addition of a PASCAL style "with" statement (3) Specification > of pointer lower bounds (4) Floating point exception handling > (5) Procedure pointers > (6) Common compiler directives > > Thank you in advance for considering these suggestions, > > Brian. > > +------------------------------------------------------------------+ > | Dr. Brian E. Mitchell K1-ES203 phone (518) 387-7845 | > | GE Corporate R&D Dial Comm: 8*833-7845 | > | P.O. Box 8 fax: > | (518) 387-7104 | Schenectady, NY 12301 > | e-mail: mitchellb@crd.ge.com | > +------------------------------------------------------------------+ > >