About applying for a large TeraGrid allocation (more than 30,000 CPU hours or 5TB of data storage)

On this page:

• About larger allocations
• Things to consider when applying
• How to apply

About larger allocations

Indiana University is a resource provider and partner in the TeraGrid, funded by the US National Science Foundation (NSF) as a flagship effort to create a national cyberinfrastructure. If you are a researcher at a college, university, or national research lab within the United States, you may request an allocation of time and/or storage space on IU resources; see Who is eligible to apply for a TeraGrid allocation? If you are new to the TeraGrid, for important information about getting started, see What is the TeraGrid, and how can I get started using it?

This document presumes you have already used the TeraGrid or have a major project in operation you plan to move to the TeraGrid, and that you need an allocation on the TeraGrid of more than 30,000 service units (SUs; each SU is roughly equal to a CPU hour) or 5TB of storage. For specifics about the two categories of allocations larger than 30,000 SUs per year (MRAC and LRAC), see What are DAC, MRAC, and LRAC TeraGrid allocations?

Things to consider when applying

One SU is worth slightly more than $1; thus, when you apply for an allocation of more than 30,000 SUs, you are writing a proposal for use of National Science Foundation (NSF) resources with a value of more than $30,000. Applications for these large allocations are subject to real peer review. As a result, you should plan enough time to prepare a good proposal for one of the large allocations.

For more, including sample language, see the IU Research Technologies Request a TeraGrid account page. The staff of the Research Technologies division of IU's University Information Technology Services can help you in preparing your proposal, and strongly encourages you to request such assistance.

In your proposal, the justification for your request for computing resources is very important. Poorly reviewed proposals frequently share common errors. The following guidelines can help improve your chances for success:

• Make computing the focus: 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.

  Proposals should not focus on science and are generally not heavily judged on science; focus more attention on methods, justification, and a plan for your allocation.

  Possibly the most common mistake is for researchers to submit pared down versions of the science proposals they submitted to request funding for their work. If you already have merit-reviewed funding, MRAC and LRAC reviewers will generally accept that the science is sound.

• Justify your request: Most of your proposal should emphasize the justification of your computational request. Many poorly reviewed proposals contain only one- or two-sentence summary justifications, which don't provide reviewers with enough information.

  In general, your justification should explain in detail how the computations planned will address the scientific question at hand, and how fewer computations would be insufficient to reach meaningful answers. Section 4 of the NSF Resource Allocations Policies outlines what reviewers expect in a successful proposal.

  Also, if you're requesting a particular resource, include why you need that resource.

• Show parallel scaling and familiarity with the systems: Successful proposals describe how scalable the code is (i.e., 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. It's best to obtain this data on the architecture you are requesting; development allocations are available for collecting such performance information.

  For proposals that rely on home-grown 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.

• Follow page limit guidelines: 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 NSF Resource Allocations Policies. Adherence to these details is important.
  
  
• Attach recent papers regarding the proposed research: Especially 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.
  
  
• Note your funding sources: For new proposals and for very large requests, supporting grants assure the reviewers that the science has been reviewed and that staff will be available to do the work.
  
  
• Complete code development before applying: Complete all code development before requesting a large allocation to use that code.
  
  
• Justify your advanced support request: If you're requesting assistance from the Advanced Support Program, you must justify your request. Many potential Advanced Support candidates cannot be rated by the review committee, because no justification is provided. You should submit a one-page justification as an appendix to the standard proposal documents. For more on the Advanced Support Program, plus tips on writing a successful request, see the Advance Support Program page in the TeraGrid User Support documentation.

For further information about writing your proposal, award types, and deadlines, see the Allocations and Accounts page in the TeraGrid User Support documentation.

How to apply

For application instructions, see How do I apply for a TeraGrid allocation?

This document was developed with support from the National Science Foundation (NSF) under Grant No. 0503697 to the University of Chicago and subcontracted to Indiana University. Additional support was provided by IU through its participation in the TeraGrid, which is supported by the NSF under Grants No. 0833618, SCI451237, SCI535258, and SCI504075. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the NSF.