Writing a Successful MRAC or LRAC Proposal

Home > User Support > Access > Allocations & Accounts

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.

Policy information is based on the NSF Allocations Policy for TeraGrid.

• 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.

• 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?

• Justify your Advanced Support request - Advanced Support Program requests must also be justified. See the special instructions here. Many potential Advanced Support candidates cannot be rated by the review committee because no justification is provided for Advanced Support.



• 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.

• 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.

• 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.

Please contact the TeraGrid Allocations Staff if you have any questions about submitting proposals, your award expiration, or POPS.

TeraGrid Allocation Cycles

Allocation Cycle

Meeting	Service Units (SUs) of Computation Time Requested (Computation Allocation)	Terabytes (TB) of Data Space Requested (Data Allocation)	Open submissions	Close submissions	Allocations begin	Review Cycle
Development Allocations Committee (DAC)	1 – 30,000	1 – 5   disk and/or 1 – 25    tape	Any time	n/a	Usually 2-3 weeks after submitted	Year round
Medium Resource Allocations Committee (MRAC)	30,001 – 500,000	6 – 25    disk and/or 26 – 100    tape	Dec. 15, 2007	Jan. 15, 2008	Apr. 1, 2008	Quarterly
			Mar. 15, 2008	Apr. 15, 2008	Jul. 1, 2008
			Jun. 15, 2008	Jul. 15, 2008	Oct. 1, 2008
			Sept. 15, 2008	Oct. 15, 2008	Jan. 1, 2009
Large Resource Allocations Committee (LRAC)	> 500,000	>25   disk and/or >100   tape	Dec. 15, 2007	Jan. 15, 2008	Apr. 1, 2008	Semi-annually
			Jun. 15, 2008	Jul. 15, 2008	Oct. 1, 2008

¹ The MRAC and LRAC Meetings schedule is available for reviewers on the POPS Review page.