ASIS:Code development

make contents here


 * Relevant pieces of code. Per existing code that may contribute to this project.


 * Software development plan. This is the place to discuss which pieces of code we should use, which development strands will need to be split or merged, which existing codes can be made more modular, which need to be maintained etc.


 * Guidelines for code development. This is the place to discuss which compilers we should use, version control, how to implement simple tests to make our development process more robust etc.


 * Current issues. Discuss ongoing debugging, development and testing issues here.  Or just about anything that's bothering you.


 * Relevant pieces of code. Per existing code that may contribute to this project.

This is a list of the pieces of code currently in existence that may be included in some form or other. Please add to this list.


 * 1) GLIMMER (see glimmer website)
 * 2) glam (higher order ice sheet model)
 * 3) 3rd party nested grid code (e.g. Paramesh,Chombo)
 * 4) PETSc (3rd party pde solvers)


 * Software development plan. This is the place to discuss which pieces of code we should use, which development strands will need to be split or merged, which existing codes can be made more modular, which need to be maintained etc.

Possible plan (RG):

Modularise solvers within glimmer and glam, keep them under seperate version control in a new project. Define API.

For our project, merge the following into one piece of code:
 * relevant solvers
 * relevant glam code
 * relevant glimmer code (thermodynamics? glint?)
 * 3rd party nested grid code

BL and SP are likely to run a parallelised version of glam using much of glimmer. This may well be a seperate code thread if we need to do major restructuring in order to incorporate nested grids.

Needs further discussion with IR, BL, TP, SP, RG, GW. Also depends somewhat on success of 1D nested grid study.


 * Guidelines for code development. This is the place to discuss which compilers we should use, version control, how to implement simple tests to make our development process more robust etc.

Here is an article about good coding. You can easily find many more. The main point is that by spending a little extra time during development adopting a pragmatic programming approach one can greatly reduce the amount of time one has to spend later on trying to debug or expand the code in the future.

Linux vs MS Windows
'' RG comments: More will follow here after we at Bristol have discussed this further (probably late June or July 2008).

Some members of the group use a development environment on windows for their fortran programming. This environment includes a debugger. It also interrogates the code to establish dependancies, so a seperate makefile is not required. I think it uses only the ifort compiler.

Some members use Linux. This requires a little more effort on the part of the developer. The developer has to write their own makefile. Emacs is probably the text editor of choice. It supports the user as far as compilation debugging, but not for runtime debugging. Debugging can be done using ddd, but ddd does not work smoothly for all compilers. It probably works better with g95 and gfortran. We have had problems trying to use it with ifort. ''

General guidelines
RG: We could put down a couple of guidelines specific to this project. Note the purpose of this wiki is not to provide detailed generic good coding practice guidelines, such things can be found elsewhere. But perhaps we should define which compilers we want code to run with, and advocate implementation of simple test scripts. I (and possibly Gethin) can help with this.

RG to add links to some of Gethins pages.


 * Current issues. Discuss ongoing debugging, development and testing issues here.  Or just about anything that's bothering you.

DAGW, SP and RG are currently trying to make glam more portable accross compilers, and implement a simple test. Several issues relating to corss compiler differences and other bugs have arisen.