GMDGeoscientific Model DevelopmentGMDGeosci. Model Dev.1991-9603Copernicus PublicationsGöttingen, Germany10.5194/gmd-10-4393-2017A JavaScript API for the Ice Sheet System Model (ISSM) 4.11: towards an online interactive model for the cryosphere
communityLarourEriceric.larour@jpl.nasa.govChengDanielPerezGilbertoQuinnJustinhttps://orcid.org/0000-0001-9154-5409MorlighemMathieuhttps://orcid.org/0000-0001-5219-1310DuongBaoNguyenLanPetrieKitHarounianSilvaHalkidesDariaHayesWayneJet Propulsion Laboratory – California Institute of Technology, 4800 Oak Grove
Drive 300-323, Pasadena, CA 91109, USADepartment of Information and Computer Sciences, University of California, Donald Bren Hall, Irvine, CA 92697, USADepartment of Earth System Science, University of California, Croul Hall, Irvine, CA 92697,
USAMonoprice, Inc., 11701 6th St., Rancho Cucamonga, CA 91730, USAHart, Inc., 1515 E. Orangewood Ave., Anaheim, CA 92805, USADigitized Schematic Solutions, 40 W. Cochran St. Suite 212, Simi Valley, CA 93065, USAEarth and Space Research, 2101 Fourth Ave., Suite 1310, Seattle, WA 98121, USAEric Larour (eric.larour@jpl.nasa.gov)4December20171012439344039July201625August20161February20174February2017This work is licensed under the Creative Commons Attribution 3.0 Unported License. To view a copy of this licence, visit https://creativecommons.org/licenses/by/3.0/This article is available from https://gmd.copernicus.org/articles/10/4393/2017/gmd-10-4393-2017.htmlThe full text article is available as a PDF file from https://gmd.copernicus.org/articles/10/4393/2017/gmd-10-4393-2017.pdf
Earth system models (ESMs) are becoming increasingly complex, requiring
extensive knowledge and experience to deploy and use in an efficient manner.
They run on high-performance architectures that are significantly different
from the everyday environments that scientists use to pre- and post-process
results (i.e., MATLAB, Python). This results in models that are hard to use
for non-specialists and are increasingly specific in their application.
It also makes them relatively inaccessible to the wider science community,
not to mention to the general public. Here, we present a new software/model
paradigm that attempts to bridge the gap between the science community and
the complexity of ESMs by developing a new JavaScript application program
interface (API) for the Ice Sheet System Model (ISSM). The aforementioned API
allows cryosphere scientists to run ISSM on the client side of a web page
within the JavaScript environment. When combined with a web server running
ISSM (using a Python API), it enables the serving of ISSM computations in an
easy and straightforward way. The deep integration and similarities between
all the APIs in ISSM (MATLAB, Python, and now JavaScript) significantly
shortens and simplifies the turnaround of state-of-the-art science runs and
their use by the larger community. We demonstrate our approach via a new
Virtual Earth System Laboratory (VESL) website (http://vesl.jpl.nasa.gov, ).
Introduction
Earth system models (ESMs) across the Earth science community have become
increasingly sophisticated, enabling more accurate simulations and
projections of the Earth's climate as well as the state of the atmosphere,
ocean, land, ice, and biosphere. As demonstrated by the Coupled Model
Intercomparison Project 5 CMIP-5; and its
new iteration CMIP-6; of the World Climate Research
Programme (WCRP), the multiplicity of ESMs and the complexity of the physics
they capture are significant. The description of the outputs for CMIP-5 runs
is 133 pages long by itself, showing the complexity and comprehensive nature
of the processes modeled in the ESMs that participated in the project. Any
one of these models is massive in terms of the number of lines of code
but also in terms of structure and modularity (or lack thereof). GEOS-5 e.g.,, one of the atmosphere and ocean general
circulation models (AOGCMs) that participated in CMIP-5, is made of 600 000
lines of Fortran code, comprising 88 physical modules (as of January 2016). This
is fairly representative of the complexity of ESMs nowadays, and of the
multiplicity of physical processes necessary to realistically model the
evolution of the whole Earth system.
The above-described complexity results in serious issues regarding the way
simulations are run. For example, what we generally define as pre-processing
and post-processing phases are increasingly different from the computational
phase itself. The computational core is usually written in C or Fortran,
which easily supports parallelism and high-performance computing (HPC).
However, in the pre-processing phase, where datasets are processed into a
binary file used by the computational core, or in the post-processing phase,
where simulation results are visualized, scientific environments such as
MATLAB or Python are increasingly relied upon. This results in additional
complexity to manage different environments: scientists are well acquainted
with the difficulties of porting their software to HPC instances, while
struggling to process the data inputs and results on local workstations where
data upload/download can be a limiting factor, hard drive memory requirements
can be substantial, and problems due to the use of different APIs can be significant
(MATLAB, Python, and IDL, among others).
Another complexity originating from the wide variety of physical processes
represented in ESMs is the difficulty in initializing a computational run.
For example, in the Ice Sheet System Model ISSM;, one of
the land ice components of GEOS-5, developed at the National Aeronautics and
Space Administration (NASA) Jet Propulsion Laboratory (JPL), in collaboration
with University of California, Irvine (UCI), the initialization setup for the
Greenland Ice Sheet (GIS) transient simulations from 1850 to present day
amounts to 3000 lines of MATLAB code. This comprises model setup, data
interpolation onto an ISSM compatible mesh, solution parameterizations, and
initialization strategies, among other things. This simulation, part of the
Ice Sheet Modeling Intercomparison Project 6 ISMIP-6;
that accounts for ice sheets in CMIP-6, is a fairly representative example of
some of the most advanced simulations that can be run with an ice sheet model
(ISM). Such simulations cannot easily be systematized and need to be tailored
specifically for each ice sheet they are applied to.
One of the approaches that could mitigate some of the issues discussed above
involves the development of computational frameworks capable of serving ESM
simulations. This type of solution involves running simulations that already
include pre- and post-processing phases (i.e., where the model setup has already
been carried out or is carried out by the server itself by uploading key
datasets) and in which the user is allowed to control only a few key
parameters. Similarly, once the computation is carried out on the
server side, the results are post-processed automatically, and only
significant results are provided to the user. This type of approach has
already been explored, for example, in areas related to serving of large
datasets, such as the NASA Earth Observing System Data and Information System
(EOSDIS) EarthData server, which provides a portal with integrated processing
capabilities for large-scale datasets collected by NASA missions. However,
fewer examples of this kind of approach are available that serve simulation
results, and to our knowledge, no comprehensive ESM, nor module thereof, has
ever been integrated into a server solution capable of delivering ESM
computations on the fly. The reason for this is simple: the complexity of the
physics involved is significant, reconciling pre/post-processing phases and
simulation cores is inherently difficult, and basing a simulation framework
on server technologies represents a significant software development
challenge.
Specifically, the bottlenecks that preclude deeper integration of ESMs within
server infrastructures include the following:
Bridging the gap between ESM formulations of the physical cores and web technologies such as Hypertext
Markup Language HTML; and JavaScript , which are not scientifically oriented languages
and are thus not inherently used by Earth scientists. Because ESMs are not natively integrated into
web technologies, it renders the link between server infrastructures and simulation engines
difficult.
The significant turnaround between generation and serving of simulations. This lag is due to the fact that
these two processes are inherently different in the way they are designed
and, moreover, are usually considered to be completely separate phases of
what should, essentially, be the same process.
The distributed nature of web simulations. Every step of an ESM run can be considered a separate, logical
component. For example, post-processing of a simulation may be done on a different machine than the one that
initially generated it.
The lack of existing integrated frameworks wherein simulations, pre- and post-processing, and the serving
of the data and/or simulation results all occur within the same architecture.
Here, we present a new approach applied to the ISSM framework, a land ice
model of significant size and complexity, to serve simulations relating to
the evolution of polar ice sheets. By serving, we imply providing a way
to run simulations interactively within a web environment, without any of the
results ever being cached. Our solution is based on a new JavaScript API for
the ISSM framework itself, allowing it to be fully integrated within an HTML
web page (described in Sect. 2) and to run locally to the web page. For models
of larger size, we also show how we leverage the existing ISSM Python API to
run a web server (based on Apache and the FastCGI module) that can run faster
parallel computations, and to which the web page client can upload model
inputs and download computations along with pre- and post-processing results
directly (Sect. 3). This new approach allows for a quick turnaround between
running simulations and porting such simulations to a web page interface for
access to the wider science community (Sect. 4). We execute this approach
(Sect. 5) within the newly designed Virtual Earth System Laboratory (VESL),
demonstrating how we can provide access to cryosphere-related simulations to
the science community and to the wider public in general, thereby easily
providing access to the wide array of modular physics embedded in ISSM. We
conclude with a discussion of the potential of this new approach to both
facilitate a wider use of ESMs by scientists of varied disciplines and to
shorten the gap between science simulations and public outreach.
ISSM JavaScript API
Most ISMs are written in Fortran, C, or C++ for reasons related to
computational efficiency and to the ease of integration within HPC
environments using parallel libraries, such as message passing interface
(MPI) via OpenMP . However, many
simpler models exist that rely on different APIs, such as the MATLAB code
described in or the Excel-based Greenland and Antarctica
Ice Sheet Model designed for educational purposes
GRANTISM;. These models have in common the desire to
rely on a simple code base and to reduce/optimize the set of physics
captured in the code in order to make it more accessible. Our approach here,
however, is to facilitate accessibility without sacrificing the complexity
and full set of features of ISSM by implementing a brand new API using the
JavaScript language. The goal is to be able to integrate ISSM within
web-based solutions, relying on JavaScript as a language that enables control
of the behavior of an HTML web page. In addition, by making the JavaScript API
similar in all possible aspects to the existing MATLAB and Python ISSM APIs,
model runs and simulations can be transferred easily to the web, furthering
our objective of disseminating ISSM to the larger scientific community and,
possibly, the general public through web interfaces. It is to be noted that
due to the new API being of equivalent complexity (to capture the full range of
physics) to the MATLAB or Python APIs, users that want to use this API should
be fully knowledgeable with using ISSM in MATLAB or Python already. This
means that the new API does not make use of ISSM easier in terms of learning
curve but makes it more flexible in terms of being deployed to the web.
The basis for representing a model in ISSM is a series of classes (mesh,
mask, geometry, settings, toolkits, etc.) that are carried into a global
class. The first task was therefore to translate all ISSM
classes from MATLAB and Python into JavaScript. Figure shows
an example of such a translation for the class (used to
represent a 2-D mesh triangulation comprising a list of vertex coordinates
, of size with corresponding
, coordinates, a list of triangle indices called
(of size ), and a projection code
using an EPSG geodetic parameter dataset). The constructors are very similar,
and there is a one-to-one correspondence between the mesh2d methods in both
APIs. The example of the routine (which collects all the mesh
info onto a binary buffer that will be sent to the ISSM C++ core) shows the
similarity between both codes, with differences in the syntax reduced to a
bare minimum. This equivalence is essential in preserving all of the physics
captured in each class of ISSM and could only be achieved because MATLAB,
Python, and JavaScript are similar in their syntax and grammar.
Line-by-line comparison of the code behind the mesh2d class, within the
MATLAB ISSM API (upper frame) and the JavaScript ISSM API (lower frame). Class methods
that are not relevant to the discussion have been erased for ease of reading.
Makefile for the JavaScript Emscripten compilation of ISSM.
In a standard modeling analysis, scientists will develop their models and run
within the MATLAB (or Python) environment. Usually, outreach of the results
will be done separately, in a different web-based environment, leading to
inefficiencies and potential loss of information/accuracy between the science
analysis and the outreach itself. To remedy this issue, it is very convenient
to provide an efficient way to transfer a model directly from MATLAB to the
JavaScript environment, where it will be loaded easily using a standard
“include” statement. This is implemented through the routine
for each subclass of the class. As shown in
Fig. for the class implementation, the
routine allows users to write the MATLAB model to a
JavaScript file. This allows users to run simulations in MATLAB using ISSM,
and, once the simulations are over, to save the MATLAB-defined model into a
JavaScript equivalent file. This routine, which closely matches the
constructor, is the key to shortening the transition time between the setup
of an ISSM simulation and its transition into a web page environment. The fact
that all of the information of a given class is identical in both APIs
demonstrates the comprehensiveness of the new JavaScript implementation of
ISSM and shows that it achieves its goal of replicating ISSM within a web page
environment.
In a standard model run, MATLAB classes (or Python) are used to setup the
model, but the computations themselves are carried out in C++. This C++ code
is present at several levels: (1) for each pre- and post-processing module
(or, wrapper) that requires significant computational power, such as
interpolation routines that transfer information between gridded dataset and
unstructured finite element modeling (FEM) meshes typical of ISSM; and
(2) for each of the computations pertaining to ice flow itself (the physical
engine in ISSM), which we refer to as the ISSM core. For pre- and
post-processing modules, the computations are assumed local to the
workstation. For the ISSM core itself, parallelization is inherent (using the
MPI libraries), and this core usually runs on a parallel cluster.
When we look at this configuration and try and transfer this paradigm to a
web page environment, we are however faced with two issues: (1) C++ code
cannot be run native to a web page easily; and (2) parallelism is not yet
implemented in browsers and would anyway result in heavy taxation of CPU
resources (on local workstations/laptops/tablets), which is not practical.
We therefore approached this issue in two ways: (1) we translated the entire
C++ code (both modules/wrappers and the ISSM core itself) into JavaScript for
model runs that are small enough to be run locally, and (2) for models that
are too large to run locally, we implemented a way of uploading (using the
JavaScript classes) a model to a web server on the Amazon EC2 cloud, where
computations are carried out and returned to the JavaScript client once
completed. The latter approach is described in the next section. Here, we
further describe the translation of the C++ modules and ISSM core into
JavaScript code. This translation was carried out using the Emscripten
compiler . This compiler enables translation of C++ code
directly into JavaScript, with computational efficiencies that are within an
order of magnitude of the translated C++ code. Listing
shows how Emscripten was integrated within the existing Makefile structure of
ISSM. All the pre- and post-processing wrappers (TriMesh, NodeConnectivity,
ContourToMesh, ElementConnectivity, InterpFromMeshToMesh2d, IssmConfig,
EnumToString, and StringToEnum) as well as the ISSM core itself (issm) are
compiled into JavaScript executables using the C++ files and a set of
Emscripten-related flags (described in the IssmModule_CXXFLAGS variable).
This Makefile is similar to its MATLAB and Python counterparts, with the
exception of the issm core, which is compiled as a JavaScript module instead
of a C++ executable. This Makefile is integrated within Autotools
, enabling for quick activation of the compilation using a
simple “” option during the configuration phase of
the ISSM software.
The JavaScript modules and ISSM core are continuously tested against
regression tests, similar to the MATLAB and Python APIs .
The integration framework for the tests relies on Jenkins, an open-source
automation server , which provides continuous integration and
delivery of validated ISSM code. The ISSM Jenkins web page is available at
https://ross.ics.uci.edu:8080/, where the entire validation suite is in
the process of being transferred to JavaScript. This ensures that continuous
development impacts all of the APIs in ISSM in a similar fashion without
imparting delays to the JavaScript API (due to the fact that it would be used
by a smaller base of ISSM users).
HTTP/Python server
Using the JavaScript API, it is possible to run a full-fledged simulation
using any of the physical modules described in . However,
to our knowledge, Emscripten does not yet allow computations in parallel
within a browser. This limits the range of model sizes and mesh resolution to
a level that compromises large-scale simulations. In these cases, our
approach was to rely on the cloud computing capabilities of ISSM, as
described in , and to host a web server that would deliver
ISSM computations to any client running the ISSM JavaScript API. This server
relies on the Python API of ISSM to carry out computations ranging from tens
to hundreds of thousands of degrees of freedom, allowing continental-scale
simulations. The server is fully elastic and scalable, and relies on the
Amazon EC2 infrastructure , and can spin up compute-optimized
CC4.8x large instances (up to 64 threads of computational power) on demand,
making it a robust solution for serving computations. We refer to for more details on this part of the architecture.
In terms of server configuration itself, our approach was to rely on the
Python API of ISSM to leverage the FastCGI web interface, described in
, on an Apache server. This allows requests coming into the
Apache server from the client-side to be routed directly to a Python script.
The web client, running ISSM embedded inside JavaScript, can therefore upload
a marshalled binary input file (created by the call to the marshall routine
of each model class, as described in Fig. ) to the EC2
instance Apache server, which then routes it to the Python script that
launches the parallel job.
Similarities
between a standard ISSM run from a terminal running MATLAB and connected to a
HPC cluster and a web-based ISSM run from a web page running
JavaScript, connected to a web server running on an Amazon EC2 cloud instance.
In the first case (lower frames), a MATLAB instance running on a local
workstation marshalls a binary file, which is then uploaded (using an SSH call) to a master node on a cluster. The binary file
is then queued into the system (using a qsub command from a scheduler, for
example). The parallel runs are then carried out using the ISSM executable
and an MPI-compatible environment. In the second case, a browser client makes
an XMLHttpRequest and uploads a Binary Large Object (the exact same binary
file MATLAB would upload), which is received by an HTTP server (e.g., Apache)
running on an Amazon EC2 compute-optimized instance. The HTTP server then
uses a FastCGI module to interface to a Python wrapper, which automatically
triggers a system call to the MPI environment running the ISSM executable. In
both cases, an output binary file is created by the ISSM executable, which is
then shipped back to the MATLAB instance or the client's web browser.
MATLAB code
for a typical simulation of the VESL.
Figure describes this process schematically and
compares it to what happens in more classic simulations relying on MATLAB and
an HPC infrastructure, such as a cluster. The fundamental differences between
the traditional simulation paradigm and our new solution are (1) the client
architecture, which runs either MATLAB or an HTML web page with JavaScript;
(2) the upload/download of binary input files, which is done either through
an SSH copy call or an XMLHttpRequest, respective to the aforementioned
client architectures; and (3) the launching of a given computation, which is
handled via a queuing system on the head node or a FastCGI-relayed Python
call on an EC2 instance. In
terms of parallel computations, ISSM executables are run using an MPI call in
both cases. The strong similarity between both architectures was purposefully
designed so as to limit the amount of repeats in the code, and to ensure the
robustness of the computations themselves, which are transparent to the API
they rely upon.
All-in-one design/simulations
Listing shows a typical model setup for a simulation in ISSM
relying on the MATLAB API. The steps include loading a model (or generating
one using a mesher), modifying a certain input parameter, setting up a
cluster class (pointing to the parallel cluster), and calling the solve
routine. Once the results are carried out/downloaded, plotmodel is run to
visualize them.
An additional step can be carried out once a given MATLAB ISSM model has been
built, wherein the model is saved into a JavaScript file (md.js) in some
web page directory. This model can then be used (as shown in
Listing ) to run the exact same setup and simulation as is
done with MATLAB, but on the client's machine. The HTML code for this
simulation is typical of a web page, and includes (1) standard HTML markup
(i.e., W3C-compliant HTML, head, and body objects); (2) statements for
the ISSM binaries created by Emscripten, the model itself (md.js), and a sort
of front-end controller (engine.js, which controls the display of and
interaction with the simulation on the web page); and (3) HTML elements such
as a canvas where the results will be plotted (similar to the figure
statement in MATLAB), a second canvas for the color bar, and a button element
to launch the simulation. The listing for engine.js shows how similar the
MATLAB and JavaScript setup are (Listing 3).
Upon loading, if the RUN button is clicked,
the value of a slider (the model input of interest) is retrieved and then
SolveGlacier called. The SolveGlacier() routine modifies the input parameter,
sets up the cluster class (pointing to the EC2 server), and calls the solve
routine. After computations are carried out and downloaded, a callback
function PlotGlacier is triggered, which plots the model results onto the
aforementioned HTML canvas elements. If users do not want to rely on this
particular routine for plotting, they can instead provide their own callback
routine to plot using their own rendering engine.
Equivalent
(see Listing ) HTML/JavaScript code for a typical simulation
within the VESL prototype web page.
Figure shows an example of such a web page hosting a
simulation for the Columbia Glacier in Alaska. In this particular example, the
model input that is modified is the surface mass balance (SMB). This
parameter measures the amount of precipitation (in snow or water) at the
surface of the ice, minus runoff of water from melting and evaporation. This
parameter is essential in controlling the input of mass to the glacier. Once
this input is modified, we can measure its impact on the response of the
glacier (the ice flow) through time. This response is a complex interplay
between mass transport processes and the stress equilibrium of the ice. The
result is a new flow regime (speed), which ISSM can compute and which can be
visualized through a time evolution of the speed at the surface of the ice.
Here, the web page is part of VESL, where the JavaScript API of ISSM was
leveraged along with the HTTP/Python server architecture described previously
to showcase the capabilities of ISSM to serve computations on the fly and to
visualize them instantly . The simulations
within VESL are all simulations that were carried out using ISSM for
scientific publications. By adding a savemodel.js step at the end of the
MATLAB simulation workflow, we were able to transfer the model used for the
simulations from the MATLAB environment onto the web page. Once that was done,
we replicated a workflow similar to the MATLAB workflow in the engine.js
code. With this approach, it is possible to deploy a simulation like the one
described above on a web platform with significantly shortened turnaround and
using the exact same capabilities as the initial MATLAB solution itself. This
breakthrough is only possible because of the duplication of the entire
architecture, again, by making JavaScript code that is logically equivalent
to our MATLAB or Python constructs and by mapping the whole workflow
described in Fig. from MATLAB/HPC infrastructures to
HTML/JavaScript/EC2. Our methodology paves the way to leveraging web
technologies and cloud computing to host large-scale simulations of modeling
engines such as ISSM, all without loss of the physical representation of
processes nor scalability.
Columbia
Glacier ISSM simulation on the Virtual Earth System Laboratory
(https://vesl.jpl.nasa.gov). This particular
simulation allows for the introduction of user-driven SMB anomalies (using a
slider ranging from -5 to +5 m a-1) on the transient ice flow of
Columbia Glacier. The computations (upon clicking of the RUN button) are
carried out on the ISSM computational server (where the model inputs are
uploaded and from which the results are downloaded locally to the client's
web browser). The transient results are displayed as a movie, which can be
controlled via user interface (UI) controls. The interactive rendering of the
velocity and thickness fields is done in 3-D (or 2-D, upon clicking of a
toggle button) using the ISSM WebGL rendering engine. The results are
overlaid on a semitransparent topographical rendering of the Shuttle Radar
Topography Mission (SRTM) digital elevation model (DEM), and a
background geotiff image from A. Gardner, M. Fahnestock, and E. Larour
(personal communication, 2016). Model information can
be displayed by clicking the info button, allowing for extensive information
on the model setup and the datasets used to constrain the simulation.
Examples
Figures and show examples of
simulations that rely on the ISSM JavaScript API and that are hosted on the
VESL website . VESL's purpose is two-fold: to
showcase simulations that demonstrate ISSM capabilities, and to demonstrate
the capabilities of our new web-based modeling solution to the wider
scientific community and general public. Several simulations are hosted,
leveraging the large set of capabilities in ISSM.
Greenland ISSM simulation on the VESL (https://vesl.jpl.nasa.gov). This
particular simulation allows for the introduction of user-driven friction
anomalies (using a slider ranging from 5 to 100 %) on the steady-state
stress-balance velocities for the entire Greenland Ice Sheet. The
computations (upon clicking of the RUN button) are carried out on the ISSM
computational server (where the model inputs are uploaded and from which the
results are downloaded locally to the client's web browser). The steady-state
velocities are displayed for each value of the friction coefficient that the
user chooses. The interactive rendering of the velocity field is done in 3-D
using the ISSM WebGL rendering engine. The results are overlaid on a
semitransparent topographical rendering of ETOPO5 data (see for credits) and a background geotiff image from the Blue
Marble: Land Surface, Shallow Water and Shaded Topography project (see
for credits).
The first simulations pertain to the simulation of glacier flow, mainly from
work on the Haig Glacier and Columbia Glacier (A. Gardner,
M. Fahnestock, and E. Larour, personal communication, 2016). Figure shows the Columbia Glacier web page,
where SMB variations can be specified, with ISSM then computing the resulting
impact on the glacier evolution over a period of 10 years. This simulation
includes all the physical processes that control the evolution of a glacier
and is fully representative of the complex physics required in the analysis.
The second set of simulations pertain to ice sheet modeling in Antarctica and
Greenland. Figure shows the web page corresponding to the
friction SeaRISE experiment over the entire
Greenland ice sheet. In this simulation, the user can decrease the friction
at the ice/bedrock interface under the ice sheet and compute the resulting
changes in steady-state velocity at the surface. The model is fairly high
resolution (12 000 elements), which allows for computations that are
physically representative.
The third set of simulations pertains to sea-level rise (SLR) modeling,
relying on the ISSM-SESAW module to compute
gravitationally consistent sea-level and geodetic signatures caused by
cryosphere and climate-driven mass change. Presently, two sets of simulations
demonstrate (1) eustatic SLR and its impact on coastline migration in the
USA; and (2) SLR from eustatic, gravity, and elastic deformation on a global
scale, wherein users can turn off specific sets of SLR physics to understand
the impact of gravitation on redistribution of SLR around the world and the
impact of local elastic deformation of the Earth lithosphere.
Finally, a fourth set of simulations pertains to solid Earth deformation,
using the ISSM-GIA module that captures glacial
isostatic adjustment (GIA) from ice sheet loading. It should be noted that
this section is a work in progress.
One potential future section may feature recent work by the ISSM team
involving the application of ISSM to other planets (namely, Mars' ice caps).
Given the relatively quick turnaround between ISSM simulations and their
porting to the web using the ISSM JavaScript API, our hope is that VESL will
become a forum for cryosphere scientists to discuss ice-sheet-related
science. In addition, by enabling simplified interfaces on existing
simulations that resulted in scientific publications, we believe the general
public might gain increased interest in this type of approach to better
understand the complexity of science for the Earth system as a whole.
Conclusions
We developed a fully functional JavaScript API for the ISSM, which allows cryosphere scientists to carry out ice flow simulations
within a web environment. This API gives access to the entire spectrum of
physical processes captured by ISSM without compromising its complexity and
richness. For simulations requiring parallel computing, the JavaScript API
can be leveraged against a computational server hosted on a cloud instance
(such as Amazon EC2) to deliver high-performance, large-scale, and
high-fidelity simulations back to the web client. This new set of
capabilities enables hosting of high-end simulations on the NASA/JPL VESL,
effectively solving a fundamental challenge of ESMs: delivering accessible,
high-performance simulations in a timely manner. We believe that our approach paves the way for the
efficient deployment of feature-rich ESMs, a quick turnaround between
scientific work and corresponding publications, and outreach not only to the
science community but also to the general public.
The ISSM code and its JavaScript components are available at
http://issm.jpl.nasa.gov. The instructions for the compilation of ISSM
in JS mode are presented in the Supplement attached to this
paper.
The Supplement related to this article is available online at https://doi.org/10.5194/gmd-10-4393-2017-supplement.
The authors declare that they have no conflict of
interest.
Acknowledgements
This work was performed at the Jet Propulsion Laboratory (JPL), California
Institute of Technology, and the Department of Earth System Science at the
University of California, Irvine (UCI) under a contract with the National
Aeronautics and Space Administration (NASA) and funded by the Cryospheric
Sciences Program. Resources supporting the numerical simulations were
provided by the NASA High-End Computing (HEC) Program through the NASA
Advanced Supercomputing (NAS) Division at Ames Research Center, and by
Cryospheric Program Management for the Amazon EC2 instances hosting the
Virtual Earth System Laboratory. We would like to thank Surendra Adhikari and Alex Gardner from JPL
and Mark Fahnestock from the University of Alaska, Fairbanks, for the datasets
used in the Haig and Columbia Glacier model setups of the Virtual Earth System
Laboratory. We would also like to thank Daisy F. Sang for the supervision of
students from Cal Poly Pomona who participated in this project over the past
5 years. Edited by: D. Goldberg
Reviewed by: two anonymous referees
References
Adhikari, S. and Marshall, S. J.: Improvements to shear-deformational models
of glacier dynamics through a longitudinal stress factor, J. Glaciol., 57,
1003–1016, 2011.Adhikari, S., Ivins, E. R., and Larour, E.: ISSM-SESAW v1.0: mesh-based
computation of gravitationally consistent sea-level and geodetic signatures
caused by cryosphere and climate driven mass change, Geosci. Model Dev., 9,
1087–1109, 10.5194/gmd-9-1087-2016, 2016.Amazon Web Services, Inc.: Amazon Elastic Compute Cloud (Amazon EC2),
Amazon Inc., available at: http://aws.amazon.com/ec2/#pricing, 2008.Bindschadler, R., Nowicki, S., Abe-Ouchi, A., Aschwanden, A., Choi, H.,
Fastook, J., Granzow, G., Greve, R., Gutowski, G., Herzfeld, U., Jackson, C.,
Johnson, J., Khroulev, C., Levermann, A., Lipscomb, W., Martin, M.,
Morlighem, M., Parizek, B., Pollard, D., Price, S., Ren, D., Saito,
F.and Sato, T., Seddik, H., Seroussi, H., Takahashi, K., Walker, R., and
Wang, W.: Ice-Sheet Model Sensitivities to Environmental Forcing and Their
Use in Projecting Future Sea-Level (The SeaRISE Project), J. Glaciol., 59,
195–224, 10.3189/2013JoG12J125, 2013.ECMA International: ECMAScript 2016 Language Specification, available at:
http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf,
2016.Eyring, V., Bony, S., Meehl, G. A., Senior, C. A., Stevens, B., Stouffer, R.
J., and Taylor, K. E.: Overview of the Coupled Model Intercomparison Project
Phase 6 (CMIP6) experimental design and organization, Geosci. Model Dev., 9,
1937–1958, 10.5194/gmd-9-1937-2016, 2016.
Gropp, W., Lusk, E., Doss, N., and Skjellum, A.: A high-performance, portable
implementation of the MPI message passing interface standard, Parallel
Comput., 22, 789–828, 1996.Gropp, W. D. and Lusk, E.: User's Guide for mpich, a Portable
Implementation of MPI, Mathematics and Computer Science Division, Argonne
National Laboratory, aNL-96/6, 1996.Jenkins: Jenkins, open source automation server,
https://jenkins.io, 2016.Larour, E. and Schlegel, N.: On ISSM and leveraging the Cloud towards faster
quantification of the uncertainty in ice-sheet mass balance projections,
Comput. Geosci., 96, 193–201, 10.1016/j.cageo.2016.08.007, 2017.Larour, E., Seroussi, H., Morlighem, M., and Rignot, E.: Continental scale,
high order, high spatial resolution, ice sheet modeling using the Ice Sheet
System Model (ISSM), J. Geophys. Res., 117, 1–20,
10.1029/2011JF002140, 2012.
MacAyeal, D.: Binge/Purge oscillations of the Laurentide ice-sheet as a
cause of the North-Atlantic's Heinrich events, Paleoceanography, 8,
775–784, 1993.
Open Market: Fastcgi: A high-performance web server interface, Technical white
paper, 1996.Molod, A., Takacs, L., Suarez, M., and Bacmeister, J.: Development of the
GEOS-5 atmospheric general circulation model: evolution from MERRA to MERRA2,
Geosci. Model Dev., 8, 1339–1356, 10.5194/gmd-8-1339-2015, 2015.
NASA Goddard Space Flight Center, Reto Stöckli: NASA Goddard Space
Flight Center Image by Reto Stöckli (land surface, shallow water,
clouds), Enhancements by Robert Simmon (ocean color, compositing, 3-D globes,
animation), Data and technical support: MODIS Land Group; MODIS Science Data
Support Team; MODIS Atmosphere Group; MODIS Ocean Group Additional data: USGS
EROS Data Center (topography); USGS Terrestrial Remote Sensing Flagstaff
Field Center (Antarctica); Defense Meteorological Satellite Program (city
lights), 2002.
National Geophysical Data Center: Data Announcement 88-MGG-02, Digital
relief of the Surface of the Earth, NOAA, National Geophysical Data Center,
Boulder, Colorado, 1988.Nowicki, S. M. J., Payne, A., Larour, E., Seroussi, H., Goelzer, H.,
Lipscomb, W., Gregory, J., Abe-Ouchi, A., and Shepherd, A.: Ice Sheet Model
Intercomparison Project (ISMIP6) contribution to CMIP6, Geosci. Model Dev.,
9, 4521–4545, 10.5194/gmd-9-4521-2016, 2016.OpenMP Architecture Review Board: OpenMP Application Program Interface
Version 4.5, available at:
http://www.openmp.org/mp-documents/openmp-4.5.pdf, 2015.
Pattyn, F.: GRANTISM: An ExcelTM model for Greenland and Antarctica ice-sheet
response to climate changes, Comput. Geosci., 32, 316–325, 2005.Taylor, K., Stouffer, R., and Meehl, G.: An Overview of CMIP5 and the
experiment design, B. Am. Math. Soc., 93, 485–498,
10.1175/BAMS-D-11-00094.1, 2012.
Taylor, K. E., Stouffer, R. J., and Meehl, G. A.: A summary of the CMIP5 experiment design,
PCDMI Rep 33, 2009.
Vaughan, G. V., Elliston, B., Tromey, T., and Taylor, I. L.: GNU Autoconf,
Automake, and Libtool, Sams Publishing, 1st Edn., 432 pp.,
ISBN: 978-1578701902, 2000.VESL: Virtual
Earth System Laboratory Website, http://vesl.jpl.nasa.gov, 2017.World Wide Web Consortium: HTML 4.0 Specification – W3C Recommendation –
Conformance: requirements and recommendations, available at:
https://www.w3.org/TR/REC-html40-971218/conform.html, 1997.Zakai, A.: Emscripten: An LLVM-to-JavaScript Compiler, in: Proceedings of the
ACM International Conference Companion on Object Oriented Programming Systems
Languages and Applications Companion, OOPSLA'11, ACM, New York, NY, USA,
301–312, 10.1145/2048147.2048224, 2011.