68 Computing in Science & Engineering 1521-9615/14/$31.00 © 2014 IEEE Copublished by the IEEE CS and the AIP May/June 2014

Cloud CoMputing

Solving Solid and Fluid Mechanics problems in the Cloud with moSAiC

Jernej Južna and peter Cešarek | University of Ljubljana

dana petcu | West University of Timisoara

Vlado Stankovski | University of Ljubljana

An application for analysis of structures under static loading is ported to the cloud using the mOSAIC portable platform-as-a-service. The new cloud application benefits from Web availability, elasticity, and fault tolerance, while being independent from the infrastructure-as-a-service providers. This achievement paves the way for porting a range of engineering applications to multiple clouds.

Today, in many university and research departments, highly specialized engineer-ing applications are being developed—for example, applications for experimentation

with solid and fluid dynamics problems. The de-velopers as well as the potential users would find it beneficial if there existed a way to make these applications available over the Web.1 Converting such applications into Web services, however, isn’t a straightforward process, because they’re usu-ally resource-intensive and originally developed for desktop computers or local clusters requiring spe-cial environmental settings and libraries to execute.

With the development of cloud computing technologies, access to infrastructures-as-a-service (IaaS) used to acquire the necessary resources (pro-cessors, storage) for engineering and scientific ap-plications and platforms-as-a-service (PaaS) used for new application development is becoming more feasible than ever.2 Such services promise to in-crease the availability of engineering software over the Web, along with improvements of its elasticity and fault tolerance properties. There are, however, still various problems preventing the take-up of IaaS and PaaS offers in the engineering disciplines. At the moment, porting engineering applications to the cloud is a demanding process usually reserved for

cloud computing experts, while those not as familiar with cloud computing are left out of the equation.

The aim of our present study was therefore to investigate how to quickly provide existing engi-neering applications over the Web and outsource the necessary heavy computations. (For other de-velopments in this area, see the related sidebar.) We conducted experiments by porting an exist-ing, recently developed application for analysis of structures under static loading to the cloud and analyzed the needed efforts, which must be as min-imal as possible, so that engineers can follow the solution and provide their own applications over the Web. We further investigated the possibilities of achieving speedup of such applications by tak-ing advantage of the cloud environment.

nodeK—A desktop Application for Structure AnalysisFor experimentation we used NoDeK, a typical desktop application for finite-element analysis of structures under static loading, which employs ne-wly developed finite elements for a geometrically exact spatial beam with constant strains.3 The em-ployed finite elements are unique in the sense that they’re robust, computationally efficient, and ac-curate in providing results without any limitations

CISE-16-03-stan.indd 68 30/05/14 10:03 AM

www.computer.org/cise 69

on the magnitude of rotation, displacements, and strains. Several user groups might benefit from us-ing NoDeK over the Web, including civil engineers, students, and domain specialists experimenting

with structural, multibody dynamics, aeronautical, spatial, and biomechanics problems.

Figure 1 presents an overview of the NoDeK application. First, a structural model is built from

Related Cloud Computing Solutions

A first step in our research process was to gain an understanding of

the latest developments in infrastructures-as-a-service (IaaS) and

platforms-as-a-service (PaaS) and what these approaches offer to en-

able porting existing engineering applications to the cloud. Our initial

analysis revealed that IaaS is more suitable, because it allows for full

control over the entire software stack, including the choice of a suit-

able operating system, libraries, environmental settings, and other ap-

plication dependencies. Hence, every engineering application can be

provisioned on an IaaS as long as it doesn’t need special hardware for

its execution. Existing studies investigating the possibility of running

applications on top of IaaS focused on using the cloud as a grid-like

infrastructure.1,2 In many engineering applications, however, it’s nec-

essary to facilitate communication among the application parts—for

example, data exchange—in a dynamically changing environment—

for example, increasing and decreasing user numbers, and significant

changes in workloads or faults in executing virtual machines (VMs).

Existing PaaS solutions promise to improve the communication

problems among the application parts, however, they come at a cost as

the developer doesn’t have the freedom to select the rest of the soft-

ware stack. Because most PaaS promote their own APIs, users can’t

