[CSC 435] New makefile targets

Andrew J. Pounds pounds at sandbox.mercer.edu
Mon Jan 17 18:47:59 EST 2022


One more thing -- since you be comparing to the old dusty, you need to 
keep it around and also as a target in your makefile.  I recommend 
putting another target in your makefile for dusty.f95.

You could have your makefile actually have three sources

dusty.f

dusty.f90

dusty.cc

but the compilers would technically leave them with the same dusty.o 
object file.  So I recommend that you name the object files in your 
makefile using the -o command.

gfortran dusty.f -c -o dusty77.o

gfortran dusty.f90 -c -o dusty95.o

g++ dusty.cc -c -o dusty.o

you will need to update your OBJS variable and the names of the targets 
in your makefile accordingly.

The executables might be called dusty77, dusty95 and dusty. Again, you 
will have to create these targets in your makefile.

Please don't think you have to stick with fortran 95 -- the Gnu fortran 
compiler supports many of the new language features all the way through 
the ISO Fortran 2018 standard -- there may be some gems there to help 
you later!

On 1/17/22 18:25, Andrew J. Pounds wrote:
>
> Now that some of you are finishing up the "initial profiling" 
> assignment (due Wednesday night) you can start working on the re-write 
> of dusty.
>
> Remember -- you are rewriting in modern fortran (at least .f95 or 
> newer with free-form formatted source lines) and C/C++.
>
> One of the hard parts of this project is getting identical results 
> between the old code and your new code.  If you look at the old dusty 
> code it is broken up into loop sections.  I recommend working through 
> each one of these individually.  In other words complete the rewrite 
> of loop 10 and then compare the results of the dusty.f AV array with 
> your array.  Work through each loop in this manner.
>
> Once you hit loop 12 you will have to implement a new version of 
> idcheck.  That is where things get particularly nasty and you hit some 
> OLD fortran constructs that are extremely frowned upon these days.  
> For example...
>
>  goto ( 200, 300, 400, 500 ) int(mod(i+j+k,4)+1)
>
> is particularly troubling.  You may have to look this one up! It's 
> called a computed goto statement.  You will definitely have to rewrite 
> this in your new fortran.
>
> Anyway, as you work through the code stop and verify results after 
> each "loop section".   Using that strategy I was able to get 
> everything rewritten and give the same results.  Once we have the 
> codes rewritten in modern forms and giving the same results, we can 
> start working on optimizing them.
>
> Remember -- correct results first -- then optimization.  If you 
> optimize first bad things will happen and you will most likely have to 
> start over (seen it at least a dozen times in this class with this 
> piece of code).  At this point, just focus on the re-write and getting 
> correct results.
>
> -- 
> */Andrew J. Pounds, Ph.D. /* (pounds_aj at mercer.edu)
> /Professor of Chemistry and Computer Science/
> /Director of the Computational Science Program/
> /Mercer University, Macon, GA 31207 (478) 301-5627/
>
> _______________________________________________
> csc435 mailing list
> csc435 at theochem.mercer.edu
> http://theochem.mercer.edu/mailman/listinfo/csc435
-- 
*/Andrew J. Pounds, Ph.D. /* (pounds_aj at mercer.edu)
/Professor of Chemistry and Computer Science/
/Director of the Computational Science Program/
/Mercer University, Macon, GA 31207 (478) 301-5627/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://theochem.mercer.edu/pipermail/csc435/attachments/20220117/ff1b7bb5/attachment.html>


More information about the csc435 mailing list