1

Enabling immediate access to Earth science models through cloud 1

computing: application to the GEOS-Chem model 2

3

Jiawei Zhuang1, Daniel J. Jacob1, Judit Flo Gaya1, Robert M. Yantosca1, Elizabeth W. Lundgren1, Melissa 4

P. Sulprizio1, Sebastian D. Eastham2 5

6

1. John A. Paulson School of Engineering and Applied Sciences, Harvard University, Cambridge, MA 7

2. Laboratory for Aviation and the Environment, Massachusetts Institute of Technology, Cambridge, MA 8

9

Corresponding Author Information: Jiawei Zhuang (jiaweizhuang@g.harvard.edu) 10

Abstract 11

Cloud computing platforms can provide fast and easy access to complex Earth science models and large 12

datasets. This article presents a mature capability for running the GEOS-Chem global 3-D model of 13

atmospheric chemistry (http://www.geos-chem.org) on the Amazon Web Services (AWS) cloud. GEOS-14

Chem users at any experience level can get immediate access to the latest, standard version of the model 15

in a pre-configured software environment with all needed meteorological and other input data, and they 16

can analyze model output data easily within the cloud using Python tools in Jupyter notebooks. Users 17

with no prior knowledge of cloud computing are provided with easy-to-follow, step-by-step instructions 18

(http://cloud.geos-chem.org). They can learn how to complete a demo project in less than one hour, and 19

2

from there they can configure and submit their own simulations. The cloud is particularly attractive for 20

beginning and occasional users who otherwise may need to spend substantial time configuring a local 21

computing environment. Heavy users with their own local clusters can also benefit from the cloud to 22

access the latest standard model and datasets, share simulation configurations and results, benchmark 23

local simulations, and respond to surges in computing demand. Software containers allow GEOS-Chem 24

and its software environment to be moved smoothly between cloud platforms and local clusters, so that 25

the exact same simulation can be reproduced everywhere. Because the software requirements and 26

workflows tend to be similar across Earth science models, the work presented here provides general 27

guidance for porting models to cloud computing platforms in a user-accessible way. 28

Capsule 29

Cloud computing provides fast and easy access to the comprehensive GEOS-Chem atmospheric 30

chemistry model and its large input datasets for the international user community. 31

Introduction 32

Cloud computing involves on-demand access to a large remote pool of computing and data resources, 33

typically through a commercial vendor. It has considerable potential for Earth science modeling (Vance 34

et al. 2016). Cloud computing addresses three common problems researchers face when performing 35

complex computational tasks: compute, software, and data. Public cloud computing platforms like 36

Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform allow users to request 37

computing resources on demand and only pay for the computing time they consume, without having to 38

3

invest in local computing infrastructure (compute problem). Due to the use of virtual machines (VMs) on 39

cloud platforms, it is very easy to replicate an existing software environment, so researchers can avoid 40

configuring software from scratch, which can often be difficult and time-consuming (software problem). 41

Large volumes of data can be quickly shared and processed in the cloud, saving researchers the time of 42

downloading data to local machines and the cost of storing redundant copies of data (data problem). Yet 43

cloud computing has made little penetration in Earth science modeling so far because of several 44

roadblocks. Here we show how these roadblocks can be removed, and we demonstrate practical user-45

oriented application with the GEOS-Chem atmospheric chemistry model which is now fully functional 46

and user-accessible on the AWS cloud. 47

48

A number of Earth science models have been tested in the cloud environment, including the MITgcm 49

(Evangelinos and Hill 2008), the Weather Research and Forecast Model (WRF) (Withana et al. 2011; 50

Molthan et al. 2015; Duran-Limon et al. 2016; Siuta et al. 2016), the Community Earth System Model 51

(CESM) (Chen et al. 2017), the NASA GISS ModelE (Li et al. 2017), the Regional Ocean Modelling 52

System (ROMS) (Jung et al. 2017), and the Model for Prediction Across Scales (MPAS) (Coffrin et al. 53

2019). Extensive studies have benchmarked the computational performance of cloud platforms against 54

traditional clusters (Walker 2008; Hill and Humphrey 2009; Jackson et al. 2010; Gupta and Milojicic 55

2011; Yelick et al. 2011; Zhai et al. 2011; Roloff et al. 2012, 2017; Strazdins et al. 2012; Gupta et al. 56

2013; Mehrotra et al. 2016; Salaria et al. 2017). Cloud platforms are found to be efficient for small-to-57

medium sized simulations with less than 100 CPU cores, but the typically slower inter-node 58

communication on the cloud can affect the parallel efficiency of larger simulations. Cost comparisons 59

4

between cloud platforms and traditional clusters show inconsistent results, either in favor of the cloud 60

(Roloff et al. 2012; Huang et al. 2013; Oesterle et al. 2015; Thackston and Fortenberry 2015; Dodson et 61

al. 2016) or local clusters (Carlyle et al. 2010; Freniere et al. 2016; Emeras et al. 2017; Chang et al. 2018), 62

depending on assumptions regarding resource utilization, parallelization efficiency, storage requirement, 63

and billing model. The cloud is particularly cost-effective for occasional or intermittent workloads. 64

65

For complex model code, cloud platforms can considerably simplify the software configuration process. 66

On traditional machines, researchers need to properly configure library dependencies like HDF5, 67

NetCDF, and MPI, and this configuring process is becoming more and more difficult due to the growing 68

use of complicated software frameworks like ESMF (Hill et al. 2004) and NUOPC (Carman et al. 2017). 69

On cloud platforms, users can simply copy the exact software environment from an existing system 70

(virtual machine). Once a model is built, configured, and made available on the cloud by the developer, 71

it can be immediately shared with everyone. An example is the OpenFOAM Computational Fluid 72

Dynamics software officially distributed through the AWS cloud (https://cfd.direct/cloud/). 73

74

Cloud computing also greatly enhances the accessibility of Earth science datasets. Earth observing 75

systems and model simulations can produce Terabytes (TBs) or Petabytes (PBs) of data, and downloading 76

these data to local machines is often impractical. Instead of “moving data to compute”, the new paradigm 77

should be “moving compute to data”, i.e. perform data analysis in the cloud computing environment 78

where the data are already available (Yang et al. 2017). For example, NOAA’s Next Generation Weather 79

Radar (NEXRAD) product is shared through the AWS cloud (Ansari et al. 2017), and “data access that 80

5

previously took 3+ years to complete now requires only a few days” (NAS 2018). NASA’s Earth 81

Observing System Data and Information System (EOSDIS) plans to move PBs of Earth observation data 82

to the AWS cloud to enhance data accessibility (Lynnes et al. 2017). Other Earth science datasets such as 83

NASA’s Earth Exchange (NEX) data, NOAA’s GOES-16 data, and ESA’s Sentinel-2 data are publicly 84

available on the AWS cloud (https://aws.amazon.com/earth/). The Google Earth Engine (Gorelick et al. 85

2017) and Climate Engine (Huntington et al. 2017) are another examples of cloud platforms that provide 86

easy access to various Earth science data collections as well as the computing power to process the data. 87

88

Computing on the cloud further facilitates reproducibility in research (Howe 2012; de Oliveira et al. 89

2017). Scientific journals increasingly require that model source code and data be available online (Irving 90

2016). However, due to complicated software dependencies of Earth science models, the configuration 91

scripts for one system would usually require significant modifications to work on other systems, and 92

sometimes the platform differences can lead to differences in simulation results (Hong et al. 2013; Li et 93

al. 2016). It is difficult to reproduce a model simulation even if the source code is published online. Cloud 94

platforms can solve this problem by guaranteeing a consistent system environment for different research 95

groups, providing massive computing power to rerun a model, and sharing large volumes of input/output 96

data. 97

98

Our guiding example in this article is the GEOS-Chem global 3-D model of atmospheric chemistry 99

(http://www.geos-chem.org), which we have made available for users on the AWS cloud. GEOS-Chem 100

was originally described by Bey et al. (2001) and is presently used by over 150 registered research groups 101

6

worldwide (GEOS-Chem 2018a) for a wide range of applications in air quality, aerosol microphysics and 102

radiative forcing, global tropospheric-stratospheric chemistry, biogeochemical cycling of persistent 103

pollutants, and budgets of greenhouse gases. For some recent applications see, e.g., Christian et al., 2018; 104

Jeong and Park, 2018; Jing et al., 2018; Tian et al., 2018; Yu et al., 2018; Zhu et al., 2018. GEOS-Chem 105

is driven by assimilated meteorological data from the Goddard Earth Observing System (GEOS) of the 106

NASA Global Modeling and Assimilation Office (GMAO). It can operate in global or nested mode at 107

resolutions as fine as 25 km in latitude-longitude or cubed-sphere grids (Eastham et al. 2018). The GEOS-108

Chem code (https://github.com/geoschem) is open-access and undergoes continual development by its 109

users, with updates to the standard model overseen by an international GEOS-Chem Steering Committee 110

(GEOS-Chem 2018b). New versions are released and benchmarked every few months by the GEOS-111

Chem Support Team of scientific programmers based at Harvard University. 112

113

Our porting of GEOS-Chem to the cloud was motivated by the need to serve a diverse and growing base 114

of model users, many with little access to high-performance computing (HPC) resources and software 115

engineering support. This includes novice users needing easy access to the model for occasional 116

computations such as interpreting data from a field campaign, determining the atmospheric implications 117

of laboratory measurements, or specifying boundary conditions for urban/regional models. Despite intent 118

for GEOS-Chem to be an easy-to-use facility, the model is becoming increasingly complicated because 119

of more comprehensive scientific schemes, higher grid resolution, larger input datasets, and more 120

extensive software infrastructure to support these advances. Data transfer is an increasing problem as the 121

model resolution increases. GEOS-Chem users presently have access to 30 TB of model input data on 122

7

FTP servers at Harvard University. With a typical bandwidth of 1 MB/s, it takes two weeks to download 123

a 1-TB subset and a year to download the full 30 TB. This is a significant bottleneck for research progress. 124

125

To solve this problem, we have made GEOS-Chem available through the AWS cloud, with the exact same 126

code and software environment as the standard benchmarked version managed at Harvard University. All 127

GEOS-Chem input data are now hosted on the AWS cloud under the AWS public dataset program 128

(https://registry.opendata.aws/geoschem-input-data/), and can be quickly accessed by users in the cloud 129

with no additional charge. The data repository includes the GEOS-Forward Processing (GEOS-FP) 130

meteorological product at global 0.25° × 0.3125° resolution (2012-present), the Modern-Era 131

Retrospective analysis for Research and Applications version 2 (MERRA-2) meteorological product at 132

global 0.5° × 0.625° resolution (2000-present), and coarser-resolution and nested domain versions. The 133

repository also contains a large collection of emission inventories managed through the Harvard–NASA 134

Emission Component (Keller et al. 2014), and other files needed for driving GEOS-Chem simulations 135

such as the model initial conditions. Fig. 1 shows examples of these datasets. With already-available 136

datasets as well as a pre-configured software environment on the AWS cloud, a beginning user can start 137

GEOS-Chem simulations immediately and with confidence that the results will replicate those of the 138

latest standard benchmarked version. To facilitate cloud adoption by users, we provide a detailed user 139

manual with step-by-step instructions for a complete research workflow (http://cloud.geos-chem.org/), 140

assuming no prior knowledge of cloud computing. Because the software requirements and workflows 141

tend to be similar between Earth science models, our work provides general guidance beyond GEOS-142

Chem for porting models to cloud computing platforms in a user-accessible way. 143

8

Cloud computing for research: removing the roadblocks 144

Three practical roadblocks have hindered scientists from exploiting cloud computing: licensing for 145

commercial software, concerns about potential vendor lock-in, and lack of science-oriented 146

documentation and tooling. Here we show how these first two issues have been effectively addressed by 147

the availability of open-source software and HPC containers. We address the third issue by our own 148

development of documentation targeted at Earth scientists. 149

Open-source software 150

The licensing of proprietary software has been a major roadblock to cloud adoption (Section 3.2.2 of 151

Netto et al., 2017). Commercial software programs such as Intel compilers and MATLAB are often pre-152

installed on supercomputing centers and university clusters, but using the same software on cloud 153

platforms requires researchers to bring their own licenses, whose cost can be prohibitive. Further, 154

although an advantage of the cloud is the ability to share the entire software environment with users, it is 155

harder to share a system containing proprietary software1. 156

157

The increasing availability and capability of open-source software is rapidly obviating the need for 158

proprietary software in Earth science. In particular, GEOS-Chem has recently freed itself of the need for 159

proprietary software by adopting Python libraries for data analysis, and by making code changes to ensure 160

1 Strictly speaking, the Intel compiler license is only required for compiling source code, not for running pre-compiled applications. However, it is common for GEOS-Chem users to modify the model source code, for purposes like implementing new schemes, saving custom data fields, and debugging, so the ability to recompile source code is important.

9

compatibility with the GNU Fortran compiler. Data analysis in GEOS-Chem had historically relied on 161

GAMAP (http://acmg.seas.harvard.edu/gamap/), a data analysis package written in the proprietary 162

Interactive Data Language (IDL) that cannot be easily used and distributed on the cloud. With the maturity 163

of the open-source scientific Python stack in recent years (VanderPlas 2016), GEOS-Chem data analysis 164

has migrated to Python. Existing Python libraries can easily replicate, and often surpass, the 165

functionalities in MATLAB and IDL. Commonly used Python libraries for GEOS-Chem users include 166

Jupyter notebooks (Shen 2014; Perkel 2018) for user interface, Xarray (Hoyer and Hamman 2017) for 167

conveniently manipulating NetCDF files, Dask (Rocklin 2015) for parallel computation, Matplotlib 168

(Hunter 2007) and Cartopy (Met Office 2016) for data visualization, and xESMF (Zhuang 2018) for 169

transforming data between different grids. We provide a Python tutorial for the GEOS-Chem user 170

community at https://github.com/geoschem/GEOSChem-python-tutorial; the tutorial code can be 171

executed in a pre-configured Python environment on the cloud platform provided freely by the Binder 172

project (https://mybinder.org). Most contents in the tutorial are general enough to be applied to other 173

Earth data analysis problems. 174

175

Atmospheric models are typically written in Fortran that can in principle accommodate different Fortran 176

compilers. In practice, compilers have different syntax requirements. Earlier versions of GEOS-Chem 177

were intended for the proprietary Intel compiler, but failed to compile with the open-source GNU 178

compiler due to invalid syntaxes in legacy modules. With a recent refactor of legacy code, GEOS-Chem 179

now compiles with all major versions of the GNU Fortran compiler (GEOS-Chem 2018c). Although some 180

models like WRF are found to be significantly slower with GNU compilers than with Intel compilers 181

10

(Langkamp 2011; Siuta et al. 2016), for GEOS-Chem we find that switching to the GNU compiler 182

decreases performance by only 5% (GEOS-Chem 2018d), in part due to a sustained effort to only bring 183

hardware-independent and compiler-agonistic optimizations into the GEOS-Chem main code branch. 184

185

HPC containers 186

Being locked-in by a particular cloud vendor is a major concern for researchers (Section 5 of Bottum et 187

al., 2017), who may then be hostage to rising costs and unable to take advantage of cheap computing 188

elsewhere. It is indeed highly desirable for researchers to be able to switch smoothly between different 189

cloud platforms, supercomputing centers, and their own clusters, depending on the costs, the available 190

funding, the location of data repositories, and their collaborators (ECAR 2015a). The container 191

technology (Boettiger 2014) enables this by allowing immediate replication of the same software 192

environment on different systems. 193

194

From a user’s perspective, containers behave like virtual machines (VMs) that can encapsulate software 195

libraries, model code, and small data files into a single “image”. VMs and containers both allow platform-196

independent deployment of software. While VMs often incur performance penalties due to running an 197

additional guest operating system (OS) inside the original host OS, containers run on the native OS and 198

can achieve near-native performance (Hale et al. 2017). Docker (https://www.docker.com) is the most 199

widely-used container and is readily available on the cloud, but it cannot be used on shared HPC clusters 200

due to security risks (Jacobsen and Canon 2015). To address Docker’s limitations, HPC containers such 201

11

as Shifter (Canon and Jacobsen 2016), CharlieCloud (Priedhorsky et al. 2017), and Singularity (Kurtzer 202

et al. 2017) have been recently developed to allow secure execution of Docker images on shared HPC 203

clusters. It is now increasingly standard for large HPC clusters to be equipped with software containers. 204

For example, Harvard’s Odyssey cluster supports the Singularity container (Harvard RC 2018) and 205

NASA’s Pleaides cluster supports the CharlieCloud container (NASA HECC 2018). All these different 206

containers are compatible as they can all execute Docker images. 207

208

A GEOS-Chem user might want to perform initial pilot simulations on the AWS cloud, and then switch 209

to their own clusters for more intensive simulations. We provide container images on Docker Hub 210

(https://hub.docker.com) with pre-configured GEOS-Chem for users to download to their own clusters. 211

The container provides exactly the same software environment as used on the cloud, so the model is 212

guaranteed to compile and execute correctly when ported to the local cluster, and even achieve bit-wise 213

reproducibility (Hacker et al. 2017). 214

215

Science-oriented documentation 216

Cloud-computing was initially developed for business IT applications, and interest in the cloud for 217

scientific computing is more recent (Fox 2011). According to the US National Academy of Sciences 218

(NAS 2018), “the majority of U.S. Earth science students and researchers do not have the training that 219

they need to use cloud computing and big data”. Standard cloud platform documentations (Amazon 220

2018a) are largely written for system administrators and web developers, and can be difficult for scientists 221

12

to understand. Some research-oriented cloud materials (Amazon 2018b; Microsoft 2018a) and textbooks 222

(Foster and Gannon 2017) have eased the learning curve but are not specific enough to guide Earth science 223

applications. The Serverless Computing paradigm (Jonas et al. 2019) has the potential to greatly simplify 224

the use of cloud computing and reduce the system administration burden on users, but its use for scientific 225

computing is still at infancy. 226

227

To make cloud computing accessible to scientists, several high-level, black-box services have been 228

proposed to hide the technical details of cloud platforms (Tsaftaris, 2014; Hossain et al., 2017; Li et al., 229

2017; Section 2.3 of Netto et al., 2017). However, they tend to make strict assumptions on the workflow 230

and lack customizability and generalizability. We take the opposite tack -- to teach low-level AWS cloud 231

concepts to users and make them manage their own cloud infrastructures including servers, storage, and 232

network. In cloud computing terminology, we stick to the Infrastructure as a Service (IaaS) framework, 233

not the higher-level Software as a Service (SaaS) framework. 234

235

Our research-oriented tutorial and documentation (http://cloud.geos-chem.org/) provide the necessary 236

training for GEOS-Chem users, with practical focus on model simulation and data management. The 237

documentation includes “beginner tutorials” for beginning and occasional users, “advanced tutorials” for 238

heavy users, and a “developer guide” for model developers to install software libraries and configure 239

environment from scratch. By following the documentation, GEOS-Chem users can successfully finish a 240

demo project in half an hour for their first experience on the AWS cloud, and within minutes for 241

subsequent uses. This is detailed in the next section. 242

13

243

Exposing low-level infrastructures makes our work highly generalizable to other Earth science 244

applications and cloud platforms. First, users have the freedom to install and run any model by using our 245

GEOS-Chem workflow as a reference. Second, once users get familiar with AWS concepts, it becomes 246

relatively easy for them to learn other cloud platforms like Microsoft Azure and Google cloud, because 247

these different platforms have similar services and technical concepts (Google 2018a; Microsoft 2018b). 248

Third, the same set of cloud computing skills can be applied to a wide range of problems beyond model 249

simulations, such as analyzing large public Earth science data or using GPUs on the cloud to accelerate 250

machine learning workloads (Appendix B of Chollet, 2017). 251

Research workflow using basic AWS functionalities 252

Here we describe the workflow for GEOS-Chem users in two scenarios: 253

1. A demo project for initiation to the cloud. The users run our pre-configured “demo simulation” for a 254

short period. The demo is configured with GEOS-Chem’s standard troposphere-stratosphere oxidant-255

aerosol chemical mechanism and a global horizontal resolution of 4° × 5°. This same configuration 256

is used for the official GEOS-Chem benchmark (GEOS-Chem 2018e). It is fast to simulate due to the 257

coarse spatial resolution and is a good starting point for a new user. The users perform quick analysis 258

and visualization of the model output data, and then exit the system discarding all data files. 259

2. An actual research project for scientific analysis. The users set up their desired custom configuration 260

of the model, conduct their simulation, archive their output, and preserve the model configuration for 261

future runs. For illustrative and cost evaluation purposes, we assume here a 1-year global simulation 262

14

at 2° × 2.5° resolution using the standard troposphere-stratosphere oxidant-aerosol chemical 263

mechanism. For output, the simulation stores 3-D daily averaged fields for 168 transported chemical 264

species, resulting in 150 GB of data. This is typical of a research project using GEOS-Chem. The 265

same workflow applies to any other configuration of the model. 266

267

The workflow uses the most basic AWS functionalities to keep the learning curve minimum. AWS offers 268

over a hundred services (Amazon 2018c), leading to a complicated web portal that can be daunting for 269

new users. However, Earth science modeling tasks can be achieved with only two core services: Elastic 270

Compute Cloud (EC2) for computation and Simple Storage Service (S3) for data storage. Many other 271

services target various IT/business applications and are not necessary for most scientific users. The steps 272

for a complete modeling research workflow are illustrated in Fig. 2 and are explained in what follows. 273

274

Step 1: Launch virtual server 275

Under the IaaS framework, users request their own servers (“EC2 instances” in AWS terminology) with 276

customizable hardware capacity and software environment. Requests are done through the AWS console 277

in the user’s web browser. The software environment is determined by a virtual machine image (the 278

Amazon Machine Image, or AMI), which defines the operating system, pre-installed software libraries, 279

and data files that a newly-launched EC2 instance will contain. Here, users can select a publicly available 280

AMI with pre-configured GEOS-Chem environment. The hardware capacity is defined by the choice of 281

EC2 instance type (Amazon 2018d) with different capacities in CPUs, memory, disk storage, and network 282

bandwidth. Numerical models run most efficiently on “Compute-Optimized” types, which prioritize CPU 283

15

performance over other aspects (Montes et al.,2017). Launching a new EC2 instance only takes seconds. 284

Repeated launches of EC2 instances can be automated by the AWS Command Line Interface (AWSCLI, 285

https://aws.amazon.com/cli/), to avoid having to browse through the web console. 286

287

Step 2: Log into server and perform computation. 288

Once the EC2 instance is created, it can be used as a normal server, i.e. via the Secure Shell (SSH) in the 289

command line terminal. Since most Earth scientists have experience with local servers and the command 290

line, using EC2 instances is straightforward for them; if not, they can learn the command line basics easily 291

from online materials like Software Carpentry (http://swcarpentry.github.io/shell-novice/). There are no 292

cloud-computing-specific skills required at this stage. 293

294

Following standard practice for Earth science models, a GEOS-Chem simulation is controlled by a “run 295

directory” containing run-time configurations and the model executable. A pre-configured run directory 296

with a pre-compiled executable and a sample of meteorological and emission input data are provided by 297

our GEOS-Chem AMI for the demo project, so users can execute a GEOS-Chem simulation immediately 298

after log-in, without having to set up the run directory and compile model code on their own. This short 299

demo simulation finishes in minutes. 300

301

For an actual research project, users should re-compile the model with the desired model version, grid 302

resolution, and chemical mechanism. Recompilation takes about 2 minutes. Because the software libraries 303

and environment variables are already properly configured, the model is guaranteed to compile without 304

16

error. Additional operations such as modifying model source code or installing new software libraries can 305

be done as usual, just like on local servers. 306

307

GEOS-Chem users also need to access additional meteorological and emission input data for their desired 308

simulation configurations, and they can do so from the public GEOS-Chem input data repository residing 309

in the AWS Simple Storage Service (S3). The data transfer from S3 to EC2 is simply done by AWSCLI 310

command “aws s3 cp”, analogous to the “cp” command for copying data on local filesystems. For the 311

actual research project scenario described here, the user should retrieve 1 year of global 2°×2.5° 312

meteorological input data with size of 112 GB. With a typical ~250 MB/s network bandwidth between 313

S3 and EC2, the retrieval will finish in 8 minutes. 314

315

Users of shared HPC clusters are accustomed to using job schedulers to manage long model simulations. 316

However, an EC2 instance completely belongs to a single user, so a scheduler for queuing jobs is not 317

necessary. Instead, users just execute the program interactively. A simple way to keep the program 318

running after logging out of the server is to execute the model inside terminal multiplexers such as GNU 319

Screen (https://www.gnu.org/software/screen/) or tmux (https://github.com/tmux/tmux), which are 320

standard tools for managing long-running programs on the cloud (Shaikh 2018). 321

322

GEOS-Chem simulations generate potentially large amounts of output data in NetCDF format (GEOS-323

Chem 2018f). Analysis of output data can be done within the cloud using Python in web-based Jupyter 324

notebooks. Jupyter always displays the user interface, code, and graphics in the web browser, no matter 325

17

whether the program is running on the local computer or a remote cloud platform. Thus, users have a 326

convenient data analysis environment on the cloud, as if they are using Jupyter locally. Alternatively, the 327

data can be downloaded to local computers for analysis, although this involves data transfer time and a 328

data egress fee (see next section). 329

330

For a demo project, the user can simply terminate the EC2 instance after the model simulation and output 331

data analysis are finished. The output data are deleted upon termination. For an actual research project, 332

the output data will generally need to be archived before EC2 termination, as described next. 333

334

Step 3: Working with persistent storage 335

The lack of persistent disk storage is the major difference between cloud platforms and local computers. 336

The Elastic Block Store (EBS) volume is the temporary disk that backs up an EC2 instance. However, 337

when the EC2 instance is terminated, its EBS volume containing the user’s data will typically be deleted. 338

Instead of leaving files on EBS, important files such as output data and customized run directories should 339

be transferred to the S3 persistent storage service. S3 is independent of EC2 and guarantees the persistence 340

of data. 341

342

S3 offers many other advantages over EBS besides data persistence. While an EBS volume can only be 343

attached to single EC2, data in S3 can be accessed simultaneously by any number of EC2 instances, as 344

well as by computers outside of the cloud. Files in an EBS volume can only be seen from an EC2 instance, 345

but files in S3 can be viewed directly in the AWS web portal. While an EBS volume has a limited storage 346

18

capacity just like traditional disks, there is effectively no size limit on S3. Furthermore, S3 can be 347

integrated with advanced AWS services (e.g., Amazon Elastic MapReduce) and community big-data 348

platforms (e.g., Pangeo, https://pangeo.io) for large-scale data processing. 349

350

Despite the advantages of S3, new users might still feel uncomfortable with managing two types of storage 351

(S3 and EBS) at the same time. This can be simplified by mounting S3 via Filesystem in Userspace 352

(FUSE, https://github.com/s3fs-fuse/s3fs-fuse), so that data in S3 appear like normal files on the server’s 353

disk. The data transfer between EC2 and S3 happens automatically under the hood when a file is accessed, 354

without requiring the user to explicitly transfer the data. However, this approach is currently very 355

inefficient for NetCDF data, due to incompatibilities between the HDF5 library and the object-based 356

storage model that S3 uses (Rocklin 2018). This problem might be improved by developing a more cloud-357

friendly backend, such as Zarr (https://github.com/zarr-developers/zarr), for the NetCDF library. For now, 358

we recommend explicitly transferring data between EC2 and S3. 359

360

Once important files are transferred to S3 (or downloaded to local storage), users can safely terminate the 361

EC2 instance. Modification to the software environment can also be saved, by snapshotting the EC2 362

instance into an AMI and then using the new AMI to launch subsequent EC2 instances. 363

364

Advantages and limitations of the workflow 365

The workflow presented here depends on very few AWS functionalities, has a light learning curve, and 366

is flexible enough to match different usage patterns. For example, it is common to repeatedly analyze 367

19

output data after a model simulation. Whenever users need to access the data in S3, they can simply launch 368

a new EC2 instance, pull data from S3 to perform analysis, and terminate the EC2 instance after the 369

analysis is done. Simultaneous model runs can be done in parallel by launching multiple EC2 instances, 370

with input data replicated in each instance’s EBS volume. 371

372

We tested the demo project on 15 members of the Atmospheric Chemistry Modeling Group at Harvard 373

University, and recorded the time they spent on each step (Fig. 3). All were GEOS-Chem users but none 374

had any prior experience with cloud computing. Most finished the demo in less than 30 minutes, and all 375

in less than 60 minutes. The time represents the initial learning curve for first-time AWS users; an 376

experienced AWS user could finish the demo in one minute. An actual research project requires additional 377

steps such as configuring model details and working with S3, but the workflow is not fundamentally 378

different. Overall, it is very fast to get the model running on the cloud, in sharp contrast to the often slow 379

and complicated procedure of setting up the model on a local server. 380

381

The workflow as described above has several limitations for heavy users. Although GEOS-Chem is able 382

to parallelize across multiple compute nodes using MPI (Eastham et al. 2018), here we only execute the 383

model on a single EC2 instance (with up to 64 physical cores on the “x1.32large” instance type), 384

equivalent to a single compute node on an HPC cluster. Also, users need to manually manage the start 385

and termination of each EC2 instance, which can be an administrative burden if there are a large number 386

of simultaneous simulations. These issues may be addressed by creating an HPC cluster environment on 387

the cloud, using software tools such as AWS ParallelCluster (https://aws-parallelcluster.readthedocs.io，388

20

supersedes the previous CfnCluster), StarCluster (http://star.mit.edu/cluster, unmaintained), ElastiCluster 389

(http://elasticluster.readthedocs.io), AlcesFlight (http://docs.alces-flight.com), and EnginFrame 390

(https://www.nice-software.com/products/enginframe). A cluster consists of a “master node” (typically a 391

small EC2 instance) and multiple “compute nodes” (typically high-performance EC2 instances). Such a 392

cluster allows inter-node MPI communication, provides a shared disk (EBS volume) for all nodes via the 393

Network File System (NFS), and often supports “auto-scaling” capability (Amazon 2018e) that 394

automatically launches or terminates compute nodes according to the number of pending jobs. However, 395

we find that cluster tools have a much steeper learning curve for scientists and are generally an overkill 396

for moderate computing workloads. While managing individual EC2 instances is straightforward, 397

configuring and customizing a cluster involve heavier system administration tasks. We plan to address 398

this issue in future work. 399

Performance and cost 400

Computational performance and cost compared to local clusters 401

EC2 instances incur hourly cost to users, with different pricing models. Commonly used are the standard 402

“on-demand” pricing and the discounted “spot” pricing. Spot instances are cheaper than on-demand 403

instances, usually by 60%~70%, with the caveat that they may be reclaimed by AWS to serve the demand 404

from standard EC2 users. Although such spot interruption can cause model simulations to crash, a newly 405

added “Spot Hibernation” option (Amazon 2017a) allows the instance to recover the previous state so that 406

previous simulations can continue when capacity becomes available again. A recent update to the spot 407

21

pricing model further reduces the chance of interruption, so an instance is rarely reclaimed and can 408

generally keep uninterrupted for a month (Amazon 2018f). We recommend using spot pricing for 409

computationally expensive tasks. 410

411

It is challenging to compare the pay-as-you-go pricing model on the cloud with the cost of local HPC 412

clusters that vary in billing model (ECAR 2015b). To simplify such estimation, we use the NASA Pleaides 413

cluster that provides a simple, convenient billing model called Standard Billing Unit (SBU). NASA’s 414

High-End Computing Capability (HECC) Project uses this billing model to evaluate the cost of AWS 415

against the Pleaides cluster (Chang et al. 2018). Jobs on Pleaides are charged by CPU hours, with the cost 416

rate “calculated as the total annual HECC costs divided by the total number of [CPU hours used]” and 417

thus is able to represent “the costs of operating the HECC facility including hardware and software costs, 418

maintenance, support staff, facility maintenance, and electrical power costs”. Pleiades costs are not borne 419

directly by the users in that allocation of SBUs is through NASA research grants, but the costs are still 420

borne by NASA. We consider several types of AWS EC2 instances and compute nodes on the Pleiades 421

cluster with comparable performance, as summarized in Table 1. 422

423

For performance and cost comparisons we used GEOS-Chem version 12.1.1 to conduct a 7-day 424

simulation with tropospheric and stratospheric chemistry (Eastham et al. 2014) at global 4° × 5° resolution, 425

using OpenMP parallelization. We tested the model performance both on the native machine and inside 426

the software container, on both the AWS cloud (using the Singularity container) and Pleiades (using the 427

22

CharlieCloud container). The performance difference introduced by running the model inside the 428

container is less than 1%, so there is no significant penalty to using containers. 429

430

The timing results and total costs are shown in Fig.4. The newer “c5” generation has better performance 431

and lower cost than the older “c4” generation. The smaller instance “c5.4xlarge” is more cost-efficient 432

than the bigger “c5.9xlarge” instance, due to the sublinear scaling of GEOS-Chem OpenMP 433

parallelization and a fixed I/O time. With spot pricing, the cost of EC2 is close to Pleiades. It is important 434

to point out that Pleaides has a very high utilization rate of over 80% (Chang et al. 2018); for other local 435

clusters with lower utilization rates, the pay-as-you-go pricing on the cloud becomes even more attractive. 436

From a user standpoint, any comparative cost decision is complicated by the varying levels of research 437

subsidy and grant-based allocation for time on local or supercomputing clusters. A better decision basis 438

is the cost of an actual research project on the cloud, and we discuss this below. 439

440

Total cost of an example project 441

Here we calculate the total cost of the actual research simulation example in the previous section (1-year 442

2 ° × 2.5 ° global GEOS-Chem simulation of tropospheric and stratospheric chemistry with daily chemical 443

fields for 168 species archived, representing 150 GB of output data). Besides the major charge with EC2, 444

minor charges include the storage cost with EBS and S3. Users also incur a “data egress fee” if they 445

download data to their local clusters. While AWS and the other major cloud vendors usually do not charge 446

for transferring data into the cloud or between cloud services, they charge for transferring data out of the 447

23

cloud. AWS allows academic users to waive the data egress fee, up to 15% of the total charge to the user 448

(Amazon 2016). 449

450

Table 2 summarizes the major AWS services used in the GEOS-Chem simulation and their unit costs. 451

The same services would be used for any other Earth science model. Table 3 summarizes the total cost of 452

our example GEOS-Chem research simulation conducted on the most cost-efficient “c5.4xlarge” EC2 453

instance type. The compute cost for the 1-year simulation with EC2 is $224 with on-demand pricing, and 454

can be reduced to $90 with spot pricing (which we recommend). The temporary storage cost with EBS 455

($14) is relatively small. The long-term storage cost with S3 or the data egress fee greatly depends on 456

users’ needs. 1-year daily concentration fields for 168 chemical species on the global 3-D domain 457

represent 150 GB of data, only contributing a small amount to the total cost ($3.50 per month). However, 458

if the user needs to produce TBs of data (e.g. hourly fields for a year), the storage cost can become 459

important. The cost of a long-term archive can be greatly reduced by using Amazon S3 Glacier 460

(https://aws.amazon.com/glacier/), a cheaper version of S3 with 80% price reduction but longer data 461

retrieval time. Glacier can be a good option for long-term archiving of data after the research project has 462

been completed. 463

464

In summary, the total cost of a 1-year global GEOS-Chem simulation with 2° × 2.5° resolution and full 465

chemistry on the AWS cloud is about $120 using EC2 spot pricing. A 1-year 4° × 5° simulation costs four 466

times less ($30). The cost is mostly from the computing itself. Downloading or archiving output data is 467

24

generally cheap by comparison. Transferring GEOS-Chem input data from S3 to EBS is free and fast as 468

these data are already resident on the cloud. 469

470

The cost of computing on the cloud should make it highly attractive to occasional users, particularly 471

because of the time savings in model configuration and data transfer, as well as the assurance that the 472

simulation replicates the current standard benchmarked version of the model. AWS currently offers a 473

$100 credit per year to university students (Amazon 2018g) to encourage experimentation on the cloud. 474

Heavy users may still prefer local or supercomputing clusters, particularly if grant-funded. The cloud will 475

become more attractive with a funding model comparable to the research subsidies and grant allocations 476

for local clusters. Despite special funding programs such as NSF BIGDATA (NSF 2018a), E-CAS (NSF 477

2018b), AWS Cloud Credits for Research (Amazon 2018h), Azure AI for Earth (Microsoft 2018c), and 478

Google Cloud Platform research credits (Google 2018b) that directly give credits on commercial clouds, 479

the funding is still far lagging that of traditional supercomputing centers (Section 12 of Bottum et al., 480

2017). Chapter 6.3.3 of NAS (2016) suggests several ways for NSF to better fund commercial cloud 481

resources. 482

483

Heavy users running GEOS-Chem on local or supercomputing clusters can still benefit from the cloud 484

for downloading model input data, because AWS S3 has a very high outgoing bandwidth which can often 485

fully utilize the ingoing bandwidth of a local cluster. We achieve a data transfer rate of 100 MB/s from 486

S3 to the Pleiades cluster, an order of magnitude faster than from the FTP server at Harvard. Transferring 487

1 year of global 2° × 2.5° meteorological input data (112 GB) for input to GEOS-Chem finishes in 20 488

25

minutes, which would have taken 3 hours from the Harvard FTP server. The egress fee is only $10. The 489

cloud, together with software containers, can thus accelerate the deployment of GEOS-Chem on local 490

clusters as well. 491

Conclusions and future work 492

Cloud computing is becoming increasingly attractive for Earth science modeling. It provides easy access 493

to complex models and large datasets and allows straightforward and error-free computing. We have 494

described how the GEOS-Chem global model of atmospheric chemistry is now fully accessible for users 495

on the AWS cloud. The cloud gives users immediate access to the computational resources, software 496

environment, and large input data needed to perform GEOS-Chem simulations for any year and for any 497

grid resolution supported by the standard model. Single-node GEOS-Chem simulations on the AWS cloud 498

compare favorably in performance and true cost with local clusters. Scientists can learn the single-node 499

workflow on the cloud very quickly by following our project documentation and tutorial. Our specific 500

application is for GEOS-Chem but the general principles can be adapted to other Earth science models, 501

which tend to follow the same structure and requirements. 502

503

We find the cloud to be particularly attractive for beginning or occasional users, who otherwise may need 504

to spend significant personnel time configuring a local computing environment. Heavy users with their 505

own local clusters should still find the cloud useful for getting the latest model and data updates, 506

benchmarking their local simulations against the standard model resident on the cloud, carrying out 507

26

collaborative research in a reproducible environment, and temporarily expanding their computing 508

capacity. 509

510

The cloud is also a promising vehicle for massively parallel simulations emulating local HPC clusters, 511

but several issues need to be addressed. A proper research funding model becomes particularly important 512

for compute-intensive simulations, as the costs can be significant. Although it is widely perceived that 513

cloud platforms are not efficient for large-scale MPI programs due to slow communication across nodes, 514

the network performance of cloud platforms has been improving rapidly over the past several years. The 515

Microsoft Azure cloud now offers InfiniBand connection and achieves similar scalability as traditional 516

supercomputers (Mohammadi and Bazhirov 2017). Recent updates on the AWS cloud, including a new 517

instance type with 100 Gb/s bandwidth (which exceeds the typical ~50 Gb/s bandwidth on local HPC 518

clusters) (Amazon 2018j), a low-latency network interface (Amazon 2018j) to improve the scaling of MPI 519

programs, and a parallel file system service for efficient I/O (Amazon 2018k), have greatly increased the 520

potential of cloud computing for HPC applications. There remain several challenges. Although many 521

HPC cluster management tools have been developed for the cloud, the learning curve of these tools is 522

steeper than for the single-node applications described here. Also, although containers are highly portable 523

in a single-node environment, they become less portable when inter-node MPI communication is needed. 524

Docker is found to have significant overhead for multi-node MPI applications (Younge et al. 2017; Zhang 525

et al. 2017); Singularity achieves better performance by directly using the MPI installed on the host 526

machine, but requires compatibility between the MPI libraries inside and outside of the container. These 527

issues will be addressed in future work. 528

27

Code availability 529

The source code for our project documentation, the scripts for building AWS images, the Python 530

notebooks for generating all plots in this article, are available at our project repository 531

https://github.com/geoschem/geos-chem-cloud. Scripts for building GEOS-Chem Docker images are at 532

https://github.com/geoschem/geos-chem-docker. The survey results producing Fig. 3 are available at 533

https://github.com/geoschem/geos-chem-cloud/issues/15. 534

535

Acknowledgments. This work was funded by the NASA Earth Science Division. JZ was supported by 536

the NASA Earth and Space Science Fellowship. The authors would like to thank Kevin Jorissen, Joe 537

Flasher, and Jed Sundwall at Amazon Web Services for supporting this work. 538

References 539

Amazon, 2016: AWS Offers Data Egress Discount to Researchers. Accessed December 20, 2018, 540

https://aws.amazon.com/blogs/publicsector/aws-offers-data-egress-discount-to-researchers/. 541

——, 2017a: Amazon EC2 Spot Lets you Pause and Resume Your Workloads. Accessed December 20, 542

2018, https://aws.amazon.com/about-aws/whats-new/2017/11/amazon-ec2-spot-lets-you-pause-543

and-resume-your-workloads/. 544

——, 2017b: Announcing Amazon EC2 per second billing. Accessed December 20, 2018, 545

https://aws.amazon.com/about-aws/whats-new/2017/10/announcing-amazon-ec2-per-second-546

billing/. 547

28

——, 2018a: AWS official documentation. Accessed December 20, 2018, https://docs.aws.amazon.com/. 548

——, 2018b: AWS Research Cloud Program: Researcher’s Handbook. Accessed December 20, 2018, 549

https://aws.amazon.com/government-education/research-and-technical-computing/research-cloud-550

program/. 551

——, 2018c: AWS Cloud Products. Accessed December 20, 2018, https://aws.amazon.com/products/. 552

——, 2018d: Amazon EC2 Instance Types. Accessed December 20, 2018, 553

https://aws.amazon.com/ec2/instance-types/. 554

——, 2018e: AWS Auto Scaling. Accessed December 20, 2018, https://aws.amazon.com/autoscaling/. 555

——, 2018f: New Amazon EC2 Spot pricing model: Simplified purchasing without bidding and fewer 556

interruptions. Accessed December 20, 2018, https://aws.amazon.com/blogs/compute/new-amazon-557

ec2-spot-pricing/. 558

——, 2018g: AWS Educate Program. Accessed December 20, 2018, 559

https://aws.amazon.com/education/awseducate/. 560

——, 2018h: AWS Cloud Credits for Research. Accessed December 20, 2018, 561

https://aws.amazon.com/research-credits/. 562

——, 2018i: New C5n Instances with 100 Gbps Networking. Accessed December 20, 2018, 563

https://aws.amazon.com/blogs/aws/new-c5n-instances-with-100-gbps-networking/. 564

——, 2018j: Introducing Elastic Fabric Adapter. Accessed December 20, 2018, 565

https://aws.amazon.com/about-aws/whats-new/2018/11/introducing-elastic-fabric-adapter/. 566

——, 2018k: Amazon FSx for Lustre. Accessed December 20, 2018, https://aws.amazon.com/fsx/lustre/. 567

——, 2018l: Physical Cores by Amazon EC2 and RDS DB Instance Type. Accessed December 20, 2018, 568

29

https://aws.amazon.com/ec2/physicalcores/. 569

Ansari, S., and Coauthors, 2017: Unlocking the potential of NEXRAD data through NOAA’s Big Data 570

Partnership. Bull. Am. Meteorol. Soc., BAMS-D-16-0021.1, doi:10.1175/BAMS-D-16-0021.1. 571

http://journals.ametsoc.org/doi/10.1175/BAMS-D-16-0021.1. 572

Bey, I., and Coauthors, 2001: Global modeling of tropospheric chemistry with assimilated meteorology: 573

Model description and evaluation. J. Geophys. Res. Atmos., 106, 23073–23095. 574

Boettiger, C., 2014: An introduction to Docker for reproducible research, with examples from the R 575

environment. ACM SIGOPS Oper. Syst. Rev., 49, 71–79, doi:10.1145/2723872.2723882. 576

http://arxiv.org/abs/1410.0846%0Ahttp://dx.doi.org/10.1145/2723872.2723882. 577

Bottum, J., and Coauthors, 2017: The Future of Cloud for Academic Research Computing. 1-21 pp. 578

Canon, R. S., and D. Jacobsen, 2016: Shifter : Containers for HPC. Cray User Gr. 2016,. 579

Carlyle, A. G., S. L. Harrell, and P. M. Smith, 2010: Cost-effective HPC: The community or the cloud? 580

Proc. - 2nd IEEE Int. Conf. Cloud Comput. Technol. Sci. CloudCom 2010, 169–176, 581

doi:10.1109/CloudCom.2010.115. 582

Carman, J. C., and Coauthors, 2017: The national earth system prediction capability: Coordinating the 583

giant. Bull. Am. Meteorol. Soc., 98, 239–252, doi:10.1175/BAMS-D-16-0002.1. 584

Chang, S., and Coauthors, 2018: Evaluating the Suitability of Commercial Clouds for NASA ’ s High 585

Performance Computing Applications : A Trade Study. 1–46. 586

Chen, X., X. Huang, C. Jiao, M. G. Flanner, T. Raeker, and B. Palen, 2017: Running climate model on a 587

commercial cloud computing environment: A case study using Community Earth System Model 588

(CESM) on Amazon AWS. Comput. Geosci., 98, 21–25, doi:10.1016/j.cageo.2016.09.014. 589

30

Chollet, F., 2017: Deep Learning with Python. Manning,. 590

Christian, K. E., W. H. Brune, J. Mao, and X. Ren, 2018: Global sensitivity analysis of GEOS-Chem 591

modeled ozone and hydrogen oxides during the INTEX campaigns. Atmos. Chem. Phys., 18, 2443–592

2460, doi:10.5194/acp-18-2443-2018. 593

Coffrin, C., and Coauthors, 2019: The ISTI Rapid Response on Exploring Cloud Computing 2018. 1–72. 594

http://arxiv.org/abs/1901.01331. 595

Dodson, R., and Coauthors, 2016: Imaging SKA-scale data in three different computing environments. 596

Astron. Comput., 14, 8–22, doi:10.1016/j.ascom.2015.10.007. 597

Duran-Limon, H. A., J. Flores-Contreras, N. Parlavantzas, M. Zhao, and A. Meulenert-Peña, 2016: 598

Efficient execution of the WRF model and other HPC applications in the cloud. Earth Sci. 599

Informatics, 9, 365–382, doi:10.1007/s12145-016-0253-7. http://link.springer.com/10.1007/s12145-600

016-0253-7. 601

Eastham, S. D., D. K. Weisenstein, and S. R. H. Barrett, 2014: Development and evaluation of the unified 602

tropospheric-stratospheric chemistry extension (UCX) for the global chemistry-transport model 603

GEOS-Chem. Atmos. Environ., 89, 52–63, doi:10.1016/j.atmosenv.2014.02.001. 604

http://dx.doi.org/10.1016/j.atmosenv.2014.02.001. 605

——, and Coauthors, 2018: GEOS-Chem high performance (GCHP v11-02c): A next-generation 606

implementation of the GEOS-Chem chemical transport model for massively parallel applications. 607

Geosci. Model Dev., 11, 2941–2953, doi:10.5194/gmd-11-2941-2018. 608

ECAR, 2015a: Research Computing in the Cloud -- Functional Considerations for Research. 609

——, 2015b: TCO for Cloud Services. 610

31

Emeras, J., S. Varrette, and P. Bouvry, 2017: Amazon elastic compute cloud (EC2) vs. in-house HPC 611

platform: A cost analysis. IEEE International Conference on Cloud Computing, CLOUD, 284–293. 612

Evangelinos, C., and C. N. Hill, 2008: Cloud Computing for parallel Scientific HPC Applications: 613

Feasibility of Running Coupled Atmosphere-Ocean Climate Models on Amazon’s EC2. Cca’08, 2, 614

2–34. 615

Foster, I., and D. B. Gannon, 2017: Cloud computing for science and engineering. 616

https://mitpress.mit.edu/books/cloud-computing-science-and-engineering. 617

Fox, A., 2011: Cloud computing - What’s in it for me as a scientist? Science (80-. )., 331, 406–407, 618

doi:10.1126/science.1198981. 619

Freniere, C., A. Pathak, M. Raessi, and G. Khanna, 2016: The feasibility of amazon’s cloud computing 620

platform for parallel, GPU-accelerated, multiphase-flow simulations. Comput. Sci. Eng., 18, 68–77, 621

doi:10.1109/MCSE.2016.94. 622

GEOS-Chem, 2018a: GEOS-Chem People and Projects. Accessed December 20, 2018, 623

http://acmg.seas.harvard.edu/geos/geos_people.html. 624

——, 2018b: GEOS-Chem Steering Committee. Accessed December 20, 2018, 625

http://acmg.seas.harvard.edu/geos/geos_steering_cmte.html. 626

——, 2018c: GNU Fortran compiler. Accessed December 20, 2018, http://wiki.seas.harvard.edu/geos-627

chem/index.php/GNU_Fortran_compiler. 628

——, 2018d: Timing tests with GEOS-Chem 12.0.0. Accessed December 20, 2018, 629

http://wiki.seas.harvard.edu/geos-chem/index.php/Timing_tests_with_GEOS-Chem_12.0.0. 630

——, 2018e: GEOS-Chem benchmarking. Accessed December 20, 2018, 631

32

http://wiki.seas.harvard.edu/geos-chem/index.php/GEOS-Chem_benchmarking. 632

——, 2018f: List of diagnostics archived to netCDF format. Accessed December 20, 2018, 633

http://wiki.seas.harvard.edu/geos-634

chem/index.php/List_of_diagnostics_archived_to_netCDF_format. 635

Google, 2018a: Google Cloud Platform for AWS Professionals. Accessed December 20, 2018, 636

https://cloud.google.com/docs/compare/aws/. 637

——, 2018b: Google Cloud Platform announces new credits program for researchers. Accessed 638

December 20, 2018, https://www.blog.google/products/google-cloud/google-cloud-platform-639

announces-new-credits-program-researchers/. 640

Gorelick, N., M. Hancher, M. Dixon, S. Ilyushchenko, D. Thau, and R. Moore, 2017: Google Earth 641

Engine: Planetary-scale geospatial analysis for everyone. Remote Sens. Environ., 642

doi:10.1016/j.rse.2017.06.031. http://linkinghub.elsevier.com/retrieve/pii/S0034425717302900. 643

Gupta, A., and D. Milojicic, 2011: Evaluation of hpc applications on cloud. Open Cirrus Summit (OCS), 644

2011 Sixth, 22–26. 645

——, and Coauthors, 2013: The Who , What , Why and How of High Performance Computing 646

Applications in the Cloud. HP Lab., doi:10.1109/CloudCom.2013.47. 647

Hacker, J. P., J. Exby, D. Gill, I. Jimenez, C. Maltzahn, T. See, G. Mullendore, and K. Fossell, 2017: A 648

containerized mesoscale model and analysis toolkit to accelerate classroom learning, collaborative 649

research, and uncertainty quantification. Bull. Am. Meteorol. Soc., 98, 1129–1138, 650

doi:10.1175/BAMS-D-15-00255.1. 651

Hale, J. S., L. Li, C. N. Richardson, and G. N. Wells, 2017: Containers for Portable, Productive, and 652

33

Performant Scientific Computing. Comput. Sci. Eng., 19, 40–50, doi:10.1109/MCSE.2017.2421459. 653

Harvard RC, 2018: Singularity on Odyssey. Accessed December 20, 2018, 654

https://www.rc.fas.harvard.edu/resources/documentation/software/singularity-on-odyssey/. 655

Hill, C., C. DeLuca, Balaji, M. Suarez, and A. Da Silva, 2004: The architecture of the Earth system 656

modeling framework. Comput. Sci. Eng., 6, 18–28, doi:10.1109/MCISE.2004.1255817. 657

Hill, Z., and M. Humphrey, 2009: A quantitative analysis of high performance computing with Amazon’s 658

EC2 infrastructure: The death of the local cluster? Proc. - IEEE/ACM Int. Work. Grid Comput., 26–659

33, doi:10.1109/GRID.2009.5353067. 660

Hoesly, R. M., and Coauthors, 2018: Historical (1750-2014) anthropogenic emissions of reactive gases 661

and aerosols from the Community Emissions Data System (CEDS). Geosci. Model Dev., 11, 369–662

408, doi:10.5194/gmd-11-369-2018. 663

Hong, S.-Y., M.-S. Koo, J. Jang, J.-E. Esther Kim, H. Park, M.-S. Joh, J.-H. Kang, and T.-J. Oh, 2013: 664

An Evaluation of the Software System Dependency of a Global Atmospheric Model. Mon. Weather 665

Rev., 141, 4165–4172, doi:10.1175/MWR-D-12-00352.1. 666

http://journals.ametsoc.org/doi/abs/10.1175/MWR-D-12-00352.1. 667

Hossain, M. M., R. Wu, J. T. Painumkal, M. Kettouch, C. Luca, S. M. Dascalu, and F. C. Harris, 2017: 668

Web-service framework for environmental models. 2017 Internet Technol. Appl., 104–109, 669

doi:10.1109/ITECHA.2017.8101919. http://ieeexplore.ieee.org/document/8101919/. 670

Howe, B., 2012: Virtual appliances, cloud computing, and reproducible research. Comput. Sci. Eng., 14, 671

36–41, doi:10.1109/MCSE.2012.62. 672

Hoyer, S., and J. J. Hamman, 2017: xarray: N-D labeled Arrays and Datasets in Python. J. Open Res. 673

34

Softw., 5, 1–6, doi:10.5334/jors.148. 674

http://openresearchsoftware.metajnl.com/articles/10.5334/jors.148/. 675

Huang, Q., C. Yang, K. Benedict, S. Chen, A. Rezgui, and J. Xie, 2013: Utilize cloud computing to 676

support dust storm forecasting. Int. J. Digit. Earth, 6, 338–355, doi:10.1080/17538947.2012.749949. 677

Hunter, J. D., 2007: Matplotlib: A 2D graphics environment. Comput. Sci. Eng., 9, 99–104, 678

doi:10.1109/MCSE.2007.55. 679

Huntington, J. L., and Coauthors, 2017: Climate Engine: Cloud Computing and Visualization of Climate 680

and Remote Sensing Data for Advanced Natural Resource Monitoring and Process Understanding. 681

Bull. Am. Meteorol. Soc., BAMS-D-15-00324.1, doi:10.1175/BAMS-D-15-00324.1. 682

http://journals.ametsoc.org/doi/10.1175/BAMS-D-15-00324.1. 683

Irving, D., 2016: A minimum standard for publishing computational results in the weather and climate 684

sciences. Bull. Am. Meteorol. Soc., 97, 1149–1158, doi:10.1175/BAMS-D-15-00010.1. 685

Jackson, K. R., L. Ramakrishnan, K. Muriki, S. Canon, S. Cholia, J. Shalf, H. J. Wasserman, and N. J. 686

Wright, 2010: Performance Analysis of High Performance Computing Applications on the Amazon 687

Web Services Cloud. 2010 IEEE Second Int. Conf. Cloud Comput. Technol. Sci., 159–168, 688

doi:10.1109/CloudCom.2010.69. http://ieeexplore.ieee.org/document/5708447/. 689

Jacobsen, D. M., and R. S. Canon, 2015: Contain This, Unleashing Docker for HPC. Cray User Gr. 2015, 690

14. https://www.nersc.gov/assets/Uploads/cug2015udi.pdf. 691

Jeong, J. I., and R. J. Park, 2018: Efficacy of dust aerosol forecasts for East Asia using the adjoint of 692

GEOS-Chem with ground-based observations. Environ. Pollut., 234, 885–893, 693

doi:10.1016/j.envpol.2017.12.025. 694

35

Jing, Y., T. Wang, P. Zhang, L. Chen, N. Xu, and Y. Ma, 2018: Global atmospheric CO2 concentrations 695

simulated by GEOS-Chem: Comparison with GOSAT, carbon tracker and ground-based 696

measurements. Atmosphere (Basel)., 9, doi:10.3390/atmos9050175. 697

Jonas, E., and Coauthors, 2019: Cloud Programming Simplified: A Berkeley View on Serverless 698

Computing. 1–33. http://arxiv.org/abs/1902.03383. 699

Jung, K., Y. Cho, and Y. Tak, 2017: Performance evaluation of ROMS v3 . 6 on a commercial cloud 700

system. 701

Keller, C. A., M. S. Long, R. M. Yantosca, A. M. Da Silva, S. Pawson, and D. J. Jacob, 2014: HEMCO 702

v1.0: A versatile, ESMF-compliant component for calculating emissions in atmospheric models. 703

Geosci. Model Dev., 7, 1409–1417, doi:10.5194/gmd-7-1409-2014. 704

Kurtzer, G. M., V. Sochat, and M. W. Bauer, 2017: Singularity: Scientific containers for mobility of 705

compute. PLoS One, 12, e0177459, doi:10.1371/journal.pone.0177459. 706

http://www.ncbi.nlm.nih.gov/pubmed/28494014. 707

Langkamp, T., 2011: Influence of the compiler on multi-CPU performance of WRFv3. Geosci. Model 708

Dev. Discuss., 4, 547–573, doi:10.5194/gmdd-4-547-2011. http://www.geosci-model-dev-709

discuss.net/4/547/2011/. 710

Li, R., L. Liu, G. Yang, C. Zhang, and B. Wang, 2016: Bitwise identical compiling setup: Prospective for 711

reproducibility and reliability of Earth system modeling. Geosci. Model Dev., 9, 731–748, 712

doi:10.5194/gmd-9-731-2016. 713

Li, Z., C. Yang, Q. Huang, K. Liu, M. Sun, and J. Xia, 2017: Building Model as a Service to support 714

geosciences. Comput. Environ. Urban Syst., 61, 141–152, 715

36

doi:10.1016/j.compenvurbsys.2014.06.004. 716

Lynnes, C., K. Baynes, and M. A. McInerney., 2017: Archive Management of NASA Earth Observation 717

Data to Support Cloud Analysis. 0–3. 718

https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20170011455.pdf. 719

Mehrotra, P., J. Djomehri, S. Heistand, R. Hood, H. Jin, A. Lazanoff, S. Saini, and R. Biswas, 2016: 720

Performance evaluation of Amazon Elastic Compute Cloud for NASA high-performance computing 721

applications. Concurr. Comput. , 28, 1041–1055, doi:10.1002/cpe.3029. 722

http://doi.wiley.com/10.1002/cpe.3029. 723

Met Office, 2016: Cartopy: a cartographic python library with a matplotlib interface. 724

http://scitools.org.uk/cartopy. 725

Microsoft, 2018a: Microsoft Azure for Research Online. Accessed December 20, 2018, 726

https://a4ronline.azurewebsites.net. 727

——, 2018b: Azure for AWS Professionals. Accessed December 20, 2018, 728

https://docs.microsoft.com/en-us/azure/architecture/aws-professional/. 729

——, 2018c: Azure AI for Earth grants. Accessed December 20, 2018, https://www.microsoft.com/en-730

us/ai-for-earth/grants. 731

Mohammadi, M., and T. Bazhirov, 2017: Comparative benchmarking of cloud computing vendors with 732

High Performance Linpack. 1–6, doi:10.1145/3195612.3195613. http://arxiv.org/abs/1702.02968. 733

Molthan, A., J. Case, and J. Venner, 2015: Clouds in the cloud: weather forecasts and applications within 734

cloud computing environments. Bull., 96, 1369–1379. 735

http://journals.ametsoc.org/doi/abs/10.1175/BAMS-D-14-00013.1. 736

37

Montes, D., J. A. Añel, T. F. Pena, P. Uhe, and D. C. H. Wallom, 2017: Enabling BOINC in infrastructure 737

as a service cloud system. Geosci. Model Dev., 10, 811–826, doi:10.5194/gmd-10-811-2017. 738

NAS, 2018: Thriving on Our Changing Planet. National Academies Press, Washington, D.C., 739

https://www.nap.edu/catalog/24938. 740

NASA HECC, 2018: Enabling User-Defined Software Stacks with Charliecloud. Accessed December 20, 741

2018, https://www.nas.nasa.gov/hecc/support/kb/enabling-user-defined-software-stacks-with-742

charliecloud_558.html. 743

National Academies of Sciences, E., 2016: Future Directions for NSF Advanced Computing 744

Infrastructure to Support U.S. Science and Engineering in 2017-2020. 745

Netto, M. A. S., R. N. Calheiros, E. R. Rodrigues, R. L. F. Cunha, and R. Buyya, 2017: HPC Cloud for 746

Scientific and Business Applications: Taxonomy, Vision, and Research Challenges. 1, 1–29. 747

http://arxiv.org/abs/1710.08731. 748

NSF, 2018a: Critical Techniques, Technologies and Methodologies for Advancing Foundations and 749

Applications of Big Data Sciences and Engineering (BIGDATA). Accessed December 20, 2018, 750

https://www.nsf.gov/funding/pgm_summ.jsp?pims_id=504767. 751

——, 2018b: NSF and Internet2 to explore cloud computing to accelerate science frontiers. Accessed 752

December 20, 2018, https://nsf.gov/news/news_summ.jsp?cntn_id=297193. 753

Oesterle, F., S. Ostermann, R. Prodan, and G. J. Mayr, 2015: Experiences with distributed computing for 754

meteorological applications: Grid computing and cloud computing. Geosci. Model Dev., 8, 2067–755

2078, doi:10.5194/gmd-8-2067-2015. 756

de Oliveira, A. H. M., D. de Oliveira, and M. Mattoso, 2017: Clouds and Reproducibility: A Way to Go 757

38

to Scientific Experiments? Cloud Computing, Springer International Publishing, 127–151 758

http://link.springer.com/10.1007/978-3-319-54645-2_5. 759

Perkel, J. M., 2018: Why Jupyter is data scientists’ computational notebook of choice. Nature, 563, 145–760

146, doi:10.1038/d41586-018-07196-1. http://www.nature.com/articles/d41586-018-07196-1. 761

Priedhorsky, R., T. C. Randles, and T. Randles, 2017: Charliecloud: Unprivileged containers for user-762

defined software stacks in HPC Charliecloud: Unprivileged containers for user-defined software 763

stacks in HPC. SC17 Int. Conf. High Perform. Comput. Networking, Storage Anal., 17, p1-10, 764

doi:10.1145/3126908.3126925. http://permalink.lanl.gov/object/tr?what=info:lanl-765

repo/lareport/LA-UR-16-22370. 766

Rocklin, M., 2015: Dask : Parallel Computation with Blocked algorithms and Task Scheduling. Proc. 767

14th Python Sci. Conf., 130–136. 768

——, 2018: HDF in the Cloud: challenges and solutions for scientific data. Accessed December 20, 2018, 769

http://matthewrocklin.com/blog/work/2018/02/06/hdf-in-the-cloud. 770

Roloff, E., M. Diener, A. Carissimi, and P. O. A. Navaux, 2012: High Performance Computing in the 771

cloud: Deployment, performance and cost efficiency. 4th IEEE International Conference on Cloud 772

Computing Technology and Science Proceedings, IEEE, 371–378 773

http://ieeexplore.ieee.org/document/6427549/. 774

——, ——, L. P. Gaspary, and P. O. A. Navaux, 2017: HPC Application Performance and Cost Efficiency 775

in the Cloud. Proc. - 2017 25th Euromicro Int. Conf. Parallel, Distrib. Network-Based Process. PDP 776

2017, 473–477, doi:10.1109/PDP.2017.59. 777

Salaria, S., K. Brown, H. Jitsumoto, and S. Matsuoka, 2017: Evaluation of HPC-Big Data Applications 778

39

Using Cloud Platforms. Proc. 17th IEEE/ACM Int. Symp. Clust. Cloud Grid Comput., 1053–1061, 779

doi:10.1109/CCGRID.2017.143. https://doi.org/10.1109/CCGRID.2017.143. 780

Shaikh, R., 2018: tmux on AWS. Accessed December 20, 2018, 781

https://github.com/reshamas/fastai_deeplearn_part1/blob/master/tools/tmux.md. 782

Shen, H., 2014: Interactive notebooks: Sharing the code. Nature, 515, 151–152, doi:10.1038/515151a. 783

http://www.nature.com/doifinder/10.1038/515151a. 784

Siuta, D., G. West, H. Modzelewski, R. Schigas, and R. Stull, 2016: Viability of Cloud Computing for 785

Real-Time Numerical Weather Prediction. Weather Forecast., 31, 1985–1996, doi:10.1175/WAF-786

D-16-0075.1. http://journals.ametsoc.org/doi/10.1175/WAF-D-16-0075.1. 787

Strazdins, P. E., J. Cai, M. Atif, and J. Antony, 2012: Scientific application performance on HPC, private 788

and public cloud resources: A case study using climate, cardiac model codes and the NPB benchmark 789

suite. Proc. 2012 IEEE 26th Int. Parallel Distrib. Process. Symp. Work. IPDPSW 2012, 1416–1424, 790

doi:10.1109/IPDPSW.2012.186. 791

Thackston, R., and R. C. Fortenberry, 2015: The performance of low-cost commercial cloud computing 792

as an alternative in computational chemistry. J. Comput. Chem., 36, 926–933, 793

doi:10.1002/jcc.23882. 794

Tian, Y., Y. Sun, C. Liu, P. Xie, K. Chan, J. Xu, W. Wang, and J. Liu, 2018: Characterization of urban 795

CO2 column abundance with a portable low resolution spectrometer (PLRS): Comparisons with 796

GOSAT and GEOS-Chem model data. Sci. Total Environ., 612, 1593–1609. 797

Tsaftaris, S. A., 2014: A scientist’s guide to cloud computing. Comput. Sci. Eng., 16, 70–76, 798

doi:10.1109/MCSE.2014.12. 799

40

Vance, T. C., N. Merati, C. P. Yang, and M. Yuan, 2016: Cloud Computing in Ocean and Atmospheric 800

Sciences. 1-415 pp. 801

VanderPlas, J., 2016: Python Data Science Handbook. O’Reilly Media, Inc. 802

Walker, E., 2008: Benchmarking Amazon EC2 for high-performance scientific computing. login Mag. 803

USENIX SAGE, 33, 18–23. 804

Withana, E. C., B. Plale, and C. Mattocks, 2011: Towards Enabling Mid-Scale Geoscience Experiments 805

Through Microsoft Trident and Windows Azure. 806

Yang, C., Q. Huang, Z. Li, K. Liu, and F. Hu, 2017: Big Data and cloud computing: innovation 807

opportunities and challenges. Int. J. Digit. Earth, 10, 13–53, doi:10.1080/17538947.2016.1239771. 808

Yelick, K., and Coauthors, 2011: The Magellan Report on Cloud Computing for Science. 170. 809

Younge, A. J., K. Pedretti, R. E. Grant, and R. Brightwell, 2017: A Tale of Two Systems: Using 810

Containers to Deploy HPC Applications on Supercomputers and Clouds. Proc. Int. Conf. Cloud 811

Comput. Technol. Sci. CloudCom, 2017–Decem, 74–81, doi:10.1109/CloudCom.2017.40. 812

Yu, K., C. A. Keller, D. J. Jacob, A. M. Molod, S. D. Eastham, and M. S. Long, 2018: Errors and 813

improvements in the use of archived meteorological data for chemical transport modeling: An 814

analysis using GEOS-Chem v11-01 driven by GEOS-5 meteorology. Geosci. Model Dev., 11, 305–815

319, doi:10.5194/gmd-11-305-2018. 816

Zhai, Y., M. Liu, J. Zhai, X. Ma, and W. Chen, 2011: Cloud Versus In-house Cluster: Evaluating Amazon 817

Cluster Compute Instances for Running MPI Applications. State Pract. Reports - SC ’11, 1, 818

doi:10.1145/2063348.2063363. 819

Zhang, J., X. Lu, and D. K. Panda, 2017: Is Singularity-based Container Technology Ready for Running 820

41

MPI Applications on HPC Clouds? Proc. the10th Int. Conf. Util. Cloud Comput. - UCC ’17, 151–821

160, doi:10.1145/3147213.3147231. http://dl.acm.org/citation.cfm?doid=3147213.3147231. 822

Zhu, L., M. Val Martin, A. Hecobian, L. V. Gatti, R. Kahn, and E. V. Fischer, 2018: Development and 823

implementation of a new biomass burning emissions injection height scheme for the GEOSChem 824

model. Geosci. Model Dev. Discuss., 1–30, doi:10.5194/gmd-2018-93. https://www.geosci-model-825

dev-discuss.net/gmd-2018-93/. 826

Zhuang, J., 2018: JiaweiZhuang/xESMF: v0.1.1. doi:10.5281/ZENODO.1134366. 827

https://zenodo.org/record/1134366. 828

829

830

42

Table 1. Hardware specification and cost as of December 2018a. 831

Instance/node typeb Processor informationc Hourly costd

On-demand Spote

AWS

EC2 c4.8xlarge Intel Xeon CPU E5-2666v3, 2.9GHz, 32 vCPUs $1.59 $0.57

EC2 c5.9xlarge Intel Xeon Platinum 8124M, 3.0GHz, 32 vCPUs $1.53 $0.58

EC2 c4.4xlarge Intel Xeon CPU E5-2666v3, 2.9GHz, 16 vCPUs $0.80 $0.25

EC2 c5.4xlarge Intel Xeon Platinum 8124M, 3.0GHz, 16 vCPUs $0.68 $0.27

NASA HECC

Pleiades Sandy Bridge Intel Xeon E5-2680v2, 2.8 GHz, 16 CPU cores $0.29 --

Pleiades Haswell Intel Xeon E5-2680v3, 2.5 GHz, 24 CPU cores $0.53 --

a. AWS costs are from https://aws.amazon.com/ec2/pricing/. NASA High-End Computing Capability 832

(HECC) costs are from https://www.hec.nasa.gov/user/policies/sbus.html. Costs are in USD. The price 833

can vary between countries and regions. Shown here are for the US East (N. Virginia) region. Same for 834

Tables 2 and 3. 835

b. The naming of an EC2 instance follows “family, generation, size”. For example, “c4” refers to the 836

“compute-optimized” family, generation four; “8xlarge” indicates the instance size, which has twice as 837

many cores and memory as “4xlarge”. 838

c. EC2 instances are virtual machines and the processors are described by “virtual CPUs” (“vCPUs”). A 839

vCPU is a hyperthread and corresponds to half of a physical core (Amazon 2018l). 840

43

d. EC2 actually uses per-second billing, so that short computations are very cheap (Amazon 2017b). 841

e. The spot price can fluctuate with time. We show here the price when the simulations where conducted. 842

Price fluctuation is typically within 20% in a month. 843

f. The AWS cloud and container environments used GNU Fortran compiler 7.3.0; the NASA Pleiades 844

native environment used GNU Fortran compiler 6.2.0 as it is the latest available version. 845

846

Table 2. Description and cost of major AWS services as of December 2018a 847

Service Description and Purpose Cost

EC2 Server used for computing on AWS. Users

request an EC2 instance with a chosen number

of virtual CPUs (vCPUs) for their computing

need.

~$0.05 per vCPU hour, depending on

instance type. 60%~70% cheaper with

spot pricing. See Table 1 for examples.

EBS Disk storage for temporary data. It hosts input

and output data during model simulations.

$0.1 per GB per month, for the

standard solid-state drive (SSD).

Cheaper options with different I/O

characteristics are available.

S3 Major storage service. User transfer data from

EC2 to S3 for persist storage, and later retrieve

data from S3 to EC2 for continued work.

$0.023 per GB per month. Cheaper

options for infrequent access patterns

are available.

Data egress Downloading data to local machines. $0.09 per GB

a. From https://aws.amazon.com/pricing/services/ 848

44

849

Table 3. AWS cost of a 1-year 2ox2.5o global GEOS-Chem simulation with tropospheric and stratospheric 850

chemistry 851

Service Amount of resources needed Total cost (USD)

EC2 330 hours on c5.4xlarge $224 with on-demand pricing,

$90 with spot pricing

EBS 300 GB disk to host input and output

data files during simulation

$14 with standard solid-state drive

(SSD)

S3 or download 150 GB output data files $3.50 per month on S3,

or $13.50 to download

852

45

. 853

Figure 1. Examples of GEOS-Chem input data hosted on the AWS cloud. Top: Global 25 km-resolution 854

air temperature data at 4 km altitude on July 1, 2016 (0 UTC), from the GEOS-FP meteorological product. 855

Middle: Global 50 km-resolution anthropogenic nitrogen oxides (NOx) emission data averaged over Jan 856

2014,c from the Community Emissions Data System (CEDS, Hoesly et al., 2018). Bottom: Global 2° × 857

2.5° resolution ozone concentration data at 4 km altitude on July 1, 2016 (0 UTC), from model initial 858

condition files. 859

46

860

Figure 2. A complete research workflow for using the GEOS-Chem model on the AWS cloud. From the 861

AWS console accessed through web browsers, users select the GEOS-Chem Amazon Machine Image 862

(AMI) which includes the fully configured model, and launch a Linux server (EC2 instance) from that 863

AMI. Users then login to that EC2 instance through their local terminal, customize the model 864

configuration as desired, and execute the model simulation. Model output can be analyzed on the cloud 865

using Python in Jupyter notebooks, or can be downloaded to users’ local computers. Local I/O is managed 866

47

through the Elastic Block Storage (EBS) volume on the EC2 instance. The complete meteorological and 867

emission data needed to drive GEOS-Chem can be retrieved from a public bucket residing permanently 868

in the Simple Storage Service (S3) of the AWS cloud. Users can also create their own S3 buckets to 869

archive model output data and customized run directories. After finishing the computation, users 870

terminate the EC2 instance; data in the EBS volume will then be deleted but data in the S3 buckets will 871

persist. 872

873

874

Figure 3. Wall-clock time required for 15 GEOS-Chem users with no prior cloud experience to complete 875

a demo GEOS-Chem simulation on the AWS cloud and visualize the output. The actual simulation 876

runtime is not included and is a few minutes for this demo case. 877

48

878

879

Figure 4. Performance and cost comparisons between the AWS EC2 instances and the NASA Pleiades 880

supercomputing cluster for a 7-day GEOS-Chem simulation with tropospheric and stratospheric 881

chemistry at global 4° × 5° resolution, running on a single compute node. See Table 1 for description of 882

the different hardware types. The SBU model is used by NASA to estimate the true cost of Pleiades. Cost 883

is in USD. 884