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 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.

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.

U.S. computing leaders, including the National Science Foundation, have partnered with universities, government agencies, and the private sector to accelerate research into responses to COVID-19 – providing an unprecedented collection of resources that include some of the fastest computers in the world. This current work expands on last month's Leadership Computing article by continuing to showcase the range of contributions that the national cyberinfrastructure is making to global efforts to stop the pandemic. This article touches on research efforts to learn how SARS-CoV-2 spreads among different populations, the biology and structure of the virus and its mechanisms of infection, and to develop effective vaccines for prevention and antiviral therapies for treatment. Even though we are still early in the process of developing an effective therapeutic response, the rapid mobilization of the national research cyberinfrastructure is a timely reminder of the strategic importance of robust, ongoing investments in large-scale scientific computing.

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.

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?

IntroductionDeep learning (DL) has emerged as a powerful tool to solve a variety of complex problems that have been difficult to solve with traditional methods. However, domain experts attempting to apply  DL methodology have to learn to code in order to use it. Numerous frameworks have been developed, such as TensorFlow and PyTorch, that simplify the task of building and training complex DL models, yet their efficient use requires a good working knowledge of Python language.  Consequently, a variety of tools have been developed that provide easier to use DL models, ranging from the Keras API built on top of TensorFlow that still requires coding, to tools such as H2O that provide a point-and-click web-based interface to configure and train pre-built models. Among this new breed of tools, IBM Visual Insights (formerly IBM PowerAI Vision) \cite{120} and Google's AutoML Vision \cite{AutoML.Vision} have taken this concept further by providing a web-based graphical user interface (GUI) for configuring and training a variety of models, as well as tools and APIs for deploying these models on a variety of platforms.  Both IBM Visual Insights and Google AutoML Vision implement complex workflows that connect together many services and computational resources to deliver complex functionality that until recently required a substantial coding effort. The functionality of these tools is still limited to just a few pre-arranged models that work well only for specific problems.  The users are also restricted to tweak only some model parameters while leaving majority of the decisions to the computer.  Yet these tools democratize access to complex DL models and empower  domain scientists to take advantage of this new methodology.  In this short article, we walk through an example of using  IBM Visual Insights to train a DL model on a  chest X-ray image dataset.  Google's AutoML Vision's applicability to medical problems has been discussed in \cite{FAES2019e232}.   

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.

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.

In our editorial launching the new Reproducible Research Track in CiSE \citep*{Barba_2017} , we promised to explore innovations to the peer-review process. Because we require articles submitted to this track to adhere to practices that safeguard reproducibility, we must review for these aspects deliberately. For each submission, a reproducibility reviewer will be charged with checking availability, quality and usability of digital artifacts (data, code, figures). This reviewer (sometimes one of the track editors) will be known to the authors, and may interact with the authors during the review—for example, opening issues on a code repository. For this service, we ask that the authors recognize the reviewer in the article's acknowledgements section.

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.

