Pith. sign in

REVIEW 4 major objections 5 minor 84 references

An Event-Driven Approach to Serverless Seismic Imaging in the Cloud

T0 review · 4 major / 5 minor · reviewed 2026-08-14 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read The paper claims that re-expressing seismic imaging as a serverless, event-driven MapReduce workflow eliminates idle-instance cost and makes the cloud a viable alternative to on-premise HPC clusters.

desk verdict A real, measured event-driven AWS workflow for seismic imaging whose scaling and resilience results stand, but whose headline cost savings rest on an unverified billing assumption that needs correction before the 'viable alternative to on-premise' claim is credible. read the letter →

arxiv 1909.01279 v1 pith:HMD4YJMA submitted 2019-09-03 cs.DC physics.geo-ph

Philipp A. Witte , Mathias Louboutin , Henryk Modzelewski , Charles Jones , James Selvage , Felix J. Herrmann This is my paper · ORCID
classification cs.DCphysics.geo-ph
keywords serverlesscomputingseismicimagingleast-squaresreversetimemigrationAWSBatchevent-drivenworkflowsMapReducecloudHPCdomaindecomposition
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper argues that the usual way of moving high-performance computing to the cloud, recreating an on-premise cluster out of virtual machines, fails for seismic imaging because MPI codes need fast and stable networks, and long-lived instances are expensive and failure-prone. It proposes instead a serverless, event-driven workflow that treats seismic imaging as a MapReduce problem: each gradient is an independent batch job, and cheap serverless functions sum the gradients as they finish. Instances are launched only when a job starts and shut down when it ends, so idle time and the cost of idle instances drops to zero. The paper demonstrates this on a large 2D velocity benchmark with up to 128 parallel gradient jobs, shows that failures can be absorbed by automatic restarts, and estimates total savings of up to an order of magnitude compared with fixed clusters of on-demand instances.

What carries the argument

The load-bearing mechanism is the MapReduce decomposition of gradient-based seismic inversion combined with AWS's managed services. Each element of the gradient sum becomes an independent AWS Batch array job, and each job runs inside a Docker container on an EC2 instance that AWS automatically launches and terminates. Gradients are written to S3, object names go to an SQS queue, and Lambda functions recursively sum pairs of gradient arrays, streaming or chunking them when they exceed Lambda's 3 GB memory limit and 15-minute execution cap. For a single gradient too large for one instance, a multi-node AWS Batch job enables MPI domain decomposition generated by a finite-difference DSL compiler, giving nested parallelism: source-index parallelism across instances and domain decomposition inside each job.

What would settle it

Run the paper's 100-gradient benchmark on a real AWS account and compare the line-item EC2 bill with the sum of per-container runtimes; any nonzero charge for instance startup, shutdown, queue wait, or a minimum billing interval would falsify the claim that AWS Batch eliminates idle-instance cost.

Watch

Extended reading notes

Core claim

The central claim is that a seismic-imaging optimization algorithm can be re-expressed as a serverless, event-driven workflow without sacrificing HPC performance. The objective function is a sum over source experiments, which is exactly a MapReduce program: the map is the embarrassingly parallel computation of one gradient per source, and the reduce is the summation of gradients and the model update. AWS Step Functions orchestrate the iteration loop, AWS Batch runs each gradient as a Docker container on an EC2 instance that is terminated as soon as the gradient is written to object storage, and Lambda functions perform event-driven gradient summation via an SQS queue. Because instances are alive only while computing, the cumulative idle time in a 100-gradient example falls from 248 minutes on a fixed 100-instance cluster to zero. The workflow also inherits resilience: failed instances are restarted by AWS Batch, and multi-node batch jobs provide MPI-based domain decomposition when a single instance cannot hold the wavefields.

Load-bearing premise

The cost-savings claim holds only if AWS bills the user exactly for the seconds each compute instance is actually running a job, with no charge for instance startup, shutdown, queueing, or any minimum billing increment.

Editorial extensions

If this is right

  • Cloud becomes a realistic platform for large-scale least-squares reverse time migration, since a 100-gradient batch can run with zero idle-instance cost and users pay only for container runtime.
  • Instance failures no longer require restarting the whole inversion: failed gradient jobs are restarted independently, so long-running 3D-scale workloads become feasible on spot instances despite their two-minute termination warnings.
  • Spot instances can be chosen afresh at each optimization iteration across zones and instance types, reducing exposure to volatile spot prices by 15 to 40 percent in the paper's historical-price scenarios.
  • Multi-node AWS Batch jobs enable MPI domain decomposition for a single gradient, giving speedups up to 11.3 on network-optimized instances, but the paper shows that small single-instance jobs using all cores remain the cheapest strategy when spot pricing is available.
  • Because the same services exist on Azure and Google Cloud, the event-driven pattern is portable across cloud providers rather than being tied to one platform.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Beyond the paper, the same serverless MapReduce pattern should transfer to other PDE-constrained inverse problems, such as full-waveform inversion in electromagnetics or medical imaging, wherever one gradient or one forward solve takes minutes to hours.
  • A testable extension is to inspect actual AWS line-item bills for the paper's 100-gradient benchmark: if any charge appears for instance startup, shutdown, queue wait, or a minimum billing interval, the zero-idle-cost claim is measurably overstated.
  • The paper's overhead analysis implies that the advantage grows with job length: for 3D problems where each gradient runs for hours, the few minutes of instance-startup overhead become negligible, so the cost and resilience benefits should be larger than in the 2D experiments.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper presents an event-driven, serverless workflow for large-scale seismic imaging (LS-RTM) on AWS, using Step Functions, Lambda, SQS, S3, and AWS Batch. The gradient computation is carried out as embarrassingly parallel AWS Batch jobs, with an event-driven reduction via Lambda/SQS, and the iterative optimization loop is expressed as a Step Functions state machine. The authors report weak scaling from 1 to 128 jobs, strong scaling of MPI-based domain decomposition with a best speedup of 11.3, a cost comparison against a fixed EC2 cluster modeled from measured container runtimes, and a resilience analysis based on simulated instance failures with a measured restart penalty. The central claims are that the approach provides nested levels of parallelization, inherent resilience to instance shutdowns, and significant cost savings by eliminating idle instances, making the cloud a viable alternative to on-premise clusters.

