tackling the challenges of multicore. - epcc · 2017-10-20 · issue 65, summer 2009 the newsletter...

16
ISSUE 65, SUMMER 2009 The newsletter of EPCC: the high-performance computing centre at the University of Edinburgh. Tackling the challenges of multicore. 2 EPCC at ISC 2009 3 Launch of the Centre for Numerical Algorithms and Intelligent Software (NAIS) 4 The challenge of multicore 6 Adapting physics software to exploit multicore 7 Molecular dynamics on small multicore systems 8 FireGrid: predicting the progress of fires 10 Multicore training with EPCC Gridipedia: the Grid repository 11 Data management in BEinGRID 12 Alarms Service for federated networks 14 HPC-Europa 2 15 OGSA-DAI: from open source product to open source project In this issue... The Quad-Core AMD Opteron processor, which will be used in the HECToR Phase 2a upgrade.

Upload: others

Post on 15-Aug-2020

2 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Tackling the challenges of multicore. - EPCC · 2017-10-20 · Issue 65, summer 2009 The newsletter of ePCC: the high-performance computing centre at the university of edinburgh

Issue 65, summer 2009The newsletter of ePCC: the high-performance computing centre at the university of edinburgh.

Tackling the challenges of multicore.

2 ePCC at IsC 2009

3 Launch of the Centre for Numerical Algorithms and Intelligent software (NAIs)

4 The challenge of multicore

6 Adapting physics software to exploit multicore

7 molecular dynamics on small multicore systems

8 FireGrid: predicting the progress of fires

10 multicore training with ePCC Gridipedia: the Grid repository

11 Data management in BeinGrID

12 Alarms service for federated networks

14 HPC-europa 2

15 OGsA-DAI: from open source product to open source project

In this issue...

The Quad-Core AMD Opteron™ processor, which will be used in the HECToR Phase 2a upgrade.

Page 2: Tackling the challenges of multicore. - EPCC · 2017-10-20 · Issue 65, summer 2009 The newsletter of ePCC: the high-performance computing centre at the university of edinburgh

The challenge of multicore

eDITOrIALAndy Turner

Multicore technology, once the sole preserve of the HPC world, is now a major part of computing in business and science. Due to its extensive experience with a wide range of novel computer architectures, EPCC is particularly suited to exploiting this technology and is at the forefront of enabling researchers and industry to get the maximum benefit from these technological advances.

This issue of EPCC News highlights some of our multicore related activities. Mark Parsons gives an overview of the impact of multicore technology on page 4. We also feature a number of EPCC projects that are utilising multicore: a project looking specifically at the martensite phase in crystalline materials, which involved refactoring an existing code to work effectively on a commodity multicore machine; preparing quantum chromodynamics (QCD) software for the step to multicore technology; and an upcoming course at EPCC that will help you exploit multicore processors in your work.

Of course, within HPC itself there are many challenges based around how to use multicore technologies effectively. For EPCC, the issue will gain extra impetus this summer with the arrival of HECToR Phase 2a: an upgrade to the national supercomputing service that is based around AMD’s quad-core technology. And the challenges will only increase as 8- and 16-core chips become available.

In addition to multicore, the integration of distributed, heterogeneous technologies is also playing a greater role in

general computing. OGSA-DAI has just been extended by a year to create an open source project based on this type of integration technology (see page 16). BEinGRID (page 11)continues to provide distributed computing technology aimed at business users and the NPM Alarms software (page 12) is helping data from the LHC to reach scientists. We also report on FireGrid, which exploits Grid technology to provide real-time data and predictions to help fire-fighters in emergency situations.

Finally, we provide an insight into HPC-Europa2, which is continuing to enable researchers from around Europe to benefit from the experience and knowledge of EPCC staff as well as build links across the European research community.

All-in-all, a busy issue. I hope that this edition whets your appetite for meeting the challenges that multicore technology and distributed computing hold.

IsC 200923-26 June, Hamburg, Germany.

EPCC will exhibit in booth 736. Come and visit us!

EPCC Birds of a feather session“DEISA & HPC-Europa: EU Support for HPC Users”11:00-11:40am, BoF Session 13, Hall C2.2

Abstract:

The European Commission is a strong supporter of HPC in Europe. Two projects which directly focus on the current needs of HPC users are DEISA and HPC-Europa, both receiving substantial funding in FP7. EPCC is co-organising this Birds-of-a-Feather session to promote DEISA and HPC-Europa services to new users and research communities, and provide a platform for scientists to make us aware of their requirements.

The DEISA Extreme Computing Initiative, or DECI, is an excellent way to gain access to a large amount of HPC cycles, for projects which are too large to run on a single National Resource.

DEISA also offers the support and middleware to harness a Grid of 15 HPC systems, distributed across Europe.

The fifth DECI Call closed in May, 2009, and received 74 proposals from across the world. The UK-based proposals alone have requested a total of over 15 million core hours.

For further information see www.deisa.eu or contact Gavin Pringle at EPCC: [email protected]

EPCC has recently launched the EPCC Industry Hub, a one-stop shop for industry and commerce providing streamlined access to our supercomputing facilities and expertise.

To find out more please go to the Hub website: www.epcc.ed.ac.uk/eih

ePCC Industry Hub goes online

2

sixth DeIsA extreme Computing Initiative: call for proposals Opens November 2009

Page 3: Tackling the challenges of multicore. - EPCC · 2017-10-20 · Issue 65, summer 2009 The newsletter of ePCC: the high-performance computing centre at the university of edinburgh

NAIs: Numerical algorithms and intelligent software for the evolving HPC platformMark G. Beckett

