171 lines
26 KiB
Markdown
171 lines
26 KiB
Markdown
# План: Gauss-ускоритель — симулятор и оптимизатор
|
||
|
||
Многоступенчатый электромагнитный ускоритель ферромагнитного цилиндра (coilgun).
|
||
Каждая ступень: разгонная катушка (Cu/Al провод на пластиковой трубке) + батарея
|
||
конденсаторов через тиристор/MOSFET, и датчик прохода снаряда перед катушкой
|
||
(компенсация задержки включения ключа). Датчик — два конкурирующих варианта:
|
||
индукционная катушка (сигнал ~ скорости снаряда, слаб на медленных ступенях) и
|
||
оптопара/датчик Холла (не зависит от скорости) — оптимизатор сравнивает оба.
|
||
|
||
Цель поиска — КПД (кинетическая энергия снаряда на выходе / энергия во всех
|
||
конденсаторах). Скорость и стоимость — вторичные метрики. Число ступеней N,
|
||
геометрия/материал снаряда, все компоненты — часть пространства поиска, а не
|
||
фиксированные входы. Компоненты — реальные, розничные (Проконтакт/procontact74.ru,
|
||
ChipDip, Cable.ru и др.).
|
||
|
||
Требование: миллионы прогонов (Monte Carlo/LHS sweep + эволюционный поиск),
|
||
**все** результаты — успешные и неудачные, с честной причиной отказа — пишутся
|
||
в SQLite. Никаких приукрашенных цифр — если модель показывает низкий КПД или
|
||
нереализуемость, это тоже результат.
|
||
|
||
**Найденная и исправленная ошибка (Этап 3):** насыщение сердечника изначально
|
||
клэмпилось только в механическом уравнении (F=0.5·I²·dL/dx), но не в
|
||
электрическом (наведённая ЭДС всё ещё считалась по полной dL/dx) — это
|
||
незаметно ломало точный энергобаланс на ~15%. Тест на сохранение энергии
|
||
(этого же честного протокола, который просил пользователь) это поймал.
|
||
Решение: клэмп насыщения убран из динамики (F=0.5·I²·dL/dx без клэмпа,
|
||
энергобаланс теперь точен до ~0.02%), а `solenoid_field_estimate_tesla`/
|
||
`saturation_scale` оставлены как ДИАГНОСТИКА — `StageResult.saturation_warning`
|
||
честно предупреждает, когда конфигурация физически выходит за пределы
|
||
насыщения материала снаряда, не подменяя динамику. Полная нелинейная
|
||
L(x, I)-модель с coenergy-выводом силы — в разделе "ограничения модели"
|
||
как будущая работа, не как текущая гарантия точности.
|
||
|
||
Полный план архитектуры: см. историю обсуждения / `physics`, `sim`, `optim`,
|
||
`storage`, `report` модули ниже.
|
||
|
||
**Docker — основной способ запуска** (по требованию пользователя): `Dockerfile`
|
||
+ `docker-compose.yml` в корне репозитория, образ собран и провалидирован —
|
||
внутри контейнера запускаются все 37 тестов и CLI (`docker compose run --rm
|
||
--entrypoint pytest gausse -q`). Результаты (SQLite и отчёты, когда появятся)
|
||
монтируются в `./results` на хосте, чтобы переживать пересборку образа.
|
||
|
||
## Чек-лист этапов
|
||
|
||
- [x] **Этап 0 — Скелет проекта**: `pyproject.toml`, `README.md`, `.gitignore`, пакеты `src/gausse/*`, этот файл, первый коммит.
|
||
- [x] **Этап 1 — База реальных компонентов**: провод Cu/Al, конденсаторы, тиристоры/MOSFET/IGBT, датчики (Hall/оптика реальные, индукционный — оценка), материалы снаряда → `components/data/*.json`. Каждая запись честно помечена REAL (с URL источника) или ОЦЕНКА (с указанием основания); алюминиевый провод и ёмкости 1000/2200мкФ — низкая уверенность в цене, явно отмечено.
|
||
- [x] **Этап 2 — Физическое ядро**: `physics/constants.py`, `inductance.py` (Уилер + ферромагнитный сердечник + размагничивание), `force.py`, `circuit.py` (ОДУ RLC). Юнит-тесты: аналитическое RLC-решение, согласованность dL/dx.
|
||
- [x] **Этап 3 — Датчики и одна ступень**: `physics/sensors.py` (оба типа как события solve_ivp), `sim/stage.py` (полёт → триггер → разряд → энергобаланс). Тест на сохранение энергии + найден/исправлен баг насыщения (см. выше).
|
||
- [x] **Этап 4 — Многоступенчатая цепочка**: `sim/coilgun.py` — сквозная координата, отбраковка нереализуемых конфигураций. Дымовой тест на реальной базе компонентов (`test_real_components_smoke.py`) подтверждает: полный путь реальные JSON → физика → цепочка работает (пример: 22.3 м/с, КПД 3.4% — честный неоптимизированный результат).
|
||
- [x] **Этап 5 — Хранилище результатов**: `storage/schema.py` + `database.py` — SQLite (WAL), таблица `runs` со всеми прогонами (успех/провал + честная причина), однопроцессный писатель поверх многопроцессной очереди. Тест с реальными `multiprocessing.Process` (не моками) поймал реальную проблему: коллизия `run_id` роняла writer и молча останавливала осушение очереди на весь sweep — писатель теперь переживает ошибку вставки одной записи (лог в stderr) и продолжает работу.
|
||
- [x] **Этап 6 — Поиск и оптимизация**: `optim/search_space.py` (геном переменной длины — число ступеней тоже эволюционирует), `objective.py` (fitness=КПД, честный мягкий штраф за нереализуемость пропорционально пройденным ступеням), `optim/sweep.py` (параллельный Monte Carlo, каждый прогон в SQLite), `optim/evolutionary.py` ((μ+λ)-ГА + Nelder-Mead полировка непрерывных параметров лучшего генома). Тест поймал реальный баг в `crossover()` — IndexError при скрещивании двух одноступенчатых геномов (пустой список зазоров), исправлено и покрыто регрессией.
|
||
- [ ] **Не сделано**: отдельный "дешёвый квазистатический предфильтр" перед полным ODE не реализован (кроме уже встроенной в `sim/stage.py` дешёвой проверки порога индукционного датчика). Если миллионы прогонов на сервере окажутся слишком медленными, это первое место для ускорения.
|
||
- [x] **Этап 7 — Отчётность**: `report/plots.py` (ток/поле/скорость по ступеням), `summary.py` (честная сводка + раздел "ограничения модели"), `bom.py` (спецификация деталей с ценами), `animate.py` (GIF: снаряд летит по трубе, катушки светятся пропорционально току — по запросу пользователя), `cli.py` (`gausse sweep/evolve/simulate/report`, все 4 команды реально вызывают соответствующие модули, не заглушки). Проверено сквозным прогоном через `docker compose run`: sweep → report с анимацией на реальной базе компонентов, лучший найденный результат — КПД 32.8% за 982₽ (не выдумано, из реального SQLite).
|
||
- [x] **Этап 8 — Сквозная проверка**: реальный прогон через `docker compose run` — sweep на 5000 конфигураций (16 воркеров, ~59с, 30.5% реализуемо), затем `evolve` (15 поколений x 40 особей = 600 оценок, ~18с) поверх той же базы, затем `report --top 3 --animate`.
|
||
- **Найден и исправлен реальный баг именно на этом этапе**: КПД лучшего генома после `evolve` показал 387% — оказалось, `efficiency` считался как `exit_kinetic_energy / energy_in`, а `exit_kinetic_energy` включает фиксированный "бесплатный" толчок `initial_v_mps`, не учтённый в `energy_in`. Для лёгкого снаряда этот толчок доминировал и КПД пробивал 100%. Исправлено на `kinetic_energy_delta / energy_in` (энергия, реально добавленная катушками) — эта величина математически не может превысить 1 (следует из поэтапного энергобаланса). После исправления лучший результат на тот момент: **1 ступень, КПД 80.97%, скорость 26.4 м/с, снаряд Ст3 ⌀4мм x 30мм, стоимость 1029₽** (провод cu-petv2-1.0mm, конденсатор 22мкФ/400В, ключ IRG4PC50F, оптический датчик). *(Историческая запись: это физика v1 БЕЗ потерь в железе, скина и трения — после их добавления такие КПД невозможны, см. «хронологию честности» ниже.)*
|
||
- **Честное сравнение датчиков** (запрос из первого обсуждения плана) — на 5000 прогонах: индукционный датчик (`inductive-pickup-lm393`) дал **0.2% реализуемых** конфигураций (6 из 2965, где он стоял хотя бы на одной ступени), тогда как оптический (TCST2103) и Холла (A3144E) — **~45-47%** реализуемых каждый. Это количественно подтверждает опасение, высказанное в самом начале обсуждения плана: индукционная катушка-датчик ненадёжна именно потому, что требует скорости выше её порога (здесь — фиксированный старт 3 м/с как раз ниже порога срабатывания реального компонента), тогда как оптика/Холл не зависят от скорости.
|
||
- Итог: сквозная цепочка (реальные компоненты → физика → поиск → SQLite → отчёт с графиками/BOM/анимацией) работает и произвела не выдуманный, а посчитанный и перепроверенный результат.
|
||
- [x] **Обогащённая БД + лог процесса + веб-морда** (по запросу пользователя при деплое): каждая запись `runs.decoded_summary_json` теперь содержит расстояния между катушками (`inter_stage_gaps_m`), абсолютные позиции катушек вдоль трубы, все номиналы деталей, геометрию намотки, вычисленную физику (индуктивность/сопротивление/пиковый ток/поле) и результат каждой ступени (вход/выход скорость, тайминги датчика, энергобаланс) — см. `optim/objective.py::build_detail`. Ход эксперимента пишется в `<db>.log` (`optim/progress_log.py`): прогресс, доля реализуемых, скорость, ETA, отметки нового лучшего КПД. Веб-дашборд `gausse serve` (`src/gausse/web/`, только stdlib `http.server`, self-contained HTML) — счётчики, гистограмма КПД, топ конфигураций с drill-down, причины отказа, хвост лога, автообновление 3с. В `docker-compose.yml` сервис `web` на порту 8000. 77 тестов, проверено в Docker.
|
||
|
||
## Батареи конденсаторов + графики в веб-морде (по запросу пользователя)
|
||
|
||
- **Батареи конденсаторов** (`components/schema.py::CapacitorBank`): каждая ступень собирает банку из N одинаковых конденсаторов — `n_series` (1-6, складывает напряжение и ESR, делит ёмкость) × `n_parallel` (1-8, складывает ёмкость и макс.ток, делит ESR). Цена и количество масштабируются. Параметры банки — в геноме (`cap_series`, `cap_parallel` на ступень), в BOM ("N шт (Sпосл × Pпар)") и в подробной БД (`capacitor_bank`: состав, суммарные C/V/ESR/макс.ток). Диагностика по току: `bank_current_over_limit` / `switch_current_over_limit` (предупреждение, не жёсткий отказ — в базе паспортный, а не импульсный ток; параллельные конденсаторы дают реальный выигрыш через сниженный ESR).
|
||
- **Уже было (тоже запрашивалось)**: разная толщина провода на разных катушках (`wire_idx` на ступень) и длина провода (`winding_geometry.total_wire_length_m` → сопротивление/цена/БД).
|
||
- **Графики в дашборде**: клик по прогону → графики скорость/поле/ток строятся на лету (`web/render.py`, `/api/run/<id>/plot/<kind>.png`) + GIF пролёта по кнопке (`/api/run/<id>/anim.gif`). Рендер matplotlib сериализован локом (Agg не потокобезопасен). 86 тестов.
|
||
|
||
## Развёртывание на сервере (Proxmox 192.168.20.254 / VM 106 "test-math" = **192.168.20.47**)
|
||
|
||
**СТАТУС: развёрнуто, работает АВТОНОМНО (CPU-эволюция под systemd), GPU проброшен и рабочий.**
|
||
|
||
- VM 106: Ubuntu 24.04, 5 ядер, 12ГБ RAM. После перевода на q35 (нужен для
|
||
PCIe-проброса) интерфейс переименовался и IP сменился **.45 → .47**
|
||
(netplan починен привязкой по MAC).
|
||
- [x] Пуш на gitea (`gitea.jze9.ru/jze9/gausse.git`) — рабочий процесс: пуш с
|
||
локальной машины → `git pull` на VM.
|
||
- [x] GPU: `qm set 106 --machine q35 --hostpci0 0000:01:00,pcie=1`; в VM
|
||
драйвер NVIDIA 580 + CUDA, `cupy-cuda12x[ctk]` в `~/gausse/.venv`.
|
||
`nvidia-smi` видит GTX 1070 без Code 43.
|
||
- [x] Веб-морда: **http://192.168.20.47:8000** (Docker-сервис `web`).
|
||
- [x] **Автономная эволюция — systemd-сервис `gausse-evolve`** (пользователь
|
||
явно потребовал: «алгоритм должен считать сам, годами, без тебя»):
|
||
`/etc/systemd/system/gausse-evolve.service` крутит `evolve_forever.sh` —
|
||
вечный цикл `run_evolution(80 поколений × 300 особей, polish=True)` с новым
|
||
случайным семенем на каждом заходе (свежая популяция = «революция» против
|
||
застревания в локальном оптимуме). `Restart=always` + `enabled` → переживает
|
||
и падение процесса, и перезагрузку VM. Всё пишет в одну базу
|
||
`~/gausse/results/gausse.sqlite3`; «запланировано N» на дашборде — план
|
||
ТЕКУЩЕГО цикла, сам поиск бесконечен. Управление: `sudo systemctl
|
||
status|stop|restart gausse-evolve`, лог `journalctl -u gausse-evolve`.
|
||
- Обновление кода на VM: `cd ~/gausse && git pull && docker compose build web
|
||
&& docker compose up -d web && sudo systemctl restart gausse-evolve`.
|
||
|
||
- [x] **Этап 9 — GPU-ускорение массового sweep — СДЕЛАН**:
|
||
`gpu/batch_integrator.py` — батч-RK4 фиксированного шага [Q,I,x,v] на N
|
||
конфигураций одним тензором (numpy/cupy через `xp`), та же физика, что
|
||
CPU-путь (общий `sim/stage.build_stage_physics` — один источник истины).
|
||
Весь RK4-шаг слит в ОДНО `cupy.fuse`-ядро → **GTX 1070: 740 конф/с vs 193
|
||
на numpy = 3.8x** (наивный порт был 1.3x — упирался в запуск ядер);
|
||
SYNC_EVERY=256 убирает device→host синхронизацию на каждом шаге.
|
||
`gpu/batch_sweep.py` — МНОГОСТУПЕНЧАТЫЙ sweep раунд-за-раундом (подлёт
|
||
аналитически, состояние снаряда переносится между раундами), CLI
|
||
`gausse sweep --gpu`. Требование честности выполнено: GPU сверен с
|
||
CPU-эталоном — расхождение exit_v **0.084%** (tests/test_batch_sweep.py,
|
||
test_batch_integrator.py). Стиффные конфиги, переполняющие фикс-шаг,
|
||
честно бракуются (blew_up), а не записываются мусором.
|
||
- [ ] (опция) дослить cut-логику в ядро (>3.8x); GPU-батч внутрь эволюции.
|
||
|
||
## Физика: найденные завышения КПД и их исправления (хронология честности)
|
||
|
||
Пользователь ловил нереальные цифры; каждое исправление РОНЯЛО КПД к
|
||
реальности. Версия модели пишется в каждую запись БД (`model_version`),
|
||
прогоны разных версий не смешиваются.
|
||
|
||
1. **Поле 13 Тл** → насыщение железа через единое потокосцепление
|
||
λ(x,I)=L_air·I+L_iron·overlap(x)·g(I), g=I_sat·tanh(I/I_sat); сила и ЭДС
|
||
из одного λ (coenergy) → энергия сохраняется, поле упирается в B_sat.
|
||
2. **Ток сверх рейтинга ключа** → жёсткая отбраковка по импульсному пределу.
|
||
3. **КПД 83.9%: не было потерь в железе** → вихревые токи: снаряд =
|
||
короткозамкнутый виток, отражённое R_eddy=(ωM)²/R_e × overlap(x)
|
||
(physics/losses.py). Лучший упал 83.9% → ~47%, медиана ~0%.
|
||
4. **Три горба тока за выстрел** (физически невозможно — конденсатор не
|
||
перезарядить за мкс) → одиночный импульс: обрыв на первом нуле тока ИЛИ
|
||
первом локальном минимуме; остаточная энергия катушки → freewheel-диод,
|
||
считается точно через magnetic_energy (с насыщением). Энергобаланс сошёлся.
|
||
5. **gausse-physics-v2 (2026-07-08)**: скин-эффект + эффект близости обмотки
|
||
(метод Доуэлла на ω=1/√(LC), `physics/ac_resistance.py`) — для толстого
|
||
провода во многих слоях R_AC в разы выше DC; **трение о трубку**
|
||
(0.35·m·g) и **сопротивление воздуха** (½ρ·Cd·A·v²) во всей динамике
|
||
(разряд, подлёт с событием «снаряд остановлен трением», GPU-ядро,
|
||
аналитический межступенчатый пролёт — точная квадратура); паспортные
|
||
импульсные токи ключей из даташитов (`pulse_current_a`: ITSM/IDM/ICM)
|
||
вместо generic-множителей + починен вводивший в заблуждение флаг
|
||
(`switch_current_over_continuous_rating` — норма для импульса,
|
||
`switch_current_over_pulse_limit` — брак). КПД ступени теперь может быть
|
||
слегка отрицательным (трение съело больше слабой катушки) — это честно.
|
||
Для сравнения на одной и той же эволюции: v1 давал «38%» там, где v2 даёт
|
||
~8% — столько стоили неучтённые скин и трение.
|
||
|
||
## Требования пользователя, закрытые после Этапа 8
|
||
|
||
- **Снаряд до 200 г** (⌀ до 28мм, длина до 150мм, длина зажата по плотности).
|
||
- **Труба — часть поиска**: геном несёт внутренний диаметр (бор) + толщину
|
||
стенки; внешний диаметр трубы = внутренний диаметр катушки (влияет на
|
||
поле); снаряд обязан влезать в бор с зазором.
|
||
- **До 10 ступеней**; у каждой катушки СВОЙ датчик на своём расстоянии
|
||
(sensor_to_coil_distance_m на ступень; datчик не может попасть в предыдущую
|
||
катушку — repair()).
|
||
- **Ссылки на магазины** (`url`) у каждого компонента: в JSON-базе, BOM
|
||
(«Купить») и в детализации прогона.
|
||
- **Максимально детальная запись** в БД (`build_detail`): труба
|
||
внутр/стенка/внеш, масса снаряда в граммах и влезает-ли-в-бор,
|
||
внутр/внеш диаметры катушки, состав банки конденсаторов, DC/AC
|
||
сопротивление обмотки, все позиции датчиков и катушек вдоль трубы,
|
||
энергобаланс каждой ступени.
|
||
- **Анимация переделана** (была «время вырезается, результата не видно»):
|
||
кадры на равномерной сетке ФИЗИЧЕСКОГО времени (а не по индексам массива,
|
||
из-за чего плотные точки разряда съедали все кадры и подлёт выпадал),
|
||
множитель замедления в кадре; в кадре сам результат эксперимента — шапка
|
||
(выход м/с, КПД, ступени, энергия, масса), панель тока каждой катушки во
|
||
времени, панель скорости снаряда, бегущий курсор, датчики на трубе.
|
||
|
||
## Ограничения модели / следующие шаги по реализму (если потребуются)
|
||
|
||
- Поршневой эффект воздуха в трубе (учтено только лобовое сопротивление).
|
||
- Диффузия поля в снаряде (наш r_eddy — сосредоточенная оценка 1-го порядка).
|
||
- Спектр импульса для Доуэлла (взята одна характерная частота).
|
||
- Нагрев провода за импульс/серию; коэффициент трения не измерен (0.35).
|
||
- Гистерезис посчитан (losses.hysteresis_energy_j) и СОЗНАТЕЛЬНО не в
|
||
динамике: <0.1% энергии выстрела — включение изображало бы ложную точность.
|
||
- Индуктивность — Уилер+размагничивание, не МКЭ/FEA.
|
||
- Осторожно: не тюнить модель под «желаемую» цифру КПД — только физика.
|