Designing a collaborative cross-campus airport (or other transit) simulation project: panel discussion
Bibliographic record
Abstract
In this workshop participants will design a cross-campus collaborative project built around an airport (or other transit) simulation. Computer scientists and software engineers create simulations both to understand how processes work, and to avoid catastrophes in the actual implementations of those processes. At the last CCSC-NW, an airport simulation was proposed as a promising collaborative project because it is a large, real-world problem whose implementation potentially encompasses many disciplines. It makes use of multiple data structures, the potential for a nice graphical interface, and large data flows to process. The idea is an expansion of an assignment called the Airport Problem, which has been used as an intense culminating project in a Data Structures course both at the University of California, Santa Barbara, and at Clark College in Vancouver, WA. The premise of the Airport Problem is to complete a single project with multiple data structures so that students gain an understanding of the reasoning behind using different data structures. The Airport Problem uses three data structures: an incoming queue for airplanes arriving at the airport (a DEAP or Min-Max Heap), an outgoing queue for airplanes which have landed and are ready to take off (a Red-Black Tree), and a lobby for passengers who arrive and whose airplanes have not yet landed (a 2-3 tree or a linked list). The project proposed in this workshop would expand the Airport Problem to include additional components such as graphics and networking. Depending on participants' interests as well as availability of data, the transit mode could also be changed from Airport to either Shipping or Trucking.
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
How this classification was reachedexpand
Full frame machine prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. The Gemma side is a direct model label for every work in the frame, read from the title-only record. The Codex side is a classifier learned from the 10,348 direct Codex labels and calibrated to design-weighted sample rates; fields without enough sample support carry no Codex call. Candidate is the union of the two sides; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels.
Distilled classifier scores by category (both heads)
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.041 | 0.028 |
| Meta-epidemiology (narrow) | 0.002 | 0.001 |
| Meta-epidemiology (broad) | 0.001 | 0.002 |
| Bibliometrics | 0.001 | 0.001 |
| Science and technology studies | 0.012 | 0.003 |
| Scholarly communication | 0.010 | 0.010 |
| Open science | 0.006 | 0.020 |
| Research integrity | 0.013 | 0.011 |
| Insufficient payload (model declined to judge) | 0.056 | 0.015 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from itClassification
machine, unvalidatedMachine predicted; a candidate call from one source (direct Gemma or distilled Codex), not a consensus.
How this classification was reached, model by model and score by score, is at the end of the page under "How this classification was reached".