Search for: All records

Multi-messenger astrophysics has produced a wealth of data with much more to come in the future. This enormous data set will reveal new insights into the physics of core-collapse supernovae, neutron star mergers, and many other objects where it is actually possible, if not probable, that new physics is in operation. To tease out different possibilities, we will need to analyze signals from photons, neutrinos, gravitational waves, and chemical elements. This task is made all the more difficult when it is necessary to evolve the neutrino component of the radiation field and associated quantum-mechanical property of flavor in order to model the astrophysical system of interest—a numerical challenge that has not been addressed to this day. In this work, we take a step in this direction by adopting the technique of angular-integrated moments with a truncated tower of dynamical equations and a closure, convolving the flavor-transformation with spatial transport to evolve the neutrino radiation quantum field. We show that moments capture the dynamical features of fast flavor instabilities in a variety of systems, although our technique is by no means a universal blueprint for solving fast flavor transformation. To evaluate the effectiveness of our moment results, we compare to a more precise particle-in-cell method. Based on our results, we propose areas for improvement and application to complementary techniques in the future.

Current neutrino detectors will observe hundreds to thousands of neutrinos from Galactic supernovae, and future detectors will increase this yield by an order of magnitude or more. With such a data set comes the potential for a huge increase in our understanding of the explosions of massive stars, nuclear physics under extreme conditions, and the properties of the neutrino. However, there is currently a large gap between supernova simulations and the corresponding signals in neutrino detectors, which will make any comparison between theory and observation very difficult. SNEWPY is an open-source software package that bridges this gap. The SNEWPY code can interface with supernova simulation data to generate from the model either a time series of neutrino spectral fluences at Earth, or the total time-integrated spectral fluence. Data from several hundred simulations of core-collapse, thermonuclear, and pair-instability supernovae is included in the package. This output may then be used by an event generator such as sntools or an event rate calculator such as the SuperNova Observatories with General Long Baseline Experiment Simulator (SNOwGLoBES). Additional routines in the SNEWPY package automate the processing of the generated data through the SNOwGLoBES software and collate its output into the observable channels of each detector. In this paper we describe the contents of the package, the physics behind SNEWPY, the organization of the code, and provide examples of how to make use of its capabilities.

Developing sustainable software for the scientific community requires expertise in software engineering and domain science. This can be challenging due to the unique needs of scientific software, the insufficient resources for software engineering practices in the scientific community, and the complexity of developing for evolving scientific contexts. While open‐source software can partially address these concerns, it can introduce complicating dependencies and delay development. These issues can be reduced if scientists and software developers collaborate. We present a case study wherein scientists from the SuperNova Early Warning System collaborated with software developers from the Scalable Cyberinfrastructure for Multi‐Messenger Astrophysics project. The collaboration addressed the difficulties of open‐source software development, but presented additional risks to each team. For the scientists, there was a concern of relying on external systems and lacking control in the development process. For the developers, there was a risk in supporting a user‐group while maintaining core development. These issues were mitigated by creating a second Agile Scrum framework in parallel with the developers' ongoing Agile Scrum process. This Agile collaboration promoted communication, ensured that the scientists had an active role in development, and allowed the developers to evaluate and implement the scientists' software requirements. The collaboration provided benefits for each group: the scientists actuated their development by using an existing platform, and the developers utilized the scientists' use‐case to improve their systems. This case study suggests that scientists and software developers can avoid scientific computing issues by collaborating and that Agile Scrum methods can address emergent concerns.