More Scalability, Less Pain:  A Simple Programming Model and Its Implementation for Extreme Computing 

 Ewing L. Lusk Steven C. Pieper Ralph M. Butler 

 Outline:  

I. Introduction a. Fear that larger machines require more complicated programs or new 

languages b. Purpose of this paper is to show that by giving up some generality, a library 

can provide scalable performance by simplifying the programming model c. Will use case study of significant physics application (SciDAC, INCITE, ALCF 

resources) d. Text version of outline 

II. Nuclear Physics a. What we try to calculate and why b. How GFMC calculates this c. GFMC achievements before ADLB  d. Why we want 12C (Hoyle state, origin of life, etc. story) and why we need 

more than 2000 processes to do it. III. Programming Models 

a. What is a programming model b. MPI, OpenMP, others c. Master/slave algorithms 

i. In MPI (old GFMC) ii. With ADLB 

IV. ADLB a. Design:  master/slave with knobs on, illusion of shared memory b. The API c. Implementation 

i. Clients and servers ii. The status vector iii. Pushing iv. Usage of advanced features of MPI 

V. The Story a. Multiple levels of scalability (cpu load, memory load, message load) b. The picture of progress over time c. Hybrid programming with OpenMP and MPI d. Physics results (most accurate ground state of 12C) e. Future plans 

i. Use of one‐sided ii. Need for more memory per MPI process (UPC?) 

VI. Results a. The physics calculations enabled by ADLB 

VII. Conclusion a. Can get scalability without increased complexity in application b. May require advanced MPI features in Library 

c. Vendors need to support good MPI implementation practice d. Hybrid programming useful   

 Abstract 

 A critical issue for the future of high‐performance computing is the programming model to use on next‐generation architectures.  Here we describe an approach to programming very large machines that combines simplifying the programming model with a scalable library implementation that we find promising.  Our presentation takes the form of a case study in nuclear physics.  The chosen application addresses fundamental issues in the origins of our universe, while the library developed to enable this application on the largest computers may have applications beyond this one.  The work here relies heavily on DOE’s SciDAC program for funding both the physics and computer science work and its INCITE program to provide the computer time to obtain the results.  1.  Introduction 

Currently the largest computers in the world have more than a hundred thousand individual processors, and those with a million are on the near horizon.  A wide variety of scientific applications are poised to utilize such processing power.  There is widespread concern that our current dominant approach for specifying parallel algorithms, the message passing model and its standard instantiation in MPI (the Message Passing Interface) will become inadequate in the new regime.  The concern stems from an anticipation that entirely new programming models and new parallel programming languages will be necessary, stalling application development while entirely new applications codes are built from scratch.  If this were true, not only would millions of lines of thoroughly tested and tuned lines of code have to be discarded, but, even worse, a new and possibly more complicated approach to application development would have to be undertaken  It is more likely that less radical approaches will be found; we explore one of them in this paper. 

No doubt many applications will have to undergo significant change as we enter the exascale regime, and some will be rewritten entirely.  New approaches to defining and expressing parallelism will no doubt play an important role.  But is not inevitable that the only way forward is through significant upheaval.  It is the purpose of this paper to demonstrate that it is possible for an application to actually become simpler as it becomes more scalable.  The key is to adopt a programming model that may be less general than message passing while still being useful for a significant family of applications.  If this programming model is then implemented in a scalable way, which may be no small feat, then the application may be able to reuse most of its highly tuned code, simplify the way it handles parallelism, and still scale to hundreds of thousands of processors. 

In this article we present a case study from nuclear physics.  Physicists from Argonne National laboratory have developed a code called GFMC (for Green’s Function Monte Carlo).  This is mature code with origins many years ago, but recently needed to make the leap to greater scale (in numbers of processors) than before, in order to carry out nuclear theory computations for 12C, the most important isotope of the element carbon.  12C was a specific target of the SciDAC UNEDF project (Universal Nuclear Energy Density Functional) (see www.unedf.org), which funded the work described here in both the Physics Division and the Mathematics and Computer Science Division at Argonne National Laboratory.  Computer time for the calculations described here was provided by the DOE INCITE program and the 

