The IRIS DMS hosted a three-day workshop in Rolling Meadows, Illinois, in early May to discuss the future of software used in seismological research. During the preparation of the IRIS-2000 proposal, it became apparent that the seismological community wanted assistance with handling seismic data. In the early years of IRIS, typical data sets were small, and most of the analysis tools were home grown. However, the IRIS DMC now collects and distributes gigabytes of seismic data daily, and researchers complain that a great deal of time is being spent de-veloping software systems to manage these data. As a starting point for discussions of software development, the DMS Standing Committee developed a framework called FISSURES (Framework for Integration of Scientific Software for University Research in Earth Sciences). Figure 1 graphically depicts the FISSURES concept; seismic data and derived information such as arrival picks and associations need to be managed and used in a whole suite of analysis, visualization, or data management tools. Currently there is no established protocol for how the data are organized; this is a serious impediment to exchange of data and using disparate tools like SAC and MATSEIS.
The workshop was attended by 40 seismologists and several repre-sentatives from industry with expertise in computer software systems. The first two days of the meeting dealt with brief presentations of seismological experience, data management systems and issues, software tools, and where other software systems are heading. The third day focused on defining the problems seismologists face and how FISSURES might be implemented. There was general agreement that the following were problems:
1. Seismologists do not always know what data descriptions are already available and which descriptions are essential for all processing tools.
2. Since there is no established protocol for both descriptions, seismologists write the same interfaces between data and software over and over.
3. Many data sets are incomplete, or evolve with time, which requires dynamic bookkeeping. Further, there are problems establishing an audit trail that tracks the processing/archiving history.
4. The principal software tools (SAC, MATSEIS, GEOTOOL, etc.) want different seismic descriptions. How can the transfer between tools be optimized?
5. Any change must have some level of "future proofing." The changes in software and programming are rapid, so a data system must be flexible.
Further, there was agreement that the approach for imple-menting FISSURES is to take some simple steps and make something "work."
The FISSURES organizing committee is working on defining some simple seismic objects and will try some simple implementation pilot projects. 