Skip to main content

Student Cluster Competition

With sponsorship from hardware and software vendor partners, competing student teams design and build small clusters, learn scientific applications, and apply optimization techniques for their chosen architectures in a non-stop, 48-hour challenge.

48-hour hpc-a-palooza

Student Cluster Competition Schedule
Monday–Wednesday, November 18–20, 2024

student cluster

Student Cluster Competition Chair
Dan Dietz, Oak Ridge National Laboratory (ORNL)

Student Cluster Competition Vice Chair
Darshan Sarojini, University of California, San Diego (UCSD)

Student Cluster Competition (SCC) Applications open March 1, 2024.

Informational Webinars

Informational webinars are tailored for SCC/IndySCC participants. Future webinars will be added to the YouTube playlist as they become available.

SCC Applications

MAR 1, 2024

Applications Open

MAY 15, 2024

Applications Close

JUN 15, 2024

Notifications Sent

teams & Process

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.

SCC vs IndySCC

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.

Application Details

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!

support provided

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.

reproducibility challenge

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 & Applications

benchmarks

The competition begins with a benchmarking period on Monday, prior to the 48-hour competition. Teams will run industry standard benchmarks on their systems in an attempt to get the best score.

High-Performance Linpack (HPL)

The HPL benchmark solves a (random) dense linear system in double precision 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/

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/ 

Mystery Benchmark

The name of the benchmark will be revealed on the day of benchmarking. The teams will be required to follow the instructions for compiling and running the benchmark on their clusters during the allotted benchmarking duration. The teams should budget sufficient time to profile and tune the benchmark while staying below the power budget for the competition.

applications

There will be several real world applications for the teams to run during the 48-hour competition. A mystery application will also be announced at the start of the competition, so teams must be prepared to evaluate and fit this application into their strategy on the fly. Each real world application will consist of datasets, challenges, performance evaluations, and a judging interview all prepared by expert application judges. Webinars may be provided by the application judges prior to the competition to help you prepare.

NAMD

NAMD is a parallel molecular dynamics code designed for high-performance simulation of large biomolecular systems, winning the Gordon Bell Award in 2002 for its use of the Charm++ library to partition compute across multiple processors and nodes. NAMD has been used to address thousands of scientific questions around biomolecular systems by researchers the world over, including COVID-19 simulations that led to the 2020 Gordon Bell prize for HPC applications. NAMD is written in C/C++, and has been ported to run on multiple GPU architectures.

Visit NAMD Website

ICON

The  ICON (ICOsahedral Nonhydrostatic) earth system model  Earth System Model is an advanced tool for predicting weather, climate and environmental patterns. It is globally recognised and makes a significant contribution to our understanding of the Earth’s climate. ICON is particularly effective in addressing complex societal challenges and is at the forefront of computational innovation in weather, climate and environmental services. In addition, ICON uses sophisticated data management techniques to handle large datasets, improving the accuracy of its predictions.

Visit ICON Website

history

The Student Cluster Competition (SCC) was developed in 2007 to provide an immersive high performance computing experience to undergraduate and high school students.

For more information about SCC in past years, including team profiles, photos, winners, and more:

SCC FAQ

Q: Can we recruit alternate team members? Do we include their names on the application? Can alternate team members attend SC and participate in Students@SC even if they do not participate in the cluster competition?

A: You are welcome to recruit alternates, however, only the 6 team members are considered part of the team. They do not receive any support from the conference through the SCC (like registration or hotel). It wouldn’t hurt to mention you have alternatives in your application text, but that is not required (and we don’t need all their details). They are certainly more than welcome at the conference and in the Students@SC program (it is open to all students), they will just need to secure arrangements through other means.

Q: How much can we modify software for the competition, such as the kernel, slurm/job runner, libraries, and benchmark code?

A: You can modify software as needed for the competition, including the kernel, slurm/job runner, libraries, and benchmark code. The only requirement is that the software must be publicly available (free or otherwise) and not subject to non-disclosure agreements. Any modifications must be shared with the committee, especially for application codes, at least 2 weeks before the competition. Teams are encouraged to share any improvements upstream to benefit the wider community.

Q: What is the judging process like for the finals?

A: The final scoring is a combination of various competition components, including benchmark scores, completion of challenges, judging interviews, and possibly posters and other activities. The final score is based on a holistic evaluation of the team’s performance across these areas.

Q: How important is the vendor relationship for being accepted? (SCC-only)

A: Having a vendor or institution committed to providing hardware is essential for your application. While the final hardware configuration may change over time, you should have a solid plan in place for what you intend to bring to the competition at this stage.

