Allocations Corner

Writing a Successful MRAC or LRAC Proposal & Allocations Update

—David Hart

How to Write a Successful MRAC or LRAC Proposal

Submissions to the MRAC or LRAC from first-time proposers often repeat the same mistakes. To help improve your chances for success, here are some pointers to help you avoid those common mistakes in your own proposal.

1. Make computing the focus. Possibly the most common mistake is for researchers to submit a whittled down version of the science proposal they submitted to an agency to request funding for their work. But if you already have merit-reviewed funding, MRAC and LRAC reviewers will generally accept that the science is sound.
   
   The purpose of your allocation proposal is to demonstrate that you have the knowledge to make good use of your award. You need only describe the science to the extent it's essential to explaining why you've requested the resources.

2. Justify your request. Most of your proposal should emphasize the justification of your computational request. Many new proposers submit only a one- or two-sentence summary "justification" that provides reviewers with little information.

   As an example, most proposals have a statement of the sort: "We need to make 16 runs at three resolutions each; each run takes about 1,000 SUs. Therefore we need 48,000 SUs." In poorly reviewed proposals, such a statement is the entire justification. In well-reviewed proposals, this statement might be the starting point for the justification.

   In general, the justification should explain in detail both (a) that the computations planned will address the scientific question at hand, and (b) that less computation will be insufficient to reach meaningful answers. Section 4 of the allocation policies lays out what the reviewers are looking for.

   For example, a proposal that encompasses three projects should describe the algorithms and the code(s) used in each. Then, the proposal should detail how you arrived at the number of service units (SUs), or CPU-hours, for each of the three projects and explain why each number is scientifically important.

   Taking the hypothetical example above, the review committee will want to know the rationale behind every number in this statement. Why are 16 runs needed (and not 8 or 32)? Will these runs address the scientific question? Why will three resolutions suffice, and which three are planned? Has the proposer provided the performance data that show 1,000 SUs are needed for each run?

3. Show parallel scaling and familiarity with the systems. The best proposals also describe how scalable the code is -- that is, whether and how well the codes run on the system you are requesting. This affects which systems you can and should run on. Ideally, you would provide a graph or chart showing the timings on your selected systems and scalability to larger number of CPUs. Development allocations are available for collecting such performance information.
   
   For proposals that rely on homegrown codes, performance and scaling information is particularly important. (For well-known codes, such as CHARMM and AMBER in biochemistry, the reviewers will accept less detail here.)

4. Too many pages. While not quite as formal as some government agency guidelines, proposals to the MRAC and LRAC do have specified page lengths and other formatting guidelines. (See Section 3.3 of the allocations policies.) Adherence to these details is greatly appreciated.

5. Missing information. For a detailed description of what should be in your proposal, please have a look at Section 3.2, describing data to be entered into the POPS forms, and Section 4, describing elements of your proposal and appropriate supporting documents.
   
   For new proposals and for very large requests, supporting grants are important to assuring the reviewers that the science has been reviewed and that staff will be available to do the work. For renewal proposals, progress reports that describe effective use of and publications from prior allocations help demonstrate that future awards are likely to be productively used.

Allocations Update:

In early March, the Large Resource Allocations Committee (LRAC) and Medium Resource Allocations Committee (MRAC) met and reviewed more than 80 proposals for computing time on NSF Cyberinfrastructure resources at SDSC and across the TeraGrid. The LRAC awarded 35 million CPU-hours, and the MRAC awarded 4 million CPU-hours.

These awards began on April 1.

April 14, 2006 is the deadline for proposals that request time starting on July 1, 2006. Any MRAC projects expiring on June 30 should submit a renewal proposal if they plan to continue computing in 2006, and any startup (DAC) projects that expect to need larger amounts of computing time starting in July should also submit proposals now.

The current submission period also presents the first opportunity for PIs to request allocations of disk space at SDSC for hosting of data collections, with or without a simultaneous compute allocation request. For details on SDSC's offering and how to write your proposal, please visit http://datacentral.sdsc.edu/how_to_apply.html.

As of April 1, all SDSC and NCSA systems are now fully integrated into the TeraGrid and new TeraGrid Roaming allocations will include access to DataStar p655 nodes and Blue Gene at SDSC, as well as the DataStar p690 and TeraGrid cluster systems.

Please contact David Hart, SDSC Allocations Coordinator, if you have any questions about submitting proposals, your award expiration, or POPS.