Resource Allocation Competition Application Guide

1. Resources for Research Groups (RRG)
   • RRG Fast Track Application Process
2. Research Platforms and Portals (RPP)
   • RPP Annual Progress Report
3. Eligibility
   • Co-PIs and Collaborators
     • Minimum Request
4. Submission Procedures and Deadlines
   • Pre-Submission Consultations
   • Online Application Form
   • CCV Requirement
5. Assessment Process
   • Guiding Principles
   • Technical Review
   • Peer Review
   • Resource Scaling
6. Questions and Additional Information
7. APPENDIX A: Resources for Research Groups Scientific Evaluation Criteria
8. APPENDIX B: Research Platforms and Portals Scientific Evaluation Criteria
9. APPENDIX C: Scoring Matrix
10. APPENDIX D: Non-disclosure Agreement and Conflict of Interest Policy for Scientific Reviewers
    • Conflict of Interest Policy
11. APPENDIX E: Confidentiality of Information

The RRG is a peer-reviewed application process for projects whose primary purpose is to conduct research requiring compute, storage and cloud resources to meet their goals. However, projects primarily needing persistent instances in the cloud to provide a service through a platform or a portal should apply through the RPP application process instead.

Refer to the Appendices at the end of this Guide for the RRG Evaluation Criteria and scoring matrix.

RRG Fast Track Application Process

Users with an existing RRG award who meet the Fast Track eligibility are allowed to submit a lightweight progress report to renew their request for computational resources. Please read the Fast Track guidelines as this process includes important conditions and limitations that should be considered when deciding whether to use the Fast Track process or submit a new application. 

Eligible Principal Investigators (PIs) will receive an invitation by email in September 2023. Fast Track submissions start on September 26 and are due November 7, 2023, at 11:59 p.m. Eastern Standard Time (extension of this deadline is not possible).

Return to table of contents

The RPP is a peer-reviewed application process for projects whose primary purpose is to provide a service through scientific gateways that improve access to shared datasets, enhance existing online research tools and facilities, or advance national or international research collaborations. However, projects primarily needing compute resources in a cluster to conduct research should apply through the RRG process instead.

A research platform or portal is a set of community-developed tools, applications and data that are integrated via a gateway or a suite of applications, usually in a graphical user interface, that is further customized to meet the needs of a community of users associated with a specific discipline. 

RPP projects typically involve cloud resources, usually through the development of a front-end gateway on persistent virtual machines, with possible backend compute either through cloud compute nodes or job-based submission to the national clusters. Many platforms and portals also include large databases. 

Projects applying must: 

1. provide a service  to a larger research community via a set of cloud-based tools, applications and/or data, thus enabling them to access national computational resources via a common interface;
2. be able to develop, operate and manage the proposed portal or platform with minimal support from the Federation.

Please refer to the Appendices at the end of this Guide for the RPP Evaluation Criteria and the scoring matrix.

Important: If your multi-year RPP award expires in April 2024, you must submit a new RPP application this fall if your need for resources will continue for the 2024-2025 allocation cycle.

RPP Annual Progress Report

Allocations may be awarded over multiple years (maximum of three years), subject to an annual review and availability of resources.

Awarded multi-year projects do not need to submit a new application every year but are required to complete an annual progress report. The PI will be notified by email with instructions for the information required and the submission process. For more details, visit the RPP Progress Report page.

Submissions of the annual RPP Progress Report start September 26 and are due November 7, 2023.

Return to table of contents

To be eligible to submit a RAC application, the PI and all Co-PIs must: 

1. be a faculty member at a Canadian academic institution: and
2. have an active Alliance account with an Academic PI role (Faculty, Adjunct Faculty or Librarian).

Users with an Academic PI position may:

• apply as PI for only one RRG application at a time (either through the full application process or the Fast Track one) but can be involved in multiple RRG submissions as a participant; and
• be the PI for one RPP application per competition round and be involved in other RPP applications as a co-PI. 

Important: “Departmental" applications will not be accepted (i.e., applications submitted on behalf of a group of PIs that may be from the same department but are not collaborating in a common research project with clear goals and outcomes). 

Co-PIs and Collaborators

In the context of this competition, a Co-PI is any Canadian faculty with an Alliance Academic PI role that is actively involved in the computational project. The PI and any Co-PI must upload an updated CCV with the application (see CCV Requirement). The role and involvement of any Co-PI listed in the application must be justified. 

International investigators or colleagues without an Alliance account can be listed as collaborators in the Resource Management section of the application document (pdf). 