Computer-based simulation is a vital tool in today’s knowledge-driven economy, in application areas such as engineering, biosciences, materials science, energy generation and telecommunications. The development of computer-based simulations has traditionally been the remit of specialists – known as numerical analysts – working alongside the scientists and engineers that furnish the actual applications. Given the ambition and scale of these applications, it is essential that truly realistic and very precise simulations can be produced. This, in turn, necessitates the creation of efficiently implemented algorithms, able to exploit the full capacity of the available computer hardware. However, the complexity of modern high performance computing technology means that very few people can be experts in both algorithmic development and efficient implementation. Developing new numerical simulation techniques therefore requires an interdisciplinary approach.

NAIS (Numerical Algorithms and Intelligent Software) will address this skills gap by establishing a research centre, bringing together applications-oriented numerical analysts and computer scientists with HPC experts, in order to enable a paradigm shift for HPC and to build the next generation of portable and effective tools for numerical simulation, based on a combination of more instructive programming techniques (advanced annotation) and ‘intelligent’ machine-learning compilers.

The NAIS project consortium brings together top UK researchers from the three fields of numerical analysis, computer science and high performance computing, at University of Edinburgh (in EPCC, School of Informatics, and School of Mathematics), Heriot-Watt University (School of Mathematics & Computing), and the University of Strathclyde (Department of Mathematics).

NAIS will coordinate and execute a number of complementary activities in order to achieve its goal. The NAIS team will develop advanced numerical algorithms for target applications – for example, adaptive finite element methods, molecular dynamics simulations, and time-domain partial differential equations, focused on achieving efficient exploitation of parallel computing environments and ensuring portability across relevant computer architectures.

A UK-wide research network will be established, involving DAMTP at the University of Cambridge, the Warwick University Centre for Scientific Computing and the Wales Institute for Mathematics and Computer Science. The network will focus on training, and feature a comprehensive series of workshops and meetings alongside a vibrant visitor programme.

The NAIS team will establish a total of seven lectureships in mathematics and computer science, eight research posts and 25 PhD studentships across the research areas, with strong knowledge exchange partnerships with national laboratories and industry.

Commenting on the importance of NAIS, EPCC’s Director Arthur Trew said: ‘For the past forty years we have been able to rely on speeding up microprocessors to help applications get faster. Due to physical limits that is now ending and we will increasingly have to rely on scaling of algorithms if we want to improve performance. Centres such as NAIS will be essential in achieving that goal.’

www.nais.org.uk

3

The challenge of multicore

Page 4: Tackling the challenges of multicore. - EPCC · 2017-10-20 · Issue 65, summer 2009 The newsletter of ePCC: the high-performance computing centre at the university of edinburgh

Since the advent of the microprocessor over 30 years ago the vast majority of software applications have been built and executed on single processor computer systems; essentially following the Von Neumann model of computation. We have lived through an age of easy programmability where large numbers of software developers have learnt to program in a wide variety of languages which can easily be compiled into machine code for the latest and greatest microprocessor. There are estimated to be 17 million software developers worldwide today with several million of these developers based in Europe.

For many years, high performance computing (HPC) followed the same path with faster, more-complex processors delivering annual performance gains following Moore’s Law. By the mid-1980s it became clear that single-processor performance improvements could not continue to deliver the required performance improvements and the discipline of parallel computing, and hence EPCC, was born. During the early 1990s great strides forward were made in understanding the complexity of programming such computers and the main programming paradigms – task farm, regular domain decomposition, structured and unstructured mesh – were developed in association with libraries (eg MPI) and APIs (eg OpenMP) to support portable high performance application development. During, and since, this period the challenges of programming such systems have become apparent. The transition from serial to parallel programming is difficult, and as a result the number of programmers trained to develop code in this way has remained a tiny fraction (much less than 1% based on the numbers trained by the leading European HPC centres during this period) of the overall programmer population.

Until the beginning of this century, companies and individuals benefited enormously from the annual improvements in microprocessor design delivered by Intel and AMD which followed or exceeded Moore’s Law. However, these gains were driven by: silicon feature size reductions, increased design complexity and ever greater clock speed and commensurate power consumption. Clock speed peaked in 2005 and since then we have witnessed reduced clock speeds on many products, in particular to minimise energy consumption.

To continue annual performance increases and maintain the market for their products, the microprocessor vendors’ response to this crisis has been to introduce multicore chips which pack two or more microprocessors onto a single piece of silicon. Moore’s Law is often misquoted as a doubling of microprocessor performance roughly every 2 years. In reality Moore observed that “the number of transistors on a chip will double about every two years”. This has allowed both Intel and AMD to claim they are continuing to follow Moore’s Law into the future (and certainly until the middle of the next decade) since the combined peak performance of the multiple cores on a multicore microprocessor continues to increase, as we have come to expect, as well as the number of transistors.

For most businesses and individuals the introduction of multicore processors has been a positive experience. The perceived performance of laptop and desktop computers has continued to increase as processor-hungry applications (eg music players) have run on one core while other processes (eg virus scanning, word processing) have run on the other core. In parallel computing terms (which is what in essence a multicore processor is) this use of multicore processors represents a functional decomposition of the computational problem (in this case the problem being general computer interaction).

However, more technical users have not reaped the benefits of multicore processors unless they have been lucky enough to possess an already parallelised application. Indeed, in some cases their applications will run considerably slower on a multicore processor due to the reduction in clock speeds. Furthermore, as the number of cores on multicore processor continues to increase – from 4 to 8 to 16 to 32 and beyond – the functional decomposition which is currently employed will quickly run out of steam as humans are not good at performing more than 3–4 tasks at once, even on a computer. In 2006 Intel demonstrated an 80-core microprocessor with over 1 Teraflop of peak performance. However, the only way to realise true performance gains will be to parallelise all applications, which brings us to the nub of the problem: there are far too few programmers familiar with parallel programming methods in Europe and throughout the world today. Without high-

