| About Lattice |
 |
|
An Introduction to The Lattice Project
The Lattice Project is the research in Grid computing conducted by the Laboratory of Molecular Evolution. It can also refer to the Grid computing system that is currently in production at the University of Maryland. Michael Cummings has directed The Lattice Project from its inception in late 2003 to the present, and Adam Bazinet has been the primary developer. During this time the system has been continually developed, improved, and used to complete many scientific analyses. We were initially motivated by the need for more computing power for our own research, but our development of the Grid system has always been with general, non-domain-specific use in mind. In fact, the majority of our users have been other researchers at the University of Maryland.
If you're looking for background material, perhaps the Wikipedia entry on Grid computing is a neutral place to start. You will find many different takes on the concept, but here is a simply stated definition of Grid computing: applying the resources of many computers to a single problem at the same time. To broaden out this definition a little, one generally assumes that the computers in question are not centrally administered, and may not even be known to the end user of Grid computing.
Before we go further, you should be aware that there is already a lot in print about The Lattice Project. It's true that some of the technical details may have changed since a particular manuscript was published, but most of the core ideas have remained the same. If you're interested, please take a look at our publications about The Lattice Project. Slides from presentations we've given are also available.
A Quick Blurb About Grid Computing Resources
The inquiring mind wants to know: why would I use a Grid computing system? To answer this question, we will define a local resource as an established computing resource administered in one domain and capable of functioning independently from a Grid system. Users of a local resource often submit and monitor compute jobs using some kind of job scheduling software. Pools of computers running Condor software or dedicated clusters running a variant of PBS are typical examples of local resources such as we have defined them. A basic function of The Lattice Project, or most any Grid system for that matter, is to perform meta-scheduling, which is the process of assigning computational jobs that come through the Grid to an eligible local resource. This kind of functionality is what makes Grid computing appealing: it is the ability to use many different resources simultaneously and efficiently, wherein the Grid system handles user authentication and authorization, job scheduling and monitoring, and data placement. The Lattice Project provides these features and many more, thus enabling the student, scientist, or researcher to perform a large amount of computation in a short amount of time without having to worry about tedious details. In addition, the user gains access to resources outside of his or her administrative domain. In our Grid system, one of these resources is very special: The Lattice BOINC Project.
The Lattice BOINC Project
We have just mentioned how our use of BOINC fits into the comprehensive Grid system we have designed. However, we see BOINC (and by extension, the BOINC community) as our single most important resource -- potentially our biggest one. Thus, we would like to provide our users with an understanding of how The Lattice BOINC Project may differ from other BOINC projects they may be participating in.
The main thing to realize is that because The Lattice BOINC Project is hooked up to a general purpose Grid system, no single project or application dominates the landscape. We provide a description of the applications we run and the various projects they may be associated with. Our research page attempts to describe the relevant science without using too much jargon, as that can be off-putting to many potential contributors. However, for those who want a more detailed and technical treatment of the work, you may follow links to appropriate academic papers, software, web sites, and so on.
The other big difference is to understand the applications we run. Typically, these are so-called legacy applications, which means they were not originally written with BOINC in mind. If you look at our master list of Grid services (a term we use to mean a Grid-enabled application), you will see that most of them have been "ported to BOINC" at one time or another. In the majority of cases, this was achieved with a library of our own that predates the newer wrapper method. However, we recognize the advantages of a native BOINC application, the biggest of which is checkpointing. Thus, if we are going to run an application a great deal, we will at least consider the possibility of modifying that application's source code to produce a native BOINC executable when it is possible to do so.
Our main site hosts frequently asked questions about The Lattice Project and BOINC. Thank you for your participation and support!
|
