Student Cluster Competition

Teams are composed of six students, an advisor, and vendor partners. The advisor provides guidance and recommendations, the vendor provides the resources (hardware and software), and the students provide the skill and enthusiasm. Students work with their advisors to craft a proposal that describes the team, the suggested hardware, and their approach to the competition. The SCC committee reviews each proposal, ranks, and selects the team roster for the competition. The requirements for teams, the selection process, and what makes a good proposal are described more completely below.

SCC Connect (formerly IndySCC) is a virtual companion competition to the SCC that shares many of the same goals. SCC Connect teams compete using provided cloud resources and are not required to partner with a vendor, assemble a cluster, or attend the conference. 

Each year, far more team applications are received than can possibly be brought to the conference. It takes a significant amount of time and effort to put a team together, so SCC Connect was formed to provide additional opportunities for these teams to apply their hard work, gain experience, and maintain momentum for future years. 

Teams applying to the SCC may indicate they would like to be considered for SCC Connect if they are not selected to the SCC. Teams who do not indicate they are interested in SCC Connect will not be considered if not selected for the SCC. Indicating you would like to be considered for SCC Connect is not a guarantee to be selected for the competition.

Teams may also apply directly to SCC Connect without being considered for the SCC. This serves as a lower bar for entry for teams that may not have existing strong vendor relationships or sufficient funding to travel to the conference, or who are looking to gain a footing in the cluster competition world before applying to the SCC. The goal for teams participating in the SCC Connect is that they will be able to travel to the conference and compete in the SCC in a later year.

Final selections will be made considering the strength of the application, motivations as they relate to the goals of SCC Connect, and the team’s level of experience within prior cluster competitions.

Students, with the guidance of their advisor, will craft a proposal that describes their team, the proposed hardware and software, their approach to the competition, and what they hope to get out of the experience. This proposal is submitted as a team application for review by the SCC committee. The application consists of several prompts detailed below.

Your proposal will describe your team members, their strengths and weaknesses, and how everyone will work together in order to successfully compete. A good proposal will describe how the team members have different strengths and skills (i.e., academic studies and inclusion of non-STEM majors) and how they will work together and contribute to a strong team. This should not be a simple list of each team member’s qualifications–the reviewing committee will want to see how you will work together as a team.

Additionally, you will need to describe your team’s diversity. This does not mean academic diversity, but rather diversity in other areas such as underrepresented groups in your home region and institution. Diversity is relative to where you are from, so it can be helpful to describe what diversity means to your team and institution. You should also describe what efforts you made to recruit a diverse team – this is especially important if your team is not as diverse as you would have liked.

Your applications should describe in detail the hardware you propose to bring, and the software you plan to install (such as OS, resource managers, compilers, etc). A good proposal will provide sufficient detail to the reviewing committee that your proposed hardware and software meet the requirements outlined in the rules, and that you have thought through a plan on how to build and run your cluster. You should also explain how and why the hardware architecture you chose will be a great fit for typical real-world users and their workloads.

You will then need to describe the team’s relationship with your institution and vendor. Describe any financial support your institution and/or vendor is providing, such as travel expenses, cluster shipping, meals, etc. You should also describe any training or resources they are providing to help you prepare. It takes a village to build a team, so we want to see that you have a village backing you. 

Next you will describe how your team will prepare for the competition. We are looking for evidence that you have a plan to prepare. This could include things like meeting regularly to work on the cluster, explore topics, practice, attend guest lectures, etc. Mentioning any classes the team members are taking that directly relate to the competition may also be helpful, but be sure to explain how they will benefit the team rather than listing a course catalog. 

Finally, you will describe your team’s educational goals and what your team hopes to gain by participating in the competition. You should be as specific as possible with your goals rather than listing vague high level goals – we want to know what makes your team unique!

Selected teams receive full conference registration for each team member and one advisor. Each team is also provided with lodging for the students and advisor. As the competition is part of the Students@SC program, students can also participate in mentoring and networking events like the Mentor–Protégé Matching program as well as the full slate of student programming. Travel to the conference, shipping for your cluster, and per diem are not provided.