Note: In IndySCC, the organising committee provides the necessary cloud-based HPC hardware to all accepted teams. IndySCC teams are welcome and encouraged to solicit vendors to support them with optional travel to the conference, provide meals during training, the competition, training, etc; however, this is not a consideration during team application review/selection for IndySCC teams.

Q: How should I brand and represent my team if it includes students from multiple universities?

A: Consider geographical or national affiliations if your team comprises students from your region or country.. The team’s name and branding can be adjusted as needed without affecting the team’s qualification or composition. If another team from your region/country joins the competition separately, it does not impact your team’s qualification or status in the competition. Each team’s identity and qualification are based on their actual composition of students, vendors, and support, regardless of geographical or national affiliations.

Q: Can we have cluster components sitting on the floor or on a palette?

A: No. Anything that is intended to be rackable needs to be in the rack. No cardboards/wooden palettes/bare floor.

Q: Our cluster consists of servers + desktop computers. Since we cannot put the desktop computer on the rack, we have to put it on the floor. Is this allowed?

A: As a desktop computer is intended to just sit on a surface, it is fine for it to sit on the floor. Please make sure it is not a trip hazard.

SCC Rules

The Student Cluster Competition (SCC) began in 2007 to provide an immersive high performance computing experience to undergraduate and high school students. The goal of the competition is to foster interest and experience in HPC for students. The SCC includes components that reflect current, real-world considerations and challenges encountered by HPC professionals.

Violation of any rule may result in point penalization or team disqualification, at the discretion of the SCC committee. Any unsafe, unprofessional, or unethical conduct not otherwise covered in these rules will also be penalized at the discretion of the SCC Committee. All decisions are the sole discretion of the SCC committee, and SCC committee decisions concerning the rules in a given situation are final.

Safety First

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

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

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, half of the students making up any team must be first-time participants in the SCC.

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 teams 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 physical connection to the 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.

Hardware Requirements

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 15 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

All team cluster hardware must not emit noise greater than 85 dBA, measured at the team booth table and neighboring team booth tables. Essentially, no team member shall be exposed to noise levels greater than 85 dBA wherever they will be sitting for extended periods. Teams are encouraged to work with their vendor partners to determine the noise specifications in advance, consider alternative cooling solutions, or controls to limit fan speed/noise.

  • 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 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.
  • Teams that repeatedly exceed the noise limit will be penalized 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 4500W.
  • Each team will be provided with one 208V circuit and a single Geist MN02E1R1-10L138-3TL6A0H10-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 4500W for the computational system during the 48-hour or benchmarking competition.
    • A team will be subject to disqualification if total power draw on the PDU is registered at or above 4900W 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 4500W, including computational nodes, networking gear, storage, cooling, etc.
    • The cluster must comprise at least three computational nodes. The power draw of each individual node will be limited to 2000W. 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 SCC committee will review each proposal and evaluate the specifications against the 2000W per node power limit. 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.

Software Requirements & Rules

System Software

  • All system software (operating system, drivers, filesystems, compilers, etc) used in the competition must be publically 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).

Network Connections

  • A gigabit RJ45 network drop will be provided for outgoing connections only. We also anticipate providing a 10/25 Gbit fiber with Generic Compatible 10/25GBASE-LR SFP28 1310nm 10km Duplex LC SMF optics modules for each team. Teams may bring their own compatible optics. These fiber drops will be connected directly to their respective file server, with outgoing connections going through a NAT on the file server. Teams opting to connect to the fiber connection should work with their vendors to ensure compatibility. The file servers will have a gigabit connection beyond the file server/NAT outside of the SCC network, the 10 or 25 Gbit fiber connection is only between the file server and your cluster.
  • Teams are required to include a gigabit RJ45 connection in their planning at minimum, should the 10/25 Gbit connection not be available. Should the faster connection be provided, competition datasets may be scaled to utilize the faster connections.
  • 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.
  • 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.
  • 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.

Logistics

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

Mandatory Events

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

SCC Mystery Application

The SCC is looking for scientific applications from the HPC community that could be used as the SCC Mystery Application. If you have a scientific application that you think would be a great fit for the competition, please consider submitting.

The application should not have export control restrictions, require non-disclosure agreements or other such restrictions, and must have up-to-date documentation. Submissions and selections must be kept confidential until the beginning of the SCC when the mystery application selected will be revealed.

Each submission must list an application owner who will:

  • be responsible for answering questions from the SCC teams,
  • prepare test and input decks for the competition, and
  • be available to serve as judge during SC24.

Applications Open March 1–May 31, 2024

Ready to Apply?

Create an account in the online submission system and complete the form. A sample form can be viewed before signing in.

If you have questions about SCC applications, please contact the program committee.

Indyscc

A cluster competition with the intent to create a more inclusive and education-focused track of the Student Cluster Competition.

Back To Top Button