To request an Explore ACCESS allocation please have the following items handy: 

• A summary of your planned work

• A CV or résumé for the PI and any co-PIs, in PDF format.

• The following project info:

  • Title of the project

  • Keywords for the research

  • Field of science

  • Supporting grant details (if applicable) 

• Important! If you’re a Graduate Student requesting an allocation, you must upload a signed letter from your advisor, on your institution’s letterhead in PDF format, indicating their awareness of the request and engagement in guiding the computational activity. If the graduate student is an NSF Graduate Research Fellowship Program (GRFP) recipient or honorable mention, they can upload their letter from NSF in lieu of an advisor letter. Suggested language for this is as follows: 

“ACCESS Allocations,

I am aware of (Insert Student’s Name)’s interest in utilizing ACCESS resources in pursuit of their dissertation activities and intend to engage with and guide their computational and research activity.” 

When you're ready, login, and select "New Project" from the main allocations page.

To request a Discover ACCESS allocation please have the following items ready: 

• A summary of your planned activities and intended use of resources

• A CV or résumé for the PI and any co-PIs, in PDF format.

• The following project info:

  • Title of the project

  • Keywords for the research

  • Field of science

  • Supporting grant information (if applicable) 

• A one-page description of the project that addresses how you plan to use ACCESS resources. Documents should be PDF files with 1-inch margins, and 11pt or larger font size. Readability is the goal. The document should include the following: 

  • Research or Education Objectives

    • Briefly describe the objectives you plan to pursue—whether they are research questions, classroom exercises, or other activities

• Description of Resource Needs

  • Describe the sort of resources you expect to use within the ACCESS ecosystem.

    • Are specific computing architectures most appropriate (e.g. GPUs, large memory, large core counts on shared memory nodes, etc.)?

    • What are the storage needs of the project?

    • Do you need specific software to complete the work?

  • Not sure about your resource needs? Request an Advisory Review to guide you to appropriate resources.

  • Important! If you’re a Graduate Student requesting an allocation, you must upload a signed letter from your advisor, on your institution’s letterhead in PDF format, indicating their awareness of the request and engagement in guiding the computational activity. If the graduate student is an NSF Graduate Research Fellowship Program (GRFP) recipient or honorable mention, they can upload their letter from NSF in lieu of an advisor letter. Suggested language for this is as follows: 

  “ACCESS Allocations,

  I am aware of (Insert Student’s Name)’s interest in utilizing ACCESS resources in pursuit of their dissertation activities and intend to engage with and guide their computational and research activity.” 

When you're ready, login, and select "New Project" from the main allocations page.

For Accelerate projects, researchers are expected to have reasonably well defined plans for their resource use and must submit a three-page project description for panel review. Documents should have 1-inch margins, and 11pt or larger font size. Readability is the goal. Reviewers will look more closely at how your resource usage plan addresses the review criteria.

To request an Accelerate ACCESS allocation please have the following items prepared: 

• A summary of your planned activities and intended use of resources

• A CV or Résumé for the PI and any co-PIs, in PDF format.

• The following project info:

  • Title of the project

  • Keywords for the research

  • Field of science

  • Supporting grant information (if applicable) 

