Projects

Digg This!

Page 2 of 3   « previous page   next page »

How does PSICAT do this complex task? The first step is to isolate the various components of a core description diagram and analyze each one to identify which "data" it's encoding. This analysis is used to create what PSICAT calls a "model." Each model defines the data it collects and the constraints on how it can be used. For example, a model may have a depth data element that is defined as a floating point number. The model can enforce this constraint by preventing the depth from being set to a non-number. It's vital to properly define the models and their constraints so that PSICAT can extract the data from what the user has drawn.

Since my background is in computer engineering and not geology, this step required me to work closely with scientists like Dr. Chris Fielding, a sedimentologist at the University of Nebraska working with the ANDRILL project. One of the most critical aspects for this interaction to be successful was to find a common language for communication. Each of us has specialized language and domain-specific concepts that we had to make sure we explained to the other. I took this challenge as a great opportunity to learn about a science that I had little experience with. By the end, although not quite an expert, I had picked up enough of the vocabulary and concepts to use them correctly and convince casual observers that I actually had a background in geology. This was invaluable later in the design phase because I was able to say, "This looks a lot like X does it work the same way?"

The modeling step resulted in the creation of a number of models and in two significant realizations. The first realization was that there were many models but they were all essentially independent. An interval of sandstone in the core may contain areas of horizontal laminations, but on the diagram they are represented separately on different parts of the diagram. The interval model doesn't need to know anything about the sedimentary structure models that the user has defined, even if they overlap in depth. The second realization was that different projects, different groups within the same project, and different tasks, all required different features and views of the data. For example, when trying to decide where to sample the core, the group working with microfossils may be interested in seeing the rock type and where trace fossils were found in the core but not necessarily the detailed written descriptions of the core. Later, when interpreting their results, this same group may be interested in seeing all of the data that's been collected, including the descriptions.

It's important to note that while I worked closely with the ANDRILL project to make sure PSICAT would fulfill its needs, it was my intention from the very beginning to create a tool that would be useful to the broader geoscience community. Thus, when designing PSICAT I focused on developing the features that would be useful to the community while still supporting project-, group-, and task-specific customizations. This allows me to reuse most of the code and only replace or customize it where necessary to meet each group's specific needs.

Implementation
The realizations described above factored heavily into my decision to implement PSICAT as an Eclipse Rich Client Platform (RCP) application. The modular plug-in-based architecture of the RCP lent itself well to the independent nature of the models in PSICAT. Each model and its supporting classes could be implemented and tested as an independent set of plug-ins. The RCP also addressed the customization/multiple configuration issue. I could easily create multiple versions of PSICAT, each customized to specific groups or tasks, simply by controlling which plug-ins were included with each version. Another huge advantage of using the Eclipse RCP was the ability to leverage other Eclipse technologies. PSICAT builds extensively on the functionality provided by Eclipse's Graphical Editing Framework (GEF), which allowed PSICAT to get off the ground quickly. I also used the Eclipse Update Manager to distribute updates and new features, something that proved to be immensely useful when PSICAT was deployed in Antarctica.

PSICAT is implemented as four layers built on a core of Eclipse's RCP, GEF, and Update Manager. The first two layers provide the base application and foundation on which the other layers are built. The last two layers implement all of the end-user functionality and project-specific customizations. Each layer is described in more detail below:

• The first layer, closest to the core, is the CHRONOS Modeling Framework. This layer defines the object model and diagram model used by PSICAT and provides services to manage the models, diagrams, resources, and configuration. It contains nothing specific to geology so it can be reused elsewhere.
• The next layer provides the actual PSICAT application and various PSICAT-related services. These services manage depth in the core and user authorization, and provide some basic models that implement common, reusable functionality. This layer also provides the views, editors, and wizards that make up the PSICAT application.
• The third layer consists of two basic types of plug-ins: service plug-ins and column plug-ins. Service plug-ins add new features to the application such as image export functionality and subversion integration. Column plug-ins add the code for capturing and displaying new types of data. Each plug-in generally consists of models for the data being displayed, EditParts for managing the models, figures for displaying the models, and PropertySections to edit the properties of the models.
• The final layer provides project-specific customizations to PSICAT. This includes supplying configuration data and resources for the plug-ins in layer three and implementing any new project-specific column plug-ins.

The current version of PSICAT uses about a dozen Eclipse plug-ins and adds another 40 plug-ins across the four layers. During the development of PSICAT, I adopted the strategy of delivering frequent releases, every two or three weeks, to my test users. Each release was limited in scope, usually including only a few new features or updates to existing features, but the frequent feedback from the scientists made sure that I was headed in the right direction. In the meantime, I could take advantage of the modular nature of the RCP and continue developing new features. (See Figure 1)

Conclusion
Looking back over the whole experience, from the initial conception of the software, through the design phase, to spending three months at the bottom of the world, it has been a truly amazing journey. Working on PSICAT has been challenging from both a programming standpoint as well as from a user interaction perspective. Being able to experience the whole spectrum of software development, from gathering requirements to delivering an application and seeing how the users interact with it, has been extremely instructive and rewarding as a software engineer. PSICAT has transformed the core description process and the interactions between scientists by making the whole process much more efficient and effective. I'm excited to see how it will further enable the future interaction of the ANDRILL scientists with the core data. PSICAT will be returning to Antarctica again in October 2007 for ANDRILL's second drilling expedition.

Resources

• ANDRILL: http://andrill.org
• CHRONOS: http://chronos.org
• Eclipse: www.eclipse.org
• PSICAT: http://portal.chronos.org/psicat-site/
• Josh's blog from Antarctica:
  http://josh-in-antarctica.blogspot.com

Page 2 of 3   « previous page   next page »