- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi All,
I am trying to first understand somebody else's code to be able to develop it more. Could someone give me some hints on the efficient ways of getting used to a 8000-line Fortran code?
Thanks.
I am trying to first understand somebody else's code to be able to develop it more. Could someone give me some hints on the efficient ways of getting used to a 8000-line Fortran code?
Thanks.
Link Copied
8 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
spend 2days praying there be enough comment so you don't get confused.
Find the book or paper developer of code used that, notations of the code is usually according to the book developer used so you save a lot of time understanding variables.
First draw a mental image of the subroutine relations, in big codes this sort of codes you don't need to know how a subroutine is acting? in bigger codes you don't even need to know role of some subroutines, but you got to have a comprehensive image of the code to know which one is not in your business, else you wander a lot.
Best method is to find a person who has been working with the code, some minutes of his/her time will make days of your's, so put some effort of this if there is a chance.
Find the book or paper developer of code used that, notations of the code is usually according to the book developer used so you save a lot of time understanding variables.
First draw a mental image of the subroutine relations, in big codes this sort of codes you don't need to know how a subroutine is acting? in bigger codes you don't even need to know role of some subroutines, but you got to have a comprehensive image of the code to know which one is not in your business, else you wander a lot.
Best method is to find a person who has been working with the code, some minutes of his/her time will make days of your's, so put some effort of this if there is a chance.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What is your present compiler/Visual developer environment?
What does the code do?
What is the user interface to it? (Is there a GUI, does it require input files, produce output files etc.)
Is the code all Fortran? Any idea what standard of Fortran?
Does it use COMMON blocks?
Does it use EQUIVALENCE alot?
Is the code well-commented?
Is there any other documentation with it?
Does the code compile OK with your present compiler?
Have you any test input and test output?
Does it run OK without crashing?
Is it a self-contained executable, or does it require linking to other (non-windows) special libraries?
What do you mean by 'develop it more'?
What does the code do?
What is the user interface to it? (Is there a GUI, does it require input files, produce output files etc.)
Is the code all Fortran? Any idea what standard of Fortran?
Does it use COMMON blocks?
Does it use EQUIVALENCE alot?
Is the code well-commented?
Is there any other documentation with it?
Does the code compile OK with your present compiler?
Have you any test input and test output?
Does it run OK without crashing?
Is it a self-contained executable, or does it require linking to other (non-windows) special libraries?
What do you mean by 'develop it more'?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Ahmad,
Depending on the code, and more importantly, the number of times this code went through modifications by different programmers, the source files may be difficult to comprehend due to the comments not being updated as the code was updated. Also, if the code has a history back to the 1970's or 1980's mostof these programs were written for memory constrained systems. Code from this era requires special attention where COMMON's in one source file may layout the same memory used by a different source file's COMMON differently. e.g. X in one source file could be Y in a different source file. Similar issue with the use of EQUIVILANCE
If the code uses MODULE data in place of COMMON and EQUIVILANCEthen this makes your work easier.
Steps I would suggest you follow:
1) Before you do any changes to the original files make a copy of the project in a seperate location such that you can compile and rebuild the original code.
2) Assure that both the copy of the project/solution and yourworking set of the project/solution compiles and produces working (to the degree the old code was working) program(s).
3) If you do not have one already, and if the program output is not suitable for review by WinDiff, write a utility program that compares the output files from the original program and your current copy of the program (initially identical copies of the same source files).
4) Next, review the code, adding your own comments. Some of these may be temporary annotations until you get things sorted out.
5) Using the Debugger, walk through the code as it executes. This will give you a better understanding of the flow. Add additional comments as you do this (this may require you rebuild and restart the debug session).
6) Once you feel you have a understanding of the program to the point where you are willing to make changes to the code (as opposed to comments/annotations), rerun your verification (or WinDiff) on the output files of the current code and the original code to assert that what you have done to date hasn't altered the output.
7) Before you make substantive changes, archive the current sources into a versioning system (or copy sourcesto seperately named folders e.g.: FooBarAsOf.2011.07.18.001 (name, year, month, day, sequence number) Copies of the source (including headers). If you make these copies of source only keeping the same directory tree layout as the working copy then it is quite easy to use WinDiff to compare directories to find differencies amongst 100's, 1000's of files. Keeping change histories (and notes) will help you immeasureably later in tracking down that you introduce into the code.
8) If the old code uses COMMON's and EQUIVILANCE's incrimentally migrate these into MODULE files. Although this step will not directly add the new features you want to add, it potentially will decrease your debug time and/or maintenance time later. In converting COMMON's be aware that different source files can use the same named common laid out differently from each other. Carefully verify that the common declarations are the same for each named common. If they are not the same, then progress carefully making more frequent tests of the output files after each (or few) changes. Note, often an error will not appear right away. Annotate with comments where you have renamed, deleted, added variables.
9) When you delete variables, comment it out as opposed to deleting it.
10) After conversion to MODULES, then start making your improvements.
11) Make use of conditional compile statements such that your incrimental changes can be enabled and disabled. I prefer to use the FPP but you can use the !$DEC format if you prefer.
This should get you started.
Jim Dempsey
Depending on the code, and more importantly, the number of times this code went through modifications by different programmers, the source files may be difficult to comprehend due to the comments not being updated as the code was updated. Also, if the code has a history back to the 1970's or 1980's mostof these programs were written for memory constrained systems. Code from this era requires special attention where COMMON's in one source file may layout the same memory used by a different source file's COMMON differently. e.g. X in one source file could be Y in a different source file. Similar issue with the use of EQUIVILANCE
If the code uses MODULE data in place of COMMON and EQUIVILANCEthen this makes your work easier.
Steps I would suggest you follow:
1) Before you do any changes to the original files make a copy of the project in a seperate location such that you can compile and rebuild the original code.
2) Assure that both the copy of the project/solution and yourworking set of the project/solution compiles and produces working (to the degree the old code was working) program(s).
3) If you do not have one already, and if the program output is not suitable for review by WinDiff, write a utility program that compares the output files from the original program and your current copy of the program (initially identical copies of the same source files).
4) Next, review the code, adding your own comments. Some of these may be temporary annotations until you get things sorted out.
5) Using the Debugger, walk through the code as it executes. This will give you a better understanding of the flow. Add additional comments as you do this (this may require you rebuild and restart the debug session).
6) Once you feel you have a understanding of the program to the point where you are willing to make changes to the code (as opposed to comments/annotations), rerun your verification (or WinDiff) on the output files of the current code and the original code to assert that what you have done to date hasn't altered the output.
7) Before you make substantive changes, archive the current sources into a versioning system (or copy sourcesto seperately named folders e.g.: FooBarAsOf.2011.07.18.001 (name, year, month, day, sequence number) Copies of the source (including headers). If you make these copies of source only keeping the same directory tree layout as the working copy then it is quite easy to use WinDiff to compare directories to find differencies amongst 100's, 1000's of files. Keeping change histories (and notes) will help you immeasureably later in tracking down that you introduce into the code.
8) If the old code uses COMMON's and EQUIVILANCE's incrimentally migrate these into MODULE files. Although this step will not directly add the new features you want to add, it potentially will decrease your debug time and/or maintenance time later. In converting COMMON's be aware that different source files can use the same named common laid out differently from each other. Carefully verify that the common declarations are the same for each named common. If they are not the same, then progress carefully making more frequent tests of the output files after each (or few) changes. Note, often an error will not appear right away. Annotate with comments where you have renamed, deleted, added variables.
9) When you delete variables, comment it out as opposed to deleting it.
10) After conversion to MODULES, then start making your improvements.
11) Make use of conditional compile statements such that your incrimental changes can be enabled and disabled. I prefer to use the FPP but you can use the !$DEC format if you prefer.
This should get you started.
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What is your present compiler/Visual developer environment?
Intel Visual Fortran XE
What does the code do?
It models the flow field
What is the user interface to it? (Is there a GUI, does it require input files, produce output files etc.)
No GUI. It reads two geometry files and then processes it.
Is the code all Fortran? Any idea what standard of Fortran?
Yes, all Fortran 77
Does it use COMMON blocks?
Yes
Does it use EQUIVALENCE alot?
Yes
Is the code well-commented?
No :(
Is there any other documentation with it?
It has a very very brief documentation.
Does the code compile OK with your present compiler?
I have not compile it yet but I am gonna do this.
Is it a self-contained executable, or does it require linking to other (non-windows) special libraries?
Yes it is a self-contained code.
What do you mean by 'develop it more'?
I want to first understand the code to be able modify the flow field boundary conditions and output the desired parameters.
Intel Visual Fortran XE
What does the code do?
It models the flow field
What is the user interface to it? (Is there a GUI, does it require input files, produce output files etc.)
No GUI. It reads two geometry files and then processes it.
Is the code all Fortran? Any idea what standard of Fortran?
Yes, all Fortran 77
Does it use COMMON blocks?
Yes
Does it use EQUIVALENCE alot?
Yes
Is the code well-commented?
No :(
Is there any other documentation with it?
It has a very very brief documentation.
Does the code compile OK with your present compiler?
I have not compile it yet but I am gonna do this.
Is it a self-contained executable, or does it require linking to other (non-windows) special libraries?
Yes it is a self-contained code.
What do you mean by 'develop it more'?
I want to first understand the code to be able modify the flow field boundary conditions and output the desired parameters.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Ahmad
It sounds like the code I have been working with the last few years. FEMWATER dates back to the 1990s, is written in F77, 24000 lines, little in the way of comments or documentation, and the original authors are not really available to ask. FEMWATER is a 3D finite element groundwater model, and is a console application with text input and output files.
It has taken me a long time to understand this code, mostly just by reading it (!) and the user manual, which explains some of the mathematics. Buy comparing the mathematics to the code I can guess what the code does (since there are almost no comments and the variable names are very crytpic). Luckily it does compile and run, and the code structure is actually quite simple - read the input files, run the main loop, write the output files. I have only found a few minor errors.
Several things that have helped me:
1. Make a list of all the input/output files and their unit numbers.
2. Put it all in one source file (I just find this easier to navigate).
3. Make a list/diagram showing the order the subroutines are called, and what subroutines call each other.
4. I found WinMerge useful for comparing versions.
5. Stepping through the code in debug mode.
Simon
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Simon,
They are good tips. Thanks. One quick question. Are you aware of any software that can show the connectivity of the function and subroutines of a FORTRAN file graphically? I have about 70 functions.
Thanks.
They are good tips. Thanks. One quick question. Are you aware of any software that can show the connectivity of the function and subroutines of a FORTRAN file graphically? I have about 70 functions.
Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes. They are useful for learners working on small projects. They are mostly useless for situations where they would be needed and used by an experienced programmer. This is a limitation of 2D visualization and human comprehension, and not a fault of the author of the tool.
Some tools and some compilers, including Intel 12.0, can produce source listings. Some can be asked to include in the listing a section of called functions and subroutines. Such lists of caller/callee can be merged into a global listing of interconnections and interactions between subprograms.
The use of modules and CONTAINed subprograms tends to reduce the need for such tools. In medium-sized projects, the sequential conversion of more and more subprograms into modules can result in the perceived need for caller/callee lists to disappear.
Some tools and some compilers, including Intel 12.0, can produce source listings. Some can be asked to include in the listing a section of called functions and subroutines. Such lists of caller/callee can be merged into a global listing of interconnections and interactions between subprograms.
The use of modules and CONTAINed subprograms tends to reduce the need for such tools. In medium-sized projects, the sequential conversion of more and more subprograms into modules can result in the perceived need for caller/callee lists to disappear.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ahmad,
The Intel profiler has a capability to produce call trees. Although this is not a 2D chart it may give you some insight as to the organization. 70 functions is relatively small so you should you could even chart this by hand if need be.
Jim Dempsey
The Intel profiler has a capability to produce call trees. Although this is not a 2D chart it may give you some insight as to the organization. 70 functions is relatively small so you should you could even chart this by hand if need be.
Jim Dempsey
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page