From jwagener@ionet.net Sat Mar 15 01:07:55 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 BAA16126 for ; Sat, 15 Mar 1997 01:07:51 +0100 Received: from Zvyvogs (tulnas2-47.ionet.net [207.204.119.107]) by mail.ionet.net (8.8.4/8.7.3) with SMTP id SAA27134; Fri, 14 Mar 1997 18:04:39 -0600 (CST) X-Mailer: InterCon tcpCONNECT4 4.0 (Macintosh) MIME-Version: 1.0 Message-Id: <9703141815.AA56299@Zvyvogs> Date: Fri, 14 Mar 1997 18:15:56 -0600 From: "Jerrold L. Wagener" To: mitchellb@crd.GE.COM Cc: sc22wg5@dkuug.dk Subject: Re: fortran 90 Content-Type: Text/Plain; charset=US-ASCII Content-Disposition: Inline Thanks for your reply, Brian; sorry it took me so long to get back to you, but I had a "schedule" problem there for a while. I enjoyed seeing more of your prototype code and understand your problem (and suggestion) perfectly (I think). I'll copy this reply to the full group, as I did the last one, so that everyone sees (more of) the nature of your problem. I quite agree now that the "solution" I mentioned in my earlier note would involve too many (pointers to) "member functions" and that therefore that approach would probably not be satisfactory. You could have been even harder on me by pointing out that the overhead associated with calling all those procedures could well impact performance, thereby trading one performance problem (pointers) for another (procedure calls). (In this connection, a proposal for "fixing" such procedure call overhead by specifying inlining was not accepted at last month's meeting where the Fortran 2000 requirements were finalized.) Given the demise of my suggestion, I don't have ideas at the moment for solving your problem that are better than your suggestion for a WITH construct. Not only would a WITH construct allow for much less complex code, it also would be more optimizable and provide better performance (than procedure calls). Since we "finalized" the Fortran 2000 requirements at last month's meeting, without WITH, that leaves us without any good ideas for aleviating your problem. Perhaps someone will spot a solution (currently planned for Fortran 2000) that I have missed. Thanks again for your input, and let's keep the dialog channels open. Jerry Wagener ==================================== > Hi Jerry, > > Thanks for repling to and for forwarding my comments to the rest of > the commitee. I wanted to follow up on the "WITH" statement suggestion. > > I must admit from the outset that my experience with C++ and OOP > is limited, however I have programmed some using CLASS's in C++ and I > am familar with the notion of associating subroutines as components > of user defined data structures. However as I understand your > inquiry about using OOP-like constructs to mimic a "WITH" statement, > I don't think it would suit our needs. > > Certainly the simple example I sent in my previous e-mail could > easily be put in that framework. The problem comes from the complexity > of the actual problem which requires the use of several modules to > cleanly describe the data. The most substantial modules are "block_ > define" which defines a variety of 3D and 4D arrays that describe the > grid, the grid metrics, the solution, and auxillary solver arrays at > every grid point and "bc_define" which contains a large number > of 1D arrays that describe various flow quantities at the > various boundaries of the computational domain. Each of these > modules (and the others) logically describe part of data. Each of > these module looks something like: > > module block_define > type block_element > real, pointer :: X(:,:,:) > ..... > end type block_element > > type (block_element) :: block(ngbmax) > > real, pointer :: X(:,:,:) ! "Local pointer" > > contains > > subroutine allocate_block(ib,n1,n2,n3) > integer, intent(in) :: ib,n1,n2,n3 allocate(block(ib)%X(n1, > n2,n3)) > end subroutine allocate_block > > subroutine set_current_block(ib) > integer, intent(in) :: ib > X => block(ib)%X > end subroutine set_current_block > > end module block_define > > (There are at least 50 different different arrays in block_define and > a similar number in bc_define. That large number drives us to place > the data in separate models. This is a substantial Fortran 90 code > with over 73,000 lines of code divided into over 80 files.) > > The routine "allocate_block" is our "contructor" routine and the > routine "set_current_block" is our solution to the lack of a > "WITH" statement. > For example, our solver routines have the generic form: > > subroutine euler_flux(ib) > integer, intent(in) :: ib > > call set_current_block(ib) > call set_current_bc (ib) > > actual work of the routine > > end subroutine euler_flux > > There are three problems with this approach. (1) Adding a variable > is complicated since it has to be added twice, once inside block_ > element and once outside as a "local pointer." (2) The use of > pointers leads to performance penalties. At the present time, this > second point is not an issue since we were already forced to use > pointers in the block_element anyway. In Fortran 2000, the local > pointer would become the performance bottleneck when the pointers in > block_element are replaced by "allocatable". (3) Forgetting the call > to set_current_block and then using the local pointer leads to > diasterous results. > > (Of course, in this case none of the pointers refer to overlapping data > so the use of a compiler directive that tells the optimizer to > ignore dependances is quite useful.) > > To summarize, the reason I don't think the OOP approach helps is > because the data seems best organized inside of different modules or > at least different user defined data types. The OOP type approach > would only work if all the data was in the same user defined data > type. Actually a second objection is also due to the complexity. > The number of routines in the code that need to access the data is > rather large (in few hundred range), thus the number of procedure > pointers that would need to be stored as part of the user defined > data type would be prohibitive and would definately hurt code > readability and maintanability. > > The WITH solution is I think an elegant way to deal with the > problem. It recognizes the need to use user defined types but offers > a syntaxtical simplification. It is part of PASCAL but for > whatever reason was not included in C. But that having been said, I > am open to any reasonable help in the standard for this situation and I > am not set on any one method. > > Thanks again for considering these issues, > Brian. > > +------------------------------------------------------------------+ > | 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 | > +------------------------------------------------------------------+ > >