Search

Rust and Julia are two modern languages aiming to advance computing in their unique way. Julia is a dynamic language striving to bridge the performance gap between dynamic languages like Python and statically typed ones like C/C++ while improving the ergonomics for scientific computing. Rust, on the other hand, is a statically typed language with a friendly compiler guiding developers to write reliable, correct, and concurrent code while ensuring memory safety and unlocking the highest performance. Both languages seem to be appealing to the scientific domain, especially because of their focus on performance. But choosing one depends on the type of your project. [ABSTRACT FROM AUTHOR]

Computational models lie at the heart of computational science, yet few scientists have a clear idea of what a computational model actually is. Is it software? Or an algorithm? How does it relate to mathematical models? What are suitable languages or notations for expressing a computational model in the literature? And will AI make computational models obsolete? [ABSTRACT FROM AUTHOR]

Experimental and observational sciences have developed robust practices for conducting experiments, maintaining their instruments, and record keeping for provenance. Computational science has only recently begun to confront the issue of quality of their instrument, the software, and the credibility of their scientific output. Most of the available literature in software engineering relates to enterprise software. While it can inform practices in scientific software, adjustments are usually needed. From time to time quality conscious practitioners have published collections of best practices for scientific software. This article provides one more such list but with updated suggestions, motivated by the need to keep up with the rapid changes in the computing industry. [ABSTRACT FROM AUTHOR]

Numba is a game-changing compiler for high-performance computing with Python. It produces machine code that runs outside of the single-threaded Python interpreter, and that fully utilizes the resources of modern CPUs. This means support for parallel multithreading and auto-vectorization if available, as with compiled languages such as C++ or Fortran. In this article, we document our experience developing PyExaFMM, a multithreaded Numba implementation of the fast multipole method, an algorithm with a nonlinear data structure and a large amount of data organization. We find that designing performant Numba code for complex algorithms can be as challenging as writing in a compiled language. [ABSTRACT FROM AUTHOR]

Scientific codes are complex software systems. Their engineering involves various stakeholders using various computer languages for defining artifacts at different abstraction levels and for different purposes. In this article, we review the overall processes leading to the development of scientific software, and discuss the role of computer languages in the definition of the different artifacts. We provide guidelines to make informed decisions when the time comes to choose a computer language to develop scientific software. [ABSTRACT FROM AUTHOR]

Python is a widely used language in scientific computing. When the goal is high performance, however, Python lags far behind low-level languages such as C and Fortran. To support applications that stress performance, Python needs to access the full capabilities of modern CPUs. That means support for parallel multithreading. In this article, we describe PyOMP, a system that enables OpenMP in Python. Programmers write code in Python with OpenMP, Numba generates code that compiles to LLVM, and the resulting programs run with performance that approaches that from code written with C and OpenMP. In this article, we provide an update on the PyOMP project and explain how to install it and use it to write parallel multithreaded code in Python. [ABSTRACT FROM AUTHOR]

Using a simple data analysis as an example, the author explores the relative merits of general-purpose library code and code written for a specific narrow application scenario. [ABSTRACT FROM AUTHOR]

If you have been following developments in software engineering in recent years, you have probably noticed that the term DSL (domain-specific language) has become a minor buzzword in that field. You may have concluded that this is a hot new idea that is certainly not ready for application in real life. But, as I will show in this article, computational scientists (and others) have been using DSLs for decades. What is new is not DSLs per se, but the name and the attention given to them. [ABSTRACT FROM AUTHOR]

Frustrated by another failed software installation? Wondering why you can't reproduce your colleagues' computations? This story will tell you why. It won't magically solve your problems, but it does point out a glimpse of hope for the future. [ABSTRACT FROM PUBLISHER]

Many of us write code regularly as part of our scientific activity, perhaps even as a full-time job. But even though we write--and use--more and more code, we rarely think about the roles that this code will have in our research, in our publications, and ultimately in the scientific record. In this article, the author outlines some frequent roles of code in computational science. These roles aren't exclusive; in fact, it's common for a piece of code to have several roles, at the same time or as an evolution over time. Thinking about these roles, ideally before starting to write the code, is a good habit to develop. [ABSTRACT FROM PUBLISHER]

Computers are the only research tools that by design exhibit chaotic behavior: a minimal change in the input to a computation can change its output in any imaginable way. Developers and users of scientific software should be aware of this feature and set up safety nets for protecting themselves against bad surprises. [ABSTRACT FROM PUBLISHER]

Technical debt is a useful metaphor for understanding the long-term impact of technical choices. The analysis of technical debt has found its place in the software industry, with results that are applicable to scientific software as well. But technical debt is also a useful concept to look at how we use computers in doing scientific research. [ABSTRACT FROM PUBLISHER]

Numerical solutions of mathematical equations in scientific models are the result of several approximation steps. Konrad Hinsen uses a simulation of the solar system as an example for illustrating these approximations and explaining their role in the difficult problem of testing scientific software. [ABSTRACT FROM AUTHOR]

Here, Konrad Hinsen talks about how one aspect of validating a piece of software is to check that it does what it's expected to do. But how do you write down your expectations? [ABSTRACT FROM AUTHOR]

Technology being developed right now in computer science labs might change the way scientists and engineers write programs in the future. [ABSTRACT FROM AUTHOR]

In the long run, your data matters more than your code. It's worth investing some effort to keep your data in good shape for years to come. [ABSTRACT FROM PUBLISHER]

Abstract: This proposal describes how data, program code, and presentation can be stored together in a single file suitable for electronic publication and permitting the reproduction of computational results.. Universality, effciency, platformindependence, automated verifiability, and provenance tracking are the major design criteria. Existing and well-tested technology is used as much as possible, the two major building blocks being the Hierarchical Data Format for storage and the Java Virtual Machine for platform-independent code representation and secure execution. [Copyright &y& Elsevier]

Did you ever think about what your ideal work environment for scientific programming would be like? Here's my version of it. [ABSTRACT FROM AUTHOR]