[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