@conference {,
	title = {Preconditioners for Batched Iterative Linear Solvers on GPUs},
	booktitle = {Smoky Mountains Computational Sciences and Engineering Conference},
	volume = {169075},
	year = {2023},
	month = {2023-01},
	pages = {38 - 53},
	publisher = {Springer Nature Switzerland},
	organization = {Springer Nature Switzerland},
	abstract = {Batched iterative solvers can be an attractive alternative to batched direct solvers if the linear systems allow for fast convergence. In non-batched settings, iterative solvers are often enhanced with sophisticated preconditioners to improve convergence. In this paper, we develop preconditioners for batched iterative solvers that improve the iterative solver convergence without incurring detrimental resource overhead and preserving much of the iterative solver flexibility. We detail the design and implementation considerations, present a user-friendly interface to the batched preconditioners, and demonstrate the convergence and runtime benefits over non-preconditioned batched iterative solvers on state-of-the-art GPUs for a variety of benchmark problems from finite difference stencil matrices, the Suitesparse matrix collection and a computational chemistry application.},
	isbn = {978-3-031-23605-1},
	doi = {10.1007/978-3-031-23606-810.1007/978-3-031-23606-8_3},
	url = {https://link.springer.com/chapter/10.1007/978-3-031-23606-8_3},
	author = {Aggarwal, Isha and Nayak, Pratik and Kashi, Aditya and Anzt, Hartwig},
	editor = {Doug, Kothe and Al, Geist and Pophale, Swaroop and Liu, Hong and Parete-Koon, Suzanne}
}
@article {,
	title = {OpenMP application experiences: Porting to accelerated nodes},
	journal = {Parallel Computing},
	volume = {109},
	year = {2022},
	month = {2022-03},
	abstract = {As recent enhancements to the OpenMP specification become available in its implementations, there is a need to share the results of experimentation in order to better understand the OpenMP implementation{\textquoteright}s behavior in practice, to identify pitfalls, and to learn how the implementations can be effectively deployed in scientific codes. We report on experiences gained and practices adopted when using OpenMP to port a variety of ECP applications, mini-apps and libraries based on different computational motifs to accelerator-based leadership-class high-performance supercomputer systems at the United States Department of Energy. Additionally, we identify important challenges and open problems related to the deployment of OpenMP. Through our report of experiences, we find that OpenMP implementations are successful on current supercomputing platforms and that OpenMP is a promising programming model to use for applications to be run on emerging and future platforms with accelerated nodes.},
	issn = {01678191},
	doi = {10.1016/j.parco.2021.102856},
	url = {https://www.sciencedirect.com/science/article/pii/S0167819121001009},
	author = {Bak, Seonmyeong and Bertoni, Colleen and Boehm, Swen and Budiardja, Reuben and Chapman, Barbara M. and Doerfert, Johannes and Eisenbach, Markus and Finkel, Hal and Hernandez, Oscar and Huber, Joseph and Iwasaki, Shintaro and Kale, Vivek and Kent, Paul R.C. and Kwack, JaeHyuk and Lin, Meifeng and Luszczek, Piotr and Luo, Ye and Pham, Buu and Pophale, Swaroop and Ravikumar, Kiran and Sarkar, Vivek and Scogland, Thomas and Tian, Shilei and Yeung, P.K.}
}
@inproceedings {1306,
	title = {Evaluating Contexts in OpenSHMEM-X Reference Implementation},
	journal = {OpenSHMEM and Related Technologies. Big Compute and Big Data Convergence},
	year = {2018},
	pages = {50{\textendash}62},
	publisher = {Springer International Publishing},
	address = {Cham},
	abstract = {Many-core processors are now ubiquitous in supercomputing. This evolution pushes toward the adoption of mixed models in which cores are exploited with threading models (and related programming abstractions, such as OpenMP), while communication between distributed memory domains employ a communication Application Programming Interface (API). OpenSHMEM is a partitioned global address space communication specification that exposes one-sided and synchronization operations. As the threaded semantics of OpenSHMEM are being fleshed out by its standardization committee, it is important to assess the soundness of the proposed concepts. This paper implements and evaluate the {\textquoteleft}{\textquoteleft}context{\textquoteright}{\textquoteright} extension in relation to threaded operations. We discuss the implementation challenges of the context and the associated API in OpenSHMEM-X. We then evaluate its performance in threaded situations on the Infiniband network using micro-benchmarks and the Random Access benchmark and see that adding communication contexts significantly improves message rate achievable by the executing multi-threaded PEs.},
	isbn = {978-3-319-73814-7},
	doi = {https://doi.org/10.1007/978-3-319-73814-7_4},
	author = {Aurelien Bouteiller and Pophale, Swaroop and Swen Boehm and Baker, Matthew B. and Manjunath Gorentla Venkata},
	editor = {Manjunath Gorentla Venkata and Imam, Neena and Pophale, Swaroop}
}
@inproceedings {1308,
	title = {Surviving Errors with OpenSHMEM},
	journal = {OpenSHMEM and Related Technologies. Enhancing OpenSHMEM for Hybrid Environments},
	year = {2016},
	pages = {66{\textendash}81},
	publisher = {Springer International Publishing},
	address = {Baltimore, MD, USA},
	abstract = {Unexpected error conditions stem from a variety of underlying causes, including resource exhaustion, network failures, hardware failures, or program errors. As the scale of HPC systems continues to grow, so does the probability of encountering a condition that causes a failure; meanwhile, error recovery and run-through failure management are becoming mature, and interoperable HPC programming paradigms are beginning to feature advanced error management. As a result from these developments, it becomes increasingly desirable to gracefully handle error conditions in OpenSHMEM. In this paper, we present the design and rationale behind an extension of the OpenSHMEM API that can (1) notify user code of unexpected erroneous conditions, (2) permit customized user response to errors without incurring overhead on an error-free execution path, (3) propagate the occurence of an error condition to all Processing Elements, and (4) consistently close the erroneous epoch in order to resume the application.},
	isbn = {978-3-319-50995-2},
	author = {Aurelien Bouteiller and George Bosilca and Manjunath Gorentla Venkata},
	editor = {Manjunath Gorentla Venkata and Imam, Neena and Pophale, Swaroop and Mintz, Tiffany M.}
}