Significance. If the cost and resilience claims hold, this is a valuable demonstration that a carefully re-architected HPC application can leverage serverless and event-driven cloud services to avoid idle-instance costs and tolerate failures. The paper's real measurements are a clear strength: weak-scaling and strong-scaling experiments are reported with means and standard deviations, the experimental setup is described in detail, and the BP 2004 benchmark provides a reproducible use case. The event-driven gradient reduction is a novel and interesting design. However, the headline cost and resilience conclusions are supported by models rather than end-to-end measurements, and the cost model in particular relies on an unverified billing assumption. The significance is therefore conditional: the architectural ideas are compelling, but the quantitative savings and resilience factors need stronger empirical support before the central claims can be accepted.

major comments (4)
  1. [Section 4.3, Eq. (3)] The claim that 'the cumulative idle time for computing the 100 gradients is zero, regardless of the number of parallel instances' assumes that billed EC2 time equals the sum of container execution times. The paper does not measure actual billed EC2 instance time; the cost calculations are based on container runtimes only. This ignores time for Docker image pull, container initialization, data staging, output upload, and asynchronous scale-down of the Batch compute environment. Figure 6b and Figure 9c themselves show startup and cluster-establishment times of minutes, during which instances are running and billing per second. The paper should either present actual billed EC2 seconds from a real Batch run or clearly state that the cost comparison is a lower bound that omits these items.
  2. [Section 4.1, Figure 6b] The text states that 'no cost is incurred during this time period, as no EC2 instances are running while the individual containers remain in the queue.' This is incorrect as stated: the startup time measured in Figure 6b is the interval during which AWS Batch requests, launches, and initializes EC2 instances before the containers start. Those instances are running and incurring charges during this interval. This error directly affects the statement that the cost of a batch job 'only depends on the container runtime and the batch size, but not on the startup time or reduction time.' The cost analysis should use the full instance allocation time, not just container execution time.
  3. [Section 4.5, Figure 14] The resilience analysis is a simulation model rather than an end-to-end experiment under real failures. The model assumes a fixed two-minute restart penalty, random failure times, and that AWS Batch automatically restarts failed jobs in the modeled manner. The paper reports that the penalty was determined by manually terminating instances, which is a reasonable step, but the broader claim that the workflow 'inherently provides resilience to instance shut-downs' would be stronger if the authors either validated the model against a set of actual fault-injection runs or explicitly scoped the conclusion to the model's assumptions. As written, the resilience factors in Figure 14 are conditional on an ad hoc failure model.
  4. [Section 5, cost savings estimate] The estimate of 'cost savings of up to an order of magnitude' combines spot pricing (factor 2-3), avoidance of idle instances and cluster-spin-up overhead (factor 1.5-2), and improved resilience. These factors are not derived from a single measured end-to-end comparison; they are assembled from separate models and price observations. Because the idle-cost component rests on the unverified zero-idle-time claim noted above, the order-of-magnitude estimate is not supported by the measurements reported in the paper. The authors should either provide a real cost comparison between the event-driven workflow and a fixed cluster over a complete optimization run, or substantially soften this claim.
minor comments (5)
  1. [Section 4.1 and Appendix] The cross-reference to 'Table 1 of the Appendix' and 'Table 2' for the experimental setup is incorrect: the dimensions of the BP model are listed in Appendix Table 4, and the instance prices are in Table 2. Please fix the table numbering or the references.
  2. [Section 4.2, Figure 10] The caption and text refer to 'Figure 10a' for both the kernel runtimes and the corresponding cost; the cost plot is Figure 10b. Please correct the reference.
  3. [Section 5] There is a typo, 'programming paradimgs', which should be 'programming paradigms'.
  4. [References] Reference [31] is labeled 'AWS documentation: AWS Batch' but the URL points to the EC2 page; conversely, reference [57] is labeled 'Amazon Elastic Compute Cloud' but the URL points to AWS Batch documentation. These should be corrected, as they are confusing to readers.
  5. [Section 3.3] The description of the SQS/Lambda reduction would benefit from a figure or pseudocode clarifying how partial sums are combined recursively and how the 'at-least-once' delivery interacts with duplicate messages. The current text states that duplicates are avoided by deleting objects, but not how duplicate message delivery is deduplicated at the application level.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the paper's scaling, resilience, and cost claims are empirical benchmarks against the public BP 2004 model; the zero-idle-time claim is an externally checkable service property, not a derivation from its own inputs.

full rationale

