This action might not be possible to undo. Are you sure you want to continue?
Postgraduate Computing Lectures
Good Fortran 1
What is a Good FORTRAN Program? • It Works – May be ~ impossible to prove e. • Maintainable – Environment dynamic! – Well structured . Operating system. – No unnerving silence! – Restartable. diagnose bad replies. • Robust – Can handle bad data e. Postgraduate Computing Lectures Good Fortran 2 .minor changes .g. – Multi-path? Allow backoff.g.easy to find & fix and are local. I/O error or unfriendly user! • User Friendly – Not user hostile! – Questions .clear. offer help.
What is a GOOD FORTRAN Program? (cont. • Portable – Use “standard” compilers and libraries. Postgraduate Computing Lectures Good Fortran 3 .) • Extendable – To similar tasks.
• Common Fault:– Not enough time on design and testing – Coding should be ~ mechanical .Stages of Program Development • Design – Analysis of problem. – Skeleton (top-down). – Language specific translation.if not design incomplete. • Coding – Pseudo coding. – Outline design in English and Maths. – Detailed specification. Postgraduate Computing Lectures Good Fortran 4 . • Testing – Components in test-bed (bottom-up).
Design: General • Clear Statements in English and Maths – Write them down! • Specify I/O & Actions • Consider Possible Strategies – What are the intermediate data structures? Postgraduate Computing Lectures Good Fortran 5 .
General Design (cont.) • Limit Special Requirements – CPU intensive? Divide or make restartable. – Structured Design. • Take Great Care at this Stage! – Mistakes may be very expensive! • In HEP have used SA/SD – Structured Analysis. – Plan diagnostic printout of internal data structures and program flow. – Isolate specific device code (graphics packages do this for displays). Postgraduate Computing Lectures Good Fortran 6 . • Task Generalisation • Plan Testing – Write down verification procedures.
– Data Structures • Precise descriptions of each data item for:– COMMON blocks.Design: Detailed • Now use:– Routine Names • Calling sequences & “Black Box” spec. – I/O records. Postgraduate Computing Lectures Good Fortran 7 . – Top-Down. • Two Common Techniques:– Bottom-Up.
Draw (Pen Down.. Move) • Layer 2: Draw Line (Move. Join) • Layer 3: Draw Char (Move. – Each layer provides complete and consistent “model” to layer above.Bottom-Up Design • Example. • …. Plot Function. a Graphics Package • Layer 0: Pen Up/Down. • Principles:– Each layer uses services from layers below. • Layer n: Draw Histogram. Draw Line) • .. Postgraduate Computing Lectures Good Fortran 8 . Move in X/Y • Layer 1: Move (Pen Up. Move). – Only layer 1 talks to hardware.
Maintenance: easy to find and fix. Implement each section at each level as a subroutine. Postgraduate Computing Lectures Good Fortran 9 .Top-Down Design Divide and Conquer Separate program into few logically independent sections. Testing: Can test sections separately. Extendable: Plug in new section e. Has Enormous Advantages Simplifies problem. Repeat with each section as necessary. new processor.g.
• COMMONS – Keep separate data in separate commons. – Minimise Interconnections. Postgraduate Computing Lectures Good Fortran 10 .Top-Down Design (cont. • SLAVES . • Separate Out:– Machine Dependencies:• Generalise to machine independent concept.decides what to do.) • Structuring – Separate and simplify.do the work. – I/O – Control & Processing “Boss & Slave” Model:• BOSS . • Use bottom-up to implement.
– E.Called by one routine (its Boss). – Long Range i.Top-Down Design (cont. – Restrict COMMONs to lower level. tightly coupled and localise use (esp. Postgraduate Computing Lectures Good Fortran 11 .g. upper level. • Use directly within package. • Provide subroutine for caller. use arg list (easy to replace). modification).general function (test: could it go in library?) – Or .) • SUBROUTINES – Either . • Interfaces – In FORTRAN either COMMON or Arg list.e.Y in COMMON. Graphics Package • Pen X.
– Standard data may have few process paths. – To deal with an error must detect and analyse. • Example – 1000 data items. 10 error path => 90% error handling Postgraduate Computing Lectures Good Fortran 12 . 10 bad => 1% error rate – 1 good data path. interactive ones) because:– If an error can occur it will (and if it can’t it probably will). they may have many. but errors are deviations.Design: Error Paths • Error Paths May dominate program design (esp.
useless).g. Postgraduate Computing Lectures Good Fortran 13 . • COMMON Blocks – *** Meaningful names (e. – * Use a unique prefix on all variables. – *** Identical definition in all routines. Although 6 letters names is FORTRAN77 standard. – * Use INCLUDE (not official FORTRAN77 .Coding • Star System: – * – ** – *** worth thinking about. most FORTRAN compilers permit more.g. never break. – ** Avoid simple names e. I .. SUM (used locally).would be *** if it was). only break for good reason.
– ** Avoid long routines . – *** Minimise/eliminate GOTOs.) • SUBROUTINES – *** Continue top-down .Coding (cont. – *** Keep labels in ascending order. – ** Use labels that reflect block structure e. Sacrifice a little efficiency for fewer flow paths. – *** Give variables meaningful names.helps if used multiple times and when adding more.divide code into blocks. – ** Use IMPLICIT NONE if possible (not FORTRAN77). If possible only jump down to next block.200 lines is getting too long. – * Collect formats at the end .g 100-199 for first block. Postgraduate Computing Lectures Good Fortran 14 . – ** Only jump up as an iteration.
) – *** Always comment routine. list } and output – COMMONs • Details of implementation. • Description of interface:Specify what are input – Arg. • Author names and a revision history of changes.Coding (cont.indenting code and aligning material makes it more readable (and can highlight mistakes!) Postgraduate Computing Lectures Good Fortran 15 . – *** Take time to layout code professionally . • Separate out and comment each block.) • SUBROUTINES (cont. A good scheme:• 1 or 2 line summary.
take a fresh look at intermediate data. Postgraduate Computing Lectures Good Fortran 16 .Program Modification Either Function or Performance • Function – Golden Rule: How would I designed it if I were starting now? – Not: What is the absolute minimum change. – If all else fails. – Use Performance Analysers to find hot spots and then recode. It may get job done faster but shortens program lifetime! • Performance – Optimise compilation.
• Formulae. Postgraduate Computing Lectures Good Fortran 17 . – Bottom-Up testing • Test lowest level modules using a Test Bed. With complex programs it is very hard to prove free of bugs (except by redefining them as “features”). • Minimise Bugs – by Well Structured with Fewest Possible Flow Paths. • Testing Methods:– Desk Check .Testing May be easy to ~ impossible. • Calling sequences. • Test levels above.take time to read slowly checking:• Flow paths.
• Add more function step by step. – Minimum Condition:• Test every line of code. Postgraduate Computing Lectures Good Fortran 18 . • Remember to retest after fixing bugs. • Good for complex program development.) • Testing Methods (cont.) – Top-Down Testing • Start with top levels with almost dummy modules. • Leave in Switchable Debug Printout – Useful despite powerful debuggers.Testing (cont.