Near-Term Goals
Please not that there is no way to achieve everything here anytime soon, so priorities will be set according to funding
1) Officially Release Applications - Right now all applications are in beta mode, in part because it's not exactly clear what an "official release" means in terms of liability and licensing issues (exacerbated by the fact that OpenSHA constitutes a collaboration between government and academia).
2) Source code Release and Establish Email Lists - For communication between developers, users, and management. Making the source code available to community via SourceForge where users can submit bugs and suggestions.
3) Collaborate with CyberShake - Expand on our existing tools for processing and analyzing their results (CyberShake involves full PSHA calculations based on 3D waveform modeling rather than using empirical attenuation relationships).
4) Collaborate with CSEP - SCEC's Center for the Study of Earthquake Predictability (CSEP) will be an infrastructure for testing earthquake forecasts and predictions. Our involvement will not likely be in terms of helping develop the computational infrastructure, as they appear to be going with a C++ implementation, but rather to ensure interoperability (e.g., a forecast model can be plugged into our system for PSHA or their system for testing). Develop tools for them using the OpenSHA components.
5) Collaborate with Risk-Analysis Efforts:
6) Continue the WGCEP Development of a Uniform California Earthquake Rupture Forecast (UCERF):
A goal of the ongoing WGCEP has been to build a living, adaptive, and extensible model that can be updated as we collect more data, make scientific progress, or following a large, significant earthquake. This living model has been constructed using OpenSHA components, and includes interoperability with various database elements (real-time access over the internet). Future goals with respect to this project include:
7) Java Implementation of STEP (the USGS 24-Hour Aftershock Hazard Map - We have worked with Matt Gerstenberger to port his Matlab based code to Java while simultaneously defining and implementing generic components that can be used by others (e.g., for the clustering component of the WGCEP model). This is nearly completed, but finding the time to finish it off in the midst of competing efforts is difficult.
8) Implement NSHMP's Countrywide Models - Only those for California are presently implemented in OpenSHA.
9) Help Implement Non-US Models - We often get inquires from individuals in other countries that are interested in implementing their models in OpenSHA (e.g., Mark Stirling from New Zealand, Laura Paruzza and Bruno Pace from Italy, John Douglas from France, Ulrich Wegler from Germany, Tamaz Chelidze from Georgia, and others). Implementing other models currently requires Java programming, which we understand constitutes a considerable impediment to most potential users. Therefore, what we need is to define standard input files that can be used without modifying existing codes (although this will necessarily limit the number of bells and whistles).
10) Develop Standardized Input Files - OpenSHA requires that each model or data component be implemented (or wrapped) as a Java object (which enables one of greatest strengths of OpenSHA - distributed computing, where models, databases, and computational resources can be distributed over the Internet and accessed at runtime). However, we understand that many users will not want to have to create a Java object themselves in order to perform a calculation. The solution is to define ASCII- or XML-based input files that can be read and interpreted by our code. The challenge will be defining a minimum set of standard input files that can accommodate a range of model types (without becoming more complex than just writing Java code). We would like to coordinate such input-file standardization with the USGS National Seismic Hazard Mapping program in Golden.
11) Create User Manuals and Tutorials for Our Applications - Some presently exist (here's and example), but more are needed. This activity is particularly time consuming, and not a top priority given our necessity to focus on what will sustain funding for the effort (people or more willing to pay us to solve their specific problem than to write user manuals to help others solve their problems).
12) Create User Manuals and Tutorials for Code Development - These would allow easier entry for those interested in understanding or contributing to the Java code. Although the individual Java objects are pretty well documented (e.g., the Java Docs and our Glossary), we don't have documents that give specific "big picture" details (other than our Brief Overview and Publications). Therefore, we presently work with individuals on a case-by-case basis to bring them up to speed (e.g., Matt Gerstenberger and Eric Martinez are two recent examples). This approach is not efficient and therefore impedes the creation of a genuine "community" development. Solving this will take considerable resources, and will come at the expense of other activities (which, again, may not be consistent with maintaining financial support).
13) Convert this Web Site to a Wiki - Enabling the "community" to contribute to the Documentation, which would presumably increase both its volume and quality.
14) Develop Educational Tools - These would facilitate learning PSHA both in and out of the classroom. Jon Stewart, Jack Baker, and others have expressed interest in this.
15) Finish PEER's PSHA Verification Test Cases - If and when they get that project back on track. In addition to implementing the test cases, we have also developed web/GUI-based applications that allow anyone to submit and compare their results.
16) Implement Vector-Valued PSHA - Both Hong Kie Thio and Paolo Bazzurro have received SCEC funding for this (separately).
17) Implement Attenuation Relationships for Other IMTs - Allin Cornell has expressed interest in those for Nonlinear Spectral Acceleration, and Jack Baker has expressed interest in having Spectral Acceleration results averaged over a range of periods.
18) Implement Other Site-Response Modules - There is interest in applying alternative, more sophisticated site-reponse modules to existing attenuation relationships. We have already implemented some in collaboration with Jon Stewart, Christine Goulet, and Paolo Bazzurro, and there is desire to have more.
19) Worldwide PSHA Model - Ross Stein and Domenico Giardini are currently exploring the feasibility of this (an effort like GSHAP, but resulting in a living model rather than just a static map), and both have expressed a strong interest in using OpenSHA as the computational platform.
20) Open Sourcing & Licensing - The code is currently available to anyone that requests it, but this requires setting up a user account and password. Alternatively, we may want to host the code on something like SourceForge.net. This would require defining some kind of license agreement, and we don't currently know what this would involve given the present collaboration between academia (USC) and government (USGS).
21) Broadening the Developer Base - Right now there are a few core individuals developing and maintaining the code, whereas we would like to make this more of a community effort. However, it's not clear how to achieve this in terms of the required infrastructure, maintenance, and financial backing.
22) High Performance PSHA Calculations - Calculating full PSHA maps is very computationally demanding. Our current solution involves utilizing the Condor GRID at USC (e.g., see Field et al., 2005c). However, alternative approaches will be needed for those who do not have access to this resource.
23) Improve Visualization Tools - we currently use GMT for making maps and SCEC VDO for 3-D visualization (the latter developed as part of the SCEC UseIT intern program). However, we'd also like to explore the usefulness of GIS- and Google-Earth-based tools.
24) Implement PAGER's Worldwide Vs30 from Topographic Slope Model - anabling the inclusion of site effects for calculations anywhere in the world.
25) Support Physics-Based Earthquake Simulations - Work with Jim Dieterich, John Rundle, Steve Ward, and others to support their development and analysis of physics-base earthquake simulations (some of us believe these models represent the future of earthquake forecasting). In addition to providing them with input data/models (e.g., faults and slip rates) we would like to develop generic data-mining tools for analyzing simulation results (e.g., to explore implied recurrence intervals and aperiodicities).