SummaryThis is the editor's review of manuscript CiSESI-2018-02-0013, submitted to Computing in Science & Engineering, Reproducible Research Track: "automan: a Python-based, automation framework for numerical computing"  \citep{p2018b}.We received two peer-review reports for this manuscript, and the reviewers were: Thomas Pasquier and Olivier Mesnard. Both reviewers recommended that the manuscript be accepted with a minor revision, and I agree. Reviewer 1 comments on software-engineering aspects: he asks if automan could be combined with continuous integration tool chains. He also asks to state plainly the license of automan—from the LICENSE.txt file in the GitHub repository, it looks like it’s under BSD3, but you could state this in the README and in the paper. Reviewer 2 acted as Reproducibility Reviewer. He inspected the code repository of automan, installed it, and tested it with a fabricated problem. He also provides several minor suggestions in his open report \citep{o2018}.Editor's reviewOne issue that the author needs to correct is the terminology. The CiSE RR Track adopted a set terminology that we request authors to consistently apply. See the Call for Papers \citep{g2018}.Citing from there:Reproducible research is defined as research in which authors provide all the necessary data and the computer codes to run the analysis again, re-creating the results. Replication, on the other hand, is defined as arriving at the same scientific findings as another study, collecting new data (possibly with different methods), and completing new analyses.Throughout the manuscript, the author is using “repeatability” and “repeating” in place of “reproducibility” and “reproducing.” Conflicting terminology is a source of confusion in the field, and the CiSE RR editors want consistent usage in the magazine.I also recommend reading: “Re-run, Repeat, Reproduce, Reuse, Replicate…” \citep{Benureau_2018}AbstractCiSE articles don’t normally carry a standard abstract. Instead, a short “blurb” appears under the title, usually about three sentences long, to pull focus. Please edit the abstract down, in line with this style. Here's a starting point for your editing (or simply re-use this, if you like it):Automating computational workflows leads to more reproducible research. The Python tool automan assembles a suite of long-running computations, deploys them to your computational resources, and produces final plots from output data, all with a single command.Introduction and DiscussionIn the Introduction, you say “What is perhaps more important is that we discovered that [reproducibility] can be very profitable to the researcher.” The paper then goes into the design details and explains the usage of automan in section 3, and you wrap up with a summary in the first paragraph of section 4 (Discussion). Towards the end, the Discussion explains how automan helped you manage a series of about 75 computational experiments with SPH schemes. But I miss here a stronger, more persuasive statement about how automan expedited and ensured quality of the research (it doesn’t help that the paragraph in question is plagued with passive phrases). I would like it if you re-wrote this passage to reveal more about your own experience, and how you benefitted from the tool you created. Convince your readers here that the initial overhead of setting up automan for their simulation-based workflow will pay off!Editorial / style requestsThe manuscript is well written, overall, but a few small improvements would polish it further. In CiSE, we aim for a more readable style than typical scholarly literature. In line with that, I want to encourage you to especially look at whether any passive constructions are strictly necessary, and look to remove syntactic-expletive phrases like “there are,” if you can, as well as superfluous adverbs and superlatives (e.g., clearly, very).Examples:First sentence! “It is well known that…” You can easily remove that, and combine the first two sentences: “Reproducibility is a cornerstone in all science fields, and is vitally important in computational science.”p. 1, l. 39: “Unfortunately, there are not many immediate or direct incentives for a researcher to invest time…” >> “Unfortunately, researchers have few immediate or direct incentives to invest time…”p. 1, l. 41: “there can be significant challenges involved in [reproducing] and replicating numerical experiments” >> “reproducing and replicating numerical experiments involves serious challenges” (or another adjective, but don’t use “significant” unless you mean statistically significant, to avoid misunderstanding).p. 1, l. 45: “we believe this is a very important step in facilitating reproducible research” >> This step is important for facilitating reproducible research” (the terminology here is consistent with CiSE usage).p. 1, l. 46: “The approach used in our automation framework is fairly general” >> “Our automation framework typifies a general approach”p. 1, .. 49: “[reproducibility] can be very profitable to the researcher” (remove “very”)p. 1, l. 51: “It is our hope that” >> “We hope that"— The fact that we can pick several examples from just the first two paragraphs shows that you could polish the manuscript by combing through the text looking for just these patterns. I expect about a 5–10% reduction in word count from this exercise!p. 10, l. 40: Bad sentence: “It is important to note again that the commands that are executed such that one may configure the directory in which they will generate output using a command line argument.” Typos:Title: you don’t need the comma.p. 1, l. 38: “some of [the] most important articles” (missing “the”)p. 3, l. 21: capitalize DockerSoftware AppendixAs indicated in the Call for Papers: “articles will include an appendix reporting on the software engineering and data management practices followed by the authors.” Please add a description to that effect, in the form of a brief Appendix.Extended AcknowledgementIn the short statement on "Peer review in the CiSE RR Track" \citep{Barba}, we describe our ambitions for opening up the peer-review process in this track. Your reviewers opted in to open identity and open reports. We ask that you recognize reviewers by name in an extended acknowledgements section, briefly stating their contribution to your paper. You can cite the open reports with the URL or DOI, in each case.ReferencesPlease provide DOIs wherever possible for all references.For Ref. [1], please add DOI of the PDF version of this blog post, published on Figshare (10.6084/m9.figshare.4879928.v1).For Ref. [8], please update the citation, as needed.

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.

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.

SummaryThis is the editor’s review of manuscript CiSESI-2018-02-0016: “CoRR — The Cloud of Reproducible Records,” submitted to Computing in Science and Engineering Reproducible Research (RR) Track. We requested via email to the corresponding author that a preprint be made available on arXiv or an equivalent service, but did not receive a reply. It is policy of the RR Track to require a preprint; see our launch editorial \citep*{Barba_2017}.

