- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello eveybody !
Recently I began to work on the modernization of a meteriological code. However I am not a fortran expert and I came across some problems related to equivalences. In these attached programs, there is an include "COMM_SEASO3.f90" that is nothing more than a common block. However when I pass this common block to module, the use of equivalence makes it impossible since it mentions a redemption of the data. I am trying to make such a change with the use of INTRINSIC TRANSFER. But it just worked with the first equivalence block, however for the equivalence O3O3(1,1,1) I'm getting wrong result.
Someone can help me how to solve it ?
Thank you very much for your attention
All the Best !
Luis Thiago Lucci - ltlcpaolicchi@gmail.com
SUBROUTINE O3CLIM
PARAMETER (NL=81, NLP1=NL+1, NLGTH=37*NL, NKK=41, NK=81, NKP=NK+1) ! INCLUDE "COMM_SEASO3.f90" ! #include "sp.h" ! COMMON /O3DATA/ & & PH1(45) , PH2(37) , P1(48) , P2(33) , & & O3HI1(10,16), O3HI2(10,9), O3LO1(10,16), O3LO2(10,16), O3LO3(10,16), O3LO4(10,16) ! REAL, DIMENSION(10,16) :: O3HI1
REAL, DIMENSION(10, 9) :: O3HI2
DIMENSION PSTD(NL), TEMPN(19), & & O3O3(37,NL,4), & & O35DEG(37,NL), & & XRAD1(NLGTH) , XRAD2(NLGTH), XRAD3(NLGTH), XRAD4(NLGTH), & & DDUO3N(19,NL), & & DUO3N(19,41), RO3(10,41) , RO3M(10,40) , RO31(10,41) , RO32(10,41), & & O3HI(10,25), & & RSTD(81) , RBAR(NL) , RDATA(81) , PHALF(NL) , P(81) , PH(82) ! EQUIVALENCE (O3HI1(1,1), O3HI(1,1)), (O3HI2(1,1), O3HI(1,17)), & & (PH1(1), PH(1)),(PH2(1), PH(46)), & & (P1(1) , P(1) ),( P2(1), P(49)) ! EQUIVALENCE (XRAD1(1), XDUO3N(1,1) , O3O3(1,1,1)), (XRAD2(1), XDO3N2(1,1)), & & (XRAD3(1), XDO3N3(1,1)), (XRAD4(1), XDO3N4(1,1)) . . . . END SUBROUTINE O3CLIM COMMON_SEASO3.f90 !-------------------------------------------------------------------------------------------------- COMMON /SEASO3/ & & XDUO3N(37,NL), XDO3N2(37,NL), XDO3N3(37,NL), XDO3N4(37,NL), & & PRGFDL(NL)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
!DO JJ=1,37 ! DO KEN=1,NL ! O3O3(JJ,KEN,IPLACE) = O35DEG(JJ,KEN) ! END DO !END DO if ( iplace == 1 ) then XDUO3N = O35DEG elseif( iplace == 2 ) then XDO3N2 = O35DEG elseif( iplace == 3 ) then XDO3N3 = O35DEG elseif( iplace == 4 ) then XDO3N4 = O35DEG endif ! 100 END DO !----------------------- ! END OF LOOP OVER CASES !----------------------- ! !-------------------------------------------------------------------------------------------------- ! AVERAGE CLIMATOLOGICAL VALUS OF O3 FROM 5 DEG LAT MEANS, SO THAT TIME AND SPACE INTERPOLATION ! WILL WORK (SEE SUBR OZON2D) !-------------------------------------------------------------------------------------------------- do i = 1 , 37 do j = 1 , NL AVG = 0.25 * ( XDUO3N(i,j) + XDO3N2(i,j) + XDO3N3(i,j) + XDO3N4(i,j) ) A1 = 0.5 * ( XDO3N2(i,j) - XDO3N4(i,j) ) B1 = 0.5 * ( XDUO3N (i,j) - XDO3N3(i,j) ) B2 = 0.25 * ( (XDUO3N (i,j) + XDO3N3(i,j) ) - ( XDO3N2(i,j) + XDO3N4(i,j) ) ) XDUO3N (i,j) = AVG XDUO3N2(i,j) = A1 XDUO3N3(i,j) = B1 XDUO3N4(i,j) = B2 enddo enddo ! DO I=1,NLGTH ! AVG = 0.25 * ( XRAD1(I) + XRAD2(I) + XRAD3(I) + XRAD4(I)) ! A1 = 0.5 * ( XRAD2(I) - XRAD4(I)) ! B1 = 0.5 * ( XRAD1(I) - XRAD3(I)) ! B2 = 0.25 * ((XRAD1(I) + XRAD3(I)) - (XRAD2(I) + XRAD4(I))) ! ! XRAD1(I) = AVG ! XRAD2(I) = A1 ! XRAD3(I) = B1 ! XRAD4(I) = B2 ! END DO
So something like the above means than xrad1,2,3,4 and 0303 declarations and equivalences cease to exits...
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The only syntax errors that you have to fix is to remove the duplicated dimensioning of arrays O3HI1 and O3HI2, once in the COMMON declaration and again as REAL, DIMENSION ... For instance, you can simple remove the line numbered 11 in the first piece of code and the next piece, which has a single line.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Equivalence is an obsolete language feature and if not used with extreme care is a good source of very confusing bugs. If modernising/updating the code and objective should be to remove it. There is not a simple route to doing this as you need to examine what the program is actually doing. For example if the local arrays are simply using the common as a work space you can just simply allocate the local arrays in the subroutine and they will automatically deallocate when you leave the subroutine.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
andrew_4619 wrote:
Equivalence is an obsolete language feature and if not used with extreme care is a good source of very confusing bugs. If modernising/updating the code and objective should be to remove it. There is not a simple route to doing this as you need to examine what the program is actually doing. For example if the local arrays are simply using the common as a work space you can just simply allocate the local arrays in the subroutine and they will automatically deallocate when you leave the subroutine.
I strongly disagree with this statement. Like UNION (in C++), EQUIVALENCE force the compiler to place variables where the programmer wants.
A good and advanced sw architect needs this capability.
Regards
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
fwiw I agree that EQUIVALENCE has its place, and can be a very simple of accomplishing certain objectives that might be awkward and unintuitive. I am sorry to see it go. Or at least to see it downplayed in the manner illustrated above.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
However I continue with doubts:
If I remove the common block / SEASO3 / and put it as a module. I will have:
MODULE SEASO3
REAL, DIMENSION (37,NL) :: XDUO3N, XDO3N2, XDO3N3, XDO3N4
REAL, DIMENSION(NL) :: PRGFDL
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In modules, any equivalence is required to be in the same module as the declaration.
! equiv.f90 module mod_a real :: A(5) ! ** place the equivalence in the same module equivalence (A(3),A3) end module mod_a module mod_b use mod_a ! ** the following is in error ! equivalence (A(3),A3) real :: SomethingToAvoidEmptyyModule end module mod_b program equiv use mod_b implicit none integer :: i do i=1,size(A) A(i) = i end do print *, A3 end program equiv
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Your code snippets leave us guessing. What code actual creates the error, what are the error messages? My guess is that you are trying to EQUIVALENCE local variables to variables in the module. I do not believe that is legal, equivalence does not work with many more modern features.
For example EQUIVALENCE
(XRAD1(1), XDUO3N(1,1)... XDUO3N is a "global" variable from you module. XRAD1 is a 'local' variable. What do we do with XRAD1 do we make some calculation of these values? Is the equvalance just giving it some memory to work in? Do we actually keep any modified
XDUO3N that result from XRAD1 calculations? You need to understand why the equivalence is used. This is one of its problems it leads to unclear programming in many cases. If it is simply a workspace for XRAD1 allocate XRAD1 as a local variable do the calculation and copy any results to a global that takes the results.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
How big is routine O3CLIM? Can you post it?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I saw a version of the same routine at http://box.mmm.ucar.edu/mm5/mpp/wrfbrowser/html_code/phys/module_ra_gfdleta.F.html#O3CLIM
It seems to me that all the equivalence stuff is just creating 'short cut names' to slices of larger arrays . for example some simple mods to the loop that uses rad1,2,3,4 to take array averages and differences would make them cease to exist and would be faster as you would use all array operations rather than lots of looping.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
!DO JJ=1,37 ! DO KEN=1,NL ! O3O3(JJ,KEN,IPLACE) = O35DEG(JJ,KEN) ! END DO !END DO if ( iplace == 1 ) then XDUO3N = O35DEG elseif( iplace == 2 ) then XDO3N2 = O35DEG elseif( iplace == 3 ) then XDO3N3 = O35DEG elseif( iplace == 4 ) then XDO3N4 = O35DEG endif ! 100 END DO !----------------------- ! END OF LOOP OVER CASES !----------------------- ! !-------------------------------------------------------------------------------------------------- ! AVERAGE CLIMATOLOGICAL VALUS OF O3 FROM 5 DEG LAT MEANS, SO THAT TIME AND SPACE INTERPOLATION ! WILL WORK (SEE SUBR OZON2D) !-------------------------------------------------------------------------------------------------- do i = 1 , 37 do j = 1 , NL AVG = 0.25 * ( XDUO3N(i,j) + XDO3N2(i,j) + XDO3N3(i,j) + XDO3N4(i,j) ) A1 = 0.5 * ( XDO3N2(i,j) - XDO3N4(i,j) ) B1 = 0.5 * ( XDUO3N (i,j) - XDO3N3(i,j) ) B2 = 0.25 * ( (XDUO3N (i,j) + XDO3N3(i,j) ) - ( XDO3N2(i,j) + XDO3N4(i,j) ) ) XDUO3N (i,j) = AVG XDUO3N2(i,j) = A1 XDUO3N3(i,j) = B1 XDUO3N4(i,j) = B2 enddo enddo ! DO I=1,NLGTH ! AVG = 0.25 * ( XRAD1(I) + XRAD2(I) + XRAD3(I) + XRAD4(I)) ! A1 = 0.5 * ( XRAD2(I) - XRAD4(I)) ! B1 = 0.5 * ( XRAD1(I) - XRAD3(I)) ! B2 = 0.25 * ((XRAD1(I) + XRAD3(I)) - (XRAD2(I) + XRAD4(I))) ! ! XRAD1(I) = AVG ! XRAD2(I) = A1 ! XRAD3(I) = B1 ! XRAD4(I) = B2 ! END DO
So something like the above means than xrad1,2,3,4 and 0303 declarations and equivalences cease to exits...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What you may not have noticed is the local 0303 array spans over XDUO3N, XDO3N2 , XDO3N3 and XDO3N4 and the code only works if they are stored in sequential memory locations (as they are when in a common). Removing the equivalence method as I did makes this no longer a requirement. Note that in a module there is no guarantee of the storage order of the variables. This is a problem with equivalence used this way as without careful study the link between o3o3 and XDO3N2 , XDO3N3 and XDO3N4 is not apparent.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The files attached in #10 need other files if one wants to run them through the compiler: the include files sp.h and MPP.h, and the source code for the module PARMETA.
Reading Andrew's comments made me speculate whether using ASSOCIATE ... END ASSOCIATE could be used instead of employing variables associated with array segments by EQUIVALENCE.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Luigi R. wrote:
Quote:
andrew_4619 wrote:
Equivalence is an obsolete language feature and if not used with extreme care is a good source of very confusing bugs. If modernising/updating the code and objective should be to remove it. There is not a simple route to doing this as you need to examine what the program is actually doing. For example if the local arrays are simply using the common as a work space you can just simply allocate the local arrays in the subroutine and they will automatically deallocate when you leave the subroutine.
I strongly disagree with this statement. Like UNION (in C++), EQUIVALENCE force the compiler to place variables where the programmer wants.
A good and advanced sw architect needs this capability.
Regards
I also strongly disagree. I only use equivalence in a very small number of strategic ways largely aimed at improving performance or data encryption where I want to efficiently treat non-integer data as integer for manipulation. I'm usually trying to avoid procedure call overhead or some such in that case. Some may not like my methods but it is totally unacceptable to declare something so fundamental as obsolete.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page