This article demonstrates how scientists and engineers can use modern AI (artificial intelligence) tools such as ChatGPT and GitHub Copilot to learn computer programming skills that are relevant for their jobs. It begins by summarizing common ways that AI tools can already help people learn programming in general. Then it presents six learning opportunities that are catered to the needs of scientists and engineers, including using AI tools to 1) create customized programming tutorials for one’s own domain of work, 2) learn complex data visualization libraries, 3) learn to refactor exploratory code into more maintainable software, 4) learn about inherited legacy code, 5) learn new programming languages on-demand within the context of one’s workflow, and 6) question the assumptions that one’s scientific code is making. Taken together, these opportunities point toward a future where AI can help scientists and engineers learn programming on-demand within the context of their existing real-world workflows.

Our biology affects how we interact with the world, including how we learn new knowledge and respond to challenges. This article explores the impact of neurochemicals in our brain on learning and explains how to leverage our biology to improve education and problem-solving, focusing on computing education. Within this context, the article particularly examines the role of failure while learning. Learning, especially in technical fields, includes making errors on the path to success. While these errors trigger the necessary neurochemical conditions for rapid learning, these failures can also be demotivating. To gain the benefits of failure while mitigating its negative consequences, this article recommends evidence-based behavioral strategies for making the best out of failing while learning and designing for failure in learning environments.

There is a lot of focus on how Quantum Computing as an accelerator differs from other traditional HPC resources, including accelerators like GPUs and FPGAs. In classical computing, how to design the interfaces that connect the different layers of the software stack, from the applications and its high-level programming language description through compilers, schedulers, down to the hardware, and gate-level, has been critical. Likewise, quantum computing's interfaces enable the access to quantum technology as a viable accelerator. From the ideation of the quantum application to the manipulation of the quantum chip, each interface has its challenges. In this column feature, we discuss the structure of this set of quantum interfaces, their many similarities to the traditional HPC compilation stack, and how these interfaces impact the potential of quantum computers as HPC accelerators.

The paper Reproducibility of the First Image of a Black Hole in the Galaxy M87 from the Event Horizon Telescope (EHT) Collaboration by Patel et al. aims to reproduce the M87* imaging results presented by the Event Horizon Telescope (EHT) from observations made in 2017, as well as provide documentation and computational environments that allow others to reproduce the results more easily in the future. The paper gives an overview of the procedures used to generate the images, as well as clearly lays out what software and documentation is available by the collaboration and what is missing. The authors are able to qualitatively reproduce the results using scripts provided by the EHT collaboration, and quantitatively reproduce results that are similar to those presented by the collaboration. I recommend publication after addressing the following comments.

