Research
FCS is a research society. Members work in small teams on one question at a time: reproduce published work, extend it, measure carefully, and report what they find, including what did not work.
Three tracks
The tracks cover the stack from the machines up to the math. Each is a starting point, not a fence: projects can draw on more than one.
Systems & AI Infrastructure
Track A · Teams forming — Spring 2027
The hardware and software that train and serve models: schedulers, memory, networks, and the measurements that show where the time goes.
Example research questions
- How much of an open-weight model's inference time on a single GPU is spent waiting on memory rather than computing, and how does that change with batch size?
- Does storing a model's attention cache at 8 or 4 bits change throughput and output quality enough to matter on a small serving setup?
- When one node in a distributed key-value store slows down, how much does tail latency suffer, and can a simple hedged-request policy hide it?
What you'd build
Benchmark harnesses, profiling scripts, and small serving setups or system prototypes, with the configs needed to rerun every number.
Skills
- Python or C/C++
- Linux and the command line
- Profiling and measurement
- Operating systems and architecture basics
Good first step
Profile one inference run of a small open-weight model and write down where the time goes.
AI Models
Track B · Teams forming — Spring 2027
How models behave and how we know: building evaluations, testing benchmark claims, and fine-tuning small models to see what actually changes.
Example research questions
- How much does a model's score on a public multiple-choice benchmark move when the answer options are reordered or reworded?
- Does fine-tuning a small open-weight model on one narrow task lower its accuracy on unrelated tasks, and does a parameter-efficient method such as LoRA change how much?
- How often do LLM-as-judge scores agree with human ratings on a fixed set of responses, and where do they disagree?
What you'd build
Evaluation suites, fine-tuning runs with fixed seeds and reported variance, and write-ups that compare against a stated baseline.
Skills
- Python and PyTorch
- Basic statistics
- Reading ML papers
- Careful data handling
Good first step
Rerun a published evaluation of an open-weight model and check whether you get the reported number.
Theoretical Computer Science
Track C · Teams forming — Spring 2027
What can be computed and how fast: algorithm design, discrete math, and complexity, with quantum algorithms and complexity as one topic.
Example research questions
- On structured graph families, how close do simple greedy or local-search algorithms come to the optimal max-cut, and can we prove a bound for one family?
- Can a SAT solver settle the small cases of a combinatorial extremal problem, and do the solutions it finds suggest a general construction?
- For small search problems, does Grover's algorithm still give a speedup once the cost of building the oracle circuit is counted?
What you'd build
Proofs and written arguments, careful reproductions of known results, and small programs or circuit simulations that test conjectures.
Skills
- Proof writing
- Discrete math and probability
- Algorithms
- Linear algebra, for the quantum topic
Good first step
Work through the proof of one classic result line by line and present it to the reading group.
Looking for quantum hardware or a quantum-first community? doQuantum UVA is a good home, and you can join both.
The year
Seven steps from your first meeting to a finished project.
01 Join
Come to a Thursday meeting and join the Discord. No research experience is needed, and dues are never required.
02 Workshops & reading group
Workshops cover the tools each track uses. The reading group works through papers together and asks what each one does and does not show.
03 Pick a track
Choose Systems, Models, or Theory based on what you want to learn. Officers and other members can help you decide.
04 Form a team
Small teams form around one research question each, proposed by members or brought by researchers and industry collaborators.
05 Reproduce, then extend
Each team starts by reproducing a published result. Once you match it, or can explain why you cannot, you change one thing and measure what happens.
06 Peer review
Teams read each other's methods and drafts and question the evidence before anything is presented.
07 Showcase
At the end of the semester each team presents its findings, code, and limitations, including what did not work.
Research standards
These follow the purposes in the Society's constitution and apply to every project.
- Reproducibility
- Every result comes with the code, data sources, and settings needed to rerun it.
- Transparent baselines
- Claims are measured against a stated, simple baseline, and the full comparison is reported, including where the new method falls short.
- Open tools where appropriate
- We use open tools and publish code and write-ups when licenses, privacy, and agreements allow.
- Ethics, privacy, security, and safety
- Projects weigh privacy, security, safety, and social impact from the start, and every write-up states its limitations and risks.
Open projects
Project proposals open soon. Have an idea?
Tell us