The paper is a systems and performance study rather than a derivation of a theoretical result. Its central claims are that an AWS Batch/Lambda event-driven workflow provides resilience and avoids idle EC2 time. The cost comparison in Section 4.3 defines cumulative idle time by Eq. (3) as the sum over instances of max{ti} - ti using measured per-instance container runtimes, and then contrasts this cluster model with AWS Batch's automatic instance termination. The AWS Batch zero-idle claim is an assertion about an external service behavior, supported by AWS's own accelerated scale-down announcement (ref. [77]), not an algebraic consequence of Eq. (3). No fitted parameter is renamed as a prediction: Figures 6, 9, and 11 report measured runtimes and costs, while the two-minute restart penalty in Section 4.5 was determined experimentally by manually shutting down EC2 instances. Self-citations are not load-bearing for the conclusions: ref. [35] merely notes an early application, while refs. [47], [66], and [51] describe the Devito compiler and the authors' inversion framework, which are externally usable and are not invoked as a proof of the cloud-specific claims. The 'up to an order of magnitude' savings estimate in Section 5 is the paper's own aggregation of measured overhead factors with explicitly stated assumptions, rather than a result whose definition presupposes the conclusion. At most there is an unmeasured billing assumption about EC2 allocation time including startup and scale-down delay, which is a correctness or accuracy concern, not circularity. The paper even acknowledges its own limitation that the event-driven approach is only beneficial for embarrassingly parallel, long-running computations. Therefore no circular step can be exhibited under the required standard.

Assumptions & free parameters 2 free parameters · 3 assumptions · 0 invented entities

The paper introduces no new physical or mathematical entities. Its claims rest on the structure of the seismic inverse problem, on assumed behavior of AWS services, and on two hand-set inputs to the cost and resilience models.

free parameters (2)
  • Instance restart penalty = 2 minutes
    Used in the resilience model in Section 4.5 as the average time for AWS to restart a terminated EC2 instance; the authors measured it by manually stopping instances, but apply a single uniform value to all simulated failures.
  • Cost savings factors = spot 2-3x, idle and cluster overhead 1.5-2x
    Used in Section 5 to estimate 'up to an order of magnitude' savings compared with fixed on-demand clusters; these are stated estimates rather than measured end-to-end savings.
assumptions (3)
  • domain assumption The LS-RTM objective (Eq. 1) is a sum over independent source experiments, and each gradient is an embarrassingly parallel PDE solve (Section 2).
    This is what allows per-source AWS Batch jobs and the MapReduce workflow in Section 3.
  • domain assumption AWS services behave as documented: S3 gives scalable object storage with no read/write limits, SQS gives at-least-once delivery, and AWS Batch starts and stops EC2 instances automatically without user-visible idle cost (Section 3).
    The event-driven design depends on these platform guarantees, such as no lost messages and automatic instance termination.
  • ad hoc to paper A fixed two-minute restart penalty and randomly timed failures adequately model real instance failure patterns (Section 4.5).
    The resilience factor plots are generated from this simulation, not from a statistically characterized failure distribution.

how reviews work

0 comments
Cite this review

Pith. "Pith review of An Event-Driven Approach to Serverless Seismic Imaging in the Cloud." pith.science (2026). https://pith.science/paper/HMD4YJMA

@misc{pith2026190901279,
  author       = {Pith},
  title        = {Pith review of: An Event-Driven Approach to Serverless Seismic Imaging in the Cloud},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/HMD4YJMA}},
  note         = {Machine review of arXiv:1909.01279}
}
read the original abstract

Adapting the cloud for high-performance computing (HPC) is a challenging task, as software for HPC applications hinges on fast network connections and is sensitive to hardware failures. Using cloud infrastructure to recreate conventional HPC clusters is therefore in many cases an infeasible solution for migrating HPC applications to the cloud. As an alternative to the generic lift and shift approach, we consider the specific application of seismic imaging and demonstrate a serverless and event-driven approach for running large-scale instances of this problem in the cloud. Instead of permanently running compute instances, our workflow is based on a serverless architecture with high throughput batch computing and event-driven computations, in which computational resources are only running as long as they are utilized. We demonstrate that this approach is very flexible and allows for resilient and nested levels of parallelization, including domain decomposition for solving the underlying partial differential equations. While the event-driven approach introduces some overhead as computational resources are repeatedly restarted, it inherently provides resilience to instance shut-downs and allows a significant reduction of cost by avoiding idle instances, thus making the cloud a viable alternative to on-premise clusters for large-scale seismic imaging.

Figures

Figures reproduced from arXiv: 1909.01279 by the authors.