The paper Reproducibility of the First Image of a Black Hole in the Galaxy M87 from the Event Horizon Telescope (EHT) Collaboration by Patel et al. describes the steps required to reproduce the M87 black-hole image from data artifacts released by the EHT collaboration.  The paper also gives an overview of the applied software stacks and provides highly valuable containerized environments that enable easy execution of the three imaging pipelines that reproduce the ones from the EHT.  The authors succeed in generating images and compare their products (images and statistics) against the published results, generally finding consistent results. The paper also critically reviews the documentation and reproducibility efforts made by the EHT collaboration itself.I find the paper particularly interesting for two reasons:1.  It significantly lowers the entry barrier to EHT-type work and enables the public to redo the data processing steps behind the iconic black-hole image. Thus it can lead to increased participation in fundamental science and raise public interest in STEM research.2. The work itself is a case study of how to disseminate data and software products in practice and can serve as an example to future efforts.I recommend publications after incorporating the following suggestions, all of which should be straightforward to handle.Major commentsIt should also be stated what this paper is not.  It does not aim at an independent analysis of the EHT data since it only rebuilds the EHT pipelines.  As far as I am aware, parameter choices are adopted from the EHT papers.  It's important to point out this distinction in the paper. There have been several more or less independent analyses of the EHT data products by other groups (Arras et al., 2022; Carilli & Thyagarajan, 2022; Lockhart & Gralla, 2022; Miyoshi et al, 2022) and in particular the Myoshi work has found different results (prompting communications such as https://arxiv.org/pdf/2207.13279.pdf).  It could be easy to mis-quote the paper at hand for an independent analysis of the EHT results (as done by the EHT collaboration on their website(https://eventhorizontelescope.org/blog/imaging-reanalyses-eht-data), which should be avoided.  I recommend adding a paragraph to the introduction where the aforementioned independent analyses are cited and a distinction between reproduction and independent analysis is made explicit.I would like to hear the authors' perspective on how the extensive documentation needed to fully reproduce data products should be disseminated in an academic publishing process.  Surely the research papers themselves are not the right place.  Journals also often request DOIs for supplementary data.  Is this compatible with the containerized approach?  Further, in connection to funding agencies, FAIR principles are often requested (https://www.go-fair.org/fair-principles/) in research data management (RDM) plans.  An additional paragraph (e.g. in the conclusions) connecting this work with the RDM practices imposed by funding agencies and journals will be helpful to evaluate the practicability of the approach followed in this paper.The validation of the data leading to Figure 2 seems insufficient as it merely shows the integrity of the data timestamps, not the data itself.  The authors should comment on why this is sufficient, as the data itself (visibility phases and amplitudes) could still be tampered with.  Perhaps the authors could clarify the scope of the validation.  It is not clear by reading the manuscript how much interaction with EHT members was needed to reproduce the results.  Could the authors please point out where key information was not available in the publications/data release and input was needed?  A comment on reproducing the reproduced results: I have run all four Docker containers successfully but the eht-imaging one missed essential dependencies which I installed by hand (ehtim and matplotlib)... The authors should check their container (or find the one fixed by me here...)Minor commentsIn section "Reproducing the EHT Images", second paragraph, the authors state "... we only report the values with 0% systematic uncertainty". Please clarify to which systematic uncertainties you refer.  It isn't clear if there might be a fundamental problem reproducing systematic uncertainties. Do they need further information that is not available in the data products?  A brief clarification would help.  The DIFFMAP image statistics (Table 2) differs wildly from the original paper.  The corresponding statement in the paper,We also find a larger difference between the original and reproduced values for the DIFFMAP pipeline: this is consistent with the discussion of the different time averaging used in DIFFMAPdoes not clarify. Please expand on your explanation, how does time averaging come into play in DIFFMAP? 

At GTC 2022 Nvidia announced a new product family that aims to cover from small enterprise workloads through exascale HPC and trillion-parameter AI models. This column highlights the most interesting features of their new Hopper GPU and Grace CPU computer chips and the Hopper product family. We also discuss some of the history behind Nvidia technologies and their most useful features for computational scientists such as the Hopper DPX dynamic programming  instruction set, increased number of SMs, and FP 8 tensor core availability. Also included are descriptions of the new Hopper Clustered SMs architecture and updated NVSwitch technologies that integrates their new ARM-based Grace CPU. 

Introduction Most people tend to shy away from conversations around mental health. This is due to the stigma that is rooted in the long mistreatment of people with mental illness. In this article, I aim to bring conversations about mental health to the forefront and advocate for a change in culture so that the field of computing better supports the mental health of the community and is more inclusive of people with mental illness.

The is a research and education center that supports software development in the . One of ’s core objectives is to provide education and training for the next generation of computational researchers. Education targets various career stages and skill levels through its live workshops, online resources, and software fellowship program. Education focuses its efforts within four areas: programming and software development, and , faculty and curriculum development, and the software fellowship program. This article delineates educational efforts at the , overall goals, and resources that can be useful to researchers in the computational molecular sciences.

With the advent of distributed computing, the need for frameworks that facilitate its programming and management has also appeared. These tools have typically been used to support the research on application areas that require them. This poses good initial conditions for Translational Computer Science (TCS), although this does not always occur. This paper describes our experience with the PyCOMPSs project, a programming model for distributed computing. While it is a research instrument for our team, it has also been applied in multiple real use cases under the umbrella of European Funded projects or as part of internal projects between various departments at the Barcelona Supercomputing Center (BSC). The paper illustrates how the authors have engaged in TCS as an underlying research methodology, collecting experiences from three European projects.

If we knew many terms and phrases we commonly use such as, for example, sanity check, grandfathered, ladies and gentlemen or low man on the totem pole can discourage coworkers, colleagues, collaborators and other potential contributors from participating in our projects with their full authentic selves, would we still use them?

As cloud computing grows,  the types of computational hardware available in the cloud are diversifying. Field Programmable Gate Arrays (FPGAs) are a relatively new addition to high-performance computing in the cloud, with the ability to accelerate a range of different applications, and the flexibility to offer different cloud computing models. A new and growing configuration is to have the FPGAs directly connected to the network and thus reduce the latency in delivering data to processing elements. We survey the state-of-the-art in FPGAs in the cloud and present the Open Cloud Testbed (OCT), a testbed for research and experimentation into new cloud platforms, which includes network-attached FPGAs in the cloud.  

High-performance computing (HPC) storage systems are a key component of the success of HPC to date. Recently, we have seen major developments in storage-related technologies, as well as changes to how HPC platforms are used, especially in relation to artificial intelligence and experimental data analysis workloads. These developments merit a revisit of HPC storage system architectural designs. In this paper we discuss the drivers, identify key challenges to status quo posed by these developments, and discuss directions future research might take to unlock the potential of new technologies for the breadth of HPC applications.

The Digital Imaging and Vision Applications in Science (DIVAS) program was built to improve the computational self-efficacy and skill of first- and second-year college students majoring in biological and chemical sciences. Our three-year pilot study showed that the program could be successful in both fronts. The scholars, faculty, and staff who participated formed a community of practice that became the heart of the DIVAS program. Through this community, we expanded access to the image processing workshop in collaboration with The Carpentries, supported faculty and secondary educators in developing computing modules for their classrooms, and created and staffed a "writing center for computing" on the host campus. Overall, the DIVAS program has sparked a local computing culture. DIVAS interventions and resources are freely available for adoption by other institutions. We hope to grow the community in a way that builds student access and opportunities and supports educators in the process.

The integrity of science and engineering research is grounded in assumptions of rigor and transparency on the part of those engaging in such research. HPC community effort to strengthen rigor and transparency take the form of reproducibility efforts. In a recent survey of the SC conference community, we collected information about the SC Reproducibility Initiative activities. We present the survey results in this paper. Results show that the reproducibility initiative activities have contributed to higher levels of awareness on the part of SC conference technical program participants, and hint at contributing to greater scientific impact for the published papers of the SC conference series. Stringent point-of-manuscript-submission verification is problematic for reasons we point out, as are inherent difficulties of computational reproducibility in HPC. Future efforts should better decouple the community educational goals from goals that specifically strengthen a research work's potential for long-term impact through reuse 5-10 years down the road.

IntroductionMost scientific disciplines are facing exponentially increasing amounts of data, which require scalable interactive scientific visualization technology. The development of massively parallel graphics processing units (GPU), fostered by the video game industry and artificial intelligence, represents a remarkable opportunity in this respect.Real-time computer graphics technology has been used in scientific visualization for decades, mostly via OpenGL, a popular open-source graphics library created in 1992. It has been used by many video games, graphics applications, and scientific visualization software. During its first decade, OpenGL provided a fixed function pipeline that was simple to use, but not particularly powerful because of the lack of control of the rendering pipeline. In 2004, OpenGL 2.X introduced a programmable pipeline that gave the user a way to customize the various stages of rendering. Since then, there have been various open-source libraries providing OpenGL-based scientific visualization, mostly focused on 3D rendering. Mayavi is a popular example in Python \cite{Ramachandran_2011}.In 2013, Luke Campagnola, Almar Klein, Cyrille Rossant, and Nicolas P. Rougier wrote a new visualization library: VisPy \cite{np2015}. This library took full advantage of the GL ES 2.x API to achieve both fast and scalable rendering of the most common plotting objects, in both 2D and 3D (lines, scatters, images, colormaps, volumes, meshes, etc.). Within a few years, VisPy reached a large scientific audience and became the main real-time 2D/3D scientific rendering library in Python.Although usage of OpenGL is still widespread in the graphics and scientific communities for legacy reasons, the industry is steadily moving to newer low-level graphics APIs such as Vulkan (Khronos), WebGPU (W3C), Metal (Apple), and DirectX 12 (Microsoft). In this context, VisPy is now facing the same problem as Mayavi faced a few years back: it must decide on its future.The Khronos group introduced the Vulkan API in 2016 (https://www.khronos.org/news/press/khronos-releases-vulkan-1-0-specification). This has been a complete redesign from the ground up to give much more control (compared to OpenGL) and to support all features of the latest GPU hardware. However, Vulkan has a huge barrier to entry: drawing a simple triangle using the Vulkan API directly involves about a thousand lines of code. In particular, all the logic related to the presentation of images to the screen, using a swapchain for double- or triple-buffering, all the synchronization of the different GPU tasks and CPU-GPU interactions in the main rendering loop must be done manually. To leverage the power of Vulkan for applications such as scientific visualization, there is thus a crucial need for intermediate-level libraries that drastically simplify the access to Vulkan.One potential solution isbe to use existing rendering engines such as Ogre (https://www.ogre3d.org/), Unity (https://unity.com/), or Unreal (https://www.unrealengine.com/). However, although scientific visualization and video games do share many similarities, they are quite different in their ends. Games are generally highly dynamic and interactive, whereas scientific visualization is much more static and less interactive (to some extent) and can be indifferently 1D, 2D, or 3D. Furthermore, scientific visualization involves a number of concepts that are generally not present in game engines, such as colormaps, labeled axes, non-cartesian projections, image interpolations, etc. Scientific visualization must also be faithful to the data and this requires a highly precise rendering to achieve high representational accuracy. Besides, it is not unusual to render millions or even billions of points in a scientific visualization — while a modern GPU has no problem rendering such a large collection, the corresponding API must be aware of such extreme cases to ensure proper rendering. All these limitations disqualify typical video game rendering engines as a general purpose API for scientific visualization.This exposes a crucial need for a rendering engine that is to scientific visualization what game engines are to video games: an intermediate-level library that allows developers of custom scientific visualizations, or developers of high-level plotting libraries, to leverage Vulkan without delving into an incredibly complicated low-level API. We report here progress that we have made in the past couple of years towards a cross-platform, cross-language scientific visualization engine that leverages Vulkan for scalable, low-overhead, high-performance scientific visualization.

The March/April issue of CiSE's inaugural year (1999) carried an essay by eminent computer science professor John R. Rice (who at the time was area editor for Software, together with Matlab inventor Cleve Moler) titled A Perspective on Computational Science in the 21st Century \cite{Rice_1999}. In it, he looked at the development directions for the future of computational science and engineering, and threaded across these was what he called "problem-solving environments." This routine-sounding term hides an ambitious vision, for the time. Rice imagined a software system for tackling problems within a science domain without all the agonizing toil of programming by hand every solution method. He and Ronald Boisvert had a previous article (1996) explaining the idea in more detail \cite{Rice_1996}. A problem-solving environment would include a collection of mathematical and domain-specific software libraries, offer (semi-)automatic selection of solution method for a given problem, help check the problem formulation, display or assess the correctness of solutions, allow extensibility to add new methods, and even manage the overall computational process. They envisaged an environment that could be "all things to all people," meaning: it is effective when solving simple or complex problems, it supports rapid prototyping and detailed analysis, and it can be used both in introductory teaching and in productive research at the edges of knowledge. An ideal problem-solving environment would even make decisions for the user by means of an integrated knowledge base. What fabulous ambition!Prof. Rice led a research group at Purdue University that worked to develop early problem-solving environments. The Ellpack system for solving elliptic boundary value problems, developed in the early 1980s, included dozens of software modules implementing solution methods and a descriptive language to formulate problems (today, we might call it a domain-specific language, DSL). For example, the line: equation. uxx + uyy + 3 * ux - 4 * u = exp(x+y) * sin(pi * x) would be used in an Ellpack program for defining the differential equation to be solved. Similarly expressive statements would define the boundary conditions, and the grid parameters to discretize the domain (a full example at https://www.cs.purdue.edu/ellpack/example.html). Later versions of the system offered parallel solvers and a graphical user interface (screenshots of the Ellpack system from Prof. John R. Rice's website at Purdue can be found in the Internet Archive https://web.archive.org/web/19990506040312/https://www.cs.purdue.edu/research/cse/index.html).While Ellpack was licensed by Purdue University for a modest yearly fee, this project did not branch off commercially or otherwise. Perhaps a few hundred copies were distributed, mostly for use in university settings, and the project wound down by the early 2000s. By contrast, three commercial software packages for high-productivity scientific and engineering computation—Maple, Mathematica, and Matlab—had by then become very popular \cite{Chonacky_2005}. These systems continue to be widely used in education, industry, and government settings. Their purchase price and proprietary implementations, however, led many champions of open-source software to conceive alternatives, oftentimes closely imitating their functionality.In March/April 2011, twelve years after Prof. Rice's Perspective essay, CiSE ran a special issue on Python for Scientific Computing, showcasing a maturing stack of tools and a highly productive environment for researchers. The issue included one of the most-widely cited articles in the history of the magazine, discussing the high-level multidimensional array structure at the core of NumPy \cite{van_der_Walt_2011}. By this time, the scientific community had expanded Python for its purposes, and the four keystone libraries had been put in place in the first half of the decade: SciPy was consolidated as a standard collection of modules for common mathematical and statistical functions.The first version of IPython, an enhanced interactive shell for Python, was created by Fernando Pérez.Matplotlib, the rich 2D visualization and now standard Python plotting library, was released by John Hunter.Travis Oliphant created NumPy from a rewrite of the early Python array library Numeric, adding functionality from the competing array package called numarray.CiSE had previously featured the developing Python support for scientific workflows in an issue organized by Paul F. Dubois, who was the project lead for Numeric from 1997 to 2002. Paul was an editor for Computer in Physics (which got merged into CiSE) since 1993, and joined CiSE with its founding. He wrote and edited for the Scientific Programming department until 2006, and continued with the column "Café Dubois" until 2008. The issue he led included the Hunter piece on Matplotlib \cite{Hunter_2007}, the Pérez and Granger article about IPython \cite{Perez_2007}, and Travis Oliphant's general overview of the Python language and its extensions with NumPy and SciPy \cite{Oliphant_2007}. Other articles in the issue highlight applications in various science contexts: space observation, systems biology, robotics, nanophotonics, and more. An author team from the Simula Research Laboratory in Norway discussed new Python tooling for solving partial differential equations with finite element methods in what was the early development of the Fenics project (http://www.fenics.org/) \cite{Mardal_2007}. This work heralded the compelling combination of symbolic mathematics and code generation, which Ellpack anticipated.

Using simulations for scientific discovery requires that the software used in the simulations undergoes a rigorous design and development process similar to that of the lab instruments in the experimental sciences. To devise a good design methodology it is critical to understand the requirements, constraints and challenges. This article describes insights from the long-term stewardship of a multiphysics multicomponent software, FLASH, that was designed more than 20 years ago for astrophysics, now serves multiple communities, and has been successful in adapting to the changing world of high-performance computing.

Guest Editors’ IntroductionNotebook interfaces – documents combining executable code with output and notes – first became popular as part of computational mathematics software such as Mathematica and Maple. The Jupyter Notebook, which began as part of the IPython project in 2012, is an open source notebook that can be used with a wide range of general-purpose programming languages.Before notebooks, a scientist working with Python code, for instance, might have used a mixture of script files and code typed into an interactive shell. The shell is good for rapid experimentation, but the code and results are typically transient, and a linear record of everything that was tried would be long and not very clear. The notebook interface combines the convenience of the shell with some of the benefits of saving and editing code in a file, while also incorporating results, including rich output such as plots, in a document that can be shared with others.The Jupyter Notebook is used through a web browser. Although it is often run locally, on a desktop or a laptop, this design means that it can also be used remotely, so the computation occurs, and the notebook files are saved, on an institutional server, a high performance computing facility or in the cloud. This simplifies access to data and computational power, while also allowing researchers to work without installing any special software on their own computer: specialized research software environments can be provided on the server, and the researcher can access those with a standard web browser from their computer.These advantages have led to the rapid uptake of Jupyter notebooks in many kinds of research. The articles in this special issue highlight this breadth, with the authors representing various scientific fields. But more importantly, they describe different aspects of using notebooks in practice, in ways that are applicable beyond a single field.We open this special issue with an invited article by Brian Granger and Fernando Perez – two of the co-founders and leaders of Project Jupyter. Starting from the origins of the project, they introduce the main ideas behind Jupyter notebooks, and explore the question of why Jupyter notebooks have been so useful to such a wide range of users. They have three key messages. The first is that Notebooks are centered around the humans using them and building knowledge with them. Next, notebooks provide a write-eval-think loop that lets the user have a conversation with the computer and the system under study, which can be turned into a persistent narrative of computational exploration. The third idea is that Project Jupyter is more than software: it is a community that is nourished deliberately by its members and leaders.The following five articles in this special issue illustrate the key features of Project Jupyter effectively. They show us a small sample of where researchers can go when empowered by the tool, and represent a range of scientific domains.Stephanie Juneau et al. describe how Jupyter has been used to ‘bring the compute to the data’ in astrophysics, allowing geographically distributed teams to work efficiently on large datasets. Their platform is also used for education & training, including giving school students a realistic taste of modern science.Ryan Abernathey et al. , of the Pangeo project, present a similar scenario with a focus on data from the geosciences. They have enabled analysis of big datasets on public cloud platforms, facilitating a more widely accessible ‘pay as you go’ style of analysis without the high fixed costs of buying and setting up powerful computing and storage hardware. Their discussion of best practices includes details of the different data formats required for efficient access to data in cloud object stores rather than local filesystems.Marijan Beg et al. describe features of Jupyter notebooks and Project Jupyter that help scientists make their research reproducible. In particular, the work focuses on the use of computer simulation and mathematical experiments for research. The self-documenting qualities of the notebook—where the response to a code cell can be archived in the notebook—is an important aspect. The paper addresses wider questions, including use of legacy computational tools, exploitation of HPC resources, and creation of executable notebooks to accompany publications.Blaine Mooers describes the use of a snippet library in the context of molecular structure visualization. Using a Python interface, the PyMOL visualization application can be driven through commands to visualize molecular structures such as proteins and nucleic acids. By using those commands from the Jupyter notebook, a reproducible record of analysis and visualizations can be created. The paper focuses on making this process more user-friendly and efficient by developing a snippet library, which provides a wide selection of pre-composed and commonly used PyMOL commands, as a JupyterLab extension. These commands can be selected via hierarchical pull-down menus rather than having to be typed from memory. The article discusses the benefits of this approach more generally.Aaron Watters describes a widget that can display 3D objects using webGL, while the back-end processes the scene using a data visualization pipeline. In this case, the front-end takes advantage of the client GPU for visualization of the widget, while the back-end takes advantage of whatever computing resources are accessible to Python.The articles for this special issue were all invited submissions, in most cases from selected presentations given at JupyterCon in October 2020. Each article was reviewed by three independent reviewers. The guest editors are grateful to Ryan Abernathey, Luca de Alfaro, Hannah Bruce MacDonald, Christopher Cave-Ayland, Mike Croucher, Marco Della Vedova, Michael Donahue, Vidar Fauske, Jeremy Frey, Konrad Hinsen, Alistair Miles, Arik Mitschang, Blaine Mooers, Samual Munday, Chelsea Parlett, Prabhu Ramachandran, John Readey, Petr Škoda and James Tocknell for their work as reviewers, along with other reviewers who preferred not to be named. The article by Brian Granger and Fernando Perez was invited by the editor in chief, and reviewed by the editors of this special issue.Hans Fangohr is currently heading the Computational Science group at the Max Planck Institute for the Structure and Dynamics of Matter in Hamburg, Germany, and is a Professor of Computational Modelling at the University of Southampton, UK. A physicist by training, he received his PhD in Computer Science in 2002. He authored more than 150 scientific articles in computational science and materials modelling, several open source software projects, and a text book on Python for Computational Science and Engineering. Contact him at hans.fangohr@mpsd.mpg.deThomas Kluyver is currently a software engineer at European XFEL. Since gaining a PhD in plant sciences from the University of Sheffield in 2013, he has been involved in various parts of the open source & scientific computing ecosystems, including the Jupyter & IPython projects. Contact him at thomas.kluyver@xfel.euMassimo Di Pierro is a Professor of Computer Science at DePaul University. He has a PhD in Theoretical Physics from the University of Southampton and is an expert in Numerical Algorithms, High Performance Computing, and Machine Learning. Massimo is the lead developer of many open source projects including web2py, py4web, and pydal. He has authored more than 70 articles in Physics, Computer Science, and Finance and has published three books. Contact him at massimo.dipierro@gmail.com