|CCL HomeSoftware Community Operations||
Recent News in the CCL
Discovering chemistry with an ab initio nanoreactor.
Lee-Ping Wang, Alexey Titov, Robbert McGibbon, Fang Liu, Vijay Pande, and Todd J. Martinez.
Nature Chemistry (2014) doi:10.1038/nchem.2099
The paper demonstrates the "nanoreactor" technique in which simple molecules are simulated over a long time scale to observe their reaction paths into more complex molecules. For example, the picture below shows 39 Acetylene molecules merging into a variety of hydrocarbons over the course of 500ps simulated time. This technique can be used to computationally predict reaction networks in historical or inaccessible environments, such as the early Earth or the upper atmosphere.
To compute the final reaction network for this figure, the team used the Work Queue framework to harness over 300K node-hours of CPU time on the Blue Waters supercomputer at NCSA.
Credit: Lee-Ping Wang, Stanford University
Mon, 17 Nov 2014 20:18:00 +0000
One such project is a Virtual Wind Tunnel, which was created in collaboration with the Notre Dame Civil Engineering Department, as part of a larger project to explore collaboration in civil design. On the surface, this is a fairly simple idea. A user uploads a building shape for analysis to a web portal. Then, the user can run wind flow simulations upon horizontal cross sections of the building. Once complete, the results of these simulations can be viewed and downloaded.
Making all of this work, however, requires a large number of interlocking components. For now, I would just like to describe how the CCL tools play a role in this system. When simulations are to be run, one very simple way to deliver simulation tasks to available computing resources is to run a Work Queue worker on those machines. The front-end of the system runs a Work Queue master, which queues up tasks.
By using Work Queue as a means of distributing tasks, we can be more flexible about the backend upon which those tasks are run. This allows us to tailor our resource usage to our actual needs and, as needed, to adjust our resource usage when appropriate. Mon, 01 Sep 2014 18:21:00 +0000
This database design is implemented within CCTools in two parts. Part 1 (data storage) has been available for over a year and is called the catalog server. Part 2 (data analysis) has recently been implemented and is not yet in a release, but is available in the following commit:
The data model is designed to handle schema-free status reports from various services. And while the reports can be schema-free, most of the fields will normally remain the same between subsequent reports from the same instance of a service.
The first status report is saved in it's entirety, and then the subsequent reports are saved as changes (or "deltas") on the original report. Snapshots of the status of all services and instances are stored on a daily basis. This allows a query for analysis based on a given time frame to jump more quickly to the start of the time frame, rather than have to start at the very beginning of the life of the catalog server.
A query is performed by applying a series of operators to the data. For a distributed system, spatial distribution is when the data is distributed such that a given instance always ends up on the same node. In this situation, all but the last of the operators can be performed in the map stage of the MapReduce model. This allows for better scalability because less work has to be performed by a single node in the reduce stage.
Much more detail is provided in a paper which was published at IEEE Bigdata 2014, and is available at the following URL:
For further inquiries, please email firstname.lastname@example.org.
Mon, 18 Aug 2014 18:21:00 +0000
CCTools 4.2.0 includes a new feature in Parrot that allows you to automatically observe all of the files used by a given application, and then collect them up into a self-contained package. The package can then be moved to another machine -- even a different variant of Linux -- and then run correctly with all of its dependencies present. The created package does not depend upon Parrot and can be re-run in a variety of ways.
This article explains how to generate a self-contained package and then share it so that others can verify can repeat your applications. The whole process involves three steps: running the original application, creating the self-contained package, and the running the package itself.
Run your program under parrot_run and record the filename list and environment variables by using --name-list and --env-list parameters.
parrot_run --name-list namelist --env-list envlist /bin/bash
After the execution of this command, you can run your program inside parrot_run. At the end of step 1, one file named namelist containing all the accessed file names and one file named envlist containing environment variables will be generated. After everything is done, simple exit the shell.
Step 2: Generate a self-contained package
Use parrot_package_create to generate a package based on the namelist and envlist generated in step 1.
parrot_package_create --name-list namelist --env-path envlist --package-path /tmp/package
This command causes all of the files given in the name list to be copied into the package directory /tmp/package. You may customize the contents of the package by editing the namelist or the package directory by hand.
Step 3: Repeat the program using the package
The newly created package is simply a complete filesystem tree that can be moved to any convenient location. It can be re-run by any method that treats the package as a self-contained root filesystem. This can be done by using Parrot again, by setting up a chroot environment, by setting up a Linux container, or by creating a virtual machine.
To run the package using Parrot, do this:
parrot_package_run --package-path /tmp/package /bin/bash
To run the package using chroot, do this:
chroot_package_run --package-path /tmp/package /bin/bash
In both cases, you will be dropped into a shell in the preserved environment, where all the files used by the original command will be present. You will definitely be able to run the original command -- whether you can run other programs depends upon the quantity of data preserved.
For more information, see these man pages:
Fri, 01 Aug 2014 19:18:00 +0000
The software may be downloaded here: Download CCTools 4.2.0
This release is mostly a bug fix release, but introduces changes to the Work Queue protocol. Thus, workers from 4.2 do not work with masters pre 4.2.
Among the bug fixes and added capabilities are: Among the bug fixes and added capabilities are:
Thu, 31 Jul 2014 12:33:00 +0000
DeltaDB database model for time-varying schema-free data at the IEEE International Congress on Big Data in Anchorage. The DeltaDB concept is what underlies the query engine for the cctools catalog server.
Tue, 03 Jun 2014 16:50:00 +0000
paper on converting the MAKER bioinformatics analysis from MPI to Work Queue, done in collaboration with the Notre Dame Bioinformatics Laboratory was recently accepted for publication in the International Journal of Bioinformatics Research and Applications.
Tue, 03 Jun 2014 16:47:00 +0000
See the slides here.)
Historically, highly concurrent programming has been closely associated with high performance computing. Two programming models have been dominant: shared memory machines in which concurrency was expressed via multiple threads, and distributed memory machines in which concurrency was expressed via explicit message passing. It is widely agreed that both of these programming models are very challenging, even for the veteran programmer. In both cases, the programmer is directly responsible for designing the program from top to bottom and handling all of the issues of granularity, consistency, and locality necessary to achieve acceptable performance, with very little help from the runtime or operating systems.
However, a new approach to concurrent programming has been emerging over the last several years, in which the user programs in a much higher level language and relies upon the system to handle many of the challenging underlying details. To achieve this, the program is successively decomposed into simpler representations, such that each layer of the system can gradually adapt it to the hardware available.
The layers can be described as follows:
A (very incomplete) selection of systems that follow this model:
Mon, 19 May 2014 19:14:00 +0000
Each layer of the system fulfills a distinct need. The declarative language (DL) at the top is compact, expressive, and easy for end users, but is intractable to analyze in the general case because it may have a high order of complexity, possibly Turing-complete. The DL can be used to generate a (large) directed acyclic graph (DAG) that represents every single task to be executed. The DAG is not a great user-interface language, but it is much more suitable for a system to perform capacity management and optimization because it is a finite structure with discrete components. A DAG executor then plays the graph, dispatching individual tasks as their dependencies are satisfied. The BOT consists of all the tasks that are ready to run, and is then scheduled onto the underlying computer, using the data dependencies made available from the higher levels.
Why bother with this sort of model? It allows us to compare the fundamental capabilities and expressiveness of different kinds of systems. For example, in the realm of compilers, everyone knows that a proper compiler consists of a scanner, a parser, an optimizer, and a code generator. Through these stages, the input program is transformed from a series of tokens to an abstract syntax tree, an intermediate representation, and eventually to assembly code. Not every compiler uses all of these stages, much less the same code, but by using a common language, it is helpful to understand, compare, and design new systems.
We have tried a number of approaches at visualizing this complex system over the years. Our latest tool, the Condor Matrix Display started as a summer project by Nick Jaeger, a student from the University of Wisconsin at Eau Claire. The display shows a colored bar for each slot in the pool, where the width is proportional to the number of cores.
With a quick glance, you can see how many users are busy and whether they are running "thin" (1 core) or "fat" (many core) jobs. Sorting by the machine name gives you sense of how each sub-cluster in the pool is used:
While sorting by users gives you a sense of what users are dominating the pool:
The display is always a nice way of viewing the relatively new feature of "dynamic slot" in Condor. A large multi-core machine is now represented as a single slot with multiple resources. For example, this bit of the display shows a cluster of 8-core machines where some of the machines are unclaimed (green), some are running 4-core jobs (blue), and some are running 1-core jobs (green):
Fri, 14 Feb 2014 16:20:00 +0000
Mon, 18 Nov 2013 18:34:00 +0000
The workshop is an opportunity for beginners and experts alike to learn about the latest software release, get to know the CCL team, meet other people engaged in large scale scientific computing, and influence the direction of our research and development.
Thursday, October 10th
Afternoon: Introduction and Software Tutorials
Friday, October 11th
All Day: New Technology, Scientific Talks, and Discussion
There is no registration fee, however, space is limited, so please register in advance to reserve your place. We hope to see you there!
Fri, 11 Oct 2013 12:00:00 +0000
Making Work Queue Cluster Friendly for Data Intensive Scientific Applications.
In the original design of Work Queue, each worker was a sequential process that executed one task at a time. This paper describes the extension of Work Queue into two respects:
The effect of these two changes is to dramatically reduce the network footprint at the master process, and at each execution site. The resulting system is more 'friendly' to local clusters, and is capable of scaling to even greater sizes.
Wed, 21 Aug 2013 12:55:00 +0000
This is the first release of the 4.0 series, with some major changes:
Please refer to the doc/ directory in the distribution for the usage of this new features. You can download the software here:
Thanks goes to the contributors for this release: Michael Albrecht, DeVonte Applewhite, Peter Bui, Patrick Donnelly, Brenden Kokoszka, Kyle Mulholland, Francesco Prelz, Dinesh Rajan, Casey Robinson, Peter Sempolinski, Douglas Thain, Ben Tovar, and Li Yu.
Mon, 29 Jul 2013 12:11:00 +0000
Right-sizing Resource Allocations for Scientific Applications in Clusters, Grids, and Clouds!
Fri, 26 Jul 2013 12:05:00 +0000
Building Scalable Scientific Applications using Makeflow and Work Queue as part of XSEDE 2013 in San Diego on July 22. Mon, 22 Jul 2013 12:00:00 +0000
Best Presentation Award at CCGrid 2013 for his presentation of
Case Studies in Designing Elastic Applications!
Tue, 21 May 2013 13:58:00 +0000
Building Elastic Applications with Makeflow and Work Queue as part of CCGrid 2013 in Delft, the Netherlands on May 13th. Come join us and learn how to write applications that scale up to hundreds or thousands of nodes running on clusters, clouds, and grids.
Fri, 22 Mar 2013 11:12:00 +0000
Case Studies in Designing Elastic Applications at the IEEE International Conference on Clusters, Clouds, and Grids (CCGrid) in Delft, the Netherlands. This work was done in collaboration with Andrew Thrasher and Scott Emrich from the Notre Dame Bioinformatics Lab, and Badi Abdul-Wahid and Jesus Izaguirre from the Laboratory for Computational Life Sciences.
Fri, 22 Mar 2013 10:40:00 +0000
recent article in IEEE Transactions on Parallel and Distributed Computing describes our work in collaboration with the Notre Dame Bioinformatics Laboratory on SAND - The Scalable Assembler at Notre Dame.
The Cooperative Computing Lab is pleased to announce the release of version 3.7.0 of the Cooperative Computing Tools, including Parrot, Chirp, Makeflow, WorkQueue, SAND, All-Pairs, and other software.
The software may be downloaded here.
This is a minor release which adds numerous features and fixes several bugs:
Thanks goes to the contributors for many minor features and bug fixes:
Please send any feedback to the CCTools discussion mailing list.
Mon, 18 Feb 2013 16:29:00 +0000
The Cooperative Computing Lab is pleased to announce the release of version 3.6.2 of the Cooperative Computing Tools, including Parrot, Chirp, Makeflow, WorkQueue, SAND, All-Pairs, and other software.
This is a bug fix release of version 3.6.1. No new features were added.
The software may be downloaded here:
Thanks goes to the contributors for this release: Patrick Donnelly, Brian Du Sell, Dinesh Rajan, Douglas Thain, and Li Yu.
Mon, 11 Feb 2013 13:55:00 +0000
The Cooperative Computing Lab is pleased to announce the release of version 3.6.1 of the Cooperative Computing Tools, including Parrot, Chirp, Makeflow, WorkQueue, SAND, All-Pairs, and other software.
This is a bug fix release of version 3.6.0. No new features were added.
The software may be downloaded here: http://www.cse.nd.edu/~ccl/software/download
Thanks goes to the contributors for this release: Dinesh Rajan, Patrick Donnelly, Peter Bui, Li Yu, and Douglas Thain.
Fri, 02 Nov 2012 15:54:00 +0000
October 24th, 3-5PM, 303 Cushing Hall