Search

Exploring planetary systems similar to our solar system can provide a means to explore a large range of possibly temperate climates on Earth-like worlds. Rather than run hundreds of simulations with different eccentricities at fixed obliquities, our variable-eccentricity approach provides a means to cover an incredibly large parameter space. Herein Jupiter's orbital radius is moved substantially inward in two different scenarios, causing a forcing on Earth's eccentricity. In one case, the eccentricity of Earth varies from 0 to 0.27 over ~7000 yr for three different fixed obliquities (0{\deg}, 23{\deg}, and 45{\deg}). In another case, the eccentricity varies from 0 to 0.53 over ~9400 yr in a single case with zero obliquity. In all cases, we find that the climate remains stable, but regional habitability changes through time in unique ways. At the same time, the moist greenhouse state is approached but only when at the highest eccentricities., Comment: 10 pages, 11 Figures. Data/scripts used to generate figures & ROCKE-3D boundary condition files can be downloaded from doi:10.5281/zenodo.8398270

The nearby exoplanet Proxima Centauri b will be a prime future target for characterization, despite questions about its retention of water. Climate models with static oceans suggest that an Earth-like Proxima b could harbor a small dayside region of surface liquid water at fairly warm temperatures despite its weak instellation. We present the first 3-dimensional climate simulations of Proxima b with a dynamic ocean. We find that an ocean-covered Proxima b could have a much broader area of surface liquid water but at much colder temperatures than previously suggested, due to ocean heat transport and depression of the freezing point by salinity. Elevated greenhouse gas concentrations do not necessarily produce more open ocean area because of possible dynamic regime transitions. For an evolutionary path leading to a highly saline present ocean, Proxima b could conceivably be an inhabited, mostly open ocean planet dominated by halophilic life. For an ocean planet in 3:2 spin-orbit resonance, a permanent tropical waterbelt exists for moderate eccentricity. Simulations of Proxima Centauri b may also be a model for the habitability of planets receiving similar instellation from slightly cooler or warmer stars, e.g., in the TRAPPIST-1, LHS 1140, GJ 273, and GJ 3293 systems., Comment: Submitted to Astrobiology; 38 pages, 12 figures, 5 tables

This technical report records and discusses the Second Workshop on Sustainable Software for Science: Practice and Experiences (WSSSPE2). The report includes a description of the alternative, experimental submission and review process, two workshop keynote presentations, a series of lightning talks, a discussion on sustainability, and five discussions from the topic areas of exploring sustainability; software development experiences; credit & incentives; reproducibility & reuse & sharing; and code testing & code review. For each topic, the report includes a list of tangible actions that were proposed and that would lead to potential change. The workshop recognized that reliance on scientific software is pervasive in all areas of world-leading research today. The workshop participants then proceeded to explore different perspectives on the concept of sustainability. Key enablers and barriers of sustainable scientific software were identified from their experiences. In addition, recommendations with new requirements such as software credit files and software prize frameworks were outlined for improving practices in sustainable software engineering. There was also broad consensus that formal training in software development or engineering was rare among the practitioners. Significant strides need to be made in building a sense of community via training in software and technical practices, on increasing their size and scope, and on better integrating them directly into graduate education programs. Finally, journals can define and publish policies to improve reproducibility, whereas reviewers can insist that authors provide sufficient information and access to data and software to allow them reproduce the results in the paper. Hence a list of criteria is compiled for journals to provide to reviewers so as to make it easier to review software submitted for publication as a "Software Paper."

Atmospheric chemistry models are a central tool to study and forecast the impact of air pollution on the environment, vegetation, and human health. However, the numerical simulation of chemical kinetics is computationally expensive due to the stiffness of the system of ordinary differential equations that describes atmospheric chemistry. Here we present an alternative approach to the computation of atmospheric chemistry based on machine learning. Our training data set is produced using the NASA Goddard Earth Observing System (GEOS) model with GEOS-Chem chemistry, run on the NASA Center for Climate Simulation (NCCS) Discover supercomputing cluster on 384 Intel Xeon Haswell cores. This model spends more than 50% of total run time on solving atmospheric chemistry. The data set contains as input features the air pollution concentrations before solving the differential equations, together with some key physical parameters such as temperature and sun intensity. As target variables we define the air pollution concentrations after solving the differential equations. Using Dask-cuDF and Dask-XGBoost on the NVIDIA RAPIDS platform on 8 Tesla V100 GPUs, we generate from this training set gradient boosted decision tree models that can reproduce the simulation of chemical kinetics. We do this on the NCCS Advanced Data Analytics Platform (ADAPT) science cloud environment. Our application takes full advantage of recent advances in Dask-XGBoost, such as multi-node and multi-GPU scaling for distributed training with large data sets. The increase in training data size enabled by this is critical to capture the full range of chemical environments encountered across the globe and all annual seasons.The boosted tree models offer good predictability and show many of the features of the full chemistry reference simulation. Further improvements can be achieved through mass balance considerations and by accounting for error correlations. We incorporate the boosted tree models into the GEOS reference model using XGBoost's C API. This enables a seamless integration of the GPU trained models into GEOS-Chem, which is written in Fortran and optimized for use in a massively parallel CPU environment. We show the benefits of this approach and discuss the potential speedup of this machine learning accelerated atmospheric chemistry model.

