Grids: Notes for an implementation

This contains some hints and discussions about how to implement Grids  (that I learned to call CW-Complexes) in a Object Oriented language. Specifically the discussion is made with Java in mind, but obviously, not limited to it.  These slides do not contain very much bibliography and are, by far, not a complete treatment of the subject. They hope to be, however, some useful "food for thought" to start with.

Clicking on the above figure you'll be redirected to the presentation that contains the seeding for a deployment, at least in our overall system.

The first taste of Ne3 (netree) (at IEMSs in Toulouse)

We had this presentation, this morning at IEMSs, about some of the many lines of work where Francesco Serafin (his blog here) is developing his Ph.D research. The origin of the work is that modelling basins is to model hillslopes (or Hydrologic Response Units, HRUs) connected by a river network. Most of what happens in HRUs is independent from what happens in the others. Some instead is aggregated by river network. So why do not use this natural structure to organise modelling and processes (and send them in parallel, when possible, using the tree structure) ?

Actually this can grow more, since many systems (a plant, ecological interactions, hydrological interactions), can be seen described over a graph of interactions. So the Ne3 can become a more general way to investigate natural systems. However, you can enjoy the presentation, by clicking on the figure above.  Ne3 source code written so far in on Github.

Design Patterns

Programming the object oriented (OO) way is not simply writing down algorithms that do “for" loops. The core concept to understand, for a OO programmer, is how many classes have to be implemented on the basis of the analysis of the problem under scrutiny, and to be eventually managed by a client (the “main” method in C family of languages)  to solve a task. Therefore, a series of questions arise:

• Are there strategies for producing a minimum number of classes without loosing functionalities  in the work done and promote its extensibility  ? 
• What goes into a class, and what in other OO features (like methods of a class) ? 
• How to create classes with a minimum of generality that can be reused in other problems ? 
• How to build classes that can be easily maintained, modified and evolved without disrupting other parts of codes ? 

(In practise the questions are those for which OO was born but knowing an OO language does not directly answer them, just offers an infrastructure for finding the answers).

An entire discipline, software engineering (SE), was established to find the answers, and various behaviors were codified to improve software writing practice and management (but software engineering also covers the organisation of software production, and the methods to give  clear specifications to pariah-programmers for practical coding).
The key actions implied by the answers, however, are not the ones a scientific programmer was used to face: s/he would expect to have a formalised mathematical problem and the scope of her/his work to consist in fact in finding the best (shortest, fastest, cleanest) algorithms to solve it (see the classical Knuth’s books, or the popularisation of Numerical Recipes - I hate their licensing scheme) but not to answer questions about the organisation of the code.
Maintainability and efficiency comes to a cost and OO adds a further level of complexity to the programming practice that scientists are not always ready to face: and it is quite paradoxical that these aspects of SE are not wide recognised as a fundamental task in our times when computer programs have entered in the daily practice of many scientists (see also the introduction to this paper of ours). As a matter of fact bad code practices easily develop in bad science.

Back to the general questions posed at the beginning of the post, proficient programmers observed that, certain problems were recurrents and that some solutions were better than others in term of maintainability and generality. These were called "design patterns”:

"The elements of this language are entities called patterns. Each pattern describes a problem that occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice."  (from A Pattern Language by Christopher Alexander, that is said to be inspirational for the the Gang of Four book - see below).
Other definitions of patterns can be fond in the Portland Patterns Repository and in The Hillside group on patterns,.

The patterns idea gained popularity after the book of Gamma, Helm, Johnson & Vlissides, Design Patterns, which actually presents 23 free patterns, grouped in three categories, called

• behavioural, 
• creational and 
• structural patterns. 

Beyond these initial patterns, other were identified, for instance for parallel computing (see Concurrency patterns), and  in other fields.
The patterns style and  use (and concept) are not immediate to grasp. They in fact derive from long practicing some specific software issues, and a subsequent conceptualisation and abstraction. As often happens, their abstraction makes them general but  quite difficult to be assimilated without going back to develop many examples.
A few guiding ideas are behind the selection of patterns: code should be made easy to modify without large refactoring efforts, and encapsulation of code parts maintained as much as possible. Subclassing maintained to a minimum. An explicit slogan was "program to interface and not to implementation”. Roughly speaking this means: first implement abstract classes or interfaces (in C-family of languages), the, for what is possible, delay the use of concrete classes at run time. Instead of creating subclasses, create other classes to which "delegate responsability”, in order to reduce coupling between classes. The reader is invited to browse the web to understand her/himself what it does mean, advising her/him that explanations are usually full of computer science slang (I think, actually that the language is part of the success of the book).
In any case, the right way to get used to Design Patterns, is, as I said, to use and practice them a lot by trial and error. Java aficionados can have several vulgarisations, many of them can be found on the web [Ava Java].

However, the relevant questions here, in this blog,  are:

• which of the original (as well as other) patterns are useful in scientific programming ?
• Are there any pattern that is characteristic to hydrological problems ?

Certainly there exists hydrologists that apply some patterns for the tasks the patterns were created. I do not know if experienced hydrology programmers apply  patterns to some specific of hydrology. Please let me know if you are someone of those, and I will really likely exchange ideas and a (very few) experiences.

In the general science framework, instead, I find a few more references. The first books I can reference are

• Design Patterns for e-Science, by Henry Gardner, Gabriele Manduchi, Springer, 2007 (It covers the building of a system for visualising experiments from plasma physics)
• Damian Rouson (Author), Jim Xia (Author), Xiaofeng Xu (Author), Scientific Software Design: The Object-Oriented Way, 2011 (It covers arguments more close to implementation of algorithms/ Unfortunately, despite the code in C++, it is pretty oriented to FORTRAN)

