Sud now parses top-level grain_mass/water_mass (sibling to pot_mass/
pot_material/L/Td, defaulting to 0/0) - what's actually in the pot before
the brew starts, as opposed to default.step's grain_mass/water_mass, which
is just inert template filler. All sude/*.json docs gain explicit values
matching what their first step already resolved to.
tasks/sud.py's apply_plant_params() now takes grain_mass/water_mass
directly instead of a step dict: on_step_changed() still passes the active
step's own (these vary as malt goes in/water boils off), but the Load
handler now reads Sud.grain_mass/water_mass directly instead of parsing
schedule[0]. The GUI's status-line mass preview (shown immediately on
Load, before Start) does the same.
Also fixes a latent bug found along the way: _continue_forecast_after_confirm()'s
reconstructed sub-doc was missing L/Td/grain_mass/water_mass entirely,
silently falling back to generic defaults instead of the real Sud's own
values - invisible only because every current sude/*.json happens to use
those same defaults.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DkkuG48uHFCGKe6dPSERFk
Sud now parses top-level L/Td fields from sude/*.json (defaulting to 0.2/30,
matching the old hardcoded server constants), and derive_plant_params()
returns them alongside M/C - constant for the whole brew, unlike M/C which
vary per step with grain/water mass. All sude/*.json docs gain explicit
L/Td fields.
Callers (tasks/sud.py, SudForecastEstimator, demo_sud.py) switch from the
narrow set_thermal_params(M, C)/set_model_params(M, C) to the full
set_plant_params(params)/set_model_plant_params(params), since
derive_plant_params() now always returns all four keys; both narrow setters
are removed as dead code.
Caught along the way: Pot.set_plant_params() unconditionally rebuilt the
Delay ring buffer, which was harmless when only ever called once at
construction - but now running on every Sud step change, it was wiping
in-flight delayed power at each step boundary. Fixed to only rebuild when
Td actually changes; verified this restores the exact original forecast
result for sud_0010.json.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DkkuG48uHFCGKe6dPSERFk
Two compounding problems, found by actually running it:
- pot_mass=1/water_mass=1 (~2kg) is far lighter than the mass the real
PID gains are tuned for (~30kg, matching the real recipes) - same
heater power swings a 2kg pot far faster than the gains expect,
causing massive overshoot (24 -> 37.5 instead of holding at 24).
Fixed by using the same realistic mass as sud_0010.json/sud_0020.json.
- The overshoot then needed a passive cooldown back down to the next
step's target - independent of any declared rate, governed by the
plant's L/C time constant (~350 min here), regardless of mass.
Removed the (now unnecessary, since the overshoot is gone) explicit
cooldown step too.
Predicted/actual duration drops from ~408 min to ~18-21 min - verified
both via components/sud_forecast.py's estimator and a live run against
the real server (reaches DONE, no controller chattering).
6 steps covering a plain ramp, a wait-for-confirm step, a plain hold,
a combined ramp+hold (up), a combined ramp+hold (down, exercises
COOL), and a final confirm - all small temperature deltas and 1-minute
holds so a full run finishes in well under a minute at typical warp
factors, for quickly cycling through Load/Start/Pause/Stop/restart
scenarios without waiting through a real brew.
jensandClaude Sonnet 4.6