The challenge of multicore: a brief history of a brick wallMark Parsons

4

The challenge of multicore

Page 5: Tackling the challenges of multicore. - EPCC · 2017-10-20 · Issue 65, summer 2009 The newsletter of ePCC: the high-performance computing centre at the university of edinburgh

level language support for parallelism – support that has been extremely hard to develop in over 20 years of HPC computing – we are running into a performance dead-end at all levels of computing from HPC to technical to business to home computing and there is no easy solution.

In conjunction with the challenge of programmability we also face a hardware challenge directly related to multicore processors and their interaction with main memory. The speed of memory (both the time taken to randomly access a given byte of memory and the amount of data and instructions that can be delivered from memory to the processor per second) has been a bottleneck since microprocessors were invented and this has only increased with time. Many different microprocessor hardware strategies have been developed to alleviate the problem including instruction and data caching (on-chip and off-chip), compiler optimisations such as branch prediction and superscalar architectures. Even with these strategies, many modern single-core microprocessors still spend long periods waiting for data to arrive. A poorly optimised code may only utilise 5–10% of a processor, and even with good optimisation making use of hardware and compilation strategies, very few applications get near to peak performance.

With multicore processors this problem is further exacerbated. Unless data and instructions can be cached successfully (which is generally not the case because of the quantities of data and instructions involved), any expected performance gains will be lost entirely because of memory speed issues.

Some possible solutions

There is no simple solution to the challenge that multicore poses. We must attack it on a number of fronts simultaneously.

• Hardware and operating systemsWe need to address hardware issues, particularly those related to memory. We need to understand ways of hiding the lack of memory speed from the application and look at how to increase the overall speed through better hardware design. We also need to look at what changes could be made at the operating system level to support better use of multicore processors and the languages used to program them. Multicore systems will be characterised by complex memory hierarchies and many processing cores. This will make the task of programming them much more complex than the distributed systems of 5 years ago.

• TrainingWe must increase the number of people who can program in parallel. Parallel programming techniques should be taught at undergraduate level so that all IT graduates have a basic understanding of the challenges. However, it is clear that training the large body of existing software developers to become parallel programmers using existing methodologies (eg MPI and OpenMP) is probably not realistic. Conceptually, parallel programming is complex to master and there is no infrastructure available to train this many people. Furthermore,

whilst languages such as Fortran and C can be parallelised using existing methodologies that were commonly taught to software developers 20 years ago, this is not the case today with much more emphasis being put on object orientated languages such as C++ and Java and much less (if any) on parallel programming.

However, it would be wrong to dismiss Fortran and C as yesterday’s languages. We now know that codes have a much greater lifetime than anyone expected. Many of Europe’s industries rely on applications written in these languages that began life over 30 years ago. It is simply not credible that they can be re-implemented from scratch in a modern language. We therefore need to continue training graduates in these languages and traditional parallel programming paradigms.

• New languages and toolsIn addition to maintaining and extending traditional languages and libraries (eg Fortran, C, MPI and OpenMP), we need to consider new languages. In the USA the “High Productivity Computing Systems” (HPCS) programme, funded by DARPA, has worked since 2002 partly to develop novel programming languages with a focus on high productivity as well as high performance. The Partitioned Global Address Space (PGAS) programming model has grown from this work and extensions to existing languages, such as UPC and Co-Array Fortran, are now available. Furthermore, a completely new language called Chapel is being developed by Cray as part of HPCS.

Chapel is a new, high-productivity programming language for multicore and parallel systems. EPCC has recently been working with Cray to explore the use of Chapel on HECToR and HPCx. As explained above, today’s graduates are generally taught object orientated languages. Any new language must presents today’s software developer with a language, grammar and concepts with which they are familiar and an IDE similar or the same as they already use. Chapel does this.

