Implement a Multicore Overheat Prevention Controller

## Problem Simulate a firmware controller that prevents a multicore processor from overheating. Each core has a configured workload, all cores share passive cooling, and each running core can receive a dedicated active-cooling channel. Implement a pure function that processes the controller operations in order: ```text simulateOverheatController( passiveCapacity, activeCapacityPerCore, coreIds, operations ) -> list of Tick results ``` Each operation is one of: ```text ["set", timestamp, coreId, loadWatts] ["tick", timestamp] ``` Return one array for every `tick`. Each array contains strings in the form `"coreId=status"`, sorted by `coreId`, for exactly the cores whose status changed at that tick. A status is `idle` for a running core without active cooling, `cooling` for a running core with active cooling selected for the next interval, or `shutdown`. ### Initial State and Pending Loads Every core starts at `20.0` degrees Celsius, running with load `0`, active cooling off, and status `idle`. A `set` operation records a pending load but performs no temperature calculation. If several pending loads target the same core before the next `tick`, keep only the last one. For a running core, the pending load takes effect after temperature advancement and shutdown checks at the next `tick`. For a shutdown core, `set` is a one-time restart request: at that next `tick`, restart with the pending load only when its temperature is strictly below `50.0`; otherwise discard the request and leave the core shut down with load `0`. The first `tick` establishes the time origin and advances temperatures by zero seconds. Every later `tick` advances from the previous `tick` timestamp. A `set` timestamp determines operation order but does not split the thermal interval. ### Thermal Advancement During an interval, use the loads and active-cooling choices established by the previous `tick`. For every core, passive demand is `load + 2` watts. If `k` cores had active cooling during the interval, effective passive capacity is: ```text passiveCapacity * (1 - vibrationPenalty(k) / 100) ``` where: ```text vibrationPenalty(0) = 0 vibrationPenalty(k) = sum(10 / Fib[i] for i = 1..k) Fib = [1, 2, 3, 5, 8, 13, ...] ``` If total demand is at most effective capacity, each core receives its full demand. Otherwise, a core receives the same proportional fraction of its demand: ```text passiveForCore = effectiveCapacity * coreDemand / totalDemand ``` A core selected for active cooling receives an additional `activeCapacityPerCore` watts. Its net heat is: ```text load - passiveForCore - activeCoolingForCore ``` Temperature changes by `0.02` degrees Celsius per second for each watt of net heat and never falls below `20.0`. A shutdown core has load `0` and no active cooling, but it still participates in passive-demand allocation through its `2`-watt demand. After advancement, shut down every core whose temperature is at least `80.0`, clear its load to `0`, and discard any pending ordinary load for that now-shutdown core. Then process the pending load and restart rules described above. ### Choosing Active Cooling Recompute active cooling from scratch after pending loads are processed. Shutdown cores are never selected. Find the minimal stable selected set with this monotone procedure: 1. Initially select every running core whose current temperature is above `60.0`. 2. For the current selected-set size `k`, recompute the effective passive capacity and passive allocation using current loads. 3. For each running core not yet selected, compute its temperature rate without active cooling. If that rate is strictly greater than `0.5` degrees Celsius per second, select it. 4. Repeat steps 2 and 3 until no core is added. This captures the feedback in which each new active channel increases vibration, reduces passive cooling for everyone, and can force additional channels on. The selected set applies until the next `tick`. ### Status Reporting Compare each post-tick status with its status after the previous `tick`, using the initial `idle` status before the first one. Report each changed core once. Temperature or load changes alone are not status changes. ### Constraints & Assumptions - `1 <= len(coreIds) < 1024`; identifiers are unique nonempty strings. - `passiveCapacity > 0` and `activeCapacityPerCore > 0`. - `1 < len(operations) < 1024`. - Operation timestamps are globally strictly increasing positive values with millisecond precision. - `0 <= loadWatts <= 32768`, with at most three decimal places. - Test values stay safely away from the exact `50.0`, `60.0`, `80.0`, and `0.5` comparisons except when the stated strictness is intentionally tested. - Return every floating-point-independent status transition exactly; no temperature values are returned. ### Clarifying Questions to Ask - Does the first tick integrate from epoch zero? No; it establishes the controller's time origin. - Does a pending load affect the interval ending at the next tick? No; it takes effect only after that interval is advanced. - Does a failed restart request remain pending? No; another `set` is required. - Does an active-cooling selection carry over automatically? No; it is recomputed from scratch, although its physical effect lasts through the interval ending at the next tick. - Do shutdown cores consume passive demand? Yes, through the fixed `2`-watt term. ```hint Separate interval state from next-interval state Advance with the previous tick's load and cooling snapshot before applying shutdowns, pending loads, restarts, or a new cooling decision. ``` ```hint Cooling selection is a monotone fixed point The candidate set only grows. Recompute the vibration-dependent passive share after each growth step until no unselected running core exceeds the rate threshold. ``` ### Evaluation Focus - Preserves lazy load semantics and last-write-wins behavior between ticks. - Applies threshold strictness correctly for restart, temperature cooling, and active-cooling selection. - Uses the previous interval's active set for temperature advancement and the new set only for the upcoming interval. - Handles simultaneous shutdowns, failed and successful restart attempts, and cascaded active-cooling engagement. - Produces alphabetically sorted, transition-only output. - Avoids per-second simulation; work should be proportional to cores and fixed-point iterations per operation. ### Extensions to Discuss 1. How could repeated passive allocations be accelerated when only a few loads change? 2. What numeric strategy would make cross-language threshold behavior reproducible? 3. How would you expose temperature and cooling decisions for diagnosis without changing status semantics?