# Introduction

Our cranes are extremely versatile devices and if in action they are ever-changing their form. Obviously, you can consider our cranes as a kinematic system like robot arms. Our customers are promised stability and longevity of our products. Therefore, we maintain a rigorous regime of verification that our cranes provide the guaranteed level of stress resistance and user safety.

# The Problem at Hand

At some level of generalization, a crane tip can reach any point within a semisphere with the maximum length of the crane boom as a radius. Now, it is our very obligation to make sure that every position of the crane is safe.

Safety concerns a number of different aspects.

- All parts and components are within their stress limits.
- The dynamics of movements have to be taken into account.
- The load is transferred in a safe way from one position to another.

# Big Compute

We have designed mathematical models of our cranes which also take into account the flexibility of the underlying kinematic system. We then need to reduce the number of possible positions for the crane boom to a manageable set of sample points. Apparently, the high number of crane boom positions included in the sample is a challenge for the verification process. We take advantage of the fact, that our problem belongs to the class of *embarrassingly parallel* problems. Obviously, we are now entering the realm of number crunching. So, combining number crunching and loader cranes makes up a new discipline: crane crunching. In other words, we are crunching/breaking cranes in a virtual way by utilizing large amounts of computing power.

Basically, every crane boom position is absolutely independent of every other one. Thus, we can perfectly leverage the possibilities of different kinds of concurrent computing, i.e.

- multi-threading
- multi-processing
- distributed computing locally and in the cloud

# Local Machines

On-premise, we have been employing multi-threading and multi-processing on different hardware platforms. Mostly, we carried out the calculations on dedicated hardware where we utilized a number of different machines. In a first attempt, we tried to increase the number of processors. But, by increasing the number of cores beyond 10 we needed to switch from the multi-threading paradigm to the more involved multi-processing paradigm. Otherwise, we were unable to observe the speedup for the *intrinsically parallel problem* at hand.

# The Azure / HPC Approach

In an effort to massively speed up the crane crunching we combined two approaches with the support of external consultants. Namely, we utilized the Azure infrastructure (e.g. storage, ServiceBus, virtual machines) and the HPC-Pack. We installed the HPC-Pack on a virtual machine and employed a large number of Azure-computing-nodes to carry out the calculations.

**pro**

- The speedup was almost linear and the resulting overall time only a fraction compared to the on-premise efforts.
- We did not have to invest a single € into additional hardware. I would say this is IaaS as good as it can get.

**cons**

- The management (i.e. installation, starting/stopping, maintenance) of a cloud computing cluster is not trivial.

# Conclusion

Parallel computing in the environment of crane-engineering is a bare necessity to manage the overwhelming complexity of the calculation processes. Cloud computing provides an appealing option because we can acquire computation power on demand and literally at any level, and release it afterward.