large computations were carried out on the IBM Blue Gene P at the Argonne Leadership Computing Facility.  Significant program development was done on a 5,182‐processor SiCortex in the Mathematics and Computer Science Division at Argonne. 

In Section 2 we describe the physics background and our scientific motivation.  Section 3 discusses relevant programming models and introduces ADLB (Asynchronous Dynamic Load Balancing) a library that instantiates the classic manager/worker programming model.  Implementing ADLB is a challenge, since the manager worker model itself seems intuitively non‐scalable.  We describe ADLB and its implementation in Section 4.  Section 5 tells the story of how we needed to overcome successively different obstacles as we crossed various scalability thresholds.  Here we also describe the physics results, consisting of the most accurate calculations of the binding energy for the ground state of 12C, and the computer science results (scalability of ADLB to 132,00 processes.  In Section 6 we describe the physics results obtained with our new approach, and in Section 7 summarize our conclusions. 

2.  Nuclear Physics A major goal in nuclear physics is to understand how nuclear binding, stability, and 

structure arise from the underlying interactions between individual nucleons. We want to compute the properties of an A‐nucleon system [It is conventional to use A for the number of nucleons (protons and neutrons) and Z for the number of protons] as an A‐body problem with free‐space interactions that describe nucleon‐nucleon (NN) scattering. It has long been known that calculations with just realistic NN potentials fail to reproduce the binding energies of nuclei; three‐nucleon (NNN) potentials are also required. Reliable ab initio results from such a nucleon‐based model will provide a baseline against which to gauge effects of quark and other degrees of freedom. This approach will also allow the accurate calculation of nuclear matrix elements needed for some tests (such as double beta decay) of the standard model, and of nuclei and processes not presently accessible in the laboratory. This can be useful for astrophysical studies and for comparisons to future radioactive beam experiments. To achieve this goal, we must both determine the Hamiltonians to be used, and devise reliable methods for many‐body calculations using them. Presently, we have to rely on phenomenological models for the nuclear interaction, because a quantitative understanding of the nuclear force based on quantum chromodynamics is still far in the future. 

In order to make statements about the correctness of a given phenomenological Hamiltonian, one must be able to make calculations whose results reflect the properties of the Hamiltonian and are not obscured by approximations. Because the Hamiltonian is still unknown, the correctness of the calculations cannot be determined from comparison with experiment. Instead internal consistency and convergence checks that indicate the precision of the computed results are used. In the last decade there has been much progress in several approaches to the nuclear many‐body problem for light nuclei; the quantum Monte Carlo method used here consists of two stages, variational Monte Carlo (VMC) to prepare an approximate starting wave function (ΨT) and  Green's function Monte Carlo (GFMC) which improves it. 

The first application of Monte Carlo methods to nuclei interacting with realistic potentials was a VMC calculation by Pandharipande and collaborators[1], who computed upper bounds to the binding energies of 3H and 4He in 1981. Six years later, Carlson [2] improved on the VMC results by using GFMC), obtaining essentially exact results (within Monte Carlo statistical errors of 1%). Reliable calculations of light p‐shell (A=6 to 8) nuclei started to become available in the mid 1990s and are reviewed in[3]; the most recent 

results for A=10 nuclei can be found in Ref. [4].  The current frontier for GFMC calculations is A=10, specifically 12C. The increasing size of the nucleus computable has been a result of both the increasing size of available computers and significant improvements in the algorithms used.  We will concentrate here on the developments that enable the IBM Blue Gene/P to be used for 12C calculations. 