In 1995, just one year after the founding of IEEE Computational Science & Engineering—the precursor of CiSE—founding editor-in-chief Ahmed H. Sameh wrote that the board's goal was "making this magazine the flagship of all aspects of computational science and engineering" \cite{sameh1995}.  What was it like at the time? 1995 marks the beginning of the dot-com boom. That year, Amazon and eBay first opened their digital doors, the Intel Pentium Pro was released, IBM unveiled Deep Blue, and the NumPy library for array computing in Python was first introduced. It was also the year that Peter Norvig and Stuart Russell published their classic textbook on Artificial Intelligence \cite{russell1995}. And the University of Texas at Austin established its program in computational and applied mathematics, which J. Tinsley Oden announced in CS&E \cite{Oden_1995}. The dozen tenure-track positions opened with the new program and institute were housed in the departments of mathematics, computer science, engineering mechanics, aerospace engineering and other engineering specialties. It was conceived as a broadly interdisciplinary program, and that has been the hallmark of computational science and engineering across time.

Review the manuscript CiSESI-2018-02-0013 for _Computing in Science & Engineering_: _"automan: a Python-based, automation framework for numerical computing"_ (Ramachandran, 2018). The manuscript describes an open-source Python-based library, called automan, to automate scientific computational workflow. automan is open-source with a permissive license (BSD 3-clause), hosted on GitHub (developing the code in the open under a version-control system). The manuscript was made available on arXiv (https://arxiv.org/abs/1712.04786) before submission to CiSE and serves as API documentation for the Python package. The main purpose of automan is to automate a computational research manuscript: it provides a Python framework to assemble and run simulations (on local or distributed machines) and to generate figures from the data produced by those simulations. With automan, a user has the possibility to re-create all figures used in a research paper with one command line (as envisioned by ). The content of the manuscript perfectly fits into the types of submission sought by the RR track of CiSE (). The author gives an extensive review of already existing frameworks to automate workflows, leading to a clear explanation on the need for a new tool such as automan. As mentioned in the manuscript, automan has already been used by the author to automate the generation of the figures in an other manuscript (under review) that compares different Smoothed Particle Hydrodynamics schemes (to simulate incompressible fluid flow problems). The examples provided in the manuscript are well detailed such that it is easy for the users to adopt automan for their own workflow. As part of the review for the manuscript, I successfully installed automan and created a toy problem to test the features of the package. I used an in-house two-dimensional panel-method code (written in Python) to compute and compare the surface pressure coefficient on a series of NACA airfoils are different angles of attack. automan is modular enough such that I did not have to re-run the simulations if I was only creating/tweaking the post-processing code to create figures. When needed, I was also able to re-run only specific simulations (and not the entire batch). I created a public GitHub repository (https://github.com/mesnardo/automan-example) that contains the input files and Python scripts used to test automan. Finally, I would like to point out that automan helps users to make their computational workflow reproducible, but does not guarantee numerical reproducibility of the results. As mentioned by the author, automan does not capture the working environment (software versions, dependencies, etc.) The manuscript should be ACCEPTED AFTER MINOR REVISIONS. Following is a list of suggestions/modifications the author should address: 1. I think the author should favor the term "reproducibility" instead of "repeatability". The meanings of "reproducibility" and "replication" are clearly defined in the highly cited paper from . To add more clarity, the author could recall the definition the "reproducibility" and "reproducible workflow" in the introduction section. 2. As mentioned by the author in the discussion section, automan is a "very young package". Thus, it is very likely that the core of the package and/or the API will change in the future. Therefore, the author should mention the release version of automan on which the manuscript is based. 3. (p.1, l.47) Could the author add in the introduction the license under which the code is being developed and released (BSD 3-clause license)? 4. (p.3, l.31) The term "exactly similar" is too strong to describe a re-implementation of a feature that already exists in luigi. Maybe the author could remove the word "exactly". 5. (p.13, l.12) Small typo ("elgant" -> "elegant"). 6. (p.7, l.53; l.26 in Listing 1) I think the name of the method is make_output_dir, instead of make_output_directory. 7. (p.9, l.5) It was not clear to me which folders or directories I should delete to re-run a completed simulation. It would be interesting to add a command-line instruction as an example. 8. Although this is probably outside the scope for this submission, the developer could use a tool, such as Doxygen or Sphinx, to write the API documentation.

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.