NEW for SC26!

The SCC Committee will review the student clusters for operational readiness. Think of a typical real-world, user-facing supercomputer that computing centers run. How does your cluster compare to them and how ready is it for hypothetical end users? The evaluation can include the following areas: user and admin accounts, adding new users, job scheduler/management, cluster networking, security, monitoring, software environment management, etc. A detailed grading rubric will be shared in the coming months.

This component replaces the Reproducibility Challenge. 

Benchmarks

High-Performance Linpack (HPL)

The HPL benchmark solves a (random) dense linear system in double precision (FP64) arithmetic. It is often used to measure the peak performance of a computer or that of a high-performance computing (HPC) cluster. The ranking of the TOP500Supercomputers in the world is determined by their performances with the HPL benchmark.

Read more: https://netlib.org/benchmark/hpl/

HPL Mixed Precision (HPL-MxP)

While traditional HPC algorithms mostly require double-precision (64-bit) arithmetic, modern HPC workloads such as artificial intelligence (AI) can achieve desired results with lower precision (32 bit or lower). This shift in workloads and the advancement in novel accelerator architectures have led to the development of the mixed-precision HPL benchmark (HPL-MxP). HPL-MxP allows the traditional HPL solver to use reduced precision datatypes for LU factorization and couples this with an iterative refinement phase to ensure no loss in accuracy from a 64-bit solution. The outcome is a significant speedup compared to the FP64 implementation. Optimized implementation of HPL-MxP can be downloaded from respective vendor distribution channels (AMD and NVIDIA).

Read more: https://hpl-mxp.org/

MLPerf Training

The MLPerf Training benchmark suite measures how fast systems can train models to a target quality metric. Benchmarks under this suite target training models to particular ML tasks such as Large Language Modeling, Natural Language Processing, or Image Generation across a variety of of domain-specific datasets and aim to allow ML-system performance to be measured in a representative and architecture-neutral way.

Read more: https://mlcommons.org/benchmarks/training/ 

Applications

Weather Research & Forecasting Model (WRF)

The Weather Research and Forecasting (WRF) Model is a premier high-resolution mesoscale numerical weather prediction system that is used worldwide by atmospheric researchers and operational forecast teams alike to simulate the dynamics of typical and extreme weather events at scales ranging from tens of meters to thousands of kilometers.

An HPC center mainstay, WRF provides two dynamic cores, a robust data assimilation system, an architecture that supports parallel computation and system extensibility with MPI and OpenMP support, and relies on NetCDF for data management and compression.

High-resolution WRF simulations can be very computationally intensive at larger scales, requiring significant memory resources and parallel processing to resolve in a timely manner. To navigate this storm, SCC teams should consider the data management and memory requirements needed to accommodate large-scale simulations and the implementation of CPU parallelization optimizations when planning for this challenge.

Information on WRF can be found at: https://www.mmm.ucar.edu/models/wrf 

This application is supported by Wenxu (Zoey) Liao, Dania Al-Oqaily, Andrew Janiszeski, and Paola Crippa.

Multicomponent Flow Code (MFC)

The Multicomponent Flow Code (MFC) is a state-of-the-art computational fluid dynamics (CFD) simulator, solving partial differential equations representing the interactions of fluids such as air and liquids in complex systems, with real-world applications ranging from medical treatments to spacecraft takeoff.

This application is portable and scales ideally across hardware compositions ranging from consumer laptops to exascale systems. The MFC team’s recent benchmarks have proven the software’s ability to represent small-scale flow features while massively reducing the time and energy requirements for these simulations, earning recognition as a 2025 Gordon Bell Prize Finalist.

SCC teams will need to consider tuning their runs to parameters that align with their cluster’s capability for both CPU and GPU parallelism.

Information about MFC is available at: https://github.com/MFlowCode/MFC and https://mflowcode.github.io

This application is supported by Spencer Bryngelson. 

Equipment configurations, booth layout, and booth occupancy are always subject to safety as first consideration. If a task cannot be done safely, then it is unacceptable. When in doubt, ask an SCC committee member or team liaison. Any team operating in an unsafe manner may be subject to point penalties or disqualification.