easily include specific libraries or select the runtime environment.

Some recently developed cloud solutions are positioned with

capabilities in between what IaaS and PaaS offer. They provide APIs,

which support inter-VM communication (for example, data exchange),

while using IaaS clouds. A person can install all the needed software,

libraries, and settings on multiple VMs and not have to worry about

common resources needed by the application (for example, storage)

and communication among its parts (for example, messaging).

One such approach is Aneka (see www.manjrasoft.com),3 a

commercial platform for .NET-based applications that promotes

three programming models: tasks, threads, and MapReduce. The

developer specifies so-called work units. Aneka will then distribute

the work units among managed computing nodes (containers),

which can execute on various infrastructures ranging from local

computers, grids, private or public clouds, or wherever the necessary

software stack can be installed on the underlying operating system.

Another similar system is Stackato (www.activestate.com/

stackato), a commercial cloud platform that exposes its API in var-

ious popular Web languages such as Java, PHP, Ruby, and Node.

js. An application must be packed inside a so-called droplet, along

with all needed dependencies. The droplet can then be executed

by a droplet execution engine, which runs on top of VMs acquired

from an IaaS cloud provider. Stackato includes support for several

programming models in the form of supplied software components.

Another solution is Techila high-performance computing mid-

dleware,4 which creates a task-oriented platform that runs locally,

but can outsource the processing and memory intensive parts to

an IaaS cloud. Several tool suites frequently used in the engineer-

ing disciplines are supported, including Mathwork’s Matlab and R.

The mOSAIC API and software platform5 is one of the latest

developments in PaaS, offering a compromise between the PaaS

and IaaS programming models. It distinguishes itself from the

other investigated PaaS by being open source and freely available