As is stated in the nuclear science exascale workshop [5], reliable 12C calculations will be the first step towards “precise calculations of 2α(α, γ)12C and 12C(α,γ)16O rates for stellar burning (see Fig 1); these reactions are critical building blocks to life, and their importance is highlighted by the fact that a quantitative understanding of them is a 2010 U.S. Department of Energy (DOE) milestone [6].  The thermonuclear reaction rates of alpha‐capture on 8Be (2α‐resonance) and 12C during the stellar helium burning determine the carbon‐to‐oxygen ratio with broad consequences for the production of all elements made in subsequent burning stages of carbon, neon, oxygen, and silicon.  These rates also determine the sizes of the iron cores formed in Type II supernovae [7,8], and thus the ultimate fate of the collapsed remnant into either a neutron star or a black hole.  Therefore, the ability to accurately model stellar evolution and nucleosynthesis is highly dependent on a detailed knowledge of these two reactions, which is currently far from sufficient. ... Presently, all realistic theoretical models fail to describe the alpha‐cluster states, and no fundamental theory of these reactions exists. ... The first phase focuses on the Hoyle state in 12C.  This is an alpha‐cluster‐dominated, 0+ excited state lying just above the 8Be+α threshold that is responsible for the dramatic speedup in the 12C production rate.  This calculation will be the first exact description of an alpha‐cluster state.”  We are intending to do this by GFMC calculations on BG/P. 

 

 

 

 

 

 

 

 

 

 

 

 

 

Figure 1.   A schematic view of the 12C and 16O production by alpha burning.   The 8Be+a reaction  proceeds  dominantly  through  the  7.65  MeV  triple‐alpha  resonance  in  12C  (the Hoyle  state).   Both sub‐ and above‐threshold  16O resonances play a  role  in  the  12C(a,g)16O capture  reaction.    Image  courtesy  of  Commonwealth  Scientific  and  Industrial  Research Organisation (CSIRO).   

 

          Figure 1. A schematic view of the 12C and 16O production by alpha burning. The 8Be+α reaction proceeds dominantly through the 7.65 MeV triple-alpha resonance in 12C (the Hoyle state). Both sub- and above-threshold 16O resonances play a role in the 12C(α,γ)16O capture reaction.

2α(α ,γ)12C 12C(α ,γ)16O

The first, VMC, step in our method finds an upper bound, ET, to an eigenvalue of the Hamiltonian, H, by evaluating the expectation value of H using a trial wave function, ΨT. The form of ΨT is based on our physical intuition and it contains parameters are varied to minimize ET. Over the years, rather sophisticated ΨT for light nuclei have been developed[3]. The ΨT are vectors in the spin‐isospin space of the A nucleons, each component of which is a complex‐valued function of the positions of all A nucleons. The nucleon spins can be +1/2 or ‐1/2 and all 2A combinations are possible. The total charge is conserved, so the number of isospin combinations is no more than the binomial coefficient 

( ). The total numbers of components in the vectors are 16, 160, 1792, 21,504, and 267,168 for 4He, 6Li, 8Be, 10B, and 12C, respectively.  It is this rapid growth that limits the QMC method to light nuclei. 

The second, GFMC, step projects out the lowest-energy eigenstate from the VMC ΨT by using[3]

Ψ0 = Ψ(τ) = exp[-(H-E0)τ] ΨT . In practice, τ is increased until the results are converged within Monte Carlo statistical 

fluctuations. The evaluation of exp[‐(H‐E0)τ] is made by introducing a small time step, Δτ=τ /n (typically Δτ = 0.5 GeV‐1), 

Ψ(τ) = {exp[-(H-E0) Δτ] }n ΨT = Gn ΨT ;

where G is called the short‐time Green's function. This results in a multidimensional integral over 3An (typically more than 10,000) dimensions, which is done by Monte Carlo. Various tests indicate that the GFMC calculations of p‐shell binding energies have errors of 1‐2%.  The stepping of τ is referred to as propagation.  As Monte Carlo samples are propagated, they can wander into regions of low importance; they will then be discarded.  Or they can find areas of large importance and will then be multiplied.  This means that the number of samples being computed fluctuates during the calculation.   

