CIG/IRIS Workshop Survey Responses

Question 2: What level of computer hardware is required for typical computations using these codes?
The quantum-based computers yet to be invented.

Question 3: In what ways do you currently use these codes and in what ways to you want to use such methods in the future?
I am trying to define the complexity of the sampling problem (that's mathematics).

Question 4: Should we have specific community benchmarks for seismology codes?
n/a

Question 5: What software engineering services or codes would you find most useful for your research needs in the medium and long term?
Codes like Gocad, that allow to define complex models, tectonically realistic.

Question 6: Do you have your own codes that you believe may have broad interest to the computational seismology community and you would consider contributing to a code archive?
n/a

Question 1: What are the primary computationally intensive codes that you currently use in computational seismology and what algorithms are they based on?
Tomography and Ray Tracing codes written in C and Fortran by author developed from codes originally developed in Rob Clayton's group at Caltech - but 1D and 2D not 3D ray tracing

Question 2: What level of computer hardware is required for typical computations using these codes?
Workstation

Question 3: In what ways do you currently use these codes and in what ways to you want to use such methods in the future?
Testing seismic implications of simple mantle circulation models Undertaken whole earth inversions

Question 4: Should we have specific community benchmarks for seismology codes?
Yes, but I am not the best person to suggest the benchmarks

Question 5: What software engineering services or codes would you find most useful for your research needs in the medium and long term?
An easy interface to access online digital data - A code which can model forward propagation in 3D whole earth models - which is easy to install and run on Linux cluster Code(s) with easy interface to allow processing of digital seismograms 3D raytracer Robust tomographic inversion code All the above exist to some degree - but the ease of use and deployment should be increased further; and better documentation

Question 6: Do you have your own codes that you believe may have broad interest to the computational seismology community and you would consider contributing to a code archive?
Probably not of sufficient interest.

Question 1: What are the primary computationally intensive codes that you currently use in computational seismology and what algorithms are they based on?
hypocc, C language, Bruce Julian, hypoDD single-difference (sic) earthquake location (similar to hypoDD, with optimized graph-theory algorithms) simulps12, simul200A, simulDD, Fortran, Cliff Thurber, local-earthquake tomogrephy

Question 2: What level of computer hardware is required for typical computations using these codes?
UNIX workstation (Mac OS X laptop), 1+ Gb, minutes to hours, single processor

Question 3: In what ways do you currently use these codes and in what ways to you want to use such methods in the future?
Don't think I understand the question. I run commands by hand, often controlled by shell scripts to handle many sequential runs.

Question 4: Should we have specific community benchmarks for seismology codes?

Question 5: What software engineering services or codes would you find most useful for your research needs in the medium and long term?

Question 6: Do you have your own codes that you believe may have broad interest to the computational seismology community and you would consider contributing to a code archive?
hypocc, mentioned above, which is substantially faster than hypoDD and fixes several bugs. Needs some polishing. focmec (not Art Snoke's): linear-programming determination of moment-tensor earthquake mechanisms from wave polarities, amplitudes, and amplitude ratios.

Question 1: What are the primary computationally intensive codes that you currently use in computational seismology and what algorithms are they based on?
3D visco-elastic finite-difference modeling (in-house, C++, PVM). 2D and 3D migration. Incorporated in a in-house processing system.

Question 2: What level of computer hardware is required for typical computations using these codes?
Linux workstation, laptop, cluster. Requirements depend on the problem...

Question 3: In what ways do you currently use these codes and in what ways to you want to use such methods in the future?
Modeling teleseismic Receiver Functions and several other problems.

Question 4: Should we have specific community benchmarks for seismology codes?
No. I always have more interesting problems than benchmarking. maybe others feel the same.

Question 5: What software engineering services or codes would you find most useful for your research needs in the medium and long term?
I have been always arguing that IRIS ought to have a development group, beyonf serving trivial data retrieval and display tasks using Java.

Question 6: Do you have your own codes that you believe may have broad interest to the computational seismology community and you would consider contributing to a code archive?
Integrated seismic processing system. About 200 tools. Nearly full capability for reflection and wide-angle data processing, interfaces to GMT, ratinvr, plotmtv. General-purpose database subsystem. Earthquake data I/O filters and a specialized database. Parallelized using PVM. Professional GUI based on Qt. Now potrential-field processing capability and cluster management tools. Automated web documentation. Maintenance utilities. I would like to offer it to the community.

Question 1: What are the primary computationally intensive codes that you currently use in computational seismology and what algorithms are they based on?
(1) Pseudospectral modeling (aelastp, shelastp), Fortran, Cormier (2000) JGR, p.16,193 (2) Fullwave body wave by complex ray parameter integration, Fortran, Cormier and Richards (1988) Seismological Algorithms (3) Gaussian Beams and Dynamic Ray Tracing, Cerveny, (seis81,83, etc), Cerveny's text on Ray Methods in Seismology (4) Locked modes, Fortran, Harvey, GJRAS

Question 2: What level of computer hardware is required for typical computations using these codes?
Pseudospectral -- Beowulf cluster, typically 16 to 64 2 Mhz processors, runtimes 12 to 36 hours Fullwave, WKBJ, Gaussian beams/DRT -- single workstation, runtimes 2 to 20 minutes Locked modes -- single workstation, run times 30 minutes to 10 hours

Question 3: In what ways do you currently use these codes and in what ways to you want to use such methods in the future?
Trial and error modeling to match waveform data; future for 1-D codes: ease model input to allow at least Monte-Carlo type inversions; 2D and 3D codes: better interfaces for model construction, including statistical heterogeneity and generalized boundary topography

Question 4: Should we have specific community benchmarks for seismology codes?
code timing not needed catalog of synthetics for standard earth models from 0 to 180 degrees in freqency band 0.001 to 2 Hz. would be highly valuable product

Question 5: What software engineering services or codes would you find most useful for your research needs in the medium and long term?
grid generators and 2D, 3D interpolators, interface to convert models to different code input formats; catalogue of synthetics in standard earth models

Question 6: Do you have your own codes that you believe may have broad interest to the computational seismology community and you would consider contributing to a code archive?
Pseudospectral code in Fortran, 2**N FFT's equivalent to staggered grid, with attenuation, paralelized with MPI, Cormier, V.F., (2000). D" as a transition in the heterogeneity spectrum of the lowermost mantle., J. Geohys. Res., 105, 16,193-16,205. Full wave code in 1-D earth model, integration in complex ray parameter plane, Langer approximation in thick vertically inhomo layers, Fortran, Cormier, V.F., and P.G. Richards (1988). Spectral synthesis of body waves in Earth models specified by ver

Question 1: What are the primary computationally intensive codes that you currently use in computational seismology and what algorithms are they based on?
SPECFEM3D, FORTRAN90, Jeroen Tromp, Spectral Element Method (both global and basin scale codes), Komatitsch and Tromp, GJI, 139, 806-822, 1999; Komatitsch et al., BSSA, 94, 187-206, 2004. I also work a bit with e3d, an LLNL developed finite difference code, written in C by Shawn Larsen, Larsen, S. and C. Schultz (1995), ELAS3D: 2D/3D elastic finite difference wave propagation code, Lawrence Livermore National Laboratory Report, UCRL-MA-121792.

Question 2: What level of computer hardware is required for typical computations using these codes?
global scale simulations - minimum 150 CPU's, typically runs on large Livermore Computing (LC), resources, such as MCR (1024 node Linux cluster), run times 4-10 hours basin scale simulations - can run on 16 CPU's on a small Linux cluster or large LC resources, for 16 CPU's we can run 0.5 Hz synthetics for the LA Basin in 3-4 hours

Question 3: In what ways do you currently use these codes and in what ways to you want to use such methods in the future?
We are currently running exploratory runs and are working to easily specify our own models in both the global and basin scale codes. We have a wide range of applications for both codes that require user-specified models.

Question 4: Should we have specific community benchmarks for seismology codes?
Yes, having at least one benchmark case with all input and output of a given problem would be helpful to verify that a code is producing the correct result as well as to compare results from different methods. This would also help when codes are migrated to different platforms and/or system software and/or compilers are updated.

Question 5: What software engineering services or codes would you find most useful for your research needs in the medium and long term?
Having a software package that can manage the metadata associated with a run (such as the run time parameters, model, performance, etc...) would be helpful.

Question 6: Do you have your own codes that you believe may have broad interest to the computational seismology community and you would consider contributing to a code archive?
Not currently

Question 1: What are the primary computationally intensive codes that you currently use in computational seismology and what algorithms are they based on?
SPECFEM3D

Question 2: What level of computer hardware is required for typical computations using these codes?
Earth Simulator, 1944 processors, 5 hour cpu time

Question 3: In what ways do you currently use these codes and in what ways to you want to use such methods in the future?
simulate seismic wave propagation

Question 4: Should we have specific community benchmarks for seismology codes?
synthetic seismograms for standard 3D Earth model

Question 5: What software engineering services or codes would you find most useful for your research needs in the medium and long term?
paralellization assistace of programs

Question 6: Do you have your own codes that you believe may have broad interest to the computational seismology community and you would consider contributing to a code archive?
no

Question 1: What are the primary computationally intensive codes that you currently use in computational seismology and what algorithms are they based on?
Code: Language: C++ Author: Brad Aagaard Algorithm: finite-element w/explicit time integration

Question 2: What level of computer hardware is required for typical computations using these codes?
Computers: Linux workstation to Beowulf cluster memory: megabytes to 20 gigabytes run times: 1-6 hrs number of processors: 1-32

Question 3: In what ways do you currently use these codes and in what ways to you want to use such methods in the future?
Currently, I use EqSim for near-source wave propagation (domains up to 200 km x 100 km x 40 km with T > 2 sec) from kinematic and dynamic (spontaneous) finite-fault ruptures.

Question 4: Should we have specific community benchmarks for seismology codes?
A suite of benchmarks would be good. Different benchmarks might target different spatial and temporal resolutions (global, regional, near-field, point source, finite source) and different geometries (strike-slip, dip-slip). It would be helpful if the size of the computations was not extremely large. Perhaps some could even be targeted to run on a workstation. This would enable many different wave propagation codes, etc to be benchmarked.

Question 5: What software engineering services or codes would you find most useful for your research needs in the medium and long term?
Integration of geographic coordinate transformation software into CIG Integration of simple spatial database software (used to specify material properties, boundary conditions, etc)

Question 6: Do you have your own codes that you believe may have broad interest to the computational seismology community and you would consider contributing to a code archive?
I am contributing EqSim to CIG and am in the process of reengineering it to be in the Pyre framework. Its principal features are: * solves 3D wave equation in elastic domain (allowing anelastic behavior is planned) * kinematic and/or dynamic (spontaneous) ruptures * multiple, arbitrarily oriented nonplanar fault surfaces * tetrahedral finite-elements (extension to multiple element types is underway) * integration w/Lithomop (Charles Williams version of Tecton) is underway

Question 1: What are the primary computationally intensive codes that you currently use in computational seismology and what algorithms are they based on?
Code:oneway_omega Auther: Doug Angus Language: FORTRAN (g77) Ref: Angus, Thomson & Pratt, 2004, GJI, 156, 595-614.

Question 2: What level of computer hardware is required for typical computations using these codes?
standard Linux desktop

Question 3: In what ways do you currently use these codes and in what ways to you want to use such methods in the future?
modeling waveforms in complex media

Question 4: Should we have specific community benchmarks for seismology codes?
not certain

Question 5: What software engineering services or codes would you find most useful for your research needs in the medium and long term?
not certain

Question 6: Do you have your own codes that you believe may have broad interest to the computational seismology community and you would consider contributing to a code archive?
My code is still a work in progress and is likely not user-friendly enough.

Question 1: What are the primary computationally intensive codes that you currently use in computational seismology and what algorithms are they based on?
3D anisotropic refraction/reflection tomography code written in Fortran by R. Dunn (Dunn et al., JGR, in press) Uses modified shortest-path ray tracing and lsqr inversion.

Question 2: What level of computer hardware is required for typical computations using these codes?
Linux/Unix workstation for small problems or linux cluster (30 processor) for largest 3D problems. Run times are several hours for one complete solution on a single processor. Memory size is less than 1GB.

Question 3: In what ways do you currently use these codes and in what ways to you want to use such methods in the future?
Used for marine refracrtion/reflection seismic tomography work. Will continue to use in same manner on ever larger 3D experiments (volumes of 250km x 50km x 15 km).

Question 4: Should we have specific community benchmarks for seismology codes?
Performance benchmarks? Not sure what the question is asking here.

Question 5: What software engineering services or codes would you find most useful for your research needs in the medium and long term?
I would like to see lsqr inversion and several different types of ray tracers (whole earth isotropic body wave, local cartesioan grid body wave, whole earth surface wave) that are written in a very low-level language and that can be called as a function in a fortran code. I.e. something like "SeisPack" could be developed that included these things and that would be a library that is linked to the fortran code during compile time. Such library codes run much, much faster than compiled codes.

Question 6: Do you have your own codes that you believe may have broad interest to the computational seismology community and you would consider contributing to a code archive?
3D refraction/reflection tomography code written in Fortran (Dunn et al., JGR, in press). It would require some support to put it into a usable form.

Question 1: What are the primary computationally intensive codes that you currently use in computational seismology and what algorithms are they based on?
Reflectivity based on Kennett's recursive matrix formulation, written in Fortran, by G.E. Randall. Mode Synthetics written in Fortran by Bob Herrmann. Trying to establish work with SEM code in Fortran by Tromp.

Question 2: What level of computer hardware is required for typical computations using these codes?
Unix workstations (including Macs) alone or in networked informal clusters. Memory typically 1+ Gbytes, 2 processors per box. Run times from minutes to hours.

Question 3: In what ways do you currently use these codes and in what ways to you want to use such methods in the future?
Currently use codes for moment tensor source estimation and inversion for earth structure with 1D models. We need to develop codes and experience to perform these analyses in more complex realistic 3D structures.

Question 4: Should we have specific community benchmarks for seismology codes?
Benchmarks for code verification (accuracy) as well as speed are essential. We need to validate new codes with a common set of benchmarks for standard problems and expand the set of benchmarks to more complex problems. Then we can assess efficiency and accuracy.

Question 5: What software engineering services or codes would you find most useful for your research needs in the medium and long term?
Source code control, standard seismogram and spectral file formats, strong IDE's for Fortran and C/C++, strong debuggers with array inspection/plotting

Question 6: Do you have your own codes that you believe may have broad interest to the computational seismology community and you would consider contributing to a code archive?
Reflectivity based on Kennett's recursive matrix formulation, written in Fortran, by G.E. Randall. I need to go through a formal code release process here.

Question 1: What are the primary computationally intensive codes that you currently use in computational seismology and what algorithms are they based on?
E3D, C, Shawn Larsen of LLNL, 3D elastic finite difference, Larsen, S. et al. (2001 SEG). ModelAssembler, C, John Louie, interpolation and gridding from geological data, Louie, J. N. et al. (2005 SSA).

Question 2: What level of computer hardware is required for typical computations using these codes?
UNIX workstation is OK for tests and code development. Real problems run on small to large Beowulf clusters.

Question 3: In what ways do you currently use these codes and in what ways to you want to use such methods in the future?
I have created ModelAssembler as a pre-processor for E3D, and am getting the combination working on the web portal of the NSF-funded Nevada Environmental Computing Grid. If I can create an effective enough portal package, I hope to get colleagues worldwide computing sytnthetic seismograms, up to 5 Hz, for Nevada problems.

Question 4: Should we have specific community benchmarks for seismology codes?
It is essential that Shawn Larsen has already participated in the SCEC "shoot-outs" with E3D, where several codes were vetted against each other.

Question 5: What software engineering services or codes would you find most useful for your research needs in the medium and long term?
The NSF EPSCoR-funded ACES program (www.aces.dri.edu) has been very helpful in creating the computing grid, and parallelizing other codes. But that grant has run out, and development of the web portal to the Grid was thinly staffed. We need a longer-term solution for developing Grid portals. Also, Larsen can no longer maintain E3D, and while LLNL has assembled a team to update E3D, their long-term support abilities are not proven. Need development of GUIs for MA/E3D.

Question 6: Do you have your own codes that you believe may have broad interest to the computational seismology community and you would consider contributing to a code archive?
JRG for visualization of synthetics and models- and some reflection processing www.seismo.unr.edu/jrg, Java (any platform), Louie, already available from IRIS. ModelAssembler for 3D grid creation from geological data, C, Louie, built for setting up finite-difference input, www.seismo.unr.edu/geothermal , available as a portal package now but needs GUI development.