In the past, Sergey has proposed several times getting a Madagascar application for the Google Summer of Code (GSOC).
I do not know about other people’s reasons, but I refrained from making suggestions because I had doubts about the chances of success, due to the extremely high specialization of Madagascar, and the fact that GSOC tends to sponsor projects with wide applicability.
Madagascar attempts to provide a complete technology solution for the seismic imaging researcher, and is quite good at that. It is of course extensible to other applications, but most people who do not need the complete Madagascar stack (being either outside the field, or non-researchers) have difficulties understanding the parts and separating only what they need. Needing resources, the Madagascar project finds itself oscillating between:
– trying to expand its scope to fit as many needs at possible (only to discover the increased complexity, fragility and number of dependencies that come with that), and
– focusing on its highly specialized task that it does well, but then discovering that the number of seismic imaging researchers is incredibly small, and how that limits resources seriously.
There is however a deep core concept of Madagascar that has a very wide applicability: the fact that the RSF data format is an out-of-core extension of arrays in memory. Combining together Madagascar programs through a shell or Python script is essentially the same thing as writing a compiled program that calls procedures to act on arrays. It works on datasets too large to fit in memory, but small enough that it is not necessary to transition to a flow-based architecture, in which the memory is allocated only once, and subroutines called successively to act on it. It has its own niche.
How about then, proposing a GSOC project for 2012 to create Madagascar wrappers for the GNU Scientific Library and/or for ATLAS? With OpenMP threading and parallel I/O, to fully use the power of modern multicore architectures. That would be of immediate interest to a very large number of people. So large actually that it may be the case to spin this off as a separate sourceforge project — depending only on the rsflib I/O core. Then we’ll let the mathematicians take care of that project, and as a bonus, we will be able to use the already-existing GSL/ATLAS documentation to know what the similarly-named driver programs are doing! Double bonus, we may get to get rid of some of the current programs which duplicate functionality existing in widely-used packages. Triple bonus, this may lead some people to write Python scripts instead of monolithic driver programs, and this is a Good Thing.
What does the community think?
Nick, this looks like a great idea. If you ask me, Madagascar would be a tremendous success if it only wrapped other packages into a single coherent framework with a shared data format, because nothing like that exists (mind boggling considering its 2011). The closest anyone has come so far is Python with Numpy/Scipy or SAGE, but both of those approaches have serious pitfalls.
To attract individuals from other fields, I think we need to do the following:
1 – Improve our documentation. Madagascar needs to be easy to learn (or at least easier than the alternatives).
2 – Wrap key scientific packages, such as GSL, surfit, and others so that core functionality is present. Perhaps we should make a list of such packages, and start working on them?
3 – Identify commonly used data formats in other fields, and either wrap libraries for conversion to RSF, or create programs to convert to/from RSF.
4 – Identify and wrap dominant packages in other fields.
There are some technical issues associated with doing this, for example, we’d have to make our build system much more modular than it currently is, and make it easier for individuals to get all of the requisite dependencies for these packages. But, the hard work (language APIs) is already done, which means this should not be terrible to do.
If we did this then Madagascar would pick up a lot of momentum! It could turn into a one-stop shop for scientific computing.
Perhaps this should be our long-term goal for Madagascar (i.e. Madagascar 2.0).
Jeff,
Three goals were identified for Madagascar-2.0:
https://reproducibility.org/wikilocal/docs/houston.pdf
1. High-performance computing (already done but needs clear examples)
2. Seismic ?eld data processing examples
3. Applications beyond seismic
Whichever goal is reached first can trigger a new major release. What Nick is proposing relates to Goal 3.
Nick,
We did apply for Google Summer of Code in 2009, but the application was denied:
http://www.reproducibility.org/wiki/GSOC2009
Interestingly, some of the suggested projects have been implemented, even without Google’s support. Jeff’s tkMadagascar (sfgui), for example, implements one of the items on my list.
Please feel free to clone and update this page for application to GSOC2012.