Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28893 Discussions

Upgraded Code is slower in runtime as compared to Old code

Qaiser_Bozdar
Novice
1,939 Views

I am upgrading a FORTRAN code that was developed under the domain of Nuclear science.

I have attached txt format Old code and new code and input file to the code. 

My objectives were :

1 To increase capacity of the code so that it computes over large arrays of kind (500,500,500); old code was limited to only (135,135,135) and old code was developed using VISUAL Fortran Professional Edition 5.0A in Microsoft Visual Developer.

2. To increase runtime of code and have a faster convergence (possible to use parallel computing techniques) 

 

My request to you is that please compile both versions of the code using input file and inform me about the results and convergence time of the code using Intel Fortran Compiler in Visual STUDIO in Windows operating system.

I am facing following issues while achieving my objectives right now.

1. Old code converges within 4 minutes, my upgraded code converges within an hour. 58 mins&53secs

2 There is a difference in the result that is the value of converged K-eff = 1203470 is wrong in my upgraded version.

Please make sure D is input file and it must be in D.INP format.

Actual Results are attached. Actual Results are obtained using old code in a VM box in Win XP.

Labels (3)
1 Solution
jimdempseyatthecove
Honored Contributor III
1,880 Views

This may or may not be significant:

Old code: ALLOCATE(TMPOWER(153,153,153)) ! 1st element of the array is (1,1,1)

New code: ALLOCATE(TMPOWER(0:500,0:500,0:500)) ! 1st element of the array is (0,0,0)

*** and all the other lower bounds that were 1 and now are 0 ***

 

Changing the lower bound of each rank from 1 to 0 may be an issue (e.g. you overlooked this in your iteration loop(s)) this may account for results differences.

 

array(0:500,0:500,0:500) is 51.11 times the size of array(1:135.1:135,1:135) this may account for the runtime difference.

Your runtime difference is 14.75x for 51.11x more data.

 

Suggestions (leave old code alone, this is your reference):

0) Add IMPLICIT NONE to all your procedures and resolve undeclared variables.

1) change the base of the arrays that are now 0, but were formerly 1, back to 1, run your test

2) that failing, change the upper bound from 500 back to 135, run your test (may need to use old D.INP file)

3) that failing, you may have made an edition error in reformatting the file (removing continuation lines)

4) 2-succeeds, your convergence method may be sensitive to size of data when using 500x500x500. This often occurs when a limit is hand determined using a smaller dataset. Limits should be algorithmically determined at runtime based on size and nature of data.

 

Additionally, your data is default real(4), with 24 bits of significant. 51x times the data may introduce 51x more error. You might want to consider making your convergence accumulators real(8).

 

Consider placing the support procedures in a module and declaring the dummy arguments with assumed size notation:

module YourModuleNameHere
 ...
SUBROUTINE PRTCIT(V,NG,ZAF,PD,ISEC1,KSNM,JSNM,ISNM,PHI,TMPOWER ,ALPHALT,ALPHART,ALPHABT,ALPHATP,ALPHABA,ALPHAFR,S,KEFF,M,NOUT,NRST)
  IMPLICIT NONE
  REAL V(:),ZAF(:,:),PD(:),PHI(:,:,:,:),S(:,:,:),KEFF,TMPOWER(:,:,:)
  INTEGER N(:),NG,ISEC1(:),KSNM,JSNM,ISNM,M
  ...
end module YourModuleNameHere
...
Program YourProgramNameHere
  use YourModuleNameHere
  implicit none
  ...
end Program YourProgramNameHere

Then with that change

edit the allocations to use 135 and run the new new code using the old data input.

 

Jim Dempsey

 

 

View solution in original post

5 Replies
jimdempseyatthecove
Honored Contributor III
1,881 Views

This may or may not be significant:

Old code: ALLOCATE(TMPOWER(153,153,153)) ! 1st element of the array is (1,1,1)

New code: ALLOCATE(TMPOWER(0:500,0:500,0:500)) ! 1st element of the array is (0,0,0)

*** and all the other lower bounds that were 1 and now are 0 ***

 

Changing the lower bound of each rank from 1 to 0 may be an issue (e.g. you overlooked this in your iteration loop(s)) this may account for results differences.

 

array(0:500,0:500,0:500) is 51.11 times the size of array(1:135.1:135,1:135) this may account for the runtime difference.

Your runtime difference is 14.75x for 51.11x more data.

 

Suggestions (leave old code alone, this is your reference):

0) Add IMPLICIT NONE to all your procedures and resolve undeclared variables.

1) change the base of the arrays that are now 0, but were formerly 1, back to 1, run your test

2) that failing, change the upper bound from 500 back to 135, run your test (may need to use old D.INP file)

3) that failing, you may have made an edition error in reformatting the file (removing continuation lines)

4) 2-succeeds, your convergence method may be sensitive to size of data when using 500x500x500. This often occurs when a limit is hand determined using a smaller dataset. Limits should be algorithmically determined at runtime based on size and nature of data.

 

Additionally, your data is default real(4), with 24 bits of significant. 51x times the data may introduce 51x more error. You might want to consider making your convergence accumulators real(8).

 

Consider placing the support procedures in a module and declaring the dummy arguments with assumed size notation:

module YourModuleNameHere
 ...
