My CV and Five Papers that represent me

For who it may concern, I am posting my up-to-date CV here. It collects what I did,  and contains information already present here (where, in addition, you have a link to the papers).

For a shorter version of my CV, please take this.
If I would asked to choose five papers that more represent my work (and me), they would be not the most cited (among them), not those in Journals with the highest impact (well ... among them), and I would select probably:

• Rinaldo, A., A. Marani and R. Rigon, Geomorphological dispersion, Water Resources Research, 27(4), 513-525, 1991
• Rodriguez-Iturbe, I. , A. Rinaldo, R. Rigon, R. L. Bras, A. Marani and E.J. Ijjasz-Vasquez, Energy dissipation, runoff production, and the 3-dimensional structure of river basin, Water Resources Research, (28)4, 1095-1103, 1992.
• Rigon R., Bertoldi G e T. M. Over, GEOtop: A distributed hydrological model with coupled water and energy budgets, Journal of Hydrometeorology, Vol. 7, No. 3, pages 371-388, 2006
• M. Dall’Amico, S. Endrizzi, S. Gruber, and R. Rigon, A robust and energy-conserving model of freezing variably-saturated soil, The Cryosphere, 5, 469-484, 2011, doi:10.5194/tc-5-469-2011
• Formetta G., Antonello A., Franceschi S., David O., and Rigon R., Hydrological modelling with components: A GIS-based open-source framework, Environmental Modelling & Software, 5 (2014), 190-200

Obviously I did decent work also between 1992 and 2006. Enjoy!

For 5 more recent papers, representing the decade 2015 to 2024 please see here. 

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
 

Installing GEOtop 2.0 on Mac OS X

I receive from Matteo Dall'Amico and I publish the following instruction to compile GEOtop 2.0 on Mac OS X. For Linux see this other post.  Now, actually, there is a more recent guide that you can find here. Refer to this one just in case of problems.

# Install the following packages (or verify you have them already):

#Install and compile MeteoIO libraries.

This will include to install the Developers tools,  Homebrew and other required libraries. See instructions here

#Check if you have git, otherwise install
brew install git

#Install libraries

brew install pkg-config
brew install boost

# download GEOtop
git clone https://code.google.com/p/geotop/

# create the makefile

If you do not have installed before, from CMake website. When you start it a window as the one below appears:

Please, observe that, on top the path to source code has been specified, and just below, the path to binaries. click the Configure button to configure the Cmake. If not already present, add the path to MeteoIO libraires: /usr/local. After configuration, the screen should appear as below:

To process the file, Press Generate. This will generate, in the directory (folder) selected for binaries, the Makefile

# make the project

In terminal cd to the directories were binaries will be created anc check if the Makefile is present. Issue the command:

$ make

# copy either using Finder Window or Terminal commands the binaries files generated to a standard place.

I chose "/usr/local/GEOtop".

This directory is actually not a standard one, However, I placed a symbolic link into /usr/local/bin, which is a directory usually already present in the Terminal path.

$cd /usr/local/bin

$ln -s ../GEOtop/geotop geotop

#try geotop example. Due to previous operation

cd to the directory (folder) tests/test_sample_run/small_example (for instance this, among the others)

Issue:

$ geotop ./

If you did it well and the goddess of programmers assisted you, it should work, as it did for me.

Installing meteoIO on Mac OS

Matteo Dall'Amico (see previous post on GEOtop installation) also provided instructions for compiling MeteoIO on Mac and Linux). While Mac instructions can be found in this post, Linux instructions can be seen in a previous post

# Check the environment compiler: You are suppose to have installed the appropriate Developers tools (search for them in the App store). Be sure that you also download the command line tools.

#For Mac OS use Homebrew  (which needs to be installed first)
#Then write at the console, for instance for Make:
brew install make

#For any other package:
brew install subversion
brew install gdal
brew install proj
brew install doxygen

#install CMake from CMake website

# After having selected your directory for installing meteoIO libraries with the usual console commands
# download the source code from the SVN:

svn co https://models.slf.ch/svn/meteoio/trunk
#Start Cmake and a window like the one below will appear:

# Please observe that you have to indicate the directory (folder) where the source code is
# and the directory where you want the binaries. Is in this directory that the Makefile will be produced
#Click on Configure and a window like the following should appear:

#Please note that you can modify the flags just clicking on them. Be sure that you have also checked the proj.  The following fields should be "ON"


BUILD_SHARED_LIBS
PLUGIN_A3DIO
PLUGIN_ARCIO
PLUGING_ARPSIO
PLUGIN_GEOTOPIO
PLUGIN_GRASSIO
PLUGIN_PGMIO
PLUGIN_SMETIO
PLUGIN_SNIO
PROJ4 (then you have to verify the paths to LIBPROJ and to LIBPROJ_INCLUDE_DIR)

All the rest can be set to "OFF".

# Then, press  the butto to generate the makefile and exit from the console.

# In the terminal, goes in the directory where you create the Makefile and type:

make install

# (with "sudo" if you want to install it as super user).

Now move the libraries into /usr/local/lib.  They shoud be libmeteoio.2.4.3.dylib and the two symbolic links: libmeteoio.2.dylib and libmeteoio.dylib

After having installed meteoIO, in the needs to understand what it does, one can browse the examples in the "doc" directory. However, s/he can also built the doxygen documentation. For doing it, please first check you have doxygen installed. Subsequently:

