Patching things up

While most Summer of HPC projects involve creating mind-blowing visualisations, the main aim of mine is to edit visualisation software source code. Rather than producing a single impressive visualisation, the outcome will result in easing the process of visualisation for scientists.

VisIt, Open Sourcing and the unavoidable bugs

VisIt is a visualisation software used for presenting data in an intuitive way. It is widely used by scientists, specifically for visualising very large datasets that require using HPC and parallelising tasks.

VisIt is open sourced, which means that anyone is free to look at the source code and modify it. To clarify the latter – one is free to modify the code for his or her own use, however, if one feels he has made an improvement that could greatly benefit the whole community, the modification can be submitted to the main developers of the code in Lawrence Livermore National Laboratory. This is done in a form of a patch – a diff file, containing the differences between your version and the original source code. The so-called “benevolent dictators”  (ie. the main developers) will review and make the final verdict upon all the suggested changes, and if the changes are approved, the patch will be publicly released.

Unfortunately, software development follows Murphy’s laws when it comes to bugs – if a program is useful, it will have to be changed. Note that here I’m referring to bugs not only as a software failing to perform something correctly, but also to the case where an option to perform something is not there (the software failing to have a functionality it is expected to have). The first version of VisIt was released in 2002, while the current version is 2.6.2, and it’s no surprise that new features are continuously added.

The bug

My task involves fixing a few of such bugs/functionality deficiencies. More specifically, I started by modifying the VisIt Java library. While VisIt itself is written in C++, this library allows for using VisIt through a Java program. The biggest problem I set out to tackle was the fact that if the user manually closed VisIt, Java didn’t register it, fruitlessly continuing its communication attempts, and hung, getting no reply.

So, one may wonder why would one want to write a Java library for a software written in C++? You may recall Kepler I have talked about in one of my previous blogposts – a scientific workflow software. Kepler uses actors that are written in Java. One of these is a VisIt Kepler actor, which lets the user visualise the desired dataset with VisIt. That’s where my modifications come in handy – if the VisIt session is closed manually, it is still desirable to be able to open it again, without the stalling the workflow.

VisIt Kepler actor prototype. Kepler is on the left and the VisIt session is on the right, controlled by a customised GUI in the middle.

After editing and re-factoring code, I have added the following functionalities to the VisIt Kepler actor:

1. additional input – the user can now specify more initial parameters, such as the inclusion of GUIs, previous session name, etc.
2. manual closing – the user can now close VisIt and re-open it again
3. session restore – it is now possible to restore a previously saved VisIt session
4. customised Graphical User Interface (GUI) that allows the user to easily control VisIt

The future outlook

Now that I have a working solution, the code must be cleaned up and documented (to make sure there are no unnecessary modifications and other developers can understand what has been done). The final step would be submitting the changes as a patch to VisIt and sending the ready actor to Kepler developers.