Расчёт режима

Возможности

• Плановый режим («Обычный»): расчётные расходы потребителей по удельным расходам или по температурному графику, тепловые потери в сети, внутренние тепловыделения, ветер, расчёт дроссельных органов, коэффициенты смешения.
• Аварийный (фактический) режим: сеть в текущем состоянии — закрытые участки, отключённые потребители и оборудование как в базе; сопротивление потребителей «Детализированное» или «Эквивалентное», «Летний режим».
• По списку: до 50 фрагментов по очереди одним запуском, тип расчёта — плановый или аварийный для всех.
• Проверка данных до расчёта (только чтение): несвязанные потребители, подсети без источника, несколько источников в подсети, отключённые потребители, оборудование без параметров.
• Остановка идущего расчёта и повтор с теми же установками — из протокола («Остановить», «Пересчитать»).

Как это работает

1. Окно отправляет установки на сервер (POST /api/v1/calculations/run). Ключи командной строки движка сервер собирает сам из полей формы и сверяет с белым списком: из браузера нельзя передать произвольный ключ. Автор расчёта — из учётной записи.
2. Задача встаёт в очередь Celery (tgid.<город>), её берёт воркер расчёта. Окно каждые 2 с спрашивает состояние задачи и пишет в протокол ход: «в очереди», «выполняется», этапы движка («Чтение данных фрагмента», «Расчет фрагмента 1/3»…).
3. Движок — heatnet в профиле fixed (с 01.11.2026 на всех городах): гидравлический расчёт методом Ньютона с проверкой сходимости по шагу и невязке, затем тепловой расчёт. Устройство расчёта и формулы — в разделе Основы.
4. Результаты пишутся в таблицы *_out базы города (us_out — узлы, ut_out — участки, pt_out — потребители и другие) с номером расчёта; разобранный протокол — в calculation_protocol. Новый расчёт становится «текущим» для своих фрагментов: его показывают карта, карточки, пьезометр и анализ режима.
5. Флажки записи в исходные данные (дроссели, нагрузки и потери в обобщённый потребитель, коэффициенты смешения) меняют саму сеть, а не только результаты. Запись нагрузок в обобщённые потребители требует отдельного подтверждения.

Температура наружного воздуха. Значения берутся из «Системы теплоснабжения» города: t_or (расчётная для отопления), t_vr (для вентиляции), t_vnew (конец отопительного периода), среднесезонные. Для отопительного режима допустимы значения от расчётной для отопления до конца периода; любое — от −60 до 50 °C только в летнем режиме.

Что нужно для работы

• Право «Запуск расчётов».
• Воркер расчёта города запущен и слушает очередь tgid.<город>; без него задача так и останется «в очереди».
• В фрагменте — хотя бы один источник или узел с заданным напором, и потребители, подключённые участками. «Проверить данные» покажет, чего не хватает.

Шаги

1. Окно «Установки расчёта планового режима». Сверху — режим: «Обычный» (плановый), «По списку» (несколько фрагментов по очереди), «Аварийный».

   

2. Аварийный режим считает текущее состояние сети (отключённые участки и потребители — как в базе). Сопротивление потребителей — «Детализированное» или «Эквивалентное», отдельно — «Летний режим».

   

3. Температура наружного воздуха — из «Системы теплоснабжения»: расчётная для отопления, для вентиляции, конец отопительного периода, среднесезонная — или «Своя». Под полем — допустимый диапазон.

   

4. «Проверить данные» до расчёта: что остановит расчёт и что исказит результат. Итог — в окне, подробности с объектами — в протоколе под окном («Показать протокол»).

   

5. «Расчёт» ставит задачу в очередь; ход виден в протоколе на вкладке «Текст расчёта». В конце — «Статус: расчёт выполнен», ошибки и предупреждения — на вкладке «Анализ».

   

Примеры

Плановый расчёт фрагмента 74 при −25 °C (копия базы Алматы, 1777 узлов, 1037 потребителей, 2214,7 Гкал/ч):

• «Проверить данные»: ошибок 0, предупреждений 3, к сведению 5. Не считаются 8 потребителей без участков (16,3 Гкал/ч, 1 %) и 5 подсетей без узла с заданным напором; в одной подсети два узла с заданным напором (ЦТРП и ТЭЦ-1) — возможны перетоки; 34 потребителя (45,6 Гкал/ч) отключены закрытыми участками.
• «Расчёт»: 20 с от постановки в очередь до результата. В протоколе — 2 ошибки и 7 предупреждений: регуляторы давления, которые не могут обеспечить уставку (например, «Задано 59.0 м., получено 51.19 м.»), и подсеть с двумя источниками.

Если не получается

• «Необходимо выбрать фрагмент для расчёта» / «Выберите хотя бы два фрагмента» (режим «По списку»).
• «Температура наружного воздуха должна быть от … до … °C» — значение вне диапазона «Системы теплоснабжения»; для летнего режима включите «Летний режим».
• Задача долго «в очереди» — воркер расчёта не запущен или занят другим расчётом.
• «Статус: расчёт выполнен частично (есть ошибки)» — часть подсетей не посчитана; причины — на вкладке «Анализ» протокола.
• Флажки записи в исходные данные серые — на сервере выключена правка данных (подсказка под формой).

Для администратора

• Движок: SETY_ENGINE (heatnet или прежний legacy) и HEATNET_PROFILE в окружении службы воркера; меняются без перезапуска API — читаются при каждом расчёте.
• Ограничение времени: SETY_TIMEOUT_S (для расчёта по списку — ×50). Срок хранения протоколов: CALC_PROTOCOL_KEEP_DAYS.
• Запись в исходные данные — только при MUTATIONS_ENABLED; иначе сервер отвечает 503 на ключи записи.
• В журнал действий пишутся запуск (RUN_SETY) и остановка (STOP_SETY) расчёта.

Для разработчика

• API: POST /api/v1/calculations/run (тело SetyRunRequest), POST /api/v1/calculations/validate ({fragment_id}), GET /task/{task_id}, POST /api/v1/calculations/{task_id}/cancel, GET /api/v1/calculations/temperature-range. Код — routers/calc.py, сборка ключей — sety_modes.py, воркер — worker.py (run_sety_calculation).
• Веб: components/PlanningCalculationModal.vue, проверка Tн — utils/calcTemperature.ts.
• Тесты: tests/components/PlanningCalculationModal.spec.ts, tests/utils/calcTemperature.spec.ts; API — tests/test_sety_modes.py, test_calc_cancel.py, test_sety_engine.py.