Because of the rapid growth of the computation needs with the size of the nucleus, we have always used the largest computers available.  The GFMC program was written in the mid‐90's using MPI and the A=6,7 calculations were made on Argonne's 256‐processor IBM SP1.  In 2001 the program achieved a sustained speedup of 1886 using 2048 processors on NERSC's IBM SP/4 (Seaborg); this enabled calculations up to A=10.  The parallel structure developed then was used largely unchanged up to 2008.  The method depended on the complete evaluation of several Monte Carlo samples on each node; because of the discarding or multiplying of samples described above, the work had to be periodically redistributed over the nodes.   For 12C we only want about 15,000 samples so using the many 10,000's of nodes on Argonne's BG/P requires a finer‐grained parallelization in which one sample is computed on many nodes.  The ADLB library was developed to expedite this approach. 

 

3.  Programming Models for Parallel Computing 

Here we give an admittedly simplified overview of the programming model issue for high‐performance computing.  A programming model is the way a programmer thinks about the computer he is programming.  Most familiar is the von Neumann model, in which as single processor fetches both instructions and data from a single memory, executes the 

instructions on the data, storing the results back into the memory.  Execution of computer program consists of looping through this process over and over.  Today’s sophisticated hardware may overlap execution of multiple instructions that today’s sophisticated compilers have found can be executed in parallel safely, but at the level of the programming model only one instruction is executed at a time. 

In parallel programming models, the abstract machine has multiple processors, and the programmer explicitly manages the execution of multiple instructions at the same time.  Two major classes of parallel programming models are shared memory models, in which the multiple processes fetch instructions and data from the same memory, and distributed memory models, in which each processor accesses its own memory space.  Distributed memory models are sometimes referred to as message passing models, since they are like collections of von Neumann models with the additional property that data can be moved from the memory of one processor to that of another through the sending and receiving of messages.   

Programming models can be instantiated by languages or libraries that provide the actual syntax by which programmers write parallel programs to be executed on parallel machines.  In the case of the message‐passing model, the dominant library is MPI (for Message Passing Interface), which has been implemented on all parallel machines.  A number of parallel languages exist for writing programs for the shared‐memory model.  One such is OpenMP, which has both C and Fortran versions. 

We say that a programming model is general if we can express any parallel algorithm with it.  The programming models we have discussed here so far completely general; now we want to explore the advantages of using a programming model that is less than completely general. 

In this paper we will focus on a more specialized, higher‐level programming model.  One of the earliest parallel programming models is the master/slave model, shown in Figure 2.  In master/slave algorithms one process coordinates the work of many others.  The programmer divides the overall work to be done into work units, each of which will be done by a single slave process.  Slaves ask the master for a work unit, complete it, and send the results back to the master, implicitly asking for another work unit to work on.  There is no communication among the slaves.  This is not a completely general model, and is unsuitable for many important parallel algorithms.  Nonetheless, it has certain attractive features.  The most salient is automatic load balancing in the face of widely varying sizes of work unit.  One slave can work on one “shared” unit of work while others work on many work units that require shorter execution time; the master will see to it that all processes are busy as long as there is work to do.  In some cases slaves create new work units, which they communicate to the master so that he can keep them in the work pool for distribution to other slaves as appropriate.  Other complications, such as sequencing certain subsets of work units, managing multiple types of work, or prioritizing work, can all be handled by the master process. 

 

 

 

 Figure 2.  The classical Master/Slave Model.  A single process coordinates load 

balancing. 

The chief drawback to this model is its lack of scalability.  If there are very many slaves, the master can become a communication bottleneck.  Also, if the representation of some work units is large, there may not be enough memory associated with the master process to store all the work units. 

Argonne’s GFMC code described in Section 2 was a well‐behaved code written in master/slave style, using Fortran‐90 and MPI to implement the model.  In order to attack the 12C problem the number of processes would have to increase and the structure of the work units would have to change.  We wished to retain the basic master/slave model but modify it and implement it in a way that it would meet requirements for scalability (since we were targeting Argonne’s 163,840‐core Blue Gene/P, among other machines) and management of complex, large, interrelated work units. 

 

 Figure 3.  Eliminating the master process with ADLB 