• A three-page description of the project that addresses how you plan to use ACCESS resources. Documents should be PDF files with 1-inch margins, and 11pt or larger font size. Readability is the goal. The document should include the following: 

  • Research Objectives

    • Briefly describe the science objectives. Provide sufficient information to help reviewers understand how your computational experiments will help you meet your domain objectives. If it’s not obvious, describe how the science objectives fit within the scope of the supporting grant, if applicable.

  • Estimate of Compute, Storage and Other Resources

    • Provide an estimate of the scale and type of the resources needed to complete the work. Please be as specific as possible in your resource request along with data supporting the request made.

      • Are there specific computing architectures that are most appropriate (e.g. GPUs, large memory, large core counts on shared memory nodes, etc.)

      • How much computing support will this effort approximately require in terms of core, node, or GPU hours? How does this break down into the number of independent computations and their individual compute requirements?

      • How distributed can the computation be, and can it be split across multiple HPC systems?

      • Describe the storage needs of the project.

  • Computational Plan

    • Summarize your computational plan at a level sufficient to address the review criteria.

      • Methodology: What tools, methods and approaches will be used? If your group developed the codes, briefly summarize their use and performance on other resources.

      • Research plan: What computational experiments have you designed to address the science objectives?

      • Resource use: What resources do you expect to use? Do you have prior experience using similar resources and methods? If not, describe how you plan to ensure efficient use of the resources.

  • Software & Specialized Needs

    • Describe any specialized needs for completing your science runs (long-duration jobs, large-memory nodes, specific date or time constraints for completing the work, etc.).

  • Team and Team Preparedness

    • Summarize your team's qualifications and readiness to execute the project both in using the methods proposed and the type of resources needed.

When you're ready, login, and select "New Project" from the main allocations page.

ACCESS Allocations will be moving to a semi-annual cycle for Maximize ACCESS requests. For researchers with the largest-scale computational, analysis, and storage needs, requests for Maximize ACCESS allocations can be submitted during the period of December 15, 2024 to January 31, 2025, with awards starting April 1, 2025

• December 12, 2024, 2:00 p.m. ET (Live training webinar on how to apply, optional)

• December 15, 2024 (Request window opens)

• January 21, 2024 2:00 p.m. ET (Live training webinar on how to apply, optional)

• January 31, 2025 (Request window closes)

• Early March, 2025 (Review meeting)

• Mid-March, 2025 (Notifications sent to requestors)

• April 1, 2025 (Start/renewal date)

The following proposal submission window will be June 15, 2025 - July 31, 2025, with awards starting October 1, 2025. Researchers with existing large-scale ACCESS Research or earlier Maximize ACCESS allocations should contact the Allocations team with any questions or concerns to determine the best option for aligning their project renewals with the semi-annual schedule.

When your request is ready to submit, you can do that here.

These ACCESS video presentations are provided to help you prepare your request. They will be updated later this year.

How to Write a Successful ACCESS Maximize Proposal

The presentation below details all the steps and requirements needed for successful research allocation requests. Topics covered include computation methodologies, justification for SUs requested, and many others. (If you would prefer to attend a live training webinar, dates are listed above.)

 Writing and Submitting a Maximize ACCESS Proposal Webinar

Recorded: December 12, 2023
Run time: 33 minutes

Code Performance and Scaling

Ken Hackworth from PSC and Lars Koesterke from TACC discuss the technical aspects of research allocation proposals including how best to gather and present scaling and code performance statistics and estimating SU requests in your allocation proposals.

XSEDE Code Performance and Scaling Training- April 1, 2020

Recorded: April 1, 2020
Run time: 1 hour 7 minutes

Required Components

No other documents will be reviewed, and documents that exceed specified page limits will not be accepted by the XRAS system.

When writing your Research request, be clear and concise. We strive to have domain experts review every request, but they may not have deep expertise in your specific subdomain. Someone outside of your area should be able to understand the scientific objectives and understand why the chosen technique is preferred over another.

The documents required of a Research request have been requested by AARC reviewers to ensure they can effectively determine how each request satisfies the ACCESS allocation Review Criteria. Requests need not use the full page limit in all documents; concise submissions are appreciated. No other documents will be reviewed.

• Main Document

• Progress Report

• Code Performance & Resource Costs

• Curriculum Vitae (CV)

• References

• Special Requirements

Main Document

The Main Document is the primary and most critical component of a successful request. Research requests must include a well-documented resource-use plan that describes how the requested allocations are necessary and sufficient to accomplish the project's research objectives. An effective resource-use plan must address the ACCESS allocation Review Criteria and, in particular, must include the following elements, with the bulk of the document focused on the Research Objectives and the Resource Usage Plan:

1. Scientific Background-with more detail required of requests that do not have a merit-reviewed funding award