Figure 1
Figure 1. A two-dimensional depiction of marine seismic data acquisition. A vessel fires a seismic source [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. A generic seismic imaging algorithm, expressed as a serverless visual workflow using AWS [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. The gradients of the LS-RTM objective function are computed as an embarrassingly parallel workload [PITH_FULL_IMAGE:figures/full_fig_p007_3.png] view at source ↗
Figures from the paper (11 more)
Figure 4
Figure 4. Figure 4: Event-driven gradient summation using AWS Lambda functions. An SQS message queue collects [PITH_FULL_IMAGE:figures/full_fig_p008_4.png]
Figure 5
Figure 5. Figure 5: The BP 2004 benchmark model, a 2D subsurface velocity model for development and testing of [PITH_FULL_IMAGE:figures/full_fig_p009_5.png]
Figure 6
Figure 6. Figure 6: Weak scaling results for performing a single iteration of stochastic gradient as a function of the batch [PITH_FULL_IMAGE:figures/full_fig_p011_6.png]
Figure 7
Figure 7. Figure 7: Final seismic image after 30 iterations of stochastic gradient descent and a batch size of 80, which [PITH_FULL_IMAGE:figures/full_fig_p012_7.png]
Figure 8
Figure 8. Figure 8: Strong scaling results for computing a single image gradient of the BP model as a function of the [PITH_FULL_IMAGE:figures/full_fig_p013_8.png]
Figure 9
Figure 9. Figure 9: Strong scaling results for computing a single gradient as an AWS Batch multi-node job for an [PITH_FULL_IMAGE:figures/full_fig_p014_9.png]
Figure 10
Figure 10. Figure 10: Devito kernel runtimes for computing a single gradient as an AWS Batch job for an increasing [PITH_FULL_IMAGE:figures/full_fig_p015_10.png]
Figure 11
Figure 11. Figure 11: (a) Sorted container runtimes of an AWS Batch job in which we compute the gradient of the BP [PITH_FULL_IMAGE:figures/full_fig_p017_11.png]
Figure 12
Figure 12. Figure 12: (a) Historical spot price of the c5n.18xlarge instance in different zones of the US East region over a 10 ten day period in April 2019. Figure (b) shows the relative cost for running an iterative seismic imaging algorithm over this time period in the respective zones.…
Figure 13
Figure 13. Figure 13: (a) Historical spot prices for a variety of [PITH_FULL_IMAGE:figures/full_fig_p020_13.png]
Figure 14
Figure 14. Figure 14: Comparison of the resilience factor (RF) for an increasing percentage of instance failures with and [PITH_FULL_IMAGE:figures/full_fig_p021_14.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

84 extracted references · 66 canonical work pages

  1. [1]

    A. A. Valenciano. Imaging by wave-equation inversion. PhD thesis, Stanford University, 2008. 23 An event-driven approach to serverless seismic imaging in the cloud Table 5: Architectures of compute instances used in our performance analysis on AWS and Optimum. Instance Intel Xeon Architecture vCPUs RAM (GB) m4.4xlarge E5-2686 v4 @ 2.30GHz 16 64 r5.12xlarg...

    2008

  2. [2]

    S. Dong, J. Cai, M. Guo, S. Suh, Z. Zhang, B. Wang, and Z. Li. Least-squares reverse time migration: towards true amplitude imaging and improving the resolution. In 82nd Annual International Meeting, SEG, Expanded Abstracts, pages 1–5, 2012. doi: 10.1190/segam2012-1488.1

    work page doi:10.1190/segam2012-1488.1 2012

  3. [3]

    Least-squares reverse time migration: Inversion-based imaging toward true reflectivity

    Chong Zeng, Shuqian Dong, and Bing Wang. Least-squares reverse time migration: Inversion-based imaging toward true reflectivity. The Leading Edge, 33:962–964,966,968, 2014. doi: 10.1190/tle33090962.1

    work page doi:10.1190/tle33090962.1 2014

  4. [4]

    Witte, Mathias Louboutin, Fabio Luporini, Gerard J

    Philipp A. Witte, Mathias Louboutin, Fabio Luporini, Gerard J. Gorman, and Felix J. Herrmann. Compressive least-squares migration with on-the-fly Fourier transforms. GEOPHYSICS, 84(5):R655–R672, 2019. doi: 10.1190/ geo2018-0490.1. URL https://doi.org/10.1190/geo2018-0490.1

    work page doi:10.1190/geo2018-0490.1 2019

  5. [5]

    https://www.pgs.com/imaging/services/processing-and-imaging/ , 2019

    Seismic processing and imaging. https://www.pgs.com/imaging/services/processing-and-imaging/ , 2019

    2019

  6. [6]

    https://corporate.exxonmobil

    Exxonmobil sets record in high-performance oil and gas reservoir computing. https://corporate.exxonmobil. com/en/Energy-and-environment/Tools-and-processes/Exploration-technology/ExxonMobil- sets-record-in-high-performance-oil-and-gas-reservoir-computing , 2019

    2019

  7. [7]

    AWS enterprise customer success stories.https://aws.amazon.com/solutions/case-studies/enterprise, 2019

    2019

  8. [8]

    Netflix in the cloud

    Adrian Cockroft. Netflix in the cloud. In QCon San Fransisco. Netflix, 2011

    work page 2011

Show all 84 references
  1. [9]

    Performance analysis of high performance computing applications on the Amazon Web Services cloud

    Keith R Jackson, Lavanya Ramakrishnan, Krishna Muriki, Shane Canon, Shreyas Cholia, John Shalf, Harvey J Wasserman, and Nicholas J Wright. Performance analysis of high performance computing applications on the Amazon Web Services cloud. In 2010 IEEE second international confer...

    2010

  2. [10]

    Iosup, S

    A. Iosup, S. Ostermann, M. N. Yigitbasi, R. Prodan, T. Fahringer, and D. Epema. Performance analysis of cloud computing services for many-tasks scientific computing. IEEE Transactions on Parallel and Distributed Systems, 22 (6):931–945, June 2011. ISSN 1045-9219. doi: 10.1109/T...

    2011 doi

  3. [11]

    Garfinkel

    Simson L. Garfinkel. An evaluation of Amazon’s grid computing services: EC2, S3, and SQS. In Harvard Computer Science Group Technical Report TR-08-07, 2007

    2007

  4. [12]

    Jeffrey Napper and Paolo Bientinesi. Can cloud computing reach the Top500? In Proceedings of the Combined Workshops on Unconventional High Performance Computing Workshop Plus Memory Access Workshop (UCHPC- MAW ’09), UCHPC-MAW ’09, pages 17–20, New York, NY , USA, 2009. ACM. IS...

    2009

  5. [13]

    Performance and cost analysis of the supernova factory on the Amazon AWS cloud

    Keith R Jackson, Krishna Muriki, Lavanya Ramakrishnan, Karl J Runge, and Rollin C Thomas. Performance and cost analysis of the supernova factory on the Amazon AWS cloud. Scientific Programming, 19(2-3):107–119, 2011

    2011

  6. [14]

    Magellan: experiences from a science cloud

    Lavanya Ramakrishnan, Piotr T Zbiegel, Scott Campbell, Rick Bradshaw, Richard Shane Canon, Susan Coghlan, Iwona Sakrejda, Narayan Desai, Tina Declerck, and Anping Liu. Magellan: experiences from a science cloud. In Proceedings of the 2nd international workshop on Scientific clo...

    2011

  7. [15]

    Evaluating interconnect and virtualization performance for high performance computing

    Lavanya Ramakrishnan, R Shane Canon, Krishna Muriki, Iwona Sakrejda, and Nicholas J Wright. Evaluating interconnect and virtualization performance for high performance computing. ACM SIGMETRICS Performance Evaluation Review, 40(2):55–60, 2012

    2012

  8. [16]

    Performance issues and performance analysis tools for HPC cloud applications: a survey

    Shajulin Benedict. Performance issues and performance analysis tools for HPC cloud applications: a survey. Computing, 95(2):89–108, 2013

    2013

  9. [17]

    Performance evaluation of Amazon Elastic Compute Cloud for NASA high-performance computing applications

    Piyush Mehrotra, Jahed Djomehri, Steve Heistand, Robert Hood, Haoqiang Jin, Arthur Lazanoff, Subhash Saini, and Rupak Biswas. Performance evaluation of Amazon Elastic Compute Cloud for NASA high-performance computing applications. Concurrency and Computation: Practice and Expe...

    2016

  10. [18]

    Evaluation of HPC applications on cloud

    Abhishek Gupta and Dejan Milojicic. Evaluation of HPC applications on cloud. In 2011 Sixth Open Cirrus Summit, pages 22–26. IEEE, 2011. 24 An event-driven approach to serverless seismic imaging in the cloud

    2011

  11. [19]

    Sadooghi, J

    I. Sadooghi, J. H. Martin, T. Li, K. Brandstatter, K. Maheshwari, T. P. P. de Lacerda Ruivo, G. Garzoglio, S. Timm, Y . Zhao, and I. Raicu. Understanding the performance and potential of cloud computing for scientific applications. IEEE Transactions on Cloud Computing, 5(2):358...

    2017 doi

  12. [20]

    A comparison of Amazon Web Services and Microsoft Azure cloud platforms for high performance computing

    Charlotte Kotas, Thomas Naughton, and Neena Imam. A comparison of Amazon Web Services and Microsoft Azure cloud platforms for high performance computing. In 2018 IEEE International Conference on Consumer Electronics (ICCE), pages 1–4. IEEE, 2018

    2018

  13. [21]

    The LINPACK benchmark: past, present and future

    Jack J Dongarra, Piotr Luszczek, and Antoine Petitet. The LINPACK benchmark: past, present and future. Concurrency and Computation: practice and experience, 15(9):803–820, 2003

    2003

  14. [22]

    Benchmarking bare metal cloud servers for HPC applications

    Paul Rad, AT Chronopoulos, P Lama, Pranitha Madduri, and Cameron Loader. Benchmarking bare metal cloud servers for HPC applications. In 2015 IEEE International Conference on Cloud Computing in Emerging Markets (CCEM), pages 153–159. IEEE, 2015

    2015

  15. [23]

    Comparative benchmarking of cloud computing vendors with high performance LINPACK

    Mohammad Mohammadi and Timur Bazhirov. Comparative benchmarking of cloud computing vendors with high performance LINPACK. In Proceedings of the 2nd International Conference on High Performance Compilation, Computing and Communications (HP3C-2018), pages 1–5. ACM, 2018

    2018

  16. [24]

    Using MPI: portable parallel programming with the message-passing interface, volume 1

    William Gropp, William D Gropp, Argonne Distinguished Fellow Emeritus Ewing Lusk, Ewing Lusk, and Anthony Skjellum. Using MPI: portable parallel programming with the message-passing interface, volume 1. MIT press, 1999

    1999

  17. [25]

    https://aws.amazon.com/lambda/, 2019

    AWS documentation: AWS Lambda. https://aws.amazon.com/lambda/, 2019

    2019

  18. [26]

    https://docs.aws.amazon.com/AmazonS3/latest/ dev/Welcome.html, 2019

    AWS documentation: Amazon Simple Storage Service. https://docs.aws.amazon.com/AmazonS3/latest/ dev/Welcome.html, 2019

    2019

  19. [27]

    https://cloud.google.com/storage/, 2019

    Google cloud storage. https://cloud.google.com/storage/, 2019

    2019

  20. [28]

    Massively scalable object storage system, April 28 2015

    Michael Barton, Will Reese, John A Dickinson, Jay B Payne, Charles B Thier, and Gregory Holt. Massively scalable object storage system, April 28 2015. US Patent 9,021,137 to Rackspace US, Inc

    2015

  21. [29]

    Building high-throughput genomics batch workflows on AWS

    Aaron Friedman and Angel Pizarro. Building high-throughput genomics batch workflows on AWS. https://aws.amazon.com/blogs/compute/building-high-throughput-genomics-batch-workflows- on-aws-introduction-part-1-of-4/ , 5 2017

    2017

  22. [30]

    MapReduce: simplified data processing on large clusters

    Jeffrey Dean and Sanjay Ghemawat. MapReduce: simplified data processing on large clusters. Communications of the ACM, 51(1):107–113, 2008

    2008

  23. [31]

    https://aws.amazon.com/ec2/, 2019

    AWS documentation: AWS Batch. https://aws.amazon.com/ec2/, 2019

    2019

  24. [32]

    https://hadoop.apache.org/, 2019

    Apache Hadoop. https://hadoop.apache.org/, 2019

    2019

  25. [33]

    https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr- overview.html, 2019

    AWS documentation: Amazon EMR. https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr- overview.html, 2019

    2019

  26. [34]

    The 2004 BP velocity benchmark

    Frederic Billette and Sverre Brandsberg-Dahl. The 2004 BP velocity benchmark. In 67th Annual International Meeting, EAGE, Expanded Abstracts, page B035. EAGE, 2005

    2004

  27. [35]

    Witte, Mathias Louboutin, Henryk Modzelewski, Charles Jones, James Selvage, and Felix J

    Philipp A. Witte, Mathias Louboutin, Henryk Modzelewski, Charles Jones, James Selvage, and Felix J. Herrmann. Event-driven workflows for large-scale seismic imaging in the cloud. In 89th Annual International Meeting, SEG, Expanded Abstracts, page 0, 2019

    2019

  28. [36]

    https://www.hartenergy.com/exclusives/advances-seismic- imaging-technology-177370 , 2019

    Advances in seismic imaging technology. https://www.hartenergy.com/exclusives/advances-seismic- imaging-technology-177370 , 2019

    2019

  29. [37]

    Inversion of seismic reflection data in the acoustic approximation

    Albert Tarantola. Inversion of seismic reflection data in the acoustic approximation. Geophysics, 49(8):1259, 1984. doi: 10.1190/1.1441754. URL +http://dx.doi.org/10.1190/1.1441754

    1984 doi

  30. [38]

    An overview of full-waveform inversion in exploration geophysics.GEOPHYSICS, 74(6):WCC127–WCC152, November-December 2009

    Jean Virieux and Stephane Operto. An overview of full-waveform inversion in exploration geophysics.GEOPHYSICS, 74(6):WCC127–WCC152, November-December 2009. doi: 10.1190/1.3238367

    2009 doi

  31. [39]

    Gerhard Pratt

    R. Gerhard Pratt. Seismic waveform inversion in the frequency domain, part 1: Theory and verification in a physical scale model. Geophysics, 64(3):888–901, 1999. doi: 10.1190/1.1444597. URL https://doi.org/10.1190/1. 1444597

    1999 doi

  32. [40]

    Smithyman, and Felix J

    Bas Peters, Brendan R. Smithyman, and Felix J. Herrmann. Projection methods and applications for seismic nonlinear inverse problems with multiple constraints. GEOPHYSICS, 84(2):R251–R269, 2019. doi: 10.1190/geo2018-0192.1. URL https://doi.org/10.1190/geo2018-0192.1

    2019 doi

  33. [41]

    Courant, K

    R. Courant, K. Friedrichs, and H. Lewy. On the partial difference equations of mathematical physics. International Business Machines (IBM) Journal of Research and Development, 11(2):215–234, March 1967. ISSN 0018-8646. doi: 10.1147/rd.112.0215

    1967 doi

  34. [42]

    Deep neural networks motivated by partial differential equations

    Lars Ruthotto and Eldad Haber. Deep neural networks motivated by partial differential equations. CoRR, abs/1804.04272, 2018. URL http://arxiv.org/abs/1804.04272. 25 An event-driven approach to serverless seismic imaging in the cloud

    2018 arXiv

  35. [43]

    Algorithm 799: Revolve: An implementation of checkpointing for the reverse or adjoint mode of computational differentiation

    Andreas Griewank and Andrea Walther. Algorithm 799: Revolve: An implementation of checkpointing for the reverse or adjoint mode of computational differentiation. Association for Computing Machinery (ACM) Transactions on Mathematical Software, 26(1):19–45, March 2000. ISSN 0098...

  36. [44]

    C. M. Furse. Faster than Fourier-ultra-efficient time-to-frequency domain conversions for FDTD. In Institute of Electrical and Electronics Engineers (IEEE): Antennas and Propagation Society International Symposium, volume 1, pages 536–539 vol.1, June 1998. doi: 10.1109/APS.1998.699196

    1998

  37. [45]

    Abdelkhalek, H

    R. Abdelkhalek, H. Calandra, O. Coulaud, J. Roman, and G. Latu. Fast seismic modeling and reverse time migration on a GPU cluster. In 2009 International Conference on High Performance Computing Simulation, pages 36–43, June

    2009

  38. [46]

    Weiss and Jeffrey Shragge

    Robin M. Weiss and Jeffrey Shragge. Solving 3D anisotropic elastic wave equations on parallel GPU devices. GEOPHYSICS, 78(2):F7–F15, 2013. doi: 10.1190/geo2012-0063.1. URL https://doi.org/10.1190/geo2012- 0063.1

    2013 doi

  39. [47]

    Louboutin, M

    M. Louboutin, M. Lange, F. Luporini, N. Kukreja, P. A. Witte, F. J. Herrmann, P. Velesko, and G. J. Gorman. Devito (v3.1.0): an embedded domain-specific language for finite differences and geophysical exploration. Geoscientific Model Development, 12(3):1165–1187, 2019. doi: 10.51...

    2019 doi

  40. [48]

    Symes, Dong Sun, and Marco Enriquez

    William W. Symes, Dong Sun, and Marco Enriquez. From modelling to inversion: Designing a well-adapted simulator. Geophysical Prospecting, 59(5):814–833, 2011. ISSN 1365-2478. doi: 10.1111/j.1365-2478.2011.00977.x. URL 10.1111/j.1365-2478.2011.00977.x

    2011

  41. [49]

    Ruthotto, E

    L. Ruthotto, E. Treister, and E. Haber. jInv–a flexible Julia package for PDE parameter estimation. SIAM Journal on Scientific Computing, 39(5):S702–S722, 2017. doi: 10.1137/16M1081063. URL https://doi.org/10.1137/ 16M1081063

    2017 doi

  42. [50]

    Herrmann

    Curt Da Silva and Felix J. Herrmann. A unified 2D/3D large-scale software environment for nonlinear inverse problems. ACM Transactions on Mathematical Software, 45:7:1–7:35, 2017

    2017

  43. [51]

    Witte, Mathias Louboutin, Fabio Luporini, Navjot Kukreja, Michael Lange, Gerard J

    Philipp A. Witte, Mathias Louboutin, Fabio Luporini, Navjot Kukreja, Michael Lange, Gerard J. Gorman, and Felix J. Herrmann. A large-scale framework for symbolic implementations of seismic inversion algorithms in Julia. Geophysics, 84:A31 – V183, 5 2019

    2019

  44. [52]

    https://docs.aws.amazon.com/AWSEC2/latest/ UserGuide/how-spot-instances-work.html , 2019

    AWS documentation: How spot instances work. https://docs.aws.amazon.com/AWSEC2/latest/ UserGuide/how-spot-instances-work.html , 2019

    2019

  45. [53]

    Lectures on convex optimization, volume 137

    Yurii Nesterov. Lectures on convex optimization, volume 137. Springer, 2018

    2018

  46. [55]

    Function minimization by conjugate gradients

    Reeves Fletcher and Colin M Reeves. Function minimization by conjugate gradients. The computer journal, 7(2): 149–154, 1964

    1964

  47. [56]

    A fast iterative shrinkage-thresholding algorithm for linear inverse problems

    Amir Beck and Marc Teboulle. A fast iterative shrinkage-thresholding algorithm for linear inverse problems. SIAM journal on imaging sciences, 2(1):183–202, 2009

    2009

  48. [57]

    https://docs.aws.amazon.com/batch/latest/ userguide/what-is-batch.html , 2019

    AWS documentation: Amazon Elastic Compute Cloud. https://docs.aws.amazon.com/batch/latest/ userguide/what-is-batch.html , 2019

    2019

  49. [58]

    http://star.mit.edu/cluster/, 2019

    Starcluster. http://star.mit.edu/cluster/, 2019

    2019

  50. [59]

    https://aws.amazon.com/hpc/, 2019

    AWS High Performance Computing. https://aws.amazon.com/hpc/, 2019

    2019

  51. [60]

    https://aws.amazon.com/step-functions/, 2019

    AWS documentation: AWS Step Functions. https://aws.amazon.com/step-functions/, 2019

    2019

  52. [61]

    https://docs.aws.amazon.com/step-functions/latest/dg/tutorial- create-iterate-pattern-section.html , 2018

    Iterating a loop using Lambda. https://docs.aws.amazon.com/step-functions/latest/dg/tutorial- create-iterate-pattern-section.html , 2018

    2018

  53. [62]

    https://www.docker.com/, 2019

    Docker. https://www.docker.com/, 2019

    2019

  54. [63]

    The NumPy array: a structure for efficient numerical computation

    Stefan Van Der Walt, S Chris Colbert, and Gael Varoquaux. The NumPy array: a structure for efficient numerical computation. Computing in Science & Engineering, 13(2):22, 2011

    2011

  55. [64]

    https://docs.aws.amazon.com/AmazonS3/latest/ dev/Welcome.html, 2019

    AWS documentation: Amazon Simple Queue Service. https://docs.aws.amazon.com/AmazonS3/latest/ dev/Welcome.html, 2019

    2019

  56. [65]

    https://aws.amazon.com/ec2/instance-types/, 2019

    AWS documentation: Amazon EC2 instance types. https://aws.amazon.com/ec2/instance-types/, 2019

    2019

  57. [66]

    Witte, Paul H

    Fabio Luporini, Michael Lange, Mathias Louboutin, Navjot Kukreja, Jan Hückelheim, Charles Yount, Philipp A. Witte, Paul H. J. Kelly, Gerard J. Gorman, and Felix J. Herrmann. Architecture and performance of Devito, a system for automated stencil computation. To be published in ...

    2018 arXiv

  58. [67]

    David Joyner, Ondˇrej ˇCertík, Aaron Meurer, and Brian E. Granger. Open source computer algebra systems: SymPy. Association for Computing Machinery (ACM) Communications in Computer Algebra, 45(3/4):225–234, January 2012. ISSN 1932-2240. doi: 10.1145/2110170.2110185. URL http:/...

    2012

  59. [68]

    Kukreja, J

    N. Kukreja, J. Hückelheim, M. Lange, M. Louboutin, A. Walther, S. W. Funke, and G. Gorman. High-level Python abstractions for optimal checkpointing in inversion problems. ArXiv e-prints, January 2018

    2018

  60. [69]

    Building a tightly coupled molecular dynamics workflow with multi-node parallel jobs in AWS Batch

    Josh Rad, Amr Ragab, and Aswin Damodar. Building a tightly coupled molecular dynamics workflow with multi-node parallel jobs in AWS Batch. https://aws.amazon.com/blogs/compute/building-a-tightly- coupled-molecular-dynamics-workflow-with-multi-node-parallel-jobs-in-aws-batch/ , 11 2018

    2018

  61. [70]

    https://boto3.amazonaws.com/v1/documentation/api/latest/index.html#, 2019

    Boto 3 documentation. https://boto3.amazonaws.com/v1/documentation/api/latest/index.html#, 2019

    2019

  62. [71]

    Numerical optimization

    Jorge Nocedal and Stephen Wright. Numerical optimization. Springer Science & Business Media, 2006

    2006

  63. [72]

    Large-scale machine learning with stochastic gradient descent

    Léon Bottou. Large-scale machine learning with stochastic gradient descent. In Proceedings of 15th International Conference on Computational Statistics (COMPSTAT’2010), pages 177–186. Springer, 2010

    2010

  64. [73]

    Using Docker in high performance computing applications

    Minh Thanh Chung, Nguyen Quang-Hung, Manh-Thin Nguyen, and Nam Thoai. Using Docker in high performance computing applications. In 2016 IEEE Sixth International Conference on Communications and Electronics (ICCE), pages 52–57. IEEE, 2016

    2016

  65. [74]

    Domain decomposition methods for partial differential equations

    Alberto Valli and Alfio Quarteroni. Domain decomposition methods for partial differential equations. Numerical Mathematics and Scientific Computation. The Clarendon Press, Oxford University Press, New York, 1999

    1999

  66. [75]

    https://docs.aws.amazon.com/batch/latest/ userguide/multi-node-parallel-jobs.html , 2019

    AWS documentation: AWS Batch - multi node parallel jobs. https://docs.aws.amazon.com/batch/latest/ userguide/multi-node-parallel-jobs.html , 2019

    2019

  67. [76]

    https://aws.amazon.com/ec2/instance-types/c5/, 2019

    Amazon EC2 C5 instances. https://aws.amazon.com/ec2/instance-types/c5/, 2019

    2019

  68. [77]

    https://aws.amazon.com/ about-aws/whats-new/2017/10/announcing-accelerated-scale-down-of-aws-batch-managed- compute-environments/, 2019

    Announcing accelerated scale-down of AWS Batch managed compute environments. https://aws.amazon.com/ about-aws/whats-new/2017/10/announcing-accelerated-scale-down-of-aws-batch-managed- compute-environments/, 2019

    2017

  69. [78]

    Post-failure recovery of MPI communication capability: Design and rationale

    Wesley Bland, Aurelien Bouteiller, Thomas Herault, George Bosilca, and Jack Dongarra. Post-failure recovery of MPI communication capability: Design and rationale. The International Journal of High Performance Computing Applications, 27(3):244–254, 2013

    2013

  70. [79]

    Towards new metrics for high-performance computing resilience

    Saurabh Hukerikar, Rizwan A Ashraf, and Christian Engelmann. Towards new metrics for high-performance computing resilience. In Proceedings of the 2017 Workshop on Fault-Tolerance for HPC at Extreme Scale, pages 23–30. ACM, 2017

    2017

  71. [80]

    Deep residual learning for image recognition

    Kaiming He, Xiangyu Zhang, Shaoqing Ren, and Jian Sun. Deep residual learning for image recognition. In Proceedings of the IEEE conference on computer vision and pattern recognition, pages 770–778, 2016

    2016

  72. [81]

    https://docs.microsoft.com/en-us/azure/architecture/aws- professional/services, 2019

    AWS to Azure services comparison. https://docs.microsoft.com/en-us/azure/architecture/aws- professional/services, 2019

    2019

  73. [82]

    https://cloud.google.com/docs/compare/aws/, 2019

    Google Cloud Platform for AWS professionals. https://cloud.google.com/docs/compare/aws/, 2019

    2019

  74. [83]

    https://wiki.seg.org/wiki/2004_BP_velocity_ estimation_benchmark_model, 2019

    2004 BP velocity estimation benchmark model. https://wiki.seg.org/wiki/2004_BP_velocity_ estimation_benchmark_model, 2019. 27

    2004

  75. [2009]

    doi: 10.1109/HPCSIM.2009.5192786

    2009

  76. [2014]

    URL https://arxiv.org/abs/1412.6980

    arXiv

Pith tools

Reviewed August 14, 2026 · model on record in the stance chip above.