1.
What methodologies are you primarily using for your research/data modelling:
| Ray theory/Gaussian beams |
   37.0% |
(20) |
| Normal modes |
11.1% |
(6) |
| Reflectivity method |
35.2% |
(19) |
| Numerical approaches (finite differences, elements, volumes, pseudospectral, etc) |
64.8% |
(35) |
| Other: GEMINI |
1.9% |
(1) |
| Other: Gemini |
1.9% |
(1) |
| Other: Monte-Carlo simulations of energy propagation |
1.9% |
(1) |
| Other: PROMAX |
1.9% |
(1) |
| Other: stochastic simulation |
1.9% |
(1) |
| Other: stochastic, EGF |
1.9% |
(1) |
| Other: wavelet analyse |
1.9% |
(1) |
|
2.
What computationally intensive methodologies are you using?
| Finite differences |
59.3% |
(32) |
| Finite/spectral elements |
16.7% |
(9) |
| Finite volumes |
9.3% |
(5) |
| Pseudo-spectral method |
9.3% |
(5) |
| Particle methods |
7.4% |
(4) |
| Hybrid approaches |
|
(0) |
| Other: ADER-DG |
1.9% |
(1) |
| Other: FD and scattering methods in future projects |
1.9% |
(1) |
| Other: Genetic algorithms for inversion |
1.9% |
(1) |
| Other: inversion |
1.9% |
(1) |
| Other: Multiple scattering, mode coupling |
1.9% |
(1) |
| Other: none |
1.9% |
(1) |
| Other: Reflection Tomography and migration |
1.9% |
(1) |
| Other: Runge-Kutta; SVD |
1.9% |
(1) |
| Other: spectral methods |
1.9% |
(1) |
|
3.
Are you developing or using parallel algorithms?
| Developing |
27.8% |
(15) |
| Using |
42.6% |
(23) |
| Neither |
22.2% |
(12) |
| TOTAL |
92.6% |
54 |
|
|
4.
Do you have professional software engineering support for your developments?
| Yes |
5.6% |
(3) |
| Partly |
14.8% |
(8) |
| No |
72.2% |
(39) |
| TOTAL |
92.6% |
54 |
|
5.
Are you using High-Performance Computing (HPC) Hardware?
| No access |
13.0% |
(7) |
| PC-Cluster |
44.4% |
(24) |
| Supercomputer |
46.3% |
(25) |
| Other: I have access to HPC but am not using it |
1.9% |
(1) |
| Other: Not yet |
1.9% |
(1) |
| Other: SUN servers & workstations |
1.9% |
(1) |
|
6.
Where is the HPC hardware located?
| Local (e.g., at your department) |
51.9% |
(28) |
| Local Supercomputer Centre |
33.3% |
(18) |
| National Supercomputer Centre |
25.9% |
(14) |
| GRID Access (e.g., DEISA) |
1.9% |
(1) |
| Other: n.a. |
1.9% |
(1) |
|
7.
How much RAM do your “standard” applications require at present?
| 1 GByte |
33.3% |
(18) |
| 10 GByte |
42.6% |
(23) |
| 100 GByte |
22.2% |
(12) |
| 1 TByte |
3.7% |
(2) |
| Other: 4 GByte |
1.9% |
(1) |
| Other: 60 |
1.9% |
(1) |
| Other: < 1GByte |
1.9% |
(1) |
|
|
8.
Would you make use of and benefit from engineered (benchmarked, version-controlled,
multi-platform, optimised, interfaced) seismological applications in a common software
environment (examples see questions 1+2)?
| Yes |
57.4% |
(31) |
| Partly |
24.1% |
(13) |
| No |
9.3% |
(5) |
| TOTAL |
90.7% |
54 |
|
9.
Would you make us of and benefit from easy (i.e. hidden) access to parallel computational
resources through web interfaces for specific cpu-rich scientific applications (e.g.,
seismograms for 3-D reference models, wave fields for data modelling, etc.)?
| Yes |
59.3% |
(32) |
| Partly |
22.2% |
(12) |
| No |
11.1% |
(6) |
| TOTAL |
92.6% |
54 |
|
10.
Would you be able to provide computational algorithms for an Earth Science software
library?
| Yes |
55.6% |
(30) |
| No |
35.2% |
(19) |
| TOTAL |
90.7% |
54 |
|
|
11.
What other software/applications should be provided/maintained within an Earth Science
software library?
| Grid generation |
50.0% |
(27) |
| Visualization |
70.4% |
(38) |
| Processing |
44.4% |
(24) |
| Model and data format specifications/converters |
72.2% |
(39) |
| Other: any kind of seismological software tools, for example, petrophysical modelling, elastic tensor data base |
1.9% |
(1) |
| Other: imaging/inversion algorithms |
1.9% |
(1) |
| Other: inverison, 3D event location |
1.9% |
(1) |
| Other: inversion routines e.g. waveform inversion, genetic algorithms |
1.9% |
(1) |
| Other: numerical library for coordinate-type independent PDE |
1.9% |
(1) |
| Other: Receiver Functions, seismic anisotropy, |
1.9% |
(1) |
| Other:
time series analysis in a way that is prsented in small modules and
extendable by the user due to standardized data structure interfaces |
1.9% |
(1) |
| Other: updated seismometer transfer function info |
1.9% |
(1) |
|
12.
Should seismological software be connectable to other areas/applications (e.g.,
geodynamics, crustal deformation, geophysical fluid flows, etc) for example through
common model specifications etc. ?
| Yes |
55.6% |
(30) |
| Partly |
33.3% |
(18) |
| No |
3.7% |
(2) |
| TOTAL |
92.6% |
54 |
|
13.
Would you participate in training courses offered in connection with Earth science
simulation software/High Performance Computing?
| Yes |
83.3% |
(45) |
| No |
7.4% |
(4) |
| TOTAL |
90.7% |
54 |
|
|
14.
Please indicate your level?
| Undergraduate student |
1.9% |
(1) |
| PhD student |
25.9% |
(14) |
| Postdoc |
14.8% |
(8) |
| Staff scientist |
31.5% |
(17) |
| Professor |
18.5% |
(10) |
| TOTAL |
92.6% |
54 |
|
15.
Please provide any further comments/suggestions, e.g., by referring to specific questions, topics, etc.
| # |
Response |
| 1 |
100% support for this initiative |
| 1 |
A tool for phase identification in full waveform synthetics would be good to have.
In the moment my research would benefit most from spherical Earth, full waveofrm seismograms
for the extended source in 3D. |
| 1 |
earthquake
location in 3D media with quick access to 3D ray tracing for the whole
spectrum of seismic phases would be very interesting. |
| 1 |
For my
research projects there are no canned solutions available yet. Hence I
plan to write my own new code or else adopt an existing one. |
| 1 |
I think
it is very important to exchange synthetic data in a simple and robust
way. Scientific exchange between the computational and "real"
seismologist would be much easier if the computational community would
adapt standards for data storage and exchange which where developed in
the "real"-data world. I am thinking of standards/protocols like
SeedLink and ArcLink. |
| 1 |
It is
really necessary for the seismology community to develop a new
software-package. The existing ones are really old-fashioned and far
away from an intuitive handling. It would be great if the software
would have a nice graphic interface, from which I e.g. could cut
time-series, make rotations, filtering, calculate the eigenvalues of
covariance matrix, calculate receiver functions, making plots etc. As
Luther-King said: I had a dream... Maybe that dream becomes true for
seismology. |
| 1 |
Library should include imaging/migration/inversion algorithms
(for active and passive seismic data sets), e.g. waveform inversion,
PSDM, event location techniques, etc. |
| 1 |
numerical
library for combined FD-FV-FE (partly or shared) useful for research;
seismic wave propagation on poro-thermo-visco-elastic media; |
| 1 |
On top of creating an e-infrastructure more effort should be made to build stronger links between modellers and observers! |
| 1 |
Our group at the Technical University Freiberg is devloping Finite-Difference Modelling codes
that are applied for reflection seismic modelling and imaging (e.g. tunnel seismics, borehole seismics) . The current main focus
is on 2-D/3-D time domain full waveform tomography for viscoelastic media.
We could provide parallel FD MPI codes (2-D, 2.5-D and 3-D) to a Earth Science library. |
| 1 |
some of
my opinions:
- professional (software engineering) support would be highly desirable
for the development, maintenance and sharing of scientific software
- if possible, this should be organized within the community with free
licenses since young researchers have to rely on transfering their
software solutions from one research place to another (e.g. on the
opposite: the license model of Matlab is an obstacle)
- software should be provided in small modules that can easily be
extended; for research work it will always be essential to extend
existing software; monolithic solutions are only useful for routine
work; I prefer concepts like used in SeismicUnix
- software libraries are most useful if they are not restricted (by
implementation) to one specific area (e.g. normal mode calculation can
not only be used in global seismology but is also needed in shallow
seismic studies)
- seismologists are used to share their software since many years now,
but most of the code is only sparsely documented, has undergone several
stages of modifications by different researchers, use incompatible data
or parameter formats, etc.; to improve this situation is only possible
by a permanent and long-term support and maintenance by software
engineers
- due to the rapidly evolving hardware, highly complex algorithms (e.g.
to calculate wavefield partial derivatives) will become more and more
applicable in routine applications
- remote access computing facilities will only be useful if high
bandwidth data transmission is provided as well |
|
Forgot your password?