2. Research Objectives and specific questions to be pursued

3. Resource Usage Plan to achieve the research objectives

4. Justification of the allocation amounts for all resources and resource types

5. Resource Appropriateness

6. Access to other CI resources and why those resources are not available or sufficient for the work proposed in this request

Page limits: 10 pages for less than 10 million SUs total; 15 pages for 10 million SUs or more

Progress Report

The Progress Report for Renewal requests should describe how the PI's current or prior allocation was used and summarize the findings or results; the results can be discussed with respect to the publications and other communications that the PI's team has entered in their ACCESS User Profiles and linked to this request. The Progress Report should also explain any significant digressions from the originally proposed resource usage plan for the prior period.

If a PI's allocation was significantly underutilized, the Progress Report should briefly describe the reasons for the underutilization and any mitigation by the PI to avoid the situation with the current allocation.

Page limit: 3 pages.

Code Performance & Resource Costs

This REQUIRED document should contain code performance timings, resource usage details, and scaling information (for HPC resources) to support the calculation of the resource request.

For highly competitive HPC resources, the code performance data should be provided from benchmark runs on the resource requested, using the model configuration(s) needed for the computational plan proposed and demonstrating the scaling efficiency to the job size(s) planned. For smaller size requests, the panel may accept well-justified performance data from architecturally equivalent systems.

For less competitive systems or for non-traditional resources, this document should contain sufficient justification to convince the panel that you have a solid basis for calculating your allocation request.

Page limit: 5 pages.

Curriculum Vitae (CV)

Two-page (maximum) CVs for each PI and co-PI are required. The two-page NSF or NIH formats are highly recommended.

Page limit: 2 pages per individual

References

A PI may use this OPTIONAL document to separate a lengthy bibliography of cited work to take full advantage of the page limits in the Main Document. This bibliography is not the publications resulting from prior ACCESS support, which should be entered into the ACCESS publications database, but rather other citations referenced in describing or supporting the intellectual merit of the proposed work or the appropriateness of the proposed approach for addressing the research objectives.

Page limit: No limit.

Special Requirements

This OPTIONAL document should be included if the completion of the Resource Usage Plan requires capabilities that fall outside a Service Provider's (SP's) standard user and usage environment. For example, jobs longer than the standard queue lengths, specific scheduling demands, or dedicated file system space. The AARC is not required to read this document; the intended audience is the staff at the relevant SP.

Page limit: 1 page.

Review Criteria and Guidance

In addition to confirming user eligibility, reviewers evaluate the merits of each request according to three ACCESS allocation review criteria. PIs must provide justification, suitable to the nature of the request, that addresses these criteria; reviewers apply the criteria in the context of the request.

1. Appropriateness of Methodology: Does the request describe appropriate tools, methods, and approaches for addressing the research objectives? These methodologies may be community codes or models, data analysis methods, or algorithmic formulations expressed in user-developed scripts or tools.

2. Appropriateness of Research Plan: Does the request describe necessary and sufficient computational experiments to answer the research questions posed? In some cases, the research plan may be more reasonably expressed as estimates of resource use, supported by past or early experience. Serious concerns about the research plan will be documented in reviews and may lead to reduced allocation awards.

3. Efficient Use of Resources: Has the request identified appropriate resources for undertaking the research plan with the proposed methodology? And will those resources be used as efficiently as is reasonably possible and in accordance with the recommended use guidelines of those resources?

In addition to the computational review criteria, the panel also considers whether the work is aligned appropriately with any supporting grants for which the science has been merit-reviewed. If no such grants are identified, the panel will assess the intellectual merit of the work as well.

Intellectual Merit: Is the proposed work supported by a grant or grants that have undergone review for intellectual merit and/or broader impact (if relevant to the allocation)? If so, is the allocation request consistent with the objectives of the supporting grants and is the scale of resource use commensurate with the level and purpose of support? If a request is not supported by a merit-reviewed award, reviewers will assess the intellectual merit of the proposed work and factor that into their overall recommendation. Reviewers will also consider whether the identified support provides necessary and sufficient human resources to complete the proposed work.

