Computer room temperature alarm: design and implementation for UPS
Bibliographic record
Abstract
During my 4-month employment period with IOT, there have been a considerable amount of problems with the present air conditioning system that is implemented within the computer room. This presents two major problems since: a) The computer room is not accessible to general employees at IOT, and as such, is not constantly monitored; b) The room contains hundreds of thousands of dollars in equipment, and invaluable amounts of information; CPU overheating could cause irreparable damage to this sensitive equipment and lose or corrupt file systems forever. The purpose of this project was to create and implement a system that would both monitor the status of the ambient temperature of the computer room, and notify the correct personnel when the temperature reaches an undesirable level. This was achieved through the use of the C programming language and the creation of functions, loops, and system calls within the existing checkups.c source code. The UPS is monitored by a program called checkUPS, that polls the UPS status through a buffer string every five seconds. I took advantage of this pre-designed polling system by pulling select values from the string buffer, which updated as the checkUPS software polled. The design and implementation of this particular program was successful, as well as time and cost effective. The program is currently in use at IOT for their UPS1 system. There are plans in the near future to implement this system for the UPS2 system and monitor more aspects of the UPS other than the ambient temperature.
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.001 | 0.002 |
| Meta-epidemiology (narrow) | 0.001 | 0.001 |
| Meta-epidemiology (broad) | 0.000 | 0.000 |
| Bibliometrics | 0.001 | 0.000 |
| Science and technology studies | 0.000 | 0.000 |
| Scholarly communication | 0.001 | 0.001 |
| Open science | 0.003 | 0.001 |
| Research integrity | 0.001 | 0.001 |
| Insufficient payload (model declined to judge) | 0.012 | 0.005 |
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".