- Bethel, E Wes;
- Loring, Burlen;
- Ayachit, Utkarsh;
- Camp, David;
- Duque, Earl PN;
- Ferrier, Nicola;
- Insley, Joseph;
- Gu, Junmin;
- Kress, James;
- O’Leary, Patrick;
- Pugmire, David;
- Rizzi, Silvio;
- Thompson, David;
- Weber, Gunther H;
- Whitlock, Brad;
- Wolf, Matthew;
- Wu, Kesheng
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.