• using a terminal move to the directory where the meteoIo source code is located. 
• execute "doxygen -g <configfile>" to create a configuration file, "configfile" for the project
• execute doxygen <configfile> to create the documentation
• Find the documentation in a new html directory created
• Access it by clicking on the index.html file

Atlas of Mortality and Economic Losses from Weather, Climate, and Water Extremes (1970-2012)

With the limits that these large scale project have, which is neglecting most of the micro-phenomena, as small landslides, that causes huge economical losses, and several life losses, this is, however, a reference to keep in mind when talking about climate related hazards.

It was produced by WMO and it is available here. As it reports in introduction:
"Weather, climate and water-related disasters are on the rise worldwide, causing loss of life and setting back economic and social development by years, if not decades. From 1970 to 2012, 8 835 disasters, 1.94 million deaths, and US$ 2.4 trillion of economic losses were reported globally as a result of hazards such as droughts, extreme temperatures, floods, tropical cyclones and related health epidemics, according to a new report."

New Course on statistics and data inference on Coursera

Verbatim from DataCamp Blog:

" Yesterday (Monday 1st of September), a new session of Data Analysis and Statistical Inference, taught by Doctor Mine Çetinkaya-Rundel from Duke university, has started on Coursera. Just like with the previous run, all labs take place in DataCamp’s interactive learning environment.

Data Analysis and Statistical Inference will teach you how to make use of data in the face of uncertainty. Throughout the course, you will learn how to collect, analyze, and use data to make inferences and conclusions about real world phenomena. No formal background is required, but mathematical skills are definitely a plus."

Further information here.

Compiling GEOtop with Eclipse (on Mac)

[The three  operations below are in common with the compilation of GEOtop by using a makefile, and they are better described here in a previous post]

1- Follow the instructions to install meteoIO. Install and compile it. 

This create the dynamic libraries to be linked to GEOtop. Saving the libraries in a “standard place” could be useful. The other information to annotate is the position of the meteo include files (/usr/local/include, at least under Mac OS) since Eclipse needs them to compile the code.

2 - Install the boost libraries

3 - Download GEOtop from the Git:

[The above operations are in common with the compilation of GEOtop by using a makefile, here]

4 - Set up the Eclipse project^1 

Select:

File -> New -> C++ Project 

Then follow instructions from the pop-up window. If you never did it before, you better think, to browse Eclipse on-line help. 

Next you have to indicate the path of the meteoio libraries and includes. These are not the only one includes that are supposed to be made visibile, as you will learn below. 

Right click on the project. From the menu, select ‘Properties’. A pop-up window will appear. Select and open (clicking on the triangle) the C/C++ General Menu. Go and select ‘Path and Symbols’. On the right side of the pop-up window will appear. The window presents several button. The ones important for us are the ‘Include’ button and the ‘Libraries *’ buttons. 

If you click on ‘Includes’, a selection of languages will be shown. Select GNU C++ (that’s my case). Click on the ‘Add’ button at the right side of the window for adding libraries. A further pop-up menu will appear.

Select the ‘File System’ button. This will drive you to the selection of the directory you need.

Repeat the operation all the times it is required. 

Subsequently, always in the same pop-up menu, click on ‘Libraries’. Click on ‘Add’ and add the names of the libraries required: meteoio, meteoio.2.4.3, meteoio.2. These names correspond to the files called lib*.dylib where the ‘*’ stands for the name of the library required. Repeat the operation for each one of the libraries name. [I do not think it is necessary to link all the three libraries, since the real library is one. The others are symbolic links. However, I did not experimented differently]. 

Third, go back on the Path and Symbols window, and select ‘Libraries Paths’. With the same type of procedures as before, please add the path to the libraries. 

Then, you have to import manually the file into Eclipse. GEOtop “core” related files are contained in the root folder of the project, i.e. only the file ‘config.h’, and in the directory: ‘geotop’, ‘gt_utilities’, ‘libraries’, ‘meteoio_plugin’. Directory (folder) ‘libraries’ has two subdirectories (subfolders): ‘ascii’ and ‘fluidturtle’.  Therefore, these directories needed to be created inside the just created GEOtop folder:

File -> New -> Folder, as it appears in the Figure below

Now, what you have to do is to populate the folders with the files:

Right click on the folder in the Project Explorer -> Select Import, and the following window will appear:

Select ‘File System’, and then ‘Next’. Then follow the instructions. Clicking on the ‘Browse’ button a pop-up window will guide you. 

Another operation to consider is that some include files in the code were declared with < > instead than  “ “. This implies that these includes are recognised as “system include” or of this type. Therefore the path to these include has to be added to the project. This addition works the same way as in point #4. The files of which we are talking about  are 'inputKeywords.h' and  'config.h' that has to be added since it has been place directly in the root directory. [ I am not sure that this is necessary but, at the moment, I could not find a better solution. ]

Now you should be almost done. Just

5 - Build and Compile.  [To do it, get the instructions here. When I did it, I got a conflict in linking which was solved by observing that there were some duplicate classes. I just cancelled:part_snow.cc and part_snow.h from the project]

_________________________________________________________________________________

^1 - One would probably get the project directly inside Eclipse using Egit. This is not an option at moment. But I am thinking to create a clone of the git from where it will be possible. In meanwhile, you can get the project from here.