Dedicated Server Hosting Cluster StarCD Computational Fluid Dynamics HPC Software: The power of the modern HPC Cluster is brought to the end user more often than not through software like StarCD or Fluent, two typical applications in the area of computational fluid dynamics (CFD). As long as everything works correctly – or at least as expected – neither the engineer setting up the computations nor the administrator ensuring the smooth work of the cluster actually knows what goes on inside the binary package doing all the calculations.

---

by Michael Hebenstreit

The power of the modern HPC Cluster is brought to the end user more often than not through software like StarCD* or Fluent*, two typical applications in the area of computational fluid dynamics (CFD). As long as everything works correctly – or at least as expected – neither the engineer setting up the computations nor the administrator ensuring the smooth work of the cluster actually knows what goes on inside the binary package doing all the calculations.

Unfortunately things tend to go wrong. At this point, the question "What is going on?quot; is fundamental to answering "How can I fix this problem?quot;. If you are not able to answer the former question, everything you do is akin to feeling around in the dark. Even if you are able to solve the issue, you might still be wondering exactly why your fix worked, and if it is going to be an only temporary solution. Here we will speak about the Intel Cluster Tools, specifically the Intel Trace Collector, Intel Trace Analyzer and Intel MPI Benchmarks, which should be able to shed some light into this binary darkness.

At a customer visit, the author was faced with an Hewlett-Packard (HP)*/Intel Itanium 2 1.5GHz cluster running StarCD* over a Gigabit Ethernet switch. The customer was very dissatisfied with the performance of the system, pointing out that they were neither able to run a simple 32-thread job with high efficiency nor could they reproduce the benchmark results originating from the time of purchase. The author quickly verified during the visit that the main problem was the CPU utilization of each node – showing only around 60% instead of the usual mark of 95-100%