(https://bitbucket.org/mosaic). We chose mOSAIC as an experi-

mentation platform due to its main advantage over other PaaS of

having full independence from the underlying IaaS, while allowing

the freedom to setup the application’s entire software stack. The

mOSAIC software platform consists of APIs implemented in Java,

Python, Erlang, and Node.js, and a toolset suited for use in an

integrated development environment to support the life cycle of a

cloud application starting from conception: design; development;

brokering; and negotiation of resources, deployment, monitoring

and maintenance.6 All these properties make mOSAIC an attrac-

tive platform for cloud application development.

In contrast to the investigated PaaS providers, mOSAIC is not a

hosting PaaS solution. Instead, mOSAIC is a set of software services

that are automatically deployed on the target private or public IaaS pro-

viders along with the cloud application. These software services make it

possible to maintain the cloud application dynamically at runtime.

References1. A. Iosup et al., “Performance Analysis of Cloud Computing Ser-

vices for Many-Tasks Scientific Computing,” IEEE Trans. Parallel and Distributed Systems, vol. 22, no. 6, 2011, pp. 931–945.

2. G. Juve et al., “Comparing FutureGrid, Amazon EC2, and

Open Science Grid for Scientific Workflows,” Computing in Science & Eng., vol. 15, no. 4, 2013, pp. 20–29.

3. C. Vecchiola et al., “Deadline-Driven Provisioning of Resources

for Scientific Applications in Hybrid Clouds with Aneka,” Future Generation Computer Systems, vol. 28, no. 1, 2012, pp. 58–65.

4. K. Dejaeger et al., “Beyond the Hype: Cloud Computing in

Analytics,” 2012; doi:10.2139/ssrn.2165720.

5. D. Petcu et al., “Portable Cloud Applications—From Theory to

Practice,” Future Generation Computer Systems, vol. 29, no. 6,

2013, pp. 1417–1430.

6. D. Petcu et al., “Experiences in Building a mOSAIC of Clouds,” J. Cloud Computing: Advances, Systems, and Applications, vol. 2,

no. 12, 2013; www.journalofcloudcomputing.com/content/2/1/12.

CISE-16-03-stan.indd 69 30/05/14 10:03 AM

Cloud Computing

70 May/June 2014

user data. Then, the prescribed loading for which the equilibrium of the structure is sought is ap-plied increasingly in several steps. In every step, the equilibrium equations of the structure are formed and solved in an iterative manner. For each iterati-on, specific finite-element properties (for example, stiffness matrix and residual vector) are evaluated and gathered to form equilibrium equations for the whole structure. The analysis is terminated after the final load is applied.

Cloud-Enabling the nodeK ApplicationWe next explored the possibilities for porting NoDeK to the cloud. For this purpose, we pro-duced two designs: the basic design, in which the

application is elastic as a whole, thus addressing the problem of Web availability (that is, varying user numbers over the Web); and advanced design, in which we investigate the possibility of speeding up execution by exploiting the algorithm’s parallel step (that is, evaluation of stiffness matrices and resid-ual vectors of finite elements, as Figure 1 depicts). Then, we generalize the approach by implementing designs for various solid and fluid mechanics cloud applications.

Basic design and implementationTo port the existing NoDeK application to the cloud, it was first necessary to gain an under-standing of the philosophy of the selected Open Source API and Platform for Multiple Clouds (mOSAIC). The mOSAIC application promotes the design of cloud applications based on loosely coupled components, called cloudlets. Cloudlets represent the highest abstraction of the mOSAIC API stack and have important properties, includ-ing elasticity and fault tolerance, which are sup-ported by the software platform’s services. The mOSAIC method provides several components off-the-shelf (COTS), which are an abstraction of the generic resource types that a cloud appli-cation can use, including key-value stores such as Riak (http://basho.com/riak), distributed file systems such as Hadoop Distributed File System (http://hadoop.apache.org), message queuing sys-tems such as RabbitMQ (www.rabbitmq.com), and HTTP servers such as Jetty (www.eclipse.org/jetty). We can therefore use COTS and cloudlets to address engineering application bottlenecks, including their computationally intensive parts, needs for storage, and significant variations in the number of Web users.

Based on the mOSAIC philosophy, we pro-duced and implemented a first version of the cloud application (see Figure 2 on p. 72). All software components communicate among each other by us-ing asynchronous mechanisms supported by servic-es of the mOSAIC platform—for example, we use an instance of RabbitMQ for scalable messaging.

The most important software component of the design is the NoDeK cloudlet in which the existing NoDeK application is wrapped. First, we slightly modified the existing application so that it can be invoked directly from Java as a function. To set up such a function we needed to arrange a non-typical software stack on a virtual machine (VM), running a tiny Linux-based operating system cal-led mOS provided along with mOSAIC. On top

Build structural model

Evaluate stiffnessmatrices and residual

vectors of finite elements

Assemble stiffness matrixand residual vector

of structure

Solve system of linearequations

Convergence?NO

YES

Upd

ate

stru

ctur

al m

odel

START

END

Final load?

YES

Incr

ease

load

NO

Figure 1. Overview of the NoDeK application for structure analysis under static and dynamic loading. The blue actions represent application parts that can only execute as sequential procedures and the green action represents the part of the application allowing for parallel execution.

CISE-16-03-stan.indd 70 30/05/14 10:03 AM

www.computer.org/cise 71

of mOS, we set up specific libraries needed to call NoDeK from Java as a function.

Following this, we wrote a wrapper code in-side the NoDeK cloudlet to handle all commu-nication between the resulting function and the cloud environment, basically for receiving and sending input/output data by using a key-value store and control via a message queue. The rest of the design deals with communication between the user and the NoDeK cloudlet. The first de-sign goal was to allow interaction with the cloud application through a Web browser only, and the second goal was to provide for an efficient system, which can serve many users simultaneously in an elastic way.

We achieved the first goal by implementing tailored dynamic webpages, where users can sub-mit their data (input page), monitor the status of the ongoing calculation (process page), or down-load the final results (result page). The webpages are based on Java servlet technology backed up by a Jetty HTTP server.

We achieved the second goal by including message queues between the HTTP server and the NoDeK cloudlet. This design let us start multiple instances of NoDeK cloudlets to serve multiple users at the same time. In case of really heavy traffic, the design allows another level of scalability because an HTTP gateway component handles all the traffic between the users and the HTTP server, which enables the creation and running of multiple instances of the HTTP server simultaneously.

We implemented the designs by using Eclipse, for which mOSAIC plug-ins are provided, and using Apache Maven (http://maven.apache.org) templates.

Advanced designFollowing our initial success, we explored ways to obtain application speedup by exploiting par-allelism inherent in its code. The first step of the NoDeK algorithm can be executed in parallel without significant additional development effort, as the finite elements are independent among each other (see Figure 1).

Figure 3 (on p. 73) presents an advanced design of a NoDeK cloud application. The first part of the design implements communication among users and the NoDeK application in the same manner as with the basic design, however, the NoDeK cloud-let is now split into two cloudlets M1 and M2. The M1 and M2 cloudlets implement the sequen-tial and parallel actions of the NoDeK algorithm,

respectively. Similarly to the design of the NoDeK cloudlet, the M1 and M2 cloudlets call functions of the existing NoDeK application and implement a wrapper code that takes care of communication among the application’s software components. Ad-ditional message queues and key-value stores are needed to facilitate communication between the M1 and M2 cloudlets, following the communica-tion principles of the basic design.

Let’s focus on the function of the M2 cloud-let and its interaction with other components of the architecture. After receiving a message, M2 first fetches input data from the unsolved key-value store system (the received message contains a key), decodes the data, and invokes an appro-priate NoDeK function that evaluates stiffness matrices and residual vectors of finite elements. Then, the evaluation takes place and the results are encoded and published in the solved key-value store system, while a success message containing the corresponding key is posted to the message queue system. At the end, a command to delete the input data is sent to the unsolved key-value store to avoid unnecessary clutter and to free some resources.

deployment and ExecutionOnce an application is developed, an agent-based system called a cloud agency can be used to assist the developer in the selection of a suitable IaaS provider.4 The developer can set hard and soft con-straints for various properties, such as the number of needed VMs for the application, the required oper-ating system, disk space, processor type, and service cost. This is particularly helpful when an engineer needs to choose from a plethora of existing cloud providers, which are supported by the platform, for example, Amazon EC2 (http://aws.amazon.com/ec2), Flexiscale (www.flexiscale.com), Rackspace (www.rackspace.com), and CloudSigma (www.cloudsigma.com). Middleware solutions for build-ing private IaaS are also supported, including Euca-lyptus (www.eucalyptus.com), OpenNebula (http://opennebula.org), OpenStack (www.openstack.org), and CloudStack (http://cloudstack.apache.org). Ad-ditional IaaS providers can always be added through mechanisms supported by the cloud agency. The cloud agency also negotiates and manages service-level agreements with the supported IaaS providers in a fully automated process.

Once an adequate number of VMs is acquired, the mOSAIC software platform services are auto-matically downloaded from the Web, and installed

CISE-16-03-stan.indd 71 30/05/14 10:03 AM

Cloud Computing

72 May/June 2014

and started on all VMs. The VMs are then con-nected into a virtual cluster by using a Web inter-face of the mOSAIC services running on the VMs. Now, the setup is ready for the cloud application’s deployment.

At application deployment time, either the developer(s) manually or supporting tools automat-ically prepare an assembly descriptor in JavaScript Object Notation format. The assembly descriptor specifies all software components comprising the cloud application. It includes details on their con-figuration (null in the case of COTS and a URL from where to download the component in case of custom made cloudlets), annotation (the exact VM on which the software component should be started, or null in a case where the VM should be chosen randomly), count (how many instances of the component should be started), order (the start-ing order for the software component), and delay (delay in the component startup in milliseconds).

A preferred method of deployment is to let the mOSAIC platform’s services decide on which VM to start which software component. By passing the assembly descriptor to the mOSAIC platform, all the necessary software components are started in a specified order on acquired VMs on the previously selected IaaS (see Figure 4).

The services of the mOSAIC software platform can automatically detect overloaded (or not used) software components, for example, by monitoring the number of exchanged messages in the mes-sage queues, and facilitating elasticity by starting

(or stopping) software component instances dur-ing the application’s execution (see Figure 4). Moreover, if needed, the services of the mOSAIC software platform can inform the cloud agency to acquire additional VMs on which more such soft-ware components will be instantiated. In such a way, the application can adapt to increasing or de-creasing user number or to the data input of vary-ing complexity, as often needed in engineering and scientific applications.

Fault tolerance is ensured by the mOSAIC PaaS at the component level through its specific checking mechanisms installed in each VM. The cloudlets are stateless, but their input and output data and messages are recorded in persistent and reliable storage and messaging components. In case of a fault, the container that controls the compo-nents healthiness through a heartbeat code can stop, duplicate, or restart the faulty component. In practice, fault tolerance is achieved by running simultaneously at least two instances of a software component. In such case, a crash of single instance won’t interrupt the application’s normal operation. With our current experience, it’s advisable to start instances of the same component on two different VMs, which represents a fault-tolerant design in case of a VM crash. The mOSAIC platform can detect and handle both situations (VM or sofwa-re component instance crash). Moreover, as we can see in Figure 4, COTS and cloudlets execute as parallel processes, thus, taking advantage of multi-core systems.

End userInput

Input

Cloud

Result

NoDeKcloudletH

TTP

gRequest

Response

HTT

P s

erve

r

Input

Result

Process

Key-value storeHttp server Message queue

HTTP gatewayCloudlet Webpage

Figure 2. Basic design of a NoDeK cloud application based on a NoDeK cloudlet and components off-the-shelf (COTS).

CISE-16-03-stan.indd 72 30/05/14 10:03 AM

www.computer.org/cise 73

testing and ValidationWe conducted experiments to evaluate the perfor-mance of the basic and advanced designs. We used four problems of increasing computational com-plexity (see Table 1).

We performed three series of tests on a desk-top computer and on three infrastructures, se-lected manually for simplicity: a Eucalyptus-based infrastructure provided by the West University of Timişoara (WUT) and a CloudStack based infrastructure provided by Brno University of Tech-nology (BUT) as private cloud providers, and Ama-zon EC2 as a public cloud provider. To provide for comparable results, we disabled the automatic elas-ticity of the two applications and set up the execu-tion configurations manually. Table 2 shows details of the infrastructures.

In the first tests, we compared the original ap-plication’s execution times on a desktop computer

with the basic design’s execution times on the three selected IaaS (see Figure 5). The execution times are similar on all four selected infrastructures. The BUT infrastructure was the fastest among the three IaaS—however, without enough RAM, it was unable to calculate the helix problem.

In the second series of tests, we analyzed the basic design’s scalability. The configuration was one VM running all COTS, and each addi-tional VM running one instance of the NoDeK cloudlet. We measured speedup for eight concur-rent users against an increasing number of VMs. Figure 6 presents the results, which indicate good scalability. The Amazon EC2 turns out to be the best cloud provider, because the application can achieve almost perfect scaling on its infrastruc-ture. Surprisingly, the BUT infrastructure was the slowest in this test, although it was the fastest in the previous test. This is probably due to the

End user Input

Cloud

Result

Prepare data

HTT

Pg

HTT

P s

erve

r

Key-value storeHttp server Message queue

HTTP gatewayCloudlet Webpage

Assemble stiffnessmatrix and residual

vectorof structure

Evaluate stiffnessmatrices and

residual vectorsof finite elements

Unsolved

Solved

M1 M2

1

2 3

4

5

6

7

8

9

10

Prepare data

1 Write unsolved data 2 Send message 3 Receive message 4 Request data

M2 calculation

5 Write solved data 6 Send message 7 Delete unsolved data 8 Receive message9 Request data

M1 calculation10 Delete data

Figure 3. Advanced design for a NoDeK cloud application. The design is based on M1 and M2 cloudlets implementing sequential and parallel steps of the NoDeK algorithm, respectively.

M1

RabbitMQHTTPserver

HTTPgateway M2

RiaKV

M2

3MV2MV1MV

M2

RabbitMQ

HTTPserverM2 RiakKV

VM4

M2

M1M2 M2

VM5

M2M2 RiakKV

Figure 4. Runtime view of the NoDeK cloud application (advanced design). In this possible arrangement, several loosely coupled instances of all required software components are running on four virtual machines (VMs). An additional VM is added into the virtual cluster when the load increases.

CISE-16-03-stan.indd 73 30/05/14 2:41 PM

Cloud CoMputing

74 May/June 2014

infrastructure’s lack of physical resources (1 Gbyte of memory). Th ere’s only light traffi c among the application components in the basic design, so

the communication latency couldn’t signifi cant-ly infl uence these results. Focusing on the bent problem, we see that it’s quite large and requires more than 1 Gbyte of RAM to be completely cal-culated in the memory. In case of a single VM running on a host, the VM can get up to 25 per-cent additional RAM from the host (the soft li-mit), if available. Th at provides enough RAM for the entire calculation of the bent problem in the memory (see the test case presented in Figure 5). When multiple VMs are running on the same host (see the test case presented in Figure 6), ad-ditional RAM isn’t available and the VM might be given only 1 Gbyte of RAM. After the RAM limit is reached, the NoDeK cloudlet starts using the swap space (inside the VM) to successfully complete the calculation and this causes the delay observed in Figure 6.

Th e third series of tests measured the amount of possible application speedup with our ad-vanced design, which exploited a step of the NoDeK algorithm that can be easily parallelized. We conducted the tests for one concurrent user

table 2. Confi guration of the infrastructures used for testing.

infrastructure Middleware Cpu RAM (gbytes) operating system

Desktop Not applicable Intel Core i7-2640M processor @ 2.80 GHz

1.5 Ubuntu 10.04

West University of Timisoara (WUT)

Eucalyptus Intel Xeon processor E5504 @ 2.00 GHz

2 mOS

Brno University of Technology (BUT)

CloudStack Intel Xeon processor E5620 @ 2.40 GHz

1 mOS

Amazon Amazon EC2 2.5 Amazon EC2

Compute Units (ECU)

1.7 mOS

600

500

400

300

Tim

e (i

n se

cond

s)

200

100 Dome

Arm

Bent

Helix

00 50,000 100,000 150,000

Number of finite element evaluations

Amazon WUT BUT Desktop

200,000

Figure 5. Execution times of individual test cases (in seconds) on a desktop computer and three IaaS using the basic design. The confi guration was one VM on which one NoDeK cloudlet instance and all COTS were running. (WUT = West University of Timisoara; BUT = Brno University of Technology.)

Table 1. Four structural problems and their computational complexity.

problem Atypical dome Spacecraft arm Bent Helix

image

physical size 50 × 50 × 5 m 30 × 1 × 1 m 3 × 5 × 5 cm 10 × 10 × 30 cm

number of fi nite elements 240 968 1,000 4,012

iterations 45 40 79 40

total number of fi nite-element evaluations

10,800 38,720 79,000 160,480

CISE-16-03-stan.indd 74 30/05/14 10:03 AM

www.computer.org/cise 75

and an increasing number of M2 cloudlets. The configuration was one VM with all the COTS, one VM with the M1 cloudlet, and each additi-onal VM with one running instance of the M2 cloudlet.

The results presented in Figure 7 indicate that parallelization of the single step of the NoDeK algorithm may lead to an approximate speedup of about 50 percent in the case of the Amazon EC2 and WUT’s infrastructures, and almost no speed-up at all in the case of the BUT’s infrastructure. The experimental results show that the speedup is highly affected by the IaaS provider. In such situ-ations, the mOSAIC PaaS solution proves benefi-cial because it allows experimentation with IaaS providers without the need to make changes in the cloud application.

The results show low performance of the ad-vanced design, for which we investigated the root causes. First, a calculation of theoretical limits based on previous measurements of sequential and parallel steps shows a ratio of 1:3, which le-ads to a low speedup factor of four. Second, the overhead caused by communication between the components is great. This is due to a large amount of connections transferring small data packets, because all messages in the RabbitMQ and the Riak key-value store get and delete requ-ests. Third, the RabbitMQ and Riak components aren’t optimized for performance. Because all IaaS providers use the same application and soft-ware platform, the differences between the IaaS providers can be caused by either the physical infrastructure or the different IaaS virtualization stack. Unfortunately, we can’t be sure of which one is causing this issue.

As usual with loosely coupled distributed systems, any distributed or parallel application design might be more beneficial when the calcu-lations embedded in the parallel tasks are more computationally intensive and don’t require con-stant communication among the application components.

generalizing the ApproachIn the two cloud applications designs, we use cloudlets to invoke a legacy application requir-ing specific libraries and a runtime environment. The existing application contains mathemati-cal formulation of a specific finite element. As usual with finite-element analysis applications, the actual input describes the physical properties such as geometry, loading, element material, and

current stress-strain state. The mathematical for-mulae are applied to these input data and result in a classical finite element containing a stiffness ma-trix of the element and a residual vector. The key issue is in the mathematical formulation of the finite element, which might be different for vari-ous application purposes. Because the input and output data of this process don’t change, the de-veloped cloudlets can be conveniently modified in the future to account for other legacy applications and the whole range of possible finite-element

1,8001,6001,4001,2001,000

Tim

e (i

n se

cond

s)

800600400200

01 2 4

Number of NoDek cloudlets

Amazon WUT BUT

speedup BUTspeedup WUTspeedup Amazon

8

8

7

6

5

4

3

2

1

0

Figure 6. Execution times for the bent testing problem (in seconds) on the selected infrastructures with eight concurrent users. The second vertical axis represents application speedup with the increasing number of NoDeK cloudlets, each running on its own VM.

350

300

250

200

150

Tim

e (i

n se

cond

s)

100

50

01

Amazon

speedup Amazon speedup WUT speedup BUT

BUTWUT

2 4

Number of M2 cloudlets

8

1.81.61.41.21.00.80.60.40.20.0

Figure 7. Execution times for the bent testing problem (in seconds) on the selected infrastructures. The second vertical axis represents application speedup with increasing numbers of M2 cloudlets each running on a separate VM.

CISE-16-03-stan.indd 75 30/05/14 10:03 AM

76 May/June 2014

Cloud CoMputing

formulations and solutions to other solid and fluid mechanics problems.

To experiment additionally with the approach’s feasibility, we developed cloudlets for various operations frequently needed for experimentation with engineering problems. For this we used various legacy software, which we adapted to be called as a Java function. The developed cloudlets implement operations for construction and transformations of matrices, potentiation, sorting, vector products, linear regression, fast Fourier transformation, eigen-vector and determinant calculations, Cholesky de-composition, inverse matrix operations, Hilbert and Toepliz matrices, and others. The cloudlet wrap-up code is similar to the one already developed for the NoDeK application. We successfully tested all these developed cloudlets, which makes possible porting a range of engineering applications to the cloud.

The study focused on addressing problems when designing cloud applications in the en-

gineering domains. The key lessons learned are the following:

■■ Providing our civil engineering applications as services over the Web to a larger number of ex-ternal users can be achieved by using the devel-oper-friendly programming environment of the mOSAIC PaaS.

■■ The mOSAIC’s cloudlet API can be used to provide important properties to applica-tion components, such as elasticity and fault tolerance.

■■ Applications developed with mOSAIC can be seamlessly ported from one cloud provider to another. This avoids the need to commit to a cloud infrastructure provider at application de-velopment time. The mOSAIC’s cloud agency might help dynamically select an infrastructure provider offering optimal quality of service.

■■ The component-based programming model of mOSAIC makes it possible to reuse parts of ex-isting applications. This has the potential to simplify the development of a range of engineer-ing applications for the cloud. For example, the developed M2 cloudlet can be exchanged with another cloudlet containing different finite- element formulations, while maintaining the same application design. Our approach could therefore serve as an example for cloud enabling applications developed at universities and may-be even commercial tool suites and applications.

■■ Additional speedup can be achieved by re-arranging the application algorithm itself. This, however, wasn’t the focus of the present study.

Legacy software usually requires specific librar-ies and a specific runtime environment to execute. As we’ve seen, the mOSAIC PaaS solution makes it possible to incorporate computationally and data intensive legacy software in cloudlets. With this advantage, it’s possible to dynamically match external computational resources to engineering applications.

The human effort required for the two applica-tion designs was six person months spent for code rewriting in the communication part, the new Web interface, the cloudlets implementation, as well as intensive testing and documentation. We expect that a similar effort is necessary for cloud-enabling other computationally intensive engineer-ing applications.

As clouds are more appropriate for distrib-uted applications rather than parallel computing solutions, the engineering applications that can benefit from the migration toward clouds are the ones that can be decoupled in weakly coupled components. Often when implementing appli-cations for solid and fluid mechanics problems, key-value pair-based communications would be sufficient, as the computations of various parts can be decoupled.

The mOSAIC software platform has significant potential and is already being used to build applica-tions for analysis of large-scale sensor data for wind turbine operation by the Spanish company Tecna-lia and geospatial image analysis by the European Space Agency.5

AcknowledgmentThis work was supported by the European Commission Seventh Framework Programme (FP7) grant mOSAIC, contract number 256910.

References1. P.J. Guo, “CDE: A Tool for Creating Portable Experi-

mental Software Packages,” Computing in Science & Eng., vol. 14, no. 4, 2012, pp. 32–35.

2. J.J. Rehr et al., “Scientific Computing in the Cloud,” Computing in Science & Eng., vol. 12, no. 3, 2010, pp. 34–41.

3. P. Češarek, M. Saje, and D. Zupan, “Kinematically Exact Curved and Twisted Strain-Based Beam,” Int’ l J. Solids and Structures, vol. 49, no. 13, 2012, pp. 1802–1817.

CISE-16-03-stan.indd 76 30/05/14 10:03 AM

www.computer.org/cise 77

4. S. Venticinque et al., “A Cloud Agency for SLA Ne-gotiation and Management,” Proc. EuroPar 2010 Workshops, LNCS 6586, 2011, pp. 587–594.

5. R. Cossu et al., “Cloud Computing for Earth Ob-servation,” Data Intensive Storage Services for Cloud Environments, IGI Global, 2013, pp. 166–191.

Jernej Južna is a graduate student at the Faculty of Computer and Information Science at the University of Ljubljana, Slovenia. His research interests include hy-brid cloud computing. Južna has an MSc in computer science from University of Ljubljana. Contact him at jernej.juzna@fri.uni-lj.si.

Peter Cešarek is a research assistant at the Faculty of Civil and Geodetic Engineering at the University of Ljubljana, Slovenia. His research focuses on finite-element methods. Češarek has a PhD in civil engineering from University of Ljubljana. Contact him at peter.cesarek@fgg.uni-lj.si.

Dana Petcu is a professor at West University of Timişoara and the executive director at Institute e-Austria Timişoara. Her research interests include distributed and parallel com-puting. Petcu has a PhD in numerical analysis from West University of Timişoara. Contact her at petcu@info.uvt.ro.

Vlado Stankovski is an assistant professor at the Faculty of Civil and Geodetic Engineering at the University of Ljubljana, Slovenia. His research interests include seman-tic grid, cloud, sky, and fog technologies. Stankovski has a PhD in semantic grids from University of Ljubljana. Contact him at vlado.stankovski@fgg.uni-lj.si.

Selected articles and columns from IEEE Computer Society publications are also available for free at

http://ComputingNow.computer.org.

Call for ArticlesIEEE Intelligent Systems

seeks papers on all aspects of arti� cial intelligence, focusing

on the development of the latest research into practical, � elded

applications. For guidelines, see www.computer.org/mc/

intelligent/author.htm.

The #1 AI Magazinewww.computer.org/intelligent

Publish Your Paper in IEEE Intelligent Systems

Be on the Cutting Edge of Arti� cial Intelligence!

IS-28-01-c1 Cover-1 January 11, 2013 9:40 AM

P U T T I N G A I I N T O P R A C T I C E

IEE

E

January/FEbruary 2013

Also in this issue: Intelligent Sports 6 Traffic and Social Media 72 Trust in automation 84

www.computer.org/intelligent

IEEE ja

nu

ary/fEbru

ary 2013

Co

Alit

ion

op

erA

tio

ns

VOLu

ME 28 n

uM

bEr 1

IEEE

CISE-16-03-stan.indd 77 30/05/14 10:03 AM