Chapel is freely available as Open Source (http://chapel.cs.washington.edu). It is intended to be a broad solution which has applicability on a single workstation, on a compute cluster and on an HPC system. It employs the PGAS programming model and has broad applicability because it spans shared-memory (for instance a single multicore microprocessor in a laptop) and distributed-memory (for instance a Cray XT4) systems, overcoming many of the problems of current shared and distributed programming models in a single solution.

Conclusion

Multicore microprocessors are becoming ubiquitous. However, the programming tools and hardware support needed to realise their true potential are lacking. We need to invest in hardware developments, training and new languages and tools to ensure that computer systems, from the laptop to the supercomputer, continue to deliver the annual increases in performance we have come to expect over the past three decades.

5

The challenge of multicore

Page 6: Tackling the challenges of multicore. - EPCC · 2017-10-20 · Issue 65, summer 2009 The newsletter of ePCC: the high-performance computing centre at the university of edinburgh

The challenge of multicore

Preparing Particle Physics for the

many-core futureAlan Gray

EPCC collaborated with UK and US academics to develop new functionality within the USQCD code suite [1]. This software, originally developed in the US, is heavily used in the UK and throughout the world. Spacetime is represented computationally as a lattice of points, allowing for a wide range of simulations aimed at probing our current understanding of the laws of physics, and searching for new and improved theories.

The Standard Model of Particle Physics, a group of theories which encompasses our current understanding of the physical laws, is known to be extremely accurate. However it is not able to explain all observed phenomena, and is therefore thought to be an approximation of a yet undevised deeper theory. Progress in this fundamental research area requires, in combination with experimental measurements such as those at the Large Hadron Collider, demanding calculations that stress even the world’s largest supercomputers: the rate of progress depends on the code performance on such machines.

Until recently, increases in the performance of computing systems have been achieved largely through increases in the clock frequency of the processors. This trend is reaching its limits due to power requirements and heat dissipation problems. Instead the drive towards increased processing power is being satisfied by the inclusion of multiple processing elements on each chip. Current systems contain dual or quad-core chips, and the number of cores per chip is expected to continue to rise. This layout poses programming challenges, not least for scientific computing on large parallel systems.

Like many HPC codes, the original USQCD software had no mechanism for understanding which processes are associated with which chip: each process was treated as equally distinct from one another and communication was universally done through the passing of messages. A threading model has been developed within the software, where processes running within a chip can be organised as a group of threads, and can communicate with one another directly through memory which they share. One thread per chip (or group) handles the messages needed to communicate with external chips. This new programming model, which more closely maps on to the emerging hardware, can display some modest performance advantages in current systems but the real efficiency gains will be realised as the number of cores per chip rises in the future.

The project has also created additional functionality within the USQCD software. The code has been enhanced to allow calculations using new theories beyond the Standard Model, signals of which may be discovered experimentally at the Large Hadron Collider. Furthermore, improvements have been implemented which allow calculations (within the Standard Model framework) to an unprecedented precision, that in turn allow accurate testing against experimental results: any discrepancies may point to new theories.

[1] USQCD Software: www.usqcd.org/usqcd-software/

A recent project at EPCC has implemented major enhancements in an international particle physics code repository. The work has enabled the effective exploitation of emerging technologies, including those incorporating chips with many cores, and has led to new scientific results worldwide.

6

Page 7: Tackling the challenges of multicore. - EPCC · 2017-10-20 · Issue 65, summer 2009 The newsletter of ePCC: the high-performance computing centre at the university of edinburgh

molecular Dynamics on small multicore systemsKenton D’Mellow, Mark Bull, Kevin Stratford, EPCC

Graeme Ackland, Institute for Physics

In the spring 2008 edition of EPCC News, we reported on an exciting new project to investigate the use of shared-memory, multicore hardware for mid-sized simulations, as an alternative to using large, usually distributed memory, supercomputers.

The project focused on re-engineering and parallelising MOLDY, a short-range molecular dynamics code which can (among other things) be used to study the martensite-austenite phase transition. This phase transition is one of the most important in metallurgy and it exists in many materials. It has some interesting applications, for example in so-called superelastic shape memory alloys (materials that can regain their original shape after deformation). The martensite-austenite transition occurs when moving from a high temperature, ductile (austenite) phase to a low temperature, hard (martensite) phase.

The MOLDY code can be used to understand the structure of the interfaces between martensite and austentite phases, and how this structure is affected by various material parameters. Describing adequate surrounding material makes these molecular dynamics simulations very computationally intense. The MOLDY program implements constant pressure molecular dynamics using pseudopotentials, a Parinello-Rahman Lagrangian and a hybrid link-cell/neighbour-list formulation for speed and efficiency in very large simulation volumes (of order millions of atoms).

A re-engineered version of the MOLDY code has been produced, written as a modular Fortran90 application, with well-defined dependencies and extensively employing module private data. It incorporates a number of additional features and optimisations of the original algorithms. It is also structured to enable simple extension or addition to the potentials used without modification of the source code.

We adopted a shared-memory parallelisation of MOLDY using OpenMP and targeted the most computationally intensive areas of the application: calculation of the interatomic forces and neighbour-list structures that enable MOLDY to scale linearly with problem size. Our implementation of the parallel forces region allows the force between particle pairs to be calculated once and applied to each particle in such a way that the danger of simultaneous access to shared variables is avoided, without a significant synchronisation overhead.

We hope the availability of this parallel code will help to improve understanding of these important classes of material.

The MOLDY code and an associated paper will be submitted to Computer Physics Communications (in preparation).

Figure 1: The atoms of a hot bar, initially in a regular austenite phase and clamped at both ends, is cooled through the phase transition, which sweeps across the material. The texture of martensite phase regions with different orientations (colours) and their boundaries can clearly be seen. Movies of the transition process can be seen at http://www.ph.ed.ac.uk/cmatter/gja/Mart/ Courtesy G. J. Ackland and O. Kastner.

7

The challenge of multicore

Page 8: Tackling the challenges of multicore. - EPCC · 2017-10-20 · Issue 65, summer 2009 The newsletter of ePCC: the high-performance computing centre at the university of edinburgh

8 9

The challenge of multicore

Around noon, on 29th October 2008, a fire broke out in a small flat in the town of Watford, UK. The fire had been deliberately started in a sofa in the living room and, with no intervention, the sofa soon started to burn fiercely allowing the fire to spread to a nearby table and TV. The temperature within the room increased to such a level that the walls and other furnishings burst into flames, a phenomenon known as flash-over that would have been potentially fatal to anyone in the apartment. As flash-over occurred, a ball of fire coursed down the hallway, creating a plume of flame that curled around the front door (see top left image). At this point, the fire was calmly extinguished.

The fire had burned for just under an hour; however, the temperature increased dramatically in just a couple of minutes – from a level tolerable for humans to over 700 degree C at the point of flash-over – demonstrating the hazards faced by fire fighters in their daily work. In this case EPCC had been on hand, helping to monitor the incident, predict what would happen next and to relay this valuable information to the emergency services.

The fire was actually run in the state-of-the-art burn hall facility at the Building Research Establishment (BRE) Watford. This facility boasts a large hanger in which the apartment rig was assembled. It also had an elevated viewing area for the audience and an experienced team of fire engineers who coordinated the setup and execution of the experiment in a predictable and safe manner.

The monitoring and predictions were performed using a prototype integrated emergency response system for built environments, developed as part of the FireGrid project. The aim of the experiment was to demonstrate the FireGrid architecture to project partners and stakeholders.

For the experiment, the entire apartment rig bristled with sensors, measuring quantities such as temperature, smoke levels,

air flow and gas concentrations. The readings from these sensors were aggregated into a central database, from where they could be accessed by the different agents within the FireGrid system.

A predictive capability is a key element of FireGrid and this functionality was delivered using a fire/structure/egress code called K-CRISP, which ran in super-real time on a remote HPC system and was accessed over the Internet using Grid protocols.

A user interacted with FireGrid via a purpose-designed interface called a Command, Control, Communication and Intelligence (C3I) computer. The C3I gave access to the information generated by a combination of live data and predictions from K-CRISP, and was also able to accommodate user requests for specific information. The C3I included a fire alarm agent, which automatically launched the remote K-CRISP simulation when a fire was detected. Another C3I agent provided this simulation with latest sensor readings every 30 seconds. The C3I condensed the myriad of data to a simple graphical form for each room, displaying current and future hazard levels using coloured blocks, looking ahead within a 15-minute window. These hazards included smoke, structural collapse and flash-over.

K-CRISP was employed to predict both structural collapse and flash-over. To improve the reliability of model predictions, real-time data was assimilated into the computation at regular intervals. To ensure super-real-time operation, K-CRISP was parallelised following the Task Farm paradigm, where each slave ran a serial simulation of the fire, and where inter-process communication was handled via the file system. For redundancy, K-CRISP was ported to two HPC systems: ECDF, the University of Edinburgh’s research compute cluster; and HPCx, one of the UK’s two national supercomputing facilities. Access to the HPC resource in urgent computing mode is of particular importance to FireGrid to ensure the simulation can be launched as quickly as possible, generating information about the likely evolution of the fire incident in a timely manner.

ePCC watcheswhile room burnsGavin J. Pringle, Mark G. Beckett

Above, left to right: The FireGrid demonstration; the London Fire Brigade in action.

Page 9: Tackling the challenges of multicore. - EPCC · 2017-10-20 · Issue 65, summer 2009 The newsletter of ePCC: the high-performance computing centre at the university of edinburgh

8 9

The challenge of multicore

Present at the experiment was Paul Jenkins, of the London Fire Brigade Fire Engineering Group, who said the demonstrator proves that Grid-based sensors and fire models can be used together predictively: it showed that simple, accurate predictions of fire performance can be made dynamically and was a remarkable collaborative achievement. Paul went on to say that whilst there is still a very long way to go, the demonstrator showed the potential for the further development of intelligent and interactive environments and expert systems and that, in time, FireGrid may be part of an emergency response. Overall, this was regarded as a highly successful demonstrator, illustrating the great potential of the FireGrid system.

FireGrid: [email protected], www.firegrid.org.

Acknowledgements

FireGrid is co-funded by the UK Technology Strategy Board’s Collaborative Research and Development programme.

This work made use of HPCx, the UK’s national high-performance computing service, and the Edinburgh Compute and Data Facility (ECDF). The ECDF is partially supported by the eDIKT initiative: www.hpcx.ac.uk; www.ecdf.ed.ac.uk; www.edikt.org.

FireGrid was a three-year project, which ended in April 2009. It involved a multi-disciplinary team:

• The University of Edinburgh (including EPCC, the Institute for Infrastructure and Environment, the Institute for Digital Communication, the National e-Science Centre, and the Artificial Intelligence Applications Institute) provided the majority contribution to R&D for all areas of the project.

• BRE (Building Research Establishment) was the lead partner and also provided the experiment facilities which housed the fire and the K-CRISP and JASMINE modelling applications.

• Ove Arup was the overall project manager.

• SIMULIA contributed advanced structural mechanics.

• ANSYS performed CFD and two-way fluid-structure-interaction modelling.

• Xtralis provided both expertise on active fire protection systems, as well as sensor equipment in support of experiments.

• The London Fire Brigade was the principal emergency response advisor and guided the development of the user interface.

Data Logger(DAU) DTU/DGU6 O2/CO/CO2

sensors

Xtralis Camera

C3I

Query Manager (incl. job monitoring and repair)

HPC Simulation:K-CRISP

Pre-processor

Post-processor

7 56

121110

8 4

21

9 3

7 56

121110

8 4

21

9 3

7 56

121110

8 4

21

9 3

7 56

121110

8 4

21

9 3

7 56

121110

8 4

21

9 3

Presenter9 Velocity metres

98Thermocouples

2 Radiometers

8 LVDTs

2 Alarms (Xtralis)

Inte

rnet

CertificateCentre

Internet

Fire Alarm

Internet

WebCam Internet

Gas/TempAgents

Inte

rnet

Database

Left: the FireGrid architecture, which consists of three layers:

• a data acquisition and storage layer (yellow) for capturing and storing live sensor data;

• an agent-based command-and-control layer (blue) to allow fire responders to interact with data, computing resources and the Grid to perform high-level decision-making;

• an HPC resource layer (red) for deploying computational models.

These three layers are connected together by Grid middleware (coloured green).

Left: image from a pre-test simulation performed by ANSYS.

Below: the FireGrid interface.

Page 10: Tackling the challenges of multicore. - EPCC · 2017-10-20 · Issue 65, summer 2009 The newsletter of ePCC: the high-performance computing centre at the university of edinburgh

10 11

The challenge of multicore

Gridipedia – the European online repository of Grid tools and information – preserves and makes accessible a whole range of resources on Grid computing and related technologies such as cloud computing and virtualization. Originally populated with results from the BEinGRID research project, it is continuously enriched by commercial organisations and research projects and welcomes contributions.

Gridipedia has expanded massively recently and its contents include case studies, software components, business analysis and legal advice. Unique visitor numbers exceed 2,000 a month and include collaborators using Gridipedia to distribute software and research results.

Gridipedia was initially populated with the results of BEinGRID, which focuses on extracting best practice and common components from a series of pilot implementations of Grid computing in diverse business settings. More recently the site has hosted work by commercial organisations such as case studies from Univa, Sun, Digipede and IBM, as well as other research projects such as BREIN, Akogrimo and TrustCom, and on behalf of open source middleware groups including GRIA and Globus.

In the long term, Gridipedia aims to become the definitive distribution channel for cloud and Grid technologies: where

vendors will meet buyers from the commercial sector; where consultants, suppliers and programmers will exhibit and trade their offerings; and where potential buyers at all levels will find the information and products they require.

Relaunched in May, Gridipedia targets key decision-makers in both business and technical roles who will oversee the implementation of Grid in their businesses or who are looking to further develop their Grid capabilities. It demonstrates the business benefits of Grid technology, for example reduced time to market, new service offerings, reduced costs, improved quality and greater flexibility.

Gridipedia is soliciting contributions from the user community. You can join Gridipedia by contributing to the online “Grid Voices” blog or you can submit your software or article for publication on the site. We look forward to your contributions!

www.gridipedia.eu/

relaunched and expanded: Gridipedia K. Kavoussanakis, EPCC

Multicore technology is becoming ubiquitous, with dual-core processors now commonplace in the laptop and desktop, and processors with four, eight and more cores coming soon. As clock speeds are no longer increasing, the only way for an application to benefit from these new processors is by re-engineering it to run on more than one core. Parallel programming, once the preserve of high-end supercomputing, is now an essential tool for almost every software developer.

EPCC is running a three-day multicore training event, supported by the e-Science Institute. The first day will introduce the basic concepts of multicore processors and the associated issues for multicore software. It will be useful to anyone involved with IT provision or software development, but does not assume any in-depth programming knowledge. The following two days will cover how to write parallel software for multicore processors, mainly focusing on the OpenMP

programming model. The ability to program in C, C++ or Fortran is a pre-requisite for this latter part of the course.

The course will be heavily based on practical sessions, with hands-on exercises accompanying the lectures. Anyone in possession of a multicore laptop will be encouraged to do the exercises on their own machine, assuming that appropriate compilers are available (we will provide advice on this in advance). We will also provide access to our own multicore machines. Although the programming techniques taught are applicable to a wide range of software, we will concentrate on applications that are very compute-intensive such as large-scale numerical calculations or data processing.

More details and a registration form: www.epcc.ed.ac.uk/training-education/.

It is possible to register for the whole event, or just for the first day.

muLTICOre TrAINING eveNT

exploiting multicore Processors: Challenges and Programming models 8–10 september 2009, edinburgh

David Henty

Page 11: Tackling the challenges of multicore. - EPCC · 2017-10-20 · Issue 65, summer 2009 The newsletter of ePCC: the high-performance computing centre at the university of edinburgh

10 11

The challenge of multicore

BEinGRID was set up to explore the requirements of business users of Grid technology and improve the middleware available to them. As part of the project, EPCC has developed components in the area of Data Management. The goal with these components has been to enhance the OGSA-DAI middleware to better meet the needs of business users.

The OGSA-DAI Trigger is one of these components. It allows an OGSA-DAI workflow, a configurable series of data access and manipulation operations, to be executed in response to changes in a database. A part of the component integrates with the database and whenever the target table is modified, a notification is sent to an OGSA-DAI server which executes the workflow. It currently has support for MySQL, SQL Server, DB2 and Informix. The workflow is also stored on the OGSA-DAI server and can be executed multiple times, once for each notification sent from the database.

Without the Trigger, OGSA-DAI ocurrently only supports submission of a workflow for immediate processing, so this component adds an important extra feature. The component can be configured to send selected columns of the database as input to a workflow and any of OGSA-DAI’s data access and integration tools can be used to transform the information.

In addition to the OGSA-DAI Trigger, EPCC has also developed a Data Source Publisher component which is a GUI tool for publishing data using OGSA-DAI. It deploys OGSA-DAI (and the middleware it depends upon) using a few simple mouse clicks. It provides a simple way for new users to get their first OGSA-DAI system up and running.

Issue 63 of EPCC News introduced the GRID2 (B2B) experiment which forms another part of BEinGRID. This experiment uses the OGSA-DAI Trigger as a core part of their solution to the problem of low cost integration and automation of data transfer in a business-to-business (B2B) network. The Trigger allows information to be automatically transferred between members of a B2B network and directly interfaces with their existing databases. A modified version of the Data Source Publisher is used to rapidly deploy the GRID2 (B2B) solution on the machines in the network.

More information on the OGSA-DAI Trigger, Data Source Publisher and GRID2 (B2B) can be found on Gridipedia:

www.gridipedia.eu/ogsa-daitrigger.html www.gridipedia.eu/ogsa-daidatapublisher.html www.beingrid.eu/be24.html

Data management in BeinGrID Craig Thomson

Above: In addition to the OGSA-DAI Trigger, EPCC has also developed a Data Source Publisher component, which is a GUI tool for publishing data using OGSA-DAI. It deploys OGSA-DAI (and the middleware it depends upon) using a few simple mouse clicks. It provides a simple way for new users to get their first OGSA-DAI system up and running.

Right: Some of the BEinGRID team at EPCC.

Page 12: Tackling the challenges of multicore. - EPCC · 2017-10-20 · Issue 65, summer 2009 The newsletter of ePCC: the high-performance computing centre at the university of edinburgh

12 13

The challenge of multicore

An Alarms service for monitoring federated networks Charaka Palansuriya

Left: The current status of the LHCOPN network.

Below: Alarms Service web interface.

npmALARMS

EPCC has developed an Alarms Service capable of monitoring federated networks and raising alerts based on predefined conditions. The service allows timely detection and trouble-shooting of networking problems, reducing the likelihood of users encountering the problems or symptoms of the problems. It is envisaged that the service will allow better operation of a federated network as well as enabling utilisation of staff in a more effective way.

We have been involved in network monitoring projects for over 5 years. The work previously focused on providing access to federated network monitoring data, making use of standards developed by the OGF Network Monitoring Working Group (NM-WG). During the course of this work it became clear that there was a strong requirement for alarms to be raised based on the network status. Grid and network operators need access to network monitoring data to diagnose problems in the network, but more importantly they need alarms to notify them of such problems in a timely fashion. Therefore, we have developed this Alarms Service to monitor federated networks and to raise alerts when problems arise.

The requirements for the Alarms Service have been largely gathered from members of the Large Hadron Collider Optical Private Network (LHCOPN)1. Indeed, LHCOPN will be the first user of our Alarms Service (LHCOPN is the fast private network that distributes data from LHC based experiments at CERN to major sites around the world). The requirements revealed the most essential alarms to be:

• Routing Alarm: if the path changes and there are no links down between the source and destination.

• Routing Out of the Network Alarm: if the path changes and one of the hops is outside of the preferred (federated) network.

• Interface Errors Alarm: if the number of interface errors on a router interface is greater than a threshold.

• Interface Congestion Alarm: if a router interface drops packets at a rate above a threshold, whilst the link utilisation is below another threshold.

Page 13: Tackling the challenges of multicore. - EPCC · 2017-10-20 · Issue 65, summer 2009 The newsletter of ePCC: the high-performance computing centre at the university of edinburgh

12 13

The challenge of multicore

Large Hadron Collider: ATLAS beam pipe installation.

The Alarms Service is implemented as a standalone Java application. It obtains network measurement data from certain types of perfSONAR2 Measurement Archives (MAs), analyses them and provides alarm notifications according to a set of user-defined conditions. The service has multiple notifications mechanisms and one of them is a web-based status overview.

Benefits of the Alarms Service

• Gives notice of network problems as soon as they occur.

• Prompt detection and notification allows timely trouble-shooting.

• Provides multiple notification interfaces. The current version supports web-based and email notifications.

• Provides a user-configurable, alarms-definition framework based on rules.

At present we have released an early version of the Alarms Service and this has been deployed by DANTE3 to monitor the first few major LHCOPN sites that currently supply data. The plan is that more sites, including CERN, will be added to the service as and when data become available.

We are now looking for other suitable users who may benefit from using the Alarms Service. We are currently engaging with the networking task of DEISA24 to gather their requirements and to advise them. In fact, the work is being carried forward within DEISA2 to deploy and configure an Alarms Service instance to monitor the DEISA federated network to allow a technical evaluation. If you would like to find out more about the Alarms Service or would like to use the software to monitor your network then please e-mail: [email protected]

Technical aspects of the service were presented at the Fifth International Conference on Networking and Services (ICNS 2009) held during 20–25 April 2009 in Valencia, Spain. Another technical presentation is planned for this year’s Terena Networking Conference (TNC 2009) to be held on 8–11 June 2009, Málaga, Spain.

Acknowledgement

The Alarms Service work is funded by the UK Joint Information Systems Committee (JISC) and the European Union under project DEISA2 (RI–222919).

1 https://twiki.cern.ch/twiki/bin/view/LHCOPN/WebHome2 http://www.perfsonar.net/3 http://www.dante.net/4 http://www.deisa.eu/

Page 14: Tackling the challenges of multicore. - EPCC · 2017-10-20 · Issue 65, summer 2009 The newsletter of ePCC: the high-performance computing centre at the university of edinburgh

Following the success of HPC-Europa and HPC-Europa++ over the last 5 years, the HPC-Europa2 project has been funded for 4 years, starting on 1st January 2009. The core activity of HPC-Europa2 is its Transnational Access research visit programme, which is enhanced by the complementary Networking Activities and Joint Research Activities.

Many readers of EPCC News will already be familiar with the HPC-Europa visitor programme, which funds collaborative visits for researchers based in Europe who require access to powerful HPC facilities.

The HPC-Europa2 programme offers computational scientists in the UK two possible ways to collaborate with European researchers in a similar field:

• As visitors, researchers in the UK can receive funding to go to a relevant research group in Finland, France, Germany, Italy, the Netherlands or Spain for up to 3 months (the average visit length is 6 weeks);

• As hosts, UK researchers can bring members of another group based in any eligible European country1 to work with them, with minimal bureaucracy required, as HPC-Europa2 provides the logistical and administrative support.

A brand new feature of HPC-Europa2 is the “virtual visit”, for people who wish to use the HPC facilities remotely, without travelling to another country. Scientific collaboration remains a

key criterion for HPC-Europa2 funding, so a “virtual visit” must still involve joint work with a research group in the country where the HPC facility is located. For this reason, “virtual visits” are most likely to be suited to researchers who have an existing collaboration with a suitable group, perhaps as the result of a previous visit.

Other new features of HPC-Europa2 include:

• New participating centres – CSC has joined the consortium, so visitors may now apply to research groups in Finland, and GENCI-CINES has replaced IDRIS as the French partner;

• More computing time – an average of at least 75 000 Allocation Units (AU) are available per visitor;

• New eligible countries – researchers in Albania, Bosnia-Herzegovina, Croatia, FYR Macedonia, Montenegro and Serbia are now eligible to participate.

The programme is open to researchers of postgraduate level and above, in any discipline which requires access to HPC facilities.

The next deadline for applications is 31st August 2009.

For full details and the on-line application form, see: www.hpc-europa.eu

1. Full list of eligible countries: www.hpc-europa.eu/?q=node/25

Members of the HPC-Europa consortium and Scientific Users Selection Panel outside HLRS, Stuttgart.

Transnational Access: new twists on a successful formatCatherine Inglis

HPC-europa2: continuing to build european relationships

The challenge of multicore

14

Page 15: Tackling the challenges of multicore. - EPCC · 2017-10-20 · Issue 65, summer 2009 The newsletter of ePCC: the high-performance computing centre at the university of edinburgh

Networking Activities and Joint research Activities: supporting our visitors Judy Hardy and Chris Johnson

The HPC-Europa2 Networking Activities will offer enhanced support for our Transnational Access visitors through the provision of consultancy and training activities, together with support for collaborative tools for virtual meetings, seminars, workshops etc. We will also continue to offer our popular “virtual” seminars and workshops on current and emerging areas in HPC and computational science. In addition, visitors will have access to a dedicated website with online resources such as study notes and practical exercises on a range of HPC topics, which they can use for self-study both before and during their research visit.

We are also participating in three Joint Research Activities (JRAs). The first of these is entitled “HPC on Massively Parallel Architectures: Programming models”. This activity explores the ways in which we may efficiently utilize the massive numbers of processing cores to be found on modern HPC systems. With the increasing power of Cell or Graphics Processing Unit (GPU) processors we are experiencing a time when computing cycles are relatively cheap but memory bandwidth per component is comparably low. Here we are looking at the various mixed-mode models of programming – mixing distributed and shared memory models within the same codes – which will endeavour to utilize this hardware to its full potential.

The second JRA involves the creation of a “Virtual Cluster” giving our HPC-Europa2 visitors the ability to run an entire parallel-programming environment from a CD or memory stick where they can simulate the compiling and running of parallel codes before even accessing a true HPC system.

As HPC systems become ever larger so do the data-sets produced. The third JRA, “Tools for Scientific Data Services”, is looking at data storage systems and methods of describing data (eg using meta-data) applied to real-life applications. The activity has begun with an evaluation of available data-management technologies, one of which will then be chosen to use with real data.

Visitors and staff participate in an HPC-Europa virtual

seminar via AccessGrid.

HPC-Europa partner centres

The challenge of multicore

15

Page 16: Tackling the challenges of multicore. - EPCC · 2017-10-20 · Issue 65, summer 2009 The newsletter of ePCC: the high-performance computing centre at the university of edinburgh

The OGSA-DAI project has been funded by EPSRC for an additional year, until April 2010. This funding will enable us to evolve OGSA-DAI from an open source product into an open source project.

Over the lifetime of the project, an international community of users and developers has formed around OGSA-DAI, our unique open source product for access to and integration of distributed heterogeneous data resources. This includes projects and institutions in a myriad of fields including medical research, environmental science, geo-sciences, the arts and humanities and business.

Moving to an open source project will provide this community with a focal point for the evolution, development, use and support of both OGSA-DAI and its related components, providing a means by which members of the community can develop and release their components alongside the core product. It will also provide the community with an avenue to ensure the sustainability of their components.

Over the next few months we will set in place the governance and infrastructure of the OGSA-DAI open source project. This will be done in conjunction with key community members, and will draw upon the expertise of our OMII-UK partners in Manchester and Southampton and in the Globus Alliance. We aim to roll out our open source project site in October.

Our move to an open source project contributes to OMII-UK’s vision to promote software sustainability, and will guarantee that the lifetime of the OGSA-DAI product will exist outwith any single institution or funding stream.

In addition, we will continue to develop the product and engage with international standardisation activities:

Work on distributed query processing will continue, looking at more powerful distributed relational queries and integrating work on relational-XML queries produced by Japan’s AIST.

A comprehensive review of performance, scalability and robustness will be undertaken, so allowing us to identify key areas for redesign.

New components for security, data delivery via GridFTP and access to indexed and SAGA file resources will be released.

A new version of OGSA-DAI, with many improvements including refactored APIs and exploiting Java 1.6, will be released.

We will participate in inter-operability testing with the OGF DAIS working group, a vital part in the evolution of the WS-DAI specifications into standards.

The OGSA-DAI project—-which involves both EPCC and the National e-Science Centre—-is funded by EPSRC through OMII-UK. OMII-UK is an open source organisation that provides software and consultancy to the UK e-Science community.

OGSA-DAI: [email protected], www.ogsadai.org.uk

OMII-UK: [email protected], www.omii.ac.uk

OGsA-DAI: from open source product to open source project Mike Jackson

EPCC is a European centre of expertise in developing high performance, novel computing solutions; managing advanced systems and providing HPC training. Our clients and partners include local and global industry, government institutions and academia.

EPCC’s combination of advanced computing resources and expertise is unique and unmatched by any European university.

www.epcc.ed.ac.uk [email protected]