Sensor forward models are an important tool for interpreting remote sensing observations of geophysical phenomena. By implementing a three-dimensional framework, we can simulate and analyze observations from various sensors on disparate platforms. To demonstrate our model framework, we simulate observations from the Olympic Mountains Experiment (OLYMPEX). The use of cloud model simulations allows us to understand sensor response to cloud ice, falling snow, and other processes and features, and the application of model tools to observations allows us to quantify precipitation.MIIST 3D Forward ModelThe Multi-Instrument Inverse Solver Testbed(MIIST) uses the Atmospheric Radiative TransferSimulator (ARTS) for solving the vector radiativetransfer (RT) equation in up to three spatialdimensions within a spherical geometry• Gas absorptiono Line-by-line calculationso Fast transmittance tables• Hydrometeor scattering solverso Discrete ordinateo RT4 (Evans, 1D)o Radar Single Scattering (1D or 3D)o Monte Carlo (3D)Scattering TablesHigh-fidelity hydrometeor scatteringtables are necessary for accurateand consistent forward modeling ofmulti-frequency observations• Requires full Stokes matriceso And absorption vector• Randomly oriented particleso Discrete Dipole Approximationo Characteristic Basis Function Method(coming soon)• Horizontally-oriented plateso Invariant Imbedding T-matrix MethodCloud Resolving SimulationsCloud resolving simulations (e.g.,NU-WRF) supply output consistentwith ARTS needs• Atmospheric Informationo Temperatureo Pressure / heighto Water vapor• Hydrometeor Profileso ARTS architecture ripe for explicit binmicrophysics• Examples use Morrison 2M schemeThe Olympic Mountains Experiment (OLYMPEX)Validation for GPM of mid-latitudefrontal systems approaching nearcoastalmountains from the ocean• Large collection of ground-based andairborne sensorso Radarso Radiometerso In situ• Contemporaneous with RADEXo Two sets of radar at same frequenciesRadiometer Simulation (3 km NUWRF, 20151203, 15:00)2018.12.14 7Simulate 166 GHz polarizationdifference• Corresponds to the presence of aligned icecrystals• Look at trends for both simulations andobservations• Simulations can tolerate lower resolutiono Larger domainSimulations from Observations: OLYMPEXSimulate sensor response usinggeophysical retrievals as input• Single frequency radar retrievals• Multiple scattering enhancementapparent at W band• Spatially dependent phenomenonModeling Application: 1D Retrievals03 December 2015• DC-8 and ER-2 flightso Focus on APR-3 (DC-8)• Citationo Stacked microphysics legso Qualitative comparisonso Range of frozen habitso Presence of supercooledliquid cloudsResults• Retrievals match probeso Good qualitative match• Bands of increasedreflectivity correspond tolarge Dm and highaggregate fraction• Significant amounts ofsupercooled liquid water

In the context of high performance computing (HPC), software investments in support of text-based diagnostics, which monitor a running application, are typically limited compared to those for other types of IO. Examples of such diagnostics include reiteration of configuration parameters, progress indicators, simple metrics (e.g., mass conservation, convergence of solvers, etc.), and timers. To some degree, this difference in priority is justifiable as other forms of output are the primary products of a scientific model and, due to their large data volume, much more likely to be a significant performance concern. In contrast, text-based diagnostic content is generally not shared beyond the individual or group running an application and is most often used to troubleshoot when something goes wrong. We suggest that a more systematic approach enabled by a logging facility (or logger) similar to those routinely used by many communities would provide significant value to complex scientific applications. In the context of high-performance computing, an appropriate logger would provide specialized support for distributed and shared-memory parallelism and have low performance overhead. In this paper, we present our prototype implementation of pFlogger a parallel Fortran-based logging framework, and assess its suitability for use in a complex scientific application.

Developers working in Computational Science & Engineering (CSE)/High Performance Computing (HPC) must contend with constant change due to advances in computing technology and science. Test Driven Development (TDD) is a methodology that mitigates software development risks due to change at the cost of adding comprehensive and continuous testing to the development process. Testing frameworks tailored for CSE/HPC, like pFUnit, can lower the barriers to such testing, yet CSE software faces unique constraints foreign to the broader software engineering community. Effective testing of numerical software requires a comprehensive suite of oracles, i.e., use cases with known answers, as well as robust estimates for the unavoidable numerical errors associated with implementation with finite-precision arithmetic. At first glance these concerns often seem exceedingly challenging or even insurmountable for real-world scientific applications. However, we argue that this common perception is incorrect and driven by (1) a conflation between model validation and software verification and (2) the general tendency in the scientific community to develop relatively coarse-grained, large procedures that compound numerous algorithmic steps.We believe TDD can be applied routinely to numerical software if developers pursue fine-grained implementations that permit testing, neatly side-stepping concerns about needing nontrivial oracles as well as the accumulation of errors. We present an example of a successful, complex legacy CSE/HPC code whose development process shares some aspects with TDD, which we contrast with current and potential capabilities. A mix of our proposed methodology and framework support should enable everyday use of TDD by CSE-expert developers.