Student Cluster Competition

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 supervisor or team liaison.

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. 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 or high school.
• Be at least 18 years old by the start of travel to the SCC (Friday, November 10, 2023 for students traveling internationally or Saturday, November 11, 2023 for students traveling domestically).
• Not have received a bachelor’s degree or equivalent before the beginning of the competition, Monday, November 13, 2023.

Teams are encouraged to include diverse participation including new participants and under-represented groups. 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 the cloud-based computational resources during the training period.

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 Network Connections 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.

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 x 10 feet 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.
• 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.
• 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).

Power Draw Limits

• Teams must ensure that their hardware’s power consumption and that their hardware can run the applications and benchmarks without consuming more than 4000W.
• Teams will be given an extra 500W for networking equipment outside the 4000W.
• Benchmarks will be run with a 4000W power limit for the computational hardware
  and a 500W power limit for the networking gear.
• 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) may 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 4000W for the computational system and/or 500W for the networking equipment during the 48-hour competition. Teams are allowed to go over these limits for brief periods during benchmarking for tuning purposes only.
  • 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 associated with the system or with access to it, 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.
• Battery backup or UPS (Uninterruptible Power Supply) systems may NOT be used during the competition.

HarDware Configuration

• Hardware should be comprised of at least three computational nodes. Individual nodes will be limited to 2000W power draw. Once benchmarking is done, no more changes to the PDU will be allowed. Total power draw for the computational portion of your machine will be 4000W.
  • Teams will be given 500W for networking equipment. Networking equipment will be limited to 500W. Networking equipment will need to be plugged into PDU ports separate from the computational hardware.
  • 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.
• No changes to the physical configuration are permitted after the start of the competition. No one is allowed to touch any hardware plugged into the competition PDU after the end of benchmarking and the start 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 publically or commercially available at the start of the competition.
• System software must not be modified after the benchmarking period.

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 1 week 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.

• A network drop will be provided for outgoing connections only.
• 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.
• 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 can be powered from a circuit external to the PDU and provided by the SCC.
• 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 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).

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

Part of the requirements for SCC23 is for you to create a poster about your team. The poster should be in an academic format and will be on display for the entire competition. There will not be a poster session, but the poster will be judged, and the score will be included in your team’s overall score. A copy of the judging rubric is included below.

Submission deadline

Due to lead times required for printing, the final print-ready version of the poster must be submitted not later than 10 September 2023. Failure to submit your final poster by the deadline will result in no points being awarded for the poster component of the competition.

poster printing requirements

• PDF format
• Portrait orientation, 3 foot wide by 4 foot tall
• Graphics, other than photos, should be vector images (e.g. SVG)
• Photos/raster images should be prepared at high enough resolution to not become overly pixelated when printed
• Upload your poster PDF to: SC Submission System

Poster Evaluation Criteria

Introduction to the Team and School

What is the composition of the team? How does team member diversity (skillset, majors, cultural background, etc) strengthen the team? Are all team members making valuable contributions to the success of the team?

Description of Hardware and Software with Rationale

Which technologies were selected (hardware, software, interconnect, etc) and why are they a good choice for this specific competition? In addition to your physical cluster, discuss your cloud configuration as well.

Preparation and Strategy

What are your optimization strategies for the applications? What are your team/time management strategies? How are you planning to leverage your hardware and cloud resources? How are you planning to handle the dynamic power limit? How does your preparation and planning support your success in the competition? Why will your team win?

Poster Presentation

Is the poster in compliance with the printing requirements? Is the poster visually appealing? Is the text well-written and error-free? Does the poster effectively communicate the content using both text and images? Does the technical content demonstrate a deep understanding of the team and systems?

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 and provides comments for all submissions. The requirements for teams are described more completely below.

Team clusters should be able to run the competition’s applications and exercises without exceeding a fixed power limit. This year the competition will include a fixed power limit of 4000W for the computational components of the cluster with an extra 500W for networking hardware for a total of 4500W. Hardware requirements are described more completely in the SCC Rules.

Selected teams receive full conference registration for each team member and one advisor. Each team is also provided with seven single-occupancy hotel rooms for the students and advisor. As the competition is part of the Students@SC program, students can also participate in Mentor–Protégé Matching and the Job Fair. Travel to the conference 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 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/

HPC Conjugate Gradient (HPCG)
The HPCG benchmark uses a preconditioned conjugate gradient (PCG) algorithm to measure the performance of HPC platforms with respect to frequently observed but challenging patterns of computing, communication, and memory access. While HPL provides an optimistic performance target for applications, HPCG can be considered as a lower bound on performance. Many of the top 500 supercomputers also provide their HPCG performance as a reference.

Read more: https://www.hpcg-benchmark.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/en/inference-datacenter-30/

optional benchmarks

STREAM Benchmark

The STREAM benchmark is a simple synthetic benchmark that measures sustainable memory bandwidth and the corresponding computation rate for simple vector kernels. It is designed to work with datasets that are much larger than the available cache on a processor and is, therefore, indicative of the performance of very large, vector style applications.

Read more: https://www.cs.virginia.edu/stream/

OSU Microbenchmarks

The OSU micro-benchmarks consist of a collection of MPI benchmarks that measure the performances of various MPI operations. These are broadly grouped into three benchmark types—i) point-to-point, ii) collective, and iii) one-sided. We will focus on point-to-point MPI benchmarks such as osu_latency and osu_bandwidth.

Read more: https://mvapich.cse.ohio-state.edu/benchmarks/

applications

MPAS (Atmosphere Core)
The Model for Prediction Across Scales—Atmosphere (MPAS-A) is an atmospheric simulation model for use in climate, regional climate, and weather research. MPAS-A supports global and limited-area domains with horizontal resolution from O(100) km down to O(1) km or less, and it employs unstructured meshes known as centroidal Voronoi tessellations (CVTs). The model consists of a dynamical core, which handles the resolved-scale equations of motion, as well as parameterizations of additional physical processes. MPAS-A is developed by the National Center for Atmospheric Research (NCAR), and it shares software infrastructure that was co-developed with the Los Alamos National Laboratory.

Key software characteristics of MPAS-A:

• Runs on hardware as limited as a Raspberry Pi or as powerful as the largest systems on the TOP500 list
• Primarily Fortran 2008 code, with some C
• Parallelization with MPI and OpenMP by horizontal domain decomposition
• Support (in a separate code branch) for executing parts of the model on GPUs via OpenACC

Homepage in NCAR’s MMM Lab: https://www.mmm.ucar.edu/models/mpas

Source code repository: https://github.com/MPAS-Dev/MPAS-Model

3DMHD (Three-Dimensional Magneto Hydro Dynamic)
This is a numerical simulation, written in Fortran with MPI, to study the descent of cold and dense plumes in a stratified layer. Such simulations are important to understanding dynamics of plume development in regards to thermal and magnetic forces inside of stars.

Source code repository: https://github.com/dsmithlasp/Rast-3dmhd