To ensure all required and relevant aspects of each request are considered, the AARC reviews and rates each request according to the rubric below. Submissions should address each of these elements within the required documents.

AARC Review Rubric

To ensure all required and relevant aspects of each request are considered, the AARC reviews and rates each request according to the following rubric. Submissions should address each of these elements within the required documents.

Grounds for Rejection

Failure to address either of the following two items is grounds for rejection.

• Proposal describes access to other compute resources

• Code performance and scaling data are provided

Assessment and Summary

• Research objectives described

• Peer-reviewed supporting grant(s) - OR - Science review

• Progress report, publications, and prior usage (if applicable)

• Proposal adequately describes access to other compute resources

Appropriate Methodology

• Right tools, codes, algorithms, etc., for the research objectives

• Appropriate parameterizations, model configurations, etc., for the research objectives

Appropriate Research Plan

• Necessary & sufficient experiments or work plans to answer the research objectives?

• Request totals calculated correctly

• Justification provided for number of replicates, problem sizes, duration of calculations, etc.

Efficient Use of Resources

• Appropriate resources chosen

• Resources to be efficiently used

• Code performance and scaling data are provided and appropriate

Detailed Main Document Guidance

The Main Document should include the following components:

• Scientific Background and Support

• Research Questions

• Resource Usage Plan

• Justifying Allocation Amounts

• Resource Appropriateness

• Disclosure of Access to Other Compute Resources

Scientific Background and Support

The Main Document will succinctly state the scientific objectives that will be facilitated by the allocation(s). (The existing merit-reviewed supporting grants should be listed in the submission forms.) Requests with merit-reviewed supporting grants will not be subject to further scientific review by the AARC; however, the stated scientific objectives must match or be sub-goals of those described in the listed funding award(s). The description of the objectives should be sufficient to allow the reviewers to assess the resource usage plan.

If a request does not have merit-reviewed support, the Main Document should describe the science objectives in sufficient detail for the reviewers to evaluate the intellectual merit of the work covered by the allocation request. The ACCESS Allocations Coordinator will highlight such requests and the AARC will review the scientific merit of the proposed work.

Research Questions

Next, an effective Main Document will identify the specific research questions that are covered by the allocation request. Within the context of the scientific background and supporting grants, these objectives and questions should be stated so that the reviewers can understand how elements of the resource plan will contribute to relevant answers. If you consider the allocation request in terms of computational experiments, the research objectives and questions define the experiments to be conducted.

Resource Usage Plan

The bulk of the Main Document should focus on the resource usage plan and allocation request. Inadequate justification for requested resources is the primary reason for most reduced or denied allocations. Once again, the PI should keep in mind the ACCESS allocation Review Criteria when describing and justifying the choice of resources and allocation amounts, and the Main Document should include appropriate justifications for all resources being requested.

Justifying Allocation Amounts

The justification of allocation amounts takes the quantitative parameters from the resource usage plan and combines them with basic resource usage cost information (detailed in the Code Performance and Resource Cost document) to calculate the allocation needed. In terms of computational experiments, the justification should tabulate and calculate the costs of conducting each experiment for each resource and resource type.

Allocations for most resources are made in "Service Units" (SUs); however, the definition of an SU varies from resource to resource. Refer to the User Guide for each resource to determine how to calculate SUs (or other allocable units, if appropriate) for the resources in your request.

For compute resources, the request should address the appropriateness of the computational methodology, the architectural features or capabilities that make this problem a good fit for the requested systems, and the rationale for the number of runs being proposed. In terms of computational experiments, the Resource Usage Plan details the methodology, set-up, and conduct of each experiment.

For other types of resources, the request should address the appropriateness of the resource for the project's needs, the planned use and usage patterns, and the rationale for the allocation amount requested.

Resource Appropriateness

When faced with high demand for certain resources, the AARC reviewers may make recommendations for allocations that could be migrated to less busy resources. This Main Document section should briefly detail the rationale for selecting the requested resources and highlight any resource features or capabilities that would constrain how the allocation might be moved.

For example, the rationale section could mention the need for specific visualization capabilities, the need for tightly integrated or specialized storage needs, the limited availability or compatibility of specific software, a code's ability to use specific resource features (such as GPUs or Xeon Phis), dedicated support for gateway access and usage, or the need to run at very large scale.

Conversely, this section can be used to highlight the PI's flexibility in using alternate resources, which may be advantageous for the PI if the selected resources are highly oversubscribed. (If your work permits, it is generally to your advantage to request less utilized resources directly, rather than simply noting your flexibility.)

Disclosure of Access to Other Compute Resources

Because of the high demand for ACCESS-allocated resources, ACCESS and the AARC closely consider whether the PI has access to other, less constrained resources on which the proposed work could be conducted. All PIs must describe their local resources and other non-ACCESS resources available to them.

• Local resource environment: Requests should describe briefly the local (e.g., campus or lab) computing environment available to a research team and, most significantly, how ACCESS resources will provide capabilities beyond those of local resources or why the requested ACCESS resources are required in addition to those resources.

• Other non-ACCESS resources: If a PI has access to other resources (e.g., Blue Waters, NSF NCAR systems, INCITE or other Department of Energy resource allocations, or resources supported by other agencies) or could be logically expected to have such access-as with researchers affiliated with or collaborating with other agencies that may have their own resources or facilities, the Main Document should describe why those other resources are not available to the group or why the requested ACCESS resources are required in addition to those resources.

Guidance for Gateway Requests

Research requests associated with Gateway projects (sometimes called "Community" projects when a formal gateway is not the primary access mechanism) are submitted and reviewed in the same quarterly process as single-investigator requests, and most of the guidance for single investigator requests also applies to gateway requests. However, some Main Document sections and supporting documents should be modified to address gateway-specific issues.

Main Document-Research questions: In this section, gateway projects would describe the general codes or other services provided and the broad classes of research questions that could be pursued via the gateway.

Main Document-Resource usage plan: Requests for Gateways or Community Services projects would typically use this section to describe the methods or applications provided, the expected or projected consumption of resources, and mechanisms for monitoring the users and usage of the service.

Progress Report: For Gateway projects, the Progress Report should include statistics and reports of community usage to help the reviewers understand how the prior allocation was effectively used and managed.

Code Performance and Scaling: For community or gateway requests, this document can be used to explain the methods used for extrapolating from prior gateway usage, to provide "typical" model performance on the requested or architecturally similar systems, and to explain expected user needs were projected to arrive at the allocation amounts requested.

Example Proposals

• Astronomic sciences

• Biochemistry

• Biophysics

• Biophysics 2

• Computational biology

• Computational fluid dynamics

• Materials

• Physics

Appendix: Formatting Guidelines

All documents must satisfy the following minimum requirements. Documents that conform to NSF proposal format guidelines will satisfy these requirements.

• Margins: Documents must have 2.5-cm (1-inch) margins at the top, bottom, and sides.

• Fonts: Use one of the following typefaces identified below:

  • Arial, Courier New, or Palatino Linotype at a size of 10 points or larger;

  • Times New Roman at a size of 11 points or larger; or

  • Computer Modern family of fonts at a size of 11 points or larger.

  • A font size of less than 10 points may be used for mathematical formulas or equations; figures, table or diagram captions; or when using a Symbol font to insert Greek letters or special characters. PIs are cautioned, however, that the text must still be readable.

• Character spacing: No more than 15 characters per 2.5 cm (1 inch) horizontal space.

• Line spacing: No more than 6 lines within a vertical space of 2.5 cm (1 inch).

• Page numbering: Page numbers should be included in each file by the submitter. Page numbering is not provided by the submission system.

• File format: Only PDF file formats are accepted.