Writing a Successful MRAC or LRAC Proposal & Allocations Update
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.
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.
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
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?
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.
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
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.
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.
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.
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.