The key was to further abstract (and simplify) by eliminating the master process.  In this new model, shown in Figure 3,  “slave” processes access a shared work queue directly, without the step of communicating with an explicit master process.  The make calls to a library to “put” work units in to this work pool and “get” them out to work on.  The library we built to implement this model is called the ADLB (for Asynchronous Dynamic Load Balancing) library.  ADLB hides communication and memory management from the 

application, providing a simple programming interface.  In the next section we describe ADLB in detail and give an overview of its scalable implementation. 

4.  The Asynchronous Dynamic Load Balancing Library 

In this section we describe the ADLB library.  The API (Application Programmer Interface) is simple.  The complete API is shown in Figure 4, but really only three of the function calls provide the essence of its functionality.  The most important functions are shown in orange.  To put a unit of work into the work pool, an application calls ADLB_Put, specifying the work unit by an address in memory and a length in bytes, and assigning a work type and a priority.  To retrieve a unit of work, an application goes through a two‐step process.  It first calls ADLB_Reserve, specifying a list of types it is looking for.  ADLB will find such a work unit if it exists and send back a “handle,” a global identifier, along with the size of the reserved work unit.  (Not all work units, even of the same type, need be of the same size).  This gives the application the opportunity to allocate memory to hold the work unit.  Then it calls ADLB_Get_reserved, passing the handle of the work unit it has reserved and the address where ADLB will store it. 

Figure 4.   The ADLB Application Programming Interface 

When work is created by ADLB_Put, a destination rank can be given, which specifies an application process which alone will be able to reserve this work unit.  This provides a way to rout results to specific process, which may be collecting partial results as part of the application’s algorithm. 

Figure 5 shows how ADLB is implemented.  When an application starts up, after calling MPI_Init, it then calls ADLB_Init, specifying the number of processes in the parallel job to be dedicated as ADLB server processes.  ADLB carves these off for itself and returns the rest in an MPI communicator for the application to use independently of ADLB.  ADLB refers to the application processes as client processes, and each ADLB server communicates with a fixed number of clients.  When a client calls Put, Reserve, and Get_reserved, it triggers communication with its server, which then may communicate with other servers to satisfy the request before communicating back to the client. 

 

 

 Figure 5.  Architecture of ADLB 

The number of servers devoted to ADLB can be varied.  For this application we find a ratio of about one server for every thirty application processes to be about right. 

Key to the functioning of ADLB is that when a process requests work of a given type, ADLB can find it in the system either locally (that is, the server receiving the request has some work of that type) or remotely, on another server.  So that every server knows the status of work available on other servers, a status vector circulates constantly around the ring of servers.  As it passes through each server, the server updates the status vector with the information about the types of work that it is holding, and updates its own information about work on other servers.  The fact that this information can always be (slightly) out of date is what we pay for the scalability of ADLB and contributes to its complexity. 

As the clients of a server create work and deposit it on the server (with ADLB_Put), it is possible for that server to run out of memory.  As this begins to happen, the server, using the information in the status vector, sends work to other servers that have more memory available.  We call this process “pushing work.” 

Thus a significant amount of message passing, both between clients and servers and among servers, is taking place without the application being involved.  The ADLB implementation uses a wide range of MPI functionality in order to obtain performance and scalability. 

5.  Scaling Up – The Story 

As the project started, GFMC was running well on 2048 processes.  The first step in 

scaling up was the conversion of the application code from making its own MPI calls to making ADLB calls.  This was not a huge change, since the abstract master/slave programming model remained the same.  After this, the application did not need to change much at all, since the interface shown in Figure 4 was settled on early in the process and remained fixed.  At one point, as GFMC was applied to larger nuclei, the work units became too big for the memory of a single MPI process, which was limited to one fourth of the memory on a 4‐core BG/P node.  The solution was to run a single multithreaded MPI process on each node of the machine, thus making all of each node’s memory available.  This was accomplished using (the Fortran version of) OpenMP as the approach to shared‐memory parallelism within a single address space. 

