Climate Simulation Laboratory (CSL)

About the CSL | Submission instructions | Eligibility requirements

The CSL submission deadline is September 11, 2017.


  • CSL awards will begin January 1, 2018, and last for 12 months.
  • Researchers must have funding from National Science Foundation (NSF) awards to address the climate-related questions for which they are requesting CSL allocations. (See the Eligibility requirements below.)
  • Requests must meet or exceed the minimum request size of 10 million core-hours on Cheyenne.


About the CSL

The Climate Simulation Laboratory (CSL), which was established in 1995, represents CISL’s premier opportunity for researchers seeking high-performance computing and data storage systems to support extremely demanding, high-profile climate simulations. Such simulations require high resolution, span many centuries of simulated time, encompass large numbers of ensembles, integrate new physics or models, or address national and international scientific priorities.

CSL projects’ large-scale, long-running simulations typically require millions of core-hours to complete and usually produce many terabytes of model output that must be stored for analysis and comparison with other simulations and with observations.

Requests must meet or exceed the minimum request size of 10 million core-hours on Yellowstone. Very large projects, if awarded, may be required to consume their allocation approximately evenly over the course of the allocation period.

For purposes of the CSL, the Earth's climate system is defined as the coupled atmosphere, oceans, land, cryosphere, and associated biogeochemistry and ecology, studied on time scales ranging from seasons to centuries. The CSL encourages collaborations with scientists involved in policy development, including impacts, mitigation, and adaptation options for climate change as well as short-term climate variations.

The CSL computational facilities are operated and maintained by the NCAR Computational and Information Systems Laboratory (CISL) and supported by the NSF.

Submission instructions

Requesters must complete an online Allocation Request Form and attach a Request Summary document (PDF format).

The Request Summary document must provide a self-contained description of your project and allocation request. The Request Summary may be no more than eight (8) pages for Sections A-D below; Sections E-G must be included in the same uploaded document and are permitted an additional five (5) pages. The page limits apply to all requests, and it is strongly recommended that you follow the template below to help the panel locate required information within your request.

The format for CSL requests closely follows the format for CHAP/University Large Allocation requests. CSL requests are allowed three (3) extra pages due to th­e additional scrutiny that these projects receive and the expectations for significant progress in a short period. These instructions call out suggestions for topics to which requesters should devote those extra pages. The CSL Review Considerations provide further detail on considerations the review panel uses in identifying meritorious CSL requests.

A. Project Information

  • Title of project
  • Title of NSF award(s) (if different from title of project) that support the computational experiments. Important: The NSF award must explicitly support the computational experiments being proposed.
  • NSF award number(s). Please note if an NSF award is pending. Allocations will not be made until the NSF has awarded a grant for the research. Given the rapid pace at which CSL projects are expected to begin work and the uncertainty around NSF award processing, it is unlikely that a CSL allocation will be granted to a project supported solely by a pending NSF award.
  • Name of project lead and his or her institution
  • Submission date

B. Overview of Project
The overview of the project should typically be less than half a page and should summarize:

  • The science question and computational plan;
  • How the proposed work pursues an integrated program of extremely demanding climate simulations that require high resolution, span many centuries of simulated time, encompass large numbers of ensembles, integrate new physics or models, or address national and international scientific priorities; and
  • The linkage between the NSF award and the computational experiments that are being proposed, which is especially important if the published NSF award abstract does not clearly describe the computational component of the work funded.

C. Science Objectives
. The science objectives must be described with sufficient information for understanding the computational plan in Section D and the need for a large-scale CSL allocation. Please keep in mind that a collection of unrelated activities that are assembled to reach the minimum CSL allocation size does not constitute a valid CSL request.

