A JavaScript API for the Ice Sheet System Model ( ISSM ) 4 . 11 : towards an online interactive model for the Cryosphere Community

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 5 specialists, and that 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 10 ISSM on the client-side of a webpage, 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 15 via a new Virtual Earth System Laboratory (VESL) Web site.


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; Taylor et al., 2009Taylor et al., , 2012) ) and its new iteration (CMIP-6; Eyring et al., 2016) 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., Molod et al., 2015), one of the atmosphere and ocean general circulation models (AOGCMs) that participated in CMIP-5, is made of 600 000 lines of Fortran code, compris-Published by Copernicus Publications on behalf of the European Geosciences Union.
ing 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 postprocessing 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 preprocessing 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; Larour et al., 2012), 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; Nowicki et al., 2016) 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 serv-ing 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: 1. Bridging the gap between ESM formulations of the physical cores and web technologies such as Hypertext Markup Language (HTML; World Wide Web Consortium, 1997) and JavaScript (ECMA International, 2016), 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.
2. 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.
3. 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.
4. 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 postprocessing 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 (Gropp et al., 1996;Gropp and Lusk, 1996;OpenMP Architecture Review Board, 2015).However, many simpler models exist that rely on different APIs, such as the MATLAB code described in MacAyeal (1993) or the Excel-based Greenland and Antarctica Ice Sheet Model designed for educational purposes (GRANTISM; Pattyn, 2005).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 MAT-LAB 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 model class.The first task was therefore to translate all ISSM classes from MATLAB and Python into JavaScript.Figure 1 shows an example of such a translation for the mesh2d class (used to represent a 2-D mesh triangulation comprising a list of vertex coordinates x, y of size numberofvertices with corresponding lat,long coordinates, a list of triangle indices called elements (of size numberofelements), 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 marshall 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.
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 savemodel routine for each subclass of the model class.As shown in Fig. 1 for the mesh2d class implementation, the savemodel 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.
Figure 1.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.
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 (Zakai, 2011).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 1 shows how Emscripten was integrated within the existing Makefile structure of ISSM.All the pre-and postprocessing wrappers (TriMesh, NodeConnectivity, Contour-ToMesh, 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 (Vaughan et al., 2000), enabling for quick activation of the compilation using a simple "-with-javascript" 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 (Larour et al., 2012).The integration framework for the tests relies on Jenkins, an open-source automation server (Jenkins, 2016), 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 Larour et al. (2012).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 Larour and Schlegel (2017), 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 (Amazon Web Services, Inc., 2008), 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.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.
We refer to Larour and Schlegel (2017) 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 Open Market (1996), 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. 1) to the EC2 instance Apache server, which then routes it to the Python script that launches the parallel job.
Figure 2 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 in-put 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 2 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 MAT-LAB 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 3) 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.jsshows 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.
Figure 3 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, Listing 2. MATLAB code for a typical simulation of the VESL.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 (VESL, 2017).The simulations within VESL are all simulations that were carried out using ISSM for scientific publications.By adding a savemodel.jsstep at the end of the MATLAB simulation workflow, we were able to transfer the model used for the simulations from the MAT-LAB environment onto the web page.Once that was done, we replicated a workflow similar to the MATLAB workflow in the engine.jscode.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. 2 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.

Examples
Figures 3 and 4 show examples of simulations that rely on the ISSM JavaScript API and that are hosted on the VESL website (VESL, 2017).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.
The first simulations pertain to the simulation of glacier flow, mainly from work on the Haig Glacier (Adhikari andMarshall, 2011) andColumbia Glacier (A. Gardner, M. Fahnestock, andE. Larour, personal communication, 2016).Figure 3 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 4 shows the web page corresponding to the friction SeaRISE (Bindschadler et al., 2013) 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 re-E.Larour et al.: A JavaScript API for ISSM Listing 3. Equivalent (see Listing 2) HTML/JavaScript code for a typical simulation within the VESL prototype web page.
sulting 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 (Adhikari et al., 2016) 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 (Adhikari and Marshall, 2011) 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.
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 highperformance, 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.
s c r i p t s = $ {ISSM_DIR } / s r c / w r a p p e r s / TriMesh / TriMesh .j s \ $ {ISSM_DIR } / s r c / w r a p p e r s / N o d e C o n n e c t i v i t y / N o d e C o n n e c t i v i t y .j s \ $ {ISSM_DIR } / s r c / w r a p p e r s / ContourToMesh / ContourToMesh .j s \ $ {ISSM_DIR } / s r c / w r a p p e r s / E l e m e n t C o n n e c t i v i t y / E l e m e n t C o n n e c t i v i t y .j s \ $ {ISSM_DIR } / s r c / w r a p p e r s / InterpFromMeshToMesh2d / InterpFromMeshToMesh2d .j s \ $ {ISSM_DIR } / s r c / w r a p p e r s / I s s m C o n f i g / I s s m C o n f i g .j s \ $ {ISSM_DIR } / s r c / w r a p p e r s / EnumToString / EnumToString .j s \ $ {ISSM_DIR } / s r c / w r a p p e r s / StringToEnum / StringToEnum .j s \ $ {ISSM_DIR } / s r c / w r a p p e r s / Issm / issm .j s bin_SCRIPTS = issm− p r e b i n .j s bin_PROGRAMS = IssmModule issm− p r e b i n .j s : $ { j s _ s c r i p t s } c a t $ { j s _ s c r i p t s } > issm− p r e b i n .j s IssmModule_SOURCES = . ./ TriMesh / TriMesh .cpp \ . ./ N o d e C o n n e c t i v i t y / N o d e C o n n e c t i v i t y .cpp \ . ./ ContourToMesh / ContourToMesh .cpp \ . ./ E l e m e n t C o n n e c t i v i t y / E l e m e n t C o n n e c t i v i t y .cpp \ . ./ InterpFromMeshToMesh2d / InterpFromMeshToMesh2d .cpp \ . ./ I s s m C o n f i g / I s s m C o n f i g .cpp \ . ./ EnumToString / EnumToString .cpp \ . ./ StringToEnum / StringToEnum .cpp \ . ./ Issm / i ssm .cpp IssmModule_CXXFLAGS= − f PIC −D_DO_NOT_LOAD_GLOBALS_ −− memory− i n i t − f i l e 0 \ $ (AM_CXXFLAGS) $ (CXXFLAGS) $ (CXXOPTFLAGS) $ ( COPTFLAGS ) \ − s EXPORTED_FUNCTIONS= " [ ' _TriMeshModule ' , ' _ N o d eConn e c t i vity Modu l e ' , \ ' _ContourToMeshModule ' , ' _ E l e m e n t C o n n e c t i v i t y M o d u l e ' , \ ' _InterpFromMeshToMesh2dModule ' , ' _ IssmConf igModule ' , ' _EnumToStringModule ' \ , ' _StringToEnumModule ' , ' _IssmModule ' ] " − s DISABLE_EXCEPTION_CATCHING=0 \ − s ALLOW_MEMORY_GROWTH=1 − s INVOKE_RUN=0 IssmModule_LDADD = $ { d e p s } $ ( TRIANGLELIB ) $ ( GSLLIB ) Listing 1. Makefile for the JavaScript Emscripten compilation of ISSM.

Figure 2 .
Figure2.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.

Figure 3 .
Figure 3. 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.

Figure 4 .
Figure 4. 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 (seeNational Geophysical Data Center (1988)  for credits) and a background geotiff image from the Blue Marble: Land Surface, Shallow Water and Shaded Topography project (see Goddard Space Flight Center, Reto Stöckli (2002) for credits).