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.

Team clusters should be able to run the competition’s applications and exercises without exceeding a fixed power limit. More specific details regarding hardware requirements and other rules will be made available by the time team applications open. Refer to the last year’s rule set to get an idea of what the rules will look like for this year; however, power limits and other rules may change.

The IndySCC is a virtual companion competition to the SCC that shares many of the same goals. 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 the IndySCC was formed to provide additional opportunities for these teams to apply their hard work, gain experience, and come back stronger the next year and make it into the SCC.

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

Teams may also apply directly to the IndySCC, 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 IndySCC is that they are able to travel to the conference and compete in the SCC in a later year.

The IndySCC is intended for less experienced teams, and final selections will be made considering the strength of the application, motivations as they relate to the goals of IndySCC, 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. While listing technical specs is important, you should go further and explain how and why the hardware you chose will give your team an advantage.

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.

One of the applications presented to the student teams is the Reproducibility Challenge, in which students attempt to reproduce results from an accepted paper from the prior year’s Technical Program.

Students have the opportunity to interact directly with the paper’s authors as they attempt to reproduce specific results and conclusions from the paper. As part of this challenge, each student team writes a reproducibility report detailing their experience in reproducing the results from the paper. Authors of the most highly rated reproducibility reports may be invited to submit their reports to a reproducibility special issue.

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 TOP500 Supercomputers 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 Inference

Machine Learning (ML) is increasingly being used in many scientific domains for making groundbreaking innovations. MLPerf Inference is a benchmark suite for measuring how fast systems can run models in a variety of deployment scenarios. The key motivations behind this benchmark is to measure ML-system performance in an architecture-neutral, representative, and reproducible manner.

Read more: https://mlcommons.org/benchmarks/inference-datacenter/

Applications

Exascale Climate Emulator

Conventional climate models solve PDEs representing the interactions in Earth’s systems, a task whose computational and storage requirements increase dramatically with increasing resolution. Climate emulators alleviate those requirements to predict the results of a more-complex conventional climate model. 

One such emulator, trained on 318 billion hourly and 31 billion daily data points of surface temperature, generates hourly climate emulations that are statistically consistent with simulations, and was awarded the 2024 Gordon Bell Prize for Climate Modelling. The emulator utilizes the spherical harmonic transform to statistically model spatio-temporal variations in climate data and the PaRSEC runtime system to support efficient parallel matrix operations on exascale systems. SCC teams will demonstrate some aspects of the climate emulator on their own clusters.

The Gordon Bell paper is at https://dl.acm.org/doi/pdf/10.1109/SC41406.2024.00008. This application is supported by Qinglei Cao, Sameh Abdulah, and Zubair Khalid.

Structural Simulation Toolkit (SST)

The Structural Simulation Toolkit (SST) is a parallel discrete-event simulator used to model large-scale and high-performance computing platforms. It was developed to explore innovations in highly concurrent systems where the ISA, microarchitecture, and memory system interact with the programming model and communications system. SST enables this through a modular design, allowing for interoperability between various simulation components. Scalable simulation of large systems is supported through both MPI and multithreading. 

While many high-profile applications are suited to GPU acceleration, many important applications — including SST — are not, and SCC teams should take this into consideration while designing their clusters.

The SST web page is at https://sst-simulator.org/. SST and SCC25 are supported by Patrick Lavin, Shannon Kinkead, Clay Hughes, Gwen Voskuilen, and Scott Hemmert. 

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 14, 2025 for students traveling internationally or Saturday, November 15, 2025 for students traveling domestically).
• Not have received a bachelor’s degree or equivalent before the beginning of the competition, Monday, November 17, 2025.

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 that they are able to run the applications and exercises of the competition, and 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 Geist NR30214 MNR3EDR6-12CF18-6PS15D0H10-S PDU. 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.
  • 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 must be built by the team members from open source implementations.
• Vendor-provided executables for benchmarks are permitted as long as those executables are publicly available, e.g. by download from the vendor’s website.
• Teams using a vendor-provided binary for a benchmark must, at least 2 weeks before the competition starts, inform the committee of the URL for the binary and obtain confirmation from the committee that this is a valid binary for the benchmark.
• 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 repos, 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).

• A gigabit RJ45 network drop will be provided for outgoing connections only. Teams are required to include a gigabit RJ45 connection in their planning at minimum.
• Teams will NOT be permitted to access their clusters from outside the SCC-provided local network. All outgoing connections will be logged and possibly inspected.
• The only external sites that teams are allowed to access are publicly accessible websites. The committee may also choose to make public information about external websites that teams are accessing.
• VPNs, proxies, network tunneling, or remote desktop of any type to any equipment, including student laptops, connected to the competition hardware is not permitted. Examine any institution-provided laptops for VPNs that cannot be disabled or are hidden – consider using a personal device if possible.
• Competition hardware may be accessed via wired connections only – wireless access is not permitted. Teams must supply their own network cables, switches, and adapters for this purpose. This network equipment used to access the cluster (such as a small, cheap gigabit switch) can be powered from a regular 120V circuit separate from the metered PDU and provided by the SCC. Consider the dimensions of the booth and plan to bring appropriate length network, video, etc cables.
• Many commodity switches used for this purpose have a built-in wireless router. Any network devices provided by the teams or vendors in the competition area must have any wireless networking turned off. Free wireless Internet access for laptops will be available throughout the convention center via SCinet.
• Teams will be provided with a small power strip plugged into a single 120V NEMA 5-15 receptacle. Daisy-chaining of power strips is not permitted. Teams may replace this power strip with a larger power strip to accommodate laptop chargers, phone charges, and outlet adapters, etc or a power strip with appropriate outlets for the team’s laptops.

• Teams are responsible for obtaining their cluster hardware and transporting it to the convention center. Movement of equipment within the convention center must abide by conference logistics rules and be coordinated with Freeman, the SC vendor who handles the Exhibit Hall. Team vendor partners are encouraged to help their teams with this.
• Teams are responsible for their own travel arrangements to and from the conference, and for daily expenses such as meals. Team vendor partners are encouraged to help their teams with this.
• SCC will cover conference registration fees and provide hotel accommodations for the 6 team members and one advisor.

• 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.