Minimum Request

Resources available via the Rapid Access Service (RAS) will change on April 1, 2024. If your need for computational resources can be met with what will be available via the RAS after that date, do not submit a RAC application. 

Note that /HOME and /SCRATCH storage are not allocated through the RAC.

If you don't understand some of the terms listed above, please visit the Technical Glossary. 

Requesting Resources

It is extremely important that the online application form includes a request for every resource (CPU, GPU, storage or cloud) that your project needs on each cluster. There should be NO DISCREPANCIES between the amount of resources requested in your attached Application Document and what you request in the online form. In case of discrepancy, what was requested in the online form will prevail.

Please visit the Available Resources page for a list of systems available for this competition and to understand how resources must be requested in the online form. 

Example of acceptable resource requests:

• If you need 180 core-years (or core-equivalent-years) and 50 TB of project storage on Cedar, your RAC application should only request 50 TB of storage on that cluster. Do not request CPU in your application as you may be able to get the CPU that you need without a RAC allocation.
   
• If you need 500 core-years, 20 TB of project storage and 80 TB of nearline storage on Narval, your RAC application should only request 500 core-years on that cluster, as your storage needs can be met with what is available via RAS.
   
• If you need 100 core-years with 10 TB of project storage on Niagara and 50 TB of nearline storage on HPSS, then you should only request the 10 TB and 50 TB of storage on those clusters, respectively, as you may be able to get the CPU that you need without a RAC allocation.
   
• If you need 400 core-years, 30 reference GPU units (RGU) years and 200 TB of project storage on Graham, then you must request all these resources in your RAC application as they are all above the minimum eligible amounts specified in the table above.
   
• If you need 150 core-years on Béluga with different memory requirements: 100 cores with 16 GB per core (which results in 400 core-equivalent-years) and 50 cores with 4 GB per core (50 core-equivalent-years), then you should make two separate CPU requests on Béluga to account for the different memory requirements. This request is acceptable because the total core-equivalent-years needed on a single cluster is greater than 201. Another acceptable option would be to average out the total memory per core needed and just make one request for 150 cores with 12 GB per core.
• If you need 45 TB of project storage and you want to split it between Béluga and Narval as follows: 20 TB on Beluga and 25 TB on Narval, then this request will be accepted as the total amount of project storage needed exceeds41 TB.
• If you need 100 VCPU of compute cloud resources on Arbutus with 5 TB of Volume and snapshot (TB) and 5 TB of object storage, then you should request all these resources in the online form. The amount of VCPUs needed on Arbutus exceeds the minimum required to apply, and the storage resources, even if they are less than the minimum of 10 TB, must be included in the same request.

Example of resource requests that will be rejected:

• If you need 250 core-years in total but you want to split the CPU request between Cedar and Graham as follows: 100 cores with 4 GB per core on Cedar and 150 cores with 4 GB per core on Graham; this request will NOT be accepted because you may be able to get the CPU that you need without a RAC allocation. If your application only includes a CPU request in this way (that is, it does not include any additional storage, GPU or cloud resources), it will be disqualified. 
• If you need 20 reference GPU units in total but you want to split the GPU request between Narval and Béluga with 10 RGU and 10 RGU, respectively, this request will NOT be accepted. 
• If you need 25 VCPU of persistent cloud resources on Arbutus with 10 TB of Volume and snapshot storage (TB), then you should not apply for RAC as these resources are available via RAS.

Application document

Applicants are required to use the template provided below for the corresponding application process. 

Important: 

• This document must be submitted in .pdf format. 
• Maximum page limits will be enforced. Any information exceeding the maximum page limit will be ignored and the resulting score will be based exclusively on what is included within the page limits.

Return to table of contents

Proposals must be submitted electronically through the CCDB portal no later than November 7, 2023 at 11:59 p.m. Eastern Standard Time. The PI is responsible for ensuring that the application is complete, with all additional documentation uploaded, and that there is no discrepancy between the application document and the online form.

Following the review process, applicants will be informed regarding the status of their applications via email in spring 2024.

Pre-Submission Consultations

If you are applying for the first time to this competition, we strongly encourage you to consult with us prior to submitting your application. Consultations should happen prior to October 31, 2023, to allow adequate time for support by our technical staff. 

The goal of the consultation is to:

• determine whether the resources needed for your project justify submitting a RAC application;
• verify the project's eligibility to the right application process (RPP vs RRG);
• provide technical assistance with the calculation of the resources needed.

To schedule a consultation, please send an email to allocations@tech.alliancecan.ca or contact your regional support team.

Return to table of contents 

Online Application Form

All RAC applications are submitted online via the CCDB portal. Users must log in using an existing Alliance account or register for a new one. 

Important: 

• You must apply with your primary, most up-to-date position. If you recently moved to a different institution and you have not yet applied for a new faculty role on the CCDB portal, please do so before submitting your RAC application. 
• If you have more than one active faculty role in the CCDB portal, please make sure that your most up-to-date position is set as your primary role. On the CCDB portal, go to the Home page to see which of your roles is currently set as primary and, if needed, click on the Make this role primary button next to the new role that you want to set as primary.

Failing to do any of the above could create problems if your application is successful. 

CCV Requirement

An up-to-date Canadian Common CV (CCV) is required for the peer-review process. 

The PI and all Co-PIs are required to:

• Upload an up-to-date CCV with any RAC application. 
• Report publications enabled by your use of resources provided by the Federation.

Failing to provide an updated CCV will negatively impact the overall score of the submitted application.

The PI can view in the online application form the date in which any CCV linked to the application was last uploaded and whether any action is required. 

Co-PIs can update their CCVs on CCDB by clicking on Update CCV in the Resource Applications page, or by going to My Account → View Reporting. Once Co-PIs have updated their CCV, the status of the CCV will be automatically updated in the RAC online application form.

Please plan ahead to avoid delays or the risk of missing the submission deadline due to this requirement. Deadline extensions due to missing CCVs are not possible.

Please carefully read the CCV Submission Guide for further instructions.

Return to table of contents

Guiding Principles

RAC is guided by the following principles:

• All applications are given fair consideration through both a peer-review and a technical review;
• Resources are awarded based on the appropriateness of the computational resources requested to achieve the project's objectives and the likelihood that these resources will be efficiently used, rather than on the evaluation of a complete research program; and 
• The challenges arising from the shortage of resources and other constraints within the system are shared among all applicants.

Technical Review

The technical review is conducted by technical experts of the Federation who:

• ensure the appropriate system is requested by the PI and the required software is available;
• evaluate application efficiency and scalability;
• identify groups that may need help with application and workflow optimization;
• identify discrepancies between the resource request included in the online form and the attached application document;
• identify special software requirements;
• provide a technical opinion on the reasonability of the request.

Technical reviewers are required to sign a Non-Disclosure Agreement prior to accessing any RAC application.

During the technical review process, staff may require additional information from applicants and will engage them directly. In order to ensure an application can progress beyond the technical review, applicants are expected to respond to requests from the technical team within 48 hours. 

Peer Review

All applications submitted to the RAC are peer-reviewed and scored. Peer reviewers are required to accept the Alliance's Non-Disclosure Agreement and Conflict of Interest Policy prior to accessing any application.

The resulting score is based on the following: 

• the feasibility of the computational research project based on what research will be done and what outcomes will be delivered, and not on why it is important;
• the appropriateness of the resources requested to achieve the objectives of the computational research project based on the technical justification provided; and
• the likelihood that the resources requested will be efficiently used.

Applications will be reviewed in one of the committees below. PIs can select a peer-review committee of their choosing; however, applications can be moved to a different committee following consultation with the committee Chairs. 

• Astronomy, Astrophysics and Cosmology
• Bioinformatics
• Chemistry, Biochemistry and Biophysics
• Computer Sciences and Mathematics
• Engineering
• Environmental and Earth Sciences
• Humanities and Social Sciences
• Nano, Materials and Condensed Matter
• Neurosciences, Medical Imaging and Medical Physics
• Subatomic Physics, Nuclear Physics and Space Physics

Resource Scaling

Resources provided by the Federation are limited, and for this reason requests for allocations are scaled every year based on the overall score of the application and the supply and demand. 

A scaling function is applied to compute requests to provide a means by which decisions on RAC allocations in a context of insufficient capacity can be made. Visit the Past RAC results page for more details about the scaling function and other stats from previous years.

Return to table of contents

For any questions, please contact allocations@tech.alliancecan.ca or your regional support team directly:

You may also wish to consult our Frequently Asked Questions page or the Technical Glossary.

Return to table of contents

RRG applications are evaluated against the two following criteria: Research Methods and Resource Management and Computational Expertise.

Research Methods (70%)

This criterion evaluates the methods proposed to achieve the objectives of the computational project and the appropriateness of the resources requested. It focuses more on assessing what research will be done with the resources requested and on the technical justification provided, than on why the research is important.

Considerations for the evaluation of this criterion include the following:

Research Outline

• The research problem is clearly presented.

• The overall goal and objectives of the project are well-defined and clear, and they state what the computational project is ultimately expected to achieve.

Expected Outcomes

• The application presents anticipated outcomes and indicates the means by which these will be measured.
• The proposed computational project outputs (i.e., the anticipated results of the project) and impact are clearly described, are aligned to the objectives, are of relevance and are realistic and attainable.
• The proposed computational research project is likely to lead to advances in the research area.

Progress Over the Past Year

• The application shows achievements, outcomes and/or evidence of progress resulting from the utilization of resources provided by the Federation over the past year.

Computational Methods

• The application describes appropriate tools, methods and approaches for addressing the research objectives. These methodologies may be community codes or models, data analysis methods, algorithmic formulations expressed in user-developed scripts or tools, as well as trials or test implementations.

Resource Request Justification

• When applicable, a justification for low utilization (or lack thereof) of an existing allocation is provided and deemed reasonable.
• The amount of resources requested is deemed appropriate to achieve the project objectives, and the technical justification provided is excellent.
• The application describes necessary and sufficient computational experiments to answer the research questions posed.

Resource Management and Computational Expertise (30%)

This criterion evaluates the capacity of the research team as a whole to manage the project and make efficient use of the resources requested. It also assesses the overall feasibility of the computational project based on the research and computational expertise of the team.

The team includes the Principal Investigator (PI) and, if applicable, Co-PIs and any Highly Qualified Personnel (HQP) actively participating in the computational project.

HQP includes all research personnel involved in the applicant’s computational project, whether from academia, government or industry. The number of HQP using resources provided by the Federation directly is expected to be appropriate to the scope of the project.

The nature, breadth and depth of the applicants’ (PI and, if applicable, Co-PIs) experiences and contributions should be assessed in the context of their career stages. Committee members must not impart, refer to or consider information about the applicants that does not appear in the application and the provided Canadian Common CV (CCV).

It is not mandatory that an application includes Co-PIs or HQP to obtain the full Resource Management score. However, the proposed research must be achievable by the listed team members, particularly if it is only one PI and/or if there is no funding available. It is expected that applications asking for large amounts of resources will have funding to justify the request. 

The level of detail needed to get a high score for the Resource Management criterion is a function of team size and resource ask. 

Considerations of this review criterion include the following:

Funding

• Funding is available for the research project to justify the request for computational resources; when funding is not available, a reasonable explanation for how the compute resources will be utilized is provided.

Computational Expertise of the Team

• The team shows sufficient computational expertise or a training plan to make effective and efficient use of the computational resources requested.

Management Strategy

• Information about each team member (PI, Co-PIs and HQP, when applicable) and their requested computational resources are clearly described.
• The roles and responsibilities of the PI and Co-PIs, if applicable, are clearly described with respect to making efficient use of the resources requested and are linked to the objectives of the computational project (Co-PIs contribute to the Resource Management score in accordance with their involvement).

The team demonstrates the combined expertise and experience needed to execute the computational project, i.e., deliver the proposed outputs as well as achieve the proposed contribution(s).

Return to table of contents

RPP applications are evaluated based on the following two criteria: Project Justification and Resource Management and Expertise of the Team.

Project Justification (50%)

Considerations for the evaluation of this criterion include the following:

Project Description, Objectives and Impact

• The problem or need that the research platform/portal will address is clearly presented.
• The objectives and goals of the platform/portal clearly described.

 Use of the Platform/Portal

• The added value from the creation or maintenance of the platform or portal for the targeted communities is clearly explained.
• If applicable, the level of interaction between Canadian and international research groups is clearly described.

Expected Outcomes

• The application presents a clear timeline for the delivery of the anticipated outcomes over the entire duration of the requested resources and indicates the means by which these outcomes will be measured.

Progress over the Past Year

• The application shows achievements, outcomes and/or evidence of progress resulting from the utilization of resources provided by the Federation over the past year.
• When applicable, a justification for low utilization (or lack thereof) of an existing allocation is provided and deemed reasonable.

Resource Request Justification

• The amount of resources requested is deemed appropriate to achieve the project objectives, and the technical justification provided is solid.

Resource Management and Expertise of the Team (50%)

This criterion evaluates the capacity of the research team as a whole to manage, develop and operate the platform/portal, and the ability of the team to make efficient use of the resources requested. It also assesses the overall feasibility of the project based on the expertise of the team.

The team includes the Principal Investigator (PI) and, if applicable, Co-PIs and any Highly Qualified Personnel (HQP) actively participating in the project. 

HQP includes all research personnel involved in the project, whether from academia, government, or industry. The number of HQP directly involved in the management, development and operation of the platform/portal is expected to be appropriate to the scope of the project.

It is expected that applications asking for large amounts of resources will have sufficient funding to develop, manage and operate the platform/portal.

Considerations of this criteria include:

Funding

• Funding is available to support the management, development and operation of the platform/portal and to justify the request for computational resources; when funding is not available, a reasonable explanation for how the platform/portal will be managed, operated and developed and how the compute resources will be utilized is provided.

Expertise of the Team

• The team assembled to manage, develop and operate the platform has the right combination of skills (where positions are not yet filled, a description of the position has been included).

Management Strategy

• The proposed management of the resources is well defined and will provide broad access to the research community.
• The process for resource access is well defined, and a credible strategy to maintain or increase the community accessing resources is described.
• The proposed methods and technologies are suitable and well justified for the services to be provided by the platform. 
• The approach to sharing data sets across the platform or portal is well described, and potential accessibility issues are properly addressed.

Return to table of contents

RAC applications are scored based on a 5-point scale as shown in the table below. Applications with a score of 2.0 or lower are considered unsuccessful and will not be awarded.

Return to table of contents

Definitions:

• Federation: a partnership of the regional Digital Research Infrastructure Alliance of Canada (the Alliance) Digital Research Infrastructure (DRI)-serving organizations (BC DRI Group, Prairie DRI Group, Compute Ontario, Calcul Québec, and ACENET), and academic institutions across Canada.
   
• Partner: a member institution or regional DRI-serving organization that is operating infrastructure or providing services as part of Federation operations.
   
• Peer-Review Committee: panel of experts in multiple disciplines that volunteer to peer-review applications submitted to the Resource Allocation Competition (RAC).
   
• Applicant: The Principal Investigator (PI) and any co-PI listed in an application submitted to the Resource Allocation Competition (RAC).

By signing this agreement, you are accepting to abide by the policy outlined below.

The undersigned agrees to treat as strictly confidential all information received for the purpose of evaluating resource applications, as well as all unpublished material from the documents during the review process, together with all deliberations, comments, scores and recommendations of the peer-review committees. This information must not be used for any purpose beyond that for which it was originally intended.

Conflict of Interest Policy

Reviewers  must follow the guidelines below regarding conflicts of interest.

Reviewers must disclose, as early as possible, any conflict of interests with a RAC application to which they  are directly or indirectly associated. These guidelines cannot foresee all possible situations and the Alliance must rely on the judgment of the reviewers to disclose these conflicts of interests. 

Reviewers are in direct conflict if they:

• submitted an application that will be reviewed in the committee they are serving (in this case, they are in conflict with their own application only);
• are from the same university department as the applicant;
• have been a research supervisor or graduate student of the applicant within the past five (5) years;
• have collaborated or published with the applicant within the past two (2) years or have plans to collaborate or publish in the immediate future;
• are providing direct or indirect support for the application;
• are a relative or close friend, or have a personal relationship with the applicants;
• have had scientific or personal differences with the applicant that have been expressed publicly;
• are in a position to gain or lose financially from the outcome of the application (e.g., hold stock in the company of an industry partner or a competitor), or for some other reason feel that they cannot provide an objective review of the application.

Committee members are in indirect conflict if they:

• are from the same immediate institution* or company as the applicant and interact with the applicant in the course of their duties at the institution or company;
• have other reasons not to review an application.

*A reviewer is not in conflict with an application if they are from the same institution as the applicant but do not know or interact with the latter.

Difficult cases should be brought to the administrators of the RAC process, who have the authority  to rule.

All peer-reviewers must read and agree to abide by this conflict of interest policy prior to viewing any application information.

Return to table of contents

The Alliance safeguards the information it receives from applicants. All reviewers are required to sign a Non-Disclosure Agreement and accept the Conflict of Interest Policy. They are instructed to keep all proposal information confidential and to use it only for review purposes. All proposals are available for review by all reviewers and the Resource Access Program Administrative Committee (RAPAC). 

Use of Personal Information

Any personal information collected by the Alliance is used only to review applications. Such information may be shared with relevant officials in the corresponding regional partner, as well as with the research institution of these officials.

Public Information

If approved for an allocation, the Alliance will post the following project information on our website:

Full name of the PI

Institution

Department

Project Title

Project Summary

Allocation

Return to table of contents