SUBROUTINE PRTCIT(V,NG,ZAF,PD,ISEC1,KSNM,JSNM,ISNM,PHI,TMPOWER ,ALPHALT,ALPHART,ALPHABT,ALPHATP,ALPHABA,ALPHAFR,S,KEFF,M,NOUT,NRST)
  IMPLICIT NONE
  REAL V(:),ZAF(:,:),PD(:),PHI(:,:,:,:),S(:,:,:),KEFF,TMPOWER(:,:,:)
  INTEGER N(:),NG,ISEC1(:),KSNM,JSNM,ISNM,M
  ...
end module YourModuleNameHere
...
Program YourProgramNameHere
  use YourModuleNameHere
  implicit none
  ...
end Program YourProgramNameHere

Then with that change

edit the allocations to use 135 and run the new new code using the old data input.

 

Jim Dempsey

 

 

Qaiser_Bozdar
Novice
1,870 Views

Thank You Sir. You have performed a detailed analysis on my problem. 

I will implement your suggestions and then see what I get.

>> may have made an edition error in reformatting the file (removing continuation lines)

Yes, I had removed continuation lines because they were giving me a format error using Intel Fortran Compiler.

OLD Code eg: REAL SIGMAS(200,5,5),SIGMAA(200,5), NEWSIGMAF(200,5),SIGR(200,5)
* ,BSQ(200,5)

I removed that star and moved BSQ along with upper line. The error was removed.

New Code eg: REAL SIGMAS(200,5,5),SIGMAA(200,5), NEWSIGMAF(200,5),SIGR(200,5) ,BSQ(200,5)

Qaiser_Bozdar_0-1723993403155.png

 

I will report you back when a test your all suggestions.

  Thank You Sir

0 Kudos
Qaiser_Bozdar
Novice
1,696 Views

Sorry Sir, Nothing worked as you suggested. Kindly if  you can afford time, please once try to compile both versions of the code.

 

>>  0) Add IMPLICIT NONE to all your procedures and resolve undeclared variables. Not worked. It is better to not use IMPLICIT NONE

Implicit NoneImplicit None

>> 1) change the base of the arrays that are now 0, but were formerly 1, back to 1, run your test

Base array changed, bound error appearedBase array changed, bound error appeared

>> 2) that failing, change the upper bound from 500 back to 135, run your test (may need to use old D.INP file).

Failed.....  No issue concerning to input file

>> 3) that failing, you may have made an edition error in reformatting the file (removing continuation lines)

No issues with the continuation lines

4) 2-succeeds, your convergence method may be sensitive to size of data when using 500x500x500. This often occurs when a limit is hand determined using a smaller dataset. Limits should be algorithmically determined at runtime based on size and nature of data.

No idea at all,,, The old code work fine in Win XP using VM BOX in MS Visual Developer using Visual FORTRAN compiler (which is obsolete). New code with 0:135 array, takes one hour to converge even. Hence convergence is not sensitive to data size

Capture2.PNG Capture4.PNG

 

Now, I am thinking to get a new compiler for FORTRAN such as gfortran or silverfrost

0 Kudos
jimdempseyatthecove
Honored Contributor III
1,621 Views

0) "implicit none" requires you to declare every variable type. This avoids typographical errors where you misspell a variable. In the case of subroutine section1 you need to declare

INTEGER :: NINP, NOUT

And similar declarations in other procedures.

The intension is to assure no misspelling of variable names (and mistyping of variables).

 

I downloaded your original files OldCode.txt and NewCode.txt, renamed them to *.f90, created an MS VS solution for them (at first the OldCode.f90), set OldCode language to Fixed Format.

Building OldCode under MS VS in Debug build notes a typographical error in SECTION8

	SUBROUTINE SECTION8(D,SIGMAA,NEWSIGMAF,SIGMAS,PPFLUX,XI,NZ,NG,NGT
     * ,NGD,SIGE,BSQ,NINP,NOUT)

	REAL SIGMAS(200,5,5),SIGMAA(200,5), NEWSIGMAF(200,5)
	REAL XI(5),D(200,5),PPFLUX(200,5),SIGR(200,5),BSQ(200,5)

Your dummy argument "SIGE", I believe is misspelt and should be SIGR (same name as calling argument).

While SIGR from the caller is not used now, you may want the SIGR values later.

 

In OldCode, Line 9 you have:

	REAL X(135),Y(135),Z(135)

and at line 198 (and elswhere) you have:

      X(0)=X(0)-0.0
	Y(0)=Y(0)+0.0
	Z(0)=Z(0)+0.0

Seeing that you said that your old code ran and produced results, those results were produced while corrupting memory. As to if this corrupted your results it is unknown.

Please note, that, as was written, Y(0) would/may have been EQUIVILANCE to X(135) provided arrays X and Y were adjacent in memory.

Same issues with arrays XX, YY, ZZ DIF, PHI, DELTAX, DELTAY, DELTAZ.

 

IOW your OldCode was full of errors.

I made changes to OldCode, which may or may not be correct. It gets errors in reading D.INP.

You will have to work out the issues.

Revise the new OldCode such that it reads the input file correctly (likely an issue of array based on 0 vs 1).

Note, due to your array base issue in your original OldCode, those results data cannot be assumed to be correct. You will have to verify that the new OldCode results data is correct.

 

Once you have the corrected OldCode working properly, then migrate it to a new NewCode.

 

Jim Dempsey

 

 

 

Qaiser_Bozdar
Novice
1,603 Views

I am glad that you have investigated my codes.  Thank you

I will report you back. I consider your opinions on the results of oldcode.

0 Kudos
Reply