TY - CHAP
T1 - The SENSEI Generic In Situ Interface
T2 - Tool and Processing Portability at Scale
AU - Bethel, E. Wes
AU - Loring, Burlen
AU - Ayachit, Utkarsh
AU - Camp, David
AU - Duque, Earl P.N.
AU - Ferrier, Nicola
AU - Insley, Joseph
AU - Gu, Junmin
AU - Kress, James
AU - O’Leary, Patrick
AU - Pugmire, David
AU - Rizzi, Silvio
AU - Thompson, David
AU - Weber, Gunther H.
AU - Whitlock, Brad
AU - Wolf, Matthew
AU - Wu, Kesheng
N1 - Publisher Copyright:
© 2022, The Author(s), under exclusive license to Springer Nature Switzerland AG.
PY - 2022
Y1 - 2022
N2 - One key challenge when doing in situ processing is the investment required to add code to numerical simulations needed to take advantage of in situ processing. Such instrumentation code is often specialized, and tailored to a specific in situ method or infrastructure. Then, if a simulation wants to use other in situ tools, each of which has its own bespoke API [4], then the simulation code team will quickly become overwhelmed with having a different set of instrumentation APIs, one per in situ tool or method. In an ideal situation, such instrumentation need happen only once, and then the instrumentation API provides access to a large diversity of tools. In this way, a data producer’s instrumentation need not be modified if the user desires to take advantage of a different set of in situ tools. The SENSEI generic in situ interface addresses this challenge, which means that SENSEI-instrumented codes enjoy the benefit of being able to use a diversity of tools at scale, tools that include Libsim, Catalyst, Ascent, as well as user-defined methods written in C++ or Python. SENSEI has been shown to scale to greater than 1M-way concurrency on HPC platforms, and provides support for a rich and diverse collection of common scientific data models. This chapter presents the key design challenges that enable tool and processing portability at scale, some performance analysis, and example science applications of the methods.
AB - One key challenge when doing in situ processing is the investment required to add code to numerical simulations needed to take advantage of in situ processing. Such instrumentation code is often specialized, and tailored to a specific in situ method or infrastructure. Then, if a simulation wants to use other in situ tools, each of which has its own bespoke API [4], then the simulation code team will quickly become overwhelmed with having a different set of instrumentation APIs, one per in situ tool or method. In an ideal situation, such instrumentation need happen only once, and then the instrumentation API provides access to a large diversity of tools. In this way, a data producer’s instrumentation need not be modified if the user desires to take advantage of a different set of in situ tools. The SENSEI generic in situ interface addresses this challenge, which means that SENSEI-instrumented codes enjoy the benefit of being able to use a diversity of tools at scale, tools that include Libsim, Catalyst, Ascent, as well as user-defined methods written in C++ or Python. SENSEI has been shown to scale to greater than 1M-way concurrency on HPC platforms, and provides support for a rich and diverse collection of common scientific data models. This chapter presents the key design challenges that enable tool and processing portability at scale, some performance analysis, and example science applications of the methods.
UR - http://www.scopus.com/inward/record.url?scp=85130092876&partnerID=8YFLogxK
U2 - 10.1007/978-3-030-81627-8_13
DO - 10.1007/978-3-030-81627-8_13
M3 - Chapter
AN - SCOPUS:85130092876
T3 - Mathematics and Visualization
SP - 281
EP - 306
BT - Mathematics and Visualization
PB - Springer Science and Business Media Deutschland GmbH
ER -