The BG/P nodes have four cores and 2 Gbytes of memory.  If each core is used as a separate MPI/ADLB task, only 500 Mbytes is available to the tasks; this is not enough for the 12C calculation.  Thus independently of the changes to use ADLB, we had to introduce multithreading in the computationally intensive subroutines of the GFMC program.  In this “hybrid programming model” each BG/P node is one MPI/ADLB task with the full 2 Gbytes of memory.  We used OpenMP to access the four cores and were pleased at how easy this was to.  In most cases we just had to add a few PARALLEL DO directives.  In some cases this could not be done because different iterations of the DO loop accumulate into the same array element.  In these cases an extra dimension was added to the result array so that each thread could accumulate into its own copy of the array.  At the end of the loop, these four copies are added together.  OpenMP on BG/P proved to be very efficient for us; using four thread (cores) results in a speed up of about 3.8 compared to using just one thread (95% efficiency). 

Meanwhile the ADLB implementation had to evolve to be able to handle more and more client processes.  One can think of this evolution over time (shown in Figure 6) as dealing with multiple types of load balancing.  At first the focus was on balancing the CPU load, the traditional target of master/slave algorithms.  Next it was necessary to balance the memory load, first by pushing work from one server to another when the first server approached its memory limit, but eventually more proactively, to keep memory usage balanced across the servers incrementally as work was created. 

 

Figure X.  Scalability Evolving Over Time. 

 

The last hurdle was balancing the message traffic.  Beyond 10,000 processors, the unevenness in the pattern of message traffic caused certain servers to accumulate huge queues of unprocessed messages, making parts of the system unresponsive for large periods of time and thus holding down overall scalability.  This problem was address by delaying messages to busy servers, not reducing the total amount of message traffic but evening out its flow. 

Although current performance and scalability are now satisfactory for production runs on the excited states of 12C, challenges remain as one looks toward the next generation of machines and more complex nuclei such as 16O.  New approaches to ADLB implementation may be needed.  But because of the fixed application program interface for ADLB, the GFMC application itself may not have to undergo major modification.  Two approaches are being explored.  The first is the use of the MPI one‐sided operations, which will enable a significant reduction in the number of servers as the client processes take on the job of storing work units instead of putting them on the servers.  The second approach, motivated by the potential need for more memory per work unit than is available on a single node, is to find a way to create shared address spaces across multiple nodes.  A likely candidate for this approach is one of the PGAS languages, such as UPC (Unified Parallel C) or Co‐Array Fortran. 

 

 

5.  Results 

Prior to this work, we had made a few calculations of the 12C ground state using the old GFMC program and just hundreds of processors. These were necessarily simplified calculations with significant approximations that made the final result of questionable value.  Even so they had to be made as sequences of many runs over periods of several weeks.  The combination of BG/P and the ADLB version of the program has completely changed this.  We first made one very large calculation of the 12C ground state using our best interaction model and none of the previously necessary approximations.  This calculation was made with an extra large number of Monte Carlo samples to allow various tests of convergence of several aspects of the GFMC method.  These tests showed that our standard GFMC calculational parameters for lighter nuclei were also good for 12C. 

The results of the calculation were also very encouraging from a physics viewpoint.  The computed binding energy of 12C is 93.2 MeV with a Monte Carlo statistical error 0f 0.6 MeV.  Based on the convergence tests and our experience with GFMC, we estimate the systematic errors at approximately 1 MeV.  Thus this result is in excellent agreement with the experimental binding energy of 92.16 MeV.  The computed density profile is shown in Figure 7.  The red dots show the GFMC calculation while the black curve is the experimental result.  Again there is very good agreement. 

We can now do full 12C calculations on 8192 BG/P nodes in two 10‐hour runs; in fact we often have useful results from just the first run.  This is enabling us to make the many tests necessary for the development of the novel trial wave function needed to compute the Hoyle state.  It will also allow us to compute other interesting 12C states and properties in the next year. An example is the first 2+ excited state and its decay to the ground state; this decay has proven to be a problem for other methods to compute. 

As shown in Figure 6, we are now getting good efficiency on large runs up to 131,072 processors on BG/P  Efficiency is defined as the ratio of the tie spent in the application processes (“Fortran time”) divided by the product of the wall clock time and the number of processors being used. 

 

