« Back

xrac_request

Writing a Successful Resource Request

Submissions from many first-time proposers often include the same mistakes. To help improve your chances for success in getting a Research Allocation, consider the following recommendations to help you avoid those common mistakes in your own request.

Policy information is based on the TeraGrid Allocations Policy.

  • 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, reviewers will generally accept that the science is sound. The purpose of your allocation request is to demonstrate that you have the knowledge to make good use of your allocation. 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 request 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 request that encompasses three projects should describe the algorithms and the code(s) used in each. Then, the request 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, TRAC proposals 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 request, please have a look at Section 3.2, describing data to be entered into the POPS forms, and Section 4, describing elements of your request 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 allocations are likely to be productively used.

Examples of Well-Written Research Allocation Requests

Every Research request must include a Main Document that focuses on the resource request, whether for compute, storage, or advanced support.  Successful requests do not recycle an existing NSF proposal as that does not focus on computing needs.

Successful requests for compute resources must address these issues:

  • The appropriateness of the computational methodology
  • The algorithmic capabilities that make this problem a good fit for the requested systems
  • The rationale for the number of runs being proposed

Successful Requests for storage resources must address these issues:

  • The appropriateness of the storage resource for the data sharing or management needs
  • The planned use and usage patterns for the data to be stored
  • The rationale for the amount of storage space requested

Successful requests for advanced support must address these issues:

  • The work plan
  • The computational objectives to be targeted with the requested support
  • Metrics for success
  • Statements on how the advanced support will impact a community beyond the investigator's own research program

Successful Research Request Examples

The following successful research requests represent the features described above. (These documents will open in new windows.)

Research Request Type

Science Domain

Progress Reports