Advice for preparing your request. CSL requesters may want to provide greater detail on their scientific objectives, as compared to university allocation requests. The strength of the scientific justification will come into play if the panel cannot give adequate resources to all meritorious CSL requests and can recommend only a subset of requests for award. In addition, requesters may want to describe in this section the nature of any multi-institutional or multi-investigator collaboration and how the team members contribute to the pursuit of the scientific objectives and the computational effort. However, an elaborate justification of the scientific objectives does not replace the need for a strong justification of the computational need, so this section still should be no longer than 2½ to 3 pages.

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.


  • Numerical Approach. Describe the numerical approach(es) or model(s). If a standard community model is being used, simply explain why it is appropriate for the scientific objectives and include a reference to a published description of the model or method. If a community model is being modified, include a description of the modification sufficient to explain any changes in the computational cost of the model and explain why modifications are necessary for the scientific objectives. For a non-standard or non-community model, the numerical description should briefly describe the approximations and other methods proposed to obtain valid solutions to the problem.
  • Computational Experiments. Describe the computational experiments needed to address the scientific objectives. The description must clearly indicate the number and type of experiments and how they relate to the objectivesBe sure to justify the model configuration choices that are relevant to the experiment such as domain, grid size, time steps, simulated time span, ensemble size, and parameter choices. References on the selection of the ensemble size are strongly encouraged. Without an adequate justification of the model configuration, the panel may reduce or deny your computing request.
  • Code Performance. Include documentation on program code performance (for example, timings, performance monitoring tools); you may refer to a web page detailing code performance. Describe how flexible your code is in the number of processors it can use and why you may choose a particular number. The panel will evaluate the likelihood that a request can scale up its production runs based on this information. Information about the code’s performance is essential to help demonstrate that the team and code are prepared to begin work quickly.

Advice for preparing your request. Given the large-scale nature of CSL projects, ensure that the description of your computational experiments explicitly justifies why your large-scale request is both necessary and sufficient to accomplish the scientific objectives. The panel will likely downgrade requests that appear to have been padded with unnecessary work or use unnecessarily complex runs to address the science questions. Furthermore, CSL requests must demonstrate to the panel—that is, not merely claim, but provide sufficient supporting information, such as benchmark runs and scaling data—that the codes to be used are production-ready.


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 and the 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. Failure to provide such a table will reduce your chances of being recommended for an allocation.

With the Cheyenne system’s ability to generate vast amounts of data, CSL allocation requests require users to consider their data workflows and to justify their long-term storage resource use. Requesters should note that the CSL Review Considerations also apply to requests for allocated storage resources—that is, HPSS archive use and GLADE project spaces. The 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 hundreds of terabytes (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 must 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. To help reviewers evaluate whether the resources sought are justified and will be used efficiently, you must include details on how HPC resource requirements are estimated if they are not provided elsewhere.

Calculating or estimating Cheyenne core-hours. Calculating or estimating Cheyenne core-hours. Submitters can assume that one Yellowstone core-hour is equivalent to 0.82 Cheyenne core-hours. That is, estimate your computational need based on Yellowstone costs and multiply the total by 0.82 to arrive at your Cheyenne estimate. Users with benchmark runs from other systems should contact to determine a proper conversion to Cheyenne. See Calculating charges for more information about how core-hours are charged on Cheyenne.

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 that will be 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. CSL projects can request dedicated large-scale disk space on the GLADE resource. The justification for GLADE project space must 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.

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 five additional pages.

E. Data Management Plan. Consistent with NSF’s 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 becomes more critical as a project's planned output approaches a hundred terabytes or more.

F. Accomplishment Report. The Accomplishment Report should encompass computations performed using CISL resources by the principal investigator or project lead. Clearly distinguish accomplishments on this project (i.e., for prior 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 the 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.

Eligibility requirements

CSL proposals must address and discuss the following eligibility criteria in their allocation requests. 

  1. Principal investigators funded or supported at least in part by NSF awards related to climate challenges are eligible to apply. A significant fraction of the proposed calculations must be linked explicitly to current, merit-reviewed NSF research projects. Due to the anticipated scope of CSL projects, portions of the work may also be jointly supported by other agencies or sources.
  2. Calculations must require large-scale, dedicated and/or data-intensive supercomputing. For example, projects may pursue multi-decadal to multi-century runs with coupled climate models, or require large ensembles of seasonal to interannual predictability runs, or advance the state of the practice in climate simulation by incorporating new physics or higher resolution.
  3. Preference is given to collaborative group efforts, including interdisciplinary teams that address broadly posed sets of questions, such as IPCC and National Assessment issues.
  4. Requests must meet or exceed the minimum request size of 10 million core-hours on Cheyenne.