7.  Conclusion 

The research challenge for the area of programming models for high‐performance computing is to find a programming model that  

1. Is sufficiently general that any parallel algorithm can be expressed, 

2. Provides access to the performance and scalability of HPC hardware, and  

3. Is convenient to use in application code. 

It has proven difficult to achieve all three.  This project as explored what can be accomplished by weakening requirement 1.  ADLB is only for master/slave algorithms.  But within this limitation, it provides high‐performance in a portable way on large‐scale machines while simultaneously simplifying the application code.  Other applications of ADLB are currently being explored. 

 

References 

[1] J. Lomnitz-Adler, V. R. Pandharipande, and R. A. Smith, Nucl. Phys. A361, 399 (1981) [2] J. Carlson, Phys. Rev. C 36, 2026 (1987). [3] S. C. Pieper and R. B. Wiringa, Annu. Rev. Nucl. Part. Sci. 51, 53 (2001), and references

therein. [4] S. C. Pieper, K. Varga, and R. B. Wiringa. Phys. Rev. C 66, 034611 (2002).

    [5]  Scientific  Grand  Challenges:  Forefront Questions  in Nuclear  Science  and  the Role  of High Performance Computing (Report from the Workshop Held January 26‐28, 2009) 

[6] Report to the Nuclear Science Advisory Committee, submitted by the Subcommittee on Performance Measures, http://www.sc.doe.gov/np/nsac/docs/PerfMeasEvalFinal.pdf

    [7] G.E. Brown, A. Heger, N. Langer, C‐H Lee, S. Wellstein, and H.A. Bethe.  2001.  “Formation of High Mass X‐ray Black Hole Binaries.”  New Astronomy 6 (7): 457‐470 (2001). 

    [8] S.E. Woosley, A. Heger, and T.A. Weaver.  2002.  “The Evolution and Explosion of Massive Stars.” 

 

Fig 7.  The computed (red dots) and experimental (black curve) density of the 12C nucleus. 

 

 

 

 

 

 

 

Sidebar:  A Parallel Sudoku Solver with ADLB 

As a way of illustrating ho ADLB can be used to express large amounts of parallelism in a compact and simple way, we describe a parallel program to solve the popular game of Sudoku.  A typical Sudoku puzzle is illustrated on the left side of Figure X.  The challenge is to fill in the small boxes so that each of the digits from 1 to 9 appears exactly once in each row, column, and 3x3 box.  The ADLB approach to solving the puzzle on a parallel computer is shown on the right side of Figure X.  The work units to be managed by ADLB are partially completed puzzles, or Sudoku “boards.”  We start by having one process put the original board in the work pool.  The all processes proceed to take a board out of the pool and find the first empty square.  For each apparently valid value (which they determine by a quick look at the other values in the row, column, and box of the empty square) they create a new board by filling in the empty square with the value and put the resulting board back in the pool.  Then they get a new board out of the pool and repeat the process until the solution is found.  The process is illustrated in Figure 9. 

At the beginning of this process the size of the work pool grows very fast as one board is taken out and replaces with several.  But as time goes by, more and more boards are taken out and not replaced at all since there are no valid values to put in the first empty square.  Eventually a solution will be found or ADLB will detect that the work pool is empty, in which case there is no solution. 

Progress toward the solution can be accelerated by using ADLB’s ability to assign priorities to work units.  If we assign a higher priority to boards with a greater number of squares filled in, then the bad guesses are weeded out faster. 

A human Sudoku puzzle solver uses a more intelligent algorithm than this one, relying on deduction rather than guessing.  We can add deduction to our ADLB program, further speeding it up, by inserting an arbitrary amount of reasoning‐based filling‐in of squares just before the “find first blank square” step in Figure 8, where “ooh” stands for “optional optimization here”.  Ten thousand by ten thousand Sudoku, anyone? 

 

Figure 8.  Sudoku puzzle and a program to solve it with ADLB   

 

 

Figure 9.  The Sudoku Solution algorithm