Other resources come from the paper by the Izaguirre group, and are referenced below.


Further Readings

- Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides: Design Patterns: Elements of Reusable Object-Oriented Software

- Thinking in patterns’ Notes by Bruce Eckel

- [Portland Patterns Repository] - Patterns are the recurring solutions to the problems of design. People learn patterns by seeing them and recall them when need be without a lot of effort. Patterns link together in the mind so that one pattern leads to another and another until familiar problems are solved. That is, patterns form languages, not unlike natural languages, within which the human mind can assemble correct and infinitely varied statements from a small number of elements.

- [The Hillside group on patterns] - Fundamental to any science or engineering discipline is a common vocabulary for expressing its concepts, and a language for relating them together. The goal of patterns within the software community is to create a body of literature to help software developers resolve recurring problems encountered throughout all of software development. Patterns help create a shared language for communicating insight and experience about these problems and their solutions. Formally codifying these solutions and their relationships lets us successfully capture the body of knowledge which defines our understanding of good architectures that meet the needs of their users. Forming a common pattern language for conveying the structures and mechanisms of our architectures allows us to intelligibly reason about them. The primary focus is not so much on technology as it is on creating a culture to document and support sound engineering architecture and design

- [Design Pattern for scientific software] by Dan Gezelter. He pointed to some papers on Design Pattern is scientific computing by the Izaguirre group of which I found [1] and [2]

- Design Patterns in Wikipedia

Improve GEOtop informatics !

I take the occasion of the actual structure of GEOtop main to argue about best practices in programming and introduce the topic of design patterns. For browsing the actual code you can see here , while my more specific comments are available at the GEOtop Developers forum. 

I argued that a much simpler  form for the main, should be represented by a scheme like the following (dots represent missing code, the code is assumed to be C++ - please be merciful with me: my knowledge of C++ details is very limited -  but, the arguments are for every generic language with support of object orientation):

where three main phases are distinguished: an initialization phase (with allocation and initialisation of variables), an execution phase (where the real stuff is done), and a closure phase (where all the memory if freed, and whatever is needed is performed). This best practice is a suggestion that comes from many recent numerical modeling efforts, like ESMF, OpenMI, OMS and allows an encapsulation of the processes in their own part of the project, but everybody, I think, can appreciate its simplicity and cleanness. 

A structure like this should be not very difficult to obtain in a few days of work of a proficient programmer. This structure does not alter the internal of the code and rationalise what is present now, introduce some encapsulation of the procedure,  but IT IS NOT object oriented (OO) programming.

Object oriented programming has to do with the choices of appropriate classes, and instantiation of the appropriate objects, and doing OO design, for implementing the code.

Who is suited to procedural programming, for instance interprets algorithms as “procedure calls”. My view, and understanding of the matter, is instead that procedures should be instantiation of classes, a.k.a. “objects”. Therefore, a proper evolution of the above could be:

In this second case, the organisation of the code remains the same. However the execution of the single procedure is written differently, i.e., for instance:

EnergyBalance.execute( ); 

This is intended to mean that EnergyBalance is an object and .execute() (please notice without arguments) is a method called on this object. One of the advantage of making the each procedure an object, has several argument in its favour. The first is that each object, now, contains its own inputs as fields, and encapsulation is certainly improved. This makes all the code easier to maintain, and the input data for each of the procedures easy to control and parse (out of the time loop, obviously). For a simpler, but a conceptually similar, example in Java, please see here.
Doing this step is not matter of a day, it certainly require more thinking and a sequence of modifications also in the structure of the data containers actually present in GEOtop which propagates down into the inner routines.

In case, also the print( ) method is part of a class, with the rational that with proper software engineering, it can be sent in parallel with the core calculation, on different processors, and therefore, interfering the less possibile with the ‘core’ computational time. I personally bet that, at moment, a consistent part of computational time of GEOtop is wasted in printing to screen data. So, maybe we spent months to have a fast algorithm for finding the solution, and that we use that time saved to put thousands of number on the screen or to write them to disk subtracting power to the computation. 

Actually, the one above is just the beginning of the story. Opening the way to classes, open the way to use some well known  Design Patterns to make the code more maintainable, flexible and evolvable. One case, obvious to all GEOtop aficionados is that, in reality, either the water budget and the other procedures, are a bundle of different alternatives. With OO there exists at least one neat scheme to treat this case, which is called, the “Strategy pattern” where, the object really chosen is one out of a group of options which are implementation of a common interface  (I am going to use the technical OO slang here). So actually, the "main( )" can be programmed to accept a generic type of solution (algorithm) to that problem (as specified by the abstract interface), and eventually this solution can be chosen at run time among the subclasses that implement it.  Solutions can then be added to the code without the need to modify (almost) anything else of the code than just adding a new subclass.

References (you will not find them easy to read ... but take it quietly, cross-check with the web, and something will pass slowly). Besides the basic, also adressed here fro Java, try to give a look to:

Gamma, E; Helm, R.; Johnson, R; Vlissides, J; Design Patterns: Elements of Reusable Object Oriented Software, Addison-Wesley, 1995

Martin Fowler's, UML Distilled: A Brief Guide to the Standard Object Modeling Language, Addison Wesley, 1999

Freeman, Eric T; Elisabeth Robson, Bert Bates, Kathy Sierra (2004). Head First Design Patterns. O'Reilly Media. ISBN 0-596-00712-4

Bruce Eckel, Thinking in patterns', notes. 

Various Authors, Design Pattern,  from Indian Student Association of University of Nebraska at Omaha