Difference between revisions of "Category:Pragmatic Programming"

From SourceWiki
Jump to navigation Jump to search
 
(10 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
__NOTOC__
 
__NOTOC__
 
"Pragmatic Programming" is a course which was designed for new postgraduate students and members of staff in Geographical Sciences.
 
 
As well as being available year round on this wiki, the course is also given every year as series of monthly practicals starting in the Autumn term. The idea is to have a regular monthly programming skills session over the first year of a PhD. The course is open to postgraduates and postdocs in Geographical Sciences and elsewhere. If you are interested in attending the course, please contact the [mailto:ggy-source-admin@bristol.ac.uk administrators].
 
 
 
=Rationale=
 
=Rationale=
  
A considered approach to writing environmental models is of the utmost for two reasons.
+
"Pragmatic Programming" is a course which was designed for new postgraduate students postdocs and members of staff alike.
 
 
The first pertains to the word 'science' and the key tenet of reproducibility.  A well engineered model will be robust to a change of hardware or compiler.  Too often, however, we find that running a model developed by one research group on the systems of another yields different results.  How much are we to trust results which we cannot replicate?  Not to mention the time wasted trying to track down the cause of the discrepancy.  This considerations carry particular weight when model results are used to inform environmental policy in the face of climate change.
 
 
 
The second reason is that we simply cannot bear the cost of an ill-considered approach to model development.  Time is money and grappling with poorly engineered, or simply un-designed models wastes huge amounts of time.  One science experiment is often a slight variant upon another.  Well engineered code can be quickly adapted for a following experiment.  However, a change to Heath Robinson style creations which we often witness can present an impasse which requires huge efforts to overcome.  Imagine this situation repeated hundreds of times over and a sobering waste of resources comes to mind.  And this is before we contemplate the cost of tracking down bugs.
 
 
 
A few years back, there was a short course for physical geography postgraduate students providing core computer skills required for the many modelling activities in the department. It covered briefly the Linux operating system, Fortran programming and the use of numerical libraries. Although this course stopped a while ago, there is still a clear and vocalised need for that type of tuition today.  
 
  
"Pragmatic Programming" was designed to fill that gap. The course was written specifically for Geographical Sciences postgrads and postdocs but will be relevant to many researchers. Fortran and C/C++ are the main programming languages.
+
It is designed to address two key issues:
  
=Credits=
+
* The first pertains to the word 'science' and the key tenet of reproducibility.  A well engineered model will be robust to a change of hardware or compiler.  Too often, however, we find that running a model developed by one research group on the systems of another yields different results.  How much are we to trust results which we cannot replicate?  Not to mention the time wasted trying to track down the cause of the discrepancy.  This considerations carry particular weight when model results are used to inform environmental policy in the face of climate change.
  
"Pragmatic Programming" was designed in 2008 by [[user:Jprenaud | JP Renaud]] and [[user:GethinWilliams | Gethin Williams]].
+
* The second reason is that we simply cannot bear the cost of an ill-considered approach to model development.  Time is money and grappling with poorly engineered, or simply un-designed models wastes huge amounts of time.  One science experiment is often a slight variant upon another.  Well engineered code can be quickly adapted for a following experiment.  However, a change to Heath Robinson style creations which we often witness can present an impasse which requires huge efforts to overcome.  Imagine this situation repeated hundreds of times over and a sobering waste of resources comes to mind.  And this is before we contemplate the cost of tracking down bugs.
  
 
=Course content=
 
=Course content=
  
The following is a list of example-led tutorials which will be used to provide an engineering framework, upon which scientific programming can be profitably overlaid.
+
==Foundations==
  
=====Thread1: Fortran and python programming=====
+
* [[Linux1|Linux1: Linux for beginners]]
 +
* [[Linux2|Linux2: More advanced Linux]]
 +
* [[Linux3|Linux3: Starting administration]]
  
# [http://source.ggy.bris.ac.uk/wiki/Fortran1 Fortran1: Fortran for beginners].  This is friendly introduction to Fortran and will guide you from '''writing your first program''' through to using more advanced data-types, such as '''arrays'''.  Along the way, you will encounter Fortran's '''intrinsic data types''', logic such as '''conditionals''' and '''loops''', program structure and '''subroutines''' all the while providing pointers to '''good style''' and '''bug avoidance''' techniques.
+
==languages==
# [http://source.ggy.bris.ac.uk/wiki/Fortran2 Fortran2: Intermediate Fortran].  This tutorial follows on from Fortran1 and introduces features from Fortran90 which help us to write better, more maintainable programs.  The topics covered include; dynamic memory allocation using '''allocatable arrays'''; flexible and easily extensible data-types through the use of '''user-derived types'''; enhanced modularity, encapsulation and error checking provided by '''modules'''.  Linking your program to third party '''libraries''' is also covered, using '''NetCDF''' as an example.
 
# Should you wish to go further [http://source.ggy.bris.ac.uk/wiki/Numerics Numerics], [http://source.ggy.bris.ac.uk/wiki/Profiling Profiling] and [http://source.ggy.bris.ac.uk/wiki/Debugging Debugging] provide examples of '''common numerical programming gotchas'''; tips to help you find and improve any '''slow running regions of your program'''; and hints and tips for '''avoiding, finding and correcting''' any '''bugs''' that find their way into your code.
 
# [http://source.ggy.bris.ac.uk/wiki/NumericPython An introduction to Python and the numpy package] guides you through some first steps with python and highlights some of the very useful '''data manipulation and visualisation tools''' on offer.  The examples will focus on data held in 2-dimensional arrays.
 
# [http://source.ggy.bris.ac.uk/wiki/Polyglot Polyglot] offers some concrete examples of '''mixed Fortran and C''' programming, including the new '''Fortran2003 interoperability features'''.  Mixed language programming provide huge time-savings if you have access to, say, a third party library of routines written in C which you would like to make use of inside your existing Fortran project.
 
  
=====Thread2: Tools for Managing your Code and your Project=====
+
* [[Python1|Starting Python]]
 +
* [[MATLAB1|Starting MATLAB]]
 +
* [[R1|Starting R]]
 +
* [[Fortran1|Fortran1: Fortran for beginners]]  <!--This is friendly introduction to Fortran and will guide you from '''writing your first program''' through to using more advanced data-types, such as '''arrays'''.  Along the way, you will encounter Fortran's '''intrinsic data types''', logic such as '''conditionals''' and '''loops''', program structure and '''subroutines''' all the while providing pointers to '''good style''' and '''bug avoidance''' techniques.-->
 +
* [[Fortran2|Fortran2: Intermediate Fortran]]  <!--This tutorial follows on from Fortran1 and introduces features from Fortran90 which help us to write better, more maintainable programs.  The topics covered include; dynamic memory allocation using '''allocatable arrays'''; flexible and easily extensible data-types through the use of '''user-derived types'''; enhanced modularity, encapsulation and error checking provided by '''modules'''.  Linking your program to third party '''libraries''' is also covered, using '''NetCDF''' as an example.-->
 +
* [[StartingC|StartingC: C for beginners]]
 +
* [[CtoC++|CtoC++: Progressing from C to C++]]
 +
* [[Polyglot|Polyglot: Mixed language programming]] <!--offers some concrete examples of '''mixed language''' programming, including the new '''Fortran2003 interoperability features'''.  Mixed language programming provide huge time-savings if you have access to, say, a third party library of routines written in C which you would like to make use of inside your existing Fortran project.-->
  
# [http://source.ggy.bris.ac.uk/wiki/Subversion The Subversion version control system] is fantastic tool for '''collaborating''', '''debugging''', '''disaster recovery''' and, well, '''general sanity preservation!'''.  This tutorial gives you hands on practice for all the essential features.
+
==Tools==
# [http://source.ggy.bris.ac.uk/wiki/Make Project building using Make] guides you step-by-step through the otherwise opaque magic of '''Makefiles''' and highlights how they can be brought into service not only for '''code compilation''', but also for '''automatic documentation''' creation and program '''testing'''.  The combination of Subversion and Make opens the door to a nightly build for your project--a proven way to catch and correct bugs.
 
  
=====Thread3: C/C++ and Parallel Programming using OpenMP=====
+
* [[Subversion|Subversion: The Subversion version control system]] <!--is fantastic tool for '''collaborating''', '''debugging''', '''disaster recovery''' and, well, '''general sanity preservation!'''.  This tutorial gives you hands on practice for all the essential features.-->
 +
* [[Make|Make: Project building using Make]] <!--guides you step-by-step through the otherwise opaque magic of '''Makefiles''' and highlights how they can be brought into service not only for '''code compilation''', but also for '''automatic documentation''' creation and program '''testing'''.  The combination of Subversion and Make opens the door to a nightly build for your project--a proven way to catch and correct bugs.-->
  
# [http://source.ggy.bris.ac.uk/wiki/StartingC C for beginners]
+
==Topics==
# [http://source.ggy.bris.ac.uk/wiki/CtoC++ moving from C to C++]
 
# [http://source.ggy.bris.ac.uk/wiki/Parallel Parallel programming using OpenMP]
 
  
<!--
+
* [[Data|Working with data]]
* [[Linux1|Linux1]]
+
* [[Profiling|Performance Analysis]]
* [[Fortran1|Fortran1]]
+
* [[Debugging|Debugging]] <!--provide tips to help you find and improve any '''slow running regions of your program'''; and hints and tips for '''avoiding, finding and correcting''' any '''bugs''' that find their way into your code.-->
* [[StartingC|StartingC]]
+
* [[Parallel|Parallel: Parallel programming using OpenMP]]
* [[CtoC++|CtoC++]]
+
* [[NumMethodsPDEs|Numerical methods for solving PDEs]]
* [[Linux2|Linux2]]
 
* [[Fortran2|Fortran2]]
 
* [[Fortran3|Fortran3]]
 
* [[Condor|Condor]]
 
* [[Make|Make]]
 
* [[Debugging|Debugging]]
 
* [[Subversion|Subversion]]
 
* [[Profiling|Profiling]]
 
* [[Numerics|Numerics]]
 
* [[Parallel|Parallel]]
 
* [[Polyglot|Polyglot]]
 
* [[UsingNetCDF|Using NetCDF]]
 
* [[UsingSSH|Using SSH]]
 
-->
 

Latest revision as of 15:07, 20 September 2013

Rationale

"Pragmatic Programming" is a course which was designed for new postgraduate students postdocs and members of staff alike.

It is designed to address two key issues:

  • The first pertains to the word 'science' and the key tenet of reproducibility. A well engineered model will be robust to a change of hardware or compiler. Too often, however, we find that running a model developed by one research group on the systems of another yields different results. How much are we to trust results which we cannot replicate? Not to mention the time wasted trying to track down the cause of the discrepancy. This considerations carry particular weight when model results are used to inform environmental policy in the face of climate change.
  • The second reason is that we simply cannot bear the cost of an ill-considered approach to model development. Time is money and grappling with poorly engineered, or simply un-designed models wastes huge amounts of time. One science experiment is often a slight variant upon another. Well engineered code can be quickly adapted for a following experiment. However, a change to Heath Robinson style creations which we often witness can present an impasse which requires huge efforts to overcome. Imagine this situation repeated hundreds of times over and a sobering waste of resources comes to mind. And this is before we contemplate the cost of tracking down bugs.

Course content

Foundations

languages

Tools

Topics