When the exhibition is not open (after hours, before Monday opening Gala, after closing on Thursday) teams are not permitted in areas outside of the SCC booth, except to enter/exit the exhibit hall, or to use the restroom. Teams are never permitted to enter “off-limits” areas, such as staging areas used by the convention center staff. Teams that enter off-limits areas will be subject to point penalties or disqualification.

Teams are composed of six students, an advisor, and vendor partners:

• The advisor provides guidance and recommendations.
• The vendor provides the resources: hardware and software, and shipping of hardware to and from the competition. Vendors are also encouraged to cover the team members’ travel and incidental costs).
• The students provide the skill and enthusiasm.

Teams can optionally nominate up to two “logistics coordinators” who are secondary advisors or other support staff who should receive a copy of any communications sent to the primary advisor.

Teams will be invited to participate based on their Team Application, submitted via the SC Submission System. The Team Application includes a description of the team, the proposed hardware and software that will make up their cluster, and their approach to the competition, their diversity, and several other considerations. The SCC Committee reviews each proposal and provides comments for all submissions. The team composition and proposed hardware and software must all conform to the rules described below.

Advisor Requirements

• Advisors are required to be staff, faculty or graduate students of the team’s educational institution(s) or sponsoring HPC center.
• The primary advisor must be authorized to represent their institution, must attend the conference, and must be responsible for their team at all times.
• The primary advisor must be available 24 hours a day during the competition.

team Composition

Student Team Members must:

• Be enrolled in a university, college, high school, or equivalent level of academic insitution.
• Be at least 18 years old by the start of travel to the SCC (Friday, November 13, 2026 for students traveling internationally or Saturday, November 14, 2026 for students traveling domestically).
• Not have received a bachelor’s degree or equivalent before the beginning of the competition, Monday, November 16, 2026.

Team Makeup

Teams are encouraged to include diverse participation including new participants, under-represented groups, and a breadth of academic backgrounds. Teams will be gaining experience with a variety of scientific computing codes, so teams are also encouraged to recruit members with varying academic backgrounds. To encourage new participants and help new teams participate, teams that did not participate last year and teams comprised of more than 50% new students will be given preference at the discretion of the SCC Committee.

Assistance & Resource Access

During preparation for the competition, the Team Advisor, vendor partners, and other supporters are encouraged to help the team train for the competition. However, only the six registered team members will have access to any resources that may be provided during the training period.

No External Assistance

• Advisors, vendors, and other external people can help the teams set up their clusters in the exhibit hall. Once benchmarking begins, the six team members must work on the competition tasks with no external assistance – advisors, vendor partners and other supporters must not help the team in any way (other than to occasionally deliver coffee, snacks, etc). Outsourcing of competition tasks to either paid services or unpaid volunteers is not permitted.
• Teams are encouraged and allowed to help other teams. Teams are also encouraged to interact with conference attendees. Vendor partners, advisors, and alternate team members are welcome to come by during the exhibit hall hours to express support. However, teams must not receive advice or assistance from anyone except for other students competing on an SCC team (no attendees, exhibitors, advisors, vendor partners, alternate team members, etc can help) once benchmarking starts Monday morning.

Resource Access

• Once the competition starts on Monday morning, only the 6 team members that are listed on the team are allowed in the team booth or to touch any computers or equipment being used for the competition (including student laptops). Student team members may, upon invitation by another team, enter that team’s booth for the purpose of cooperative debugging.
• Teams are required to keep their booth and the area in front of their booth neat and presentable. No booth chairs are allowed to be placed outside of the booths.
• Terminal windows or screens not displaying visualization of the team’s work must not be readily visible to anyone outside the booth. This is to prevent attendees from seeing what the team is working on and offering advice.
• Teams are allowed access to clusters only via wired connection to their cluster and SCC local network. See the Network Connections section for further rules regarding network access.

Conduct

Teams must conduct themselves professionally and adhere to the Code of Conduct. Students must compete fairly and ethically.

Teams must adhere to all posted warnings, signs, and follow all instructions given by SC/ SCC committee members, convention center security/safety staff, and other officials. Teams may not attempt to bypass any security or safety devices or directives. Teams in violation of this rule may be subject to point penalties, disqualification, or expulsion from the convention center.

The two fundamental hardware requirements for team clusters are: 1) That they are able to run the applications and exercises of the competition, and 2) That they can operate within the power draw limits described below. Hardware must also meet the following constraints:

Hardware Availability

• All hardware used must be commercially available at the time of the start of the competition.
• Teams must display, for public view, a complete list of hardware and software used in the system.
• No hardware in the competition machine may be subject to a Non-Disclosure Agreement (NDA).
• All technical specifications of all hardware components must be available to the general public at the time of the start of the competition.
• All performance results from the competition hardware must be permitted to be published without restriction.

infrastructure Constraints

• Booths will be 10 feet wide x 10 feet deep and back to a solid wall. Teams must fit into this space along with the hardware for all activities. The back wall will have a mounted display and teams are to create a presentation for that display.
• Teams may only use equipment or tools they bring or with the permission of the tool owner. There are no tools or equipment provided by the conference or SCC for free use by the teams. If a team requires a tool or equipment, they must ask the SCC Committee for help in acquiring the tool. Teams may also ask other teams to borrow tools or equipment. Teams using tools or equipment without permission may be subject to point penalties or disqualification.
• An enclosure, no larger than a single 42U rack, must be provided by the team and all competition hardware must be installed in this rack throughout the competition. No competition hardware will be allowed on tables or pallets. The provided tables are intended as a workspace, eg, huddling around personal laptops.
• All hardware must be installed as it is intended to be installed. Rack-mount gear must be rack mounted. Desktop hardware may be placed on the floor. Any other hardware must be installed in an appropriate manner, e.g., hardware meant to be installed inside of an enclosure may not be laying around outside of an appropriate enclosure.
• No special cooling infrastructure is provided by the competition – student cluster hardware will be operating in normal conference center air. Any external cooling systems brought by teams must be closed-loop systems and use only the competition metered power. Once the competition starts no liquid may be removed or added to any cooling systems (e.g. no drains, no water sources).

Noise Exposure Limits

In the interest of safety, the committee wishes to prevent team exposure to noise levels greater than 85 dBA for an extended amount of time. All team cluster hardware must make an effort to not emit noise greater than 85 dBA, measured at the team booth table and neighboring team booth tables. Teams are encouraged to work with their vendor partners to determine the noise specifications in advance, consider alternative cooling solutions, controls to limit fan speed/noise, and soundproofing/dampening solutions

• Teams are encouraged to place their clusters at the rear of their booth and their table at the front to maximize distance between them.
• Noise monitoring will begin once benchmarking begins. Teams are encouraged to briefly test the noise level during setup; the SCC Committee will measure the noise level upon request.
• Teams found to be over the limit will be required to wear protective hearing gear and take immediate corrective action including using software controls, rearranging their booth/cluster (such as adding cardboard baffling), up to powering down the cluster until a solution can be found, at the discretion of the SCC committee.

Power Draw Limits

• Teams must ensure that their hardware, including networking gear, cooling gear, and any other equipment required to run the cluster, can run the applications and benchmarks without consuming more than 10,000W.
• Each team will be provided with one 208V circuit and a single Vertiv Geist NR30214 MNR3EDR6-12CF18-6PS15D0H10-S PDU (Part #VP6N62A1). All competition hardware must be powered through this PDU. Other systems (such as laptops, monitors, switches for connecting laptops to the cluster) will be powered from separate non-competition power sources which will be provided for by the conference.
  • These PDUs run at 208v and have 12 C13/C19 outlets for use. While there are places online that sell C13/C19 to US Type B (110v) cables, do NOT use these as they can very easily cause a fire or damage to the equipment. We strongly recommend not using 110v in your infrastructure as much as possible. The only safe way to step down from 208v to 110v is with something known as a step-down transformer, but these will add to the power consumption, overall noise, and heat. If more plugs are needed, there are C19 splitters available online as long as the combined load does not exceed the 19A/208V rating.
  • Teams should be prepared to tune their hardware’s power consumption based on the power measured through the PDU’s power monitor.
  • A team will be subject to a penalty any time a power draw on the PDU is registered at or above 10,000W for the computational system during the 48-hour or benchmarking competition. Any benchmark run during a power overdraw event will be considered invalid.
  • A team may be disqualified if the total power draw exceeds 11,000W at any time and for any duration.
• All components of the system must be powered through the competition PDU provided by the conference. Teams must not, at any time during setup or the competition, plug or unplug the networking connections plugged into the RJ45 ports of the PDU, or the PDU power connection to the convention center power supply If PDU, incoming PDU power connection, or PDU networking connection need to be reconfigured at any time, such as to rack mount the PDU, teams must request the assistance of the SCC infrastructure team. A team that disconnects PDU monitoring or incoming power connection without approval of the committee may be subject to penalties or disqualification.
• Battery backup or UPS (Uninterruptible Power Supply) systems may NOT be used during the competition.

HarDware Configuration

• The total power draw of all cluster components will be limited to 10,000W, including computational nodes, networking gear, storage, cooling, etc.
  • Teams should list detailed specifications of each node in their proposal, including any published power specifications of the major power draw components (e.g., the TDP of the CPU(s) and GPU(s)). The committee may reach out with clarifying questions or ask for clarifying documentation if the power limit is in question.
  • If you have a hardware proposal that does not fit into this structure, please reach out to the SCC Committee and we will attempt to accommodate your hardware configuration.
• Changes to hardware can be made until the end of benchmarking. No one is permitted to touch any hardware plugged into the competition PDU after the end of benchmarking until the end of the competition without permission from the SCC Committee. This includes, among other things, changing how the equipment is plugged into the PDU or reseating of cables plugged into the networking equipment powered by the competition PDU. In the case of hardware failure, replacements can be made while supervised by an SCC committee member.
• Use of sleep states (but no power-off and no hibernation) is permitted as long as when all devices in the rack are powered on into their lowest running OS (non-sleep) state they do not exceed the power limitation.

System Software

• All system software (operating system, drivers, filesystems, compilers, etc) used in the competition must be publicly or commercially available at the start of the competition.
• System software requiring a reboot may not be made after the benchmarking period. No reboots may be performed after the completion of benchmarking.

Benchmarks & Applications

• The application executables used in the competition may either be built by the team members from open source implementations or, in the case of using a vendor-provided binary/container, be sourced from a publicly-available source, e.g. by download from the vendor’s website.
• Executables may be built in advance by the team members, but teams must provide the URL of the source package (for tarballs, etc.) or commit hash (for git repositories, etc.). Teams should also be prepared to demonstrate building and running the executable if requested.
• Teams may study and tune the code used in the benchmarks and applications. Any modifications to the source code made by the team must be shared with the SCC Committee at least 2 weeks before the competition starts, and are subject to approval by the application judges. Judges reserve the right to reject modifications to the code (e.g., they do not produce scientifically acceptable results).

• All participants must attend the safety briefing before any unpacking or assembling of hardware, and before participating in the Benchmarking component or any computing tasks in the competition. Teams will NOT be permitted access to the exhibit hall until they have received a safety briefing. Team advisors will also NOT be permitted access to the SCC booth until they have received a safety briefing with their teams.
  • Teams whose travel schedule does not permit attending the scheduled safety briefing should contact the committee to arrange an alternative safety briefing that they can attend before performing any of those activities.
  • Teams experiencing travel delays should contact the SCC Committee ASAP to inform of the delays so alternative safety briefings can be arranged.
• All students must attend the Saturday Students@SC Orientation and Student Mixer.
• At least one student competitor from each team must attend the daily committee-and-teams stand-up meeting. Failure to attend may result in point penalties.
• There must be at least 2 student competitors in their team booth at all times while the exhibition floor is open (except during mandatory events scheduled elsewhere).

Further mandatory events will be announced at a later date.