- Data Portals
- User Support
- About Us
Note: For Yellowstone, Large Allocations are those for more than 200,000 core-hours. Small Allocations are for 200,000 core-hours or less and require only an abstract of the work to be conducted. See the CISL University Allocations page for eligibility requirements and other information.
The next deadline for Large Allocation Requests is March 28, 2016.
We have 87 million core-hours available to allocate this spring. In October 2015, the review panel recommended 52 awards totaling 97.6 million core-hours. The average award was just under 1.9 million core-hours and the largest award was for 6.9 million core-hours.
Requesters must prepare and submit a Request Summary document and attach it to the Large Allocation Request form as a PDF file. The instructions below explain how to prepare the document.
When your document is ready, submit your request via the Large Allocation Request form.
The Request Summary document must provide a self-contained description of your project and allocation request. The Request Summary may be no more than five (5) pages for Sections A–D below; Sections E–G should be included in the same uploaded document and are permitted an additional five (5) pages. The five-page limit is mandatory for all requests, and it is strongly recommended that you follow the template below to help the panel locate required information within your request.
The CHAP Allocation Review Criteria provide further detail on considerations the review panel uses in identifying meritorious requests. Recent successful requests are available at: Proposal Sample 1 and Proposal Sample 2.
A. Project Information
B. Overview of Project
The overview of the project should typically be less than half a page and include:
C. Science Objectives
The science objectives should be briefly described. This section should give sufficient information for understanding the computational plan in section D; it is not necessary to justify the science objectives as they must have already passed NSF review.
Advice for preparing your request. "Brief" is the operative word for your science description. The panel is not judging your science, only trying to understand how and if your computational experiments (described in Section D) will help you find answers to your science questions. This section should be between 1/2 and 1 page long.
D. Computational Experiments and Resource Requirements
The bulk of the Request Summary should focus on Section D. Discuss your planned computational experiments and the resources needed to conduct the work in this section. Please cover the following topics; advice for how to best address each topic is included.
Provide a table summarizing the resources required for each experimental configuration and the complete set of computational experiments. This must include the number of core-hours needed andthe terabytes of data destined for HPSS if such storage is required. The table should be accompanied by a narrative that elaborates on how you arrived at the numbers in the table and describes any needs for project disk space or data analysis and visualization resources as detailed below.
With the Yellowstone system's ability to generate vast amounts of data, CISL allocation requests now require users to consider their data workflows and to justify their long-term storage resource use. Requesters should note that the CHAP Allocation Review Criteria also apply to requests for allocated storage resources—that is, HPSS archive use and GLADE project spaces. The CHAP reviewers do not expect lengthy justifications; in most cases, a paragraph that demonstrates forethought commensurate with the scale of anticipated need will suffice. As requests approach a petabyte (or more!), longer justifications become appropriate. In addressing the criteria with respect to storage resources, justify the project’s need to retain the data to be stored, the project’s rationale for which data will be stored, and the project’s work plan for minimizing temporary data migration from disk to tape. While some statement of storage resource needs is expected in Section D, you may choose to provide details in Section E (Data Management Plan) to keep sections A-D within the five-page limit. Please note that temporary data that never move beyond scratch disk space need not be justified in the project's allocation request.
1. HPC. The table should give the core-hours per simulated year or appropriate time period and the total core-hours needed for each experimental configuration as well as the total core-hours for the request. Describe how you arrived at the number of core-hours for each proposed computational experiment. If not provided elsewhere, details on how HPC resource requirements are estimated MUST be included to help reviewers evaluate whether the resources sought are justified and will be used efficiently.
Calculating or estimating Yellowstone core-hours. Yellowstone allocations will be made in “core-hours” rather than GAUs. Eventually, performing benchmark runs on Yellowstone, or using published timings from runs on Yellowstone, will become the preferred methods for estimating resource needs. For estimating Yellowstone core-hours based on earlier Bluefire runs, users can assume that 1 GAU is equivalent to 0.47 core-hours on Yellowstone. That is, GAUs x 0.47 = Yellowstone core-hours. Users with benchmark runs from other systems should contact firstname.lastname@example.org to determine a proper conversion to Yellowstone. The core-hours for a job are calculated from the number of processor cores used multiplied by the wallclock duration in hours. Because Yellowstone jobs have exclusive use of the batch nodes, core-hour calculations should assume the number of cores will always be a multiple of 16; requests should also assume all jobs will run in the regular queue.
2. HPSS archive. If your data storage in CISL’s HPSS archive during the life of this project will be less than 20 TB, stating “<20 TB” is sufficient and no detailed justification is required. Otherwise, in the table showing core-hours include a column for the terabytes of HPSS space required for each experimental configuration and include the total terabytes stored. Projects with larger anticipated archival storage needs must include a description of how the estimate was calculated. If this request is a continuation of a previous request on the same project, please include a separate entry in the table for current data stored in HPSS.
Justifying HPSS requests. A successful justification for HPSS archive space would describe, for example, that the data have a meaningful purpose beyond initial post-processing steps; that variables or time steps not needed for planned analyses will be filtered out; and that HPC and analysis stages are interleaved where practical to minimize the need for temporary data to occupy tape. From the review criteria, it should be clear that a simple summation of all bytes generated by all proposed HPC runs may set an upper limit on HPSS needs but will not automatically constitute a sufficient justification in and of itself. Where appropriate, the justification should also describe how the project will reduce HPSS holdings in subsequent years (for example, a project may have a larger need during peak activity that will be reduced in out-years). As with computational justifications, the detail for storage justifications should grow commensurately with the project’s anticipated need.
3. Project file space. Large University projects can request dedicated long-term, large-scale disk space on the GLADE resource. The justification for GLADE project space should describe how the requested size was determined, how other available resources (such as /glade/scratch, /glade/p/work, and HPSS) will be used to minimize the size of the project space needed, why other storage options are not well suited for all of the project's needs, and how the requested project space will benefit or accelerate the project. Project file spaces must be for needs greater than 5 TB. Again, projects do not need to request or justify access to scratch or work file spaces, which are available to all users.
Justifying project space requests. A successful justification for GLADE project space must demonstrate your understanding of the unique capability offered by project spaces and show that the project will also make efficient use of scratch space and work spaces when possible. As with HPSS requests, a simple summation of all bytes generated by all proposed HPC runs may set an upper limit on overall disk use but almost certainly will not constitute a sufficient justification for dedicated project space. A description of how a project will adapt its workflow to leverage project space (along with scratch and work space) and improve its overall efficiency will strengthen the justification. Where applicable, the justification may also describe how a project space allocation will permit a project to substantially reduce its use of HPSS. As with computational justifications, the detail for storage justifications should grow commensurately with the project’s anticipated need.
4. Data analysis and visualization. Describe any planned need for CISL’s Geyser and Caldera clusters to analyze or visualize your results. For standard interactive access to these clusters, the number of users expected to use the DAV clusters will serve as sufficient justification for up to 5,000 core-hours per user. Projects with more extensive plans for use of the clusters (for example, long-duration, multi-node batch runs) must justify their needs in a manner similar to their HPC requests.
Multi-Year Plan. While the CHAP makes an effort to award each project its full resource need, very large requests should consider providing a breakdown showing the projected use of core-hours and, if applicable, terabytes to be stored in HPSS during each year of the allocation. Tie this to the planned computational experiments completed or partially completed each year.
Special Requirements. Please specify any resource requirements that fall outside of the default environment limits, such as the need for longer job runtime limits, that may affect your ability to complete the proposed computational experiments.
Sections E through G together must be no more than an additional five pages.
E. Data Management Plan. Consistent with NSF’s new requirement that all proposals include a Data Management Plan, summarize your plan for managing the data resulting from this computational work. This section can be used to provide additional details or justification for the storage resource needs, to describe plans for sharing the project’s data, and to summarize any anticipated long-term storage needs beyond the lifetime of the supporting NSF award. A well-justified data management plan is critical because of the size of Yellowstone and the potential for large-scale Yellowstone projects to produce extensive data output.
F. Accomplishment Report. The Accomplishment Report should encompass computations performed using CISL resources by the PI or Project Lead. Clearly distinguish accomplishments on this CISL project (i.e., for prior CISL use associated with the same NSF award) and accomplishments from all past use of CISL resources. Related work performed on CISL resources by other members of a larger research group may be described, if relevant to this request. Briefly describe the calculations and scientific accomplishments that were completed. Include publications submitted or published that resulted from use of CISL resources. List graduate students who used these computational resources and indicate if these resources supported their thesis or dissertation research. If so, please include the thesis or dissertation title(s).
G. References. Please limit to those directly related to the proposed project and referenced in your Request Summary document.
H. Figures and captions. Optional. Figures may be embedded within the main body of the Request Summary; embedded figures count against the five-page limit. Figures and charts at the end of the Request Summary will not count against the five-page limit.