Ladybug Tools: руководство от гика, климат, солнце, свет и энергомоделирование в Grasshopper

↓Скачать Ladybug Tools

Ladybug Tools — это не одна автономная программа с собственным окном, а открытая экосистема компонентов и Python-библиотек для экологического и энергетического анализа зданий и городских моделей. В актуальном сценарии для Rhino пользователь работает на полотне Grasshopper, связывает компоненты Ladybug, Honeybee, Dragonfly и Fairyfly, а вычисления передаёт профильным движкам — Radiance для светотехнических задач, OpenStudio/EnergyPlus для энергомоделирования и URBANopt для районного масштаба. Такой формат делает Ladybug Tools особенно полезным там, где расчёт должен оставаться частью параметрической модели, а не отдельной операцией после экспорта геометрии.

На 4 сентября 2026 года основной агрегирующий пакет lbt-grasshopper активно поддерживается: последняя подтверждённая версия общей линии — 1.10.54 от 3 сентября 2026 года. В текущем наборе зависимостей присутствуют Ladybug Grasshopper, Honeybee Core, Honeybee Radiance, Honeybee Energy, Dragonfly и Fairyfly. Это важное уточнение для старых учебных материалов: исторический Butterfly остаётся отдельным проектом семейства Ladybug Tools и связан с OpenFOAM, но в актуальный метапакет lbt-grasshopper он не входит.

Обзор ниже рассматривает именно современный Ladybug Tools для Grasshopper, а не старые Legacy-компоненты и не коммерческие продукты Pollination. Это принципиально разные уровни экосистемы: Ladybug Tools остаётся бесплатным открытым набором, Pollination предлагает отдельные установочные и облачные сервисы, а Rhino является самостоятельным коммерческим CAD-приложением, в котором открывается Grasshopper.

Основные параметры Ladybug Tools

Параметр	Актуальное состояние
Тип продукта	Набор открытых компонентов Grasshopper и Python-библиотек для экологического анализа, моделирования зданий и городских систем
Разработчик	Проект Ladybug Tools и его открытое сообщество; развитие и коммерческая поддержка связаны с Ladybug Tools LLC
Текущая линия	lbt-grasshopper 1.10.x; последняя подтверждённая общая версия — 1.10.54 от 3 сентября 2026 года
Хост-интерфейс	Rhinoceros 3D + Grasshopper; компоненты появляются на вкладках Grasshopper, результаты отображаются также во viewport Rhino
Основные модули текущего метапакета	Ladybug, Honeybee Core, Honeybee Radiance, Honeybee Energy, Dragonfly, Fairyfly
Основные движки	Radiance для световых и пространственных солнечных расчётов; OpenStudio/EnergyPlus для энергии; URBANopt для районных энергетических сценариев; THERM-связанные рабочие процессы доступны через Fairyfly
Исходные климатические данные	EnergyPlus Weather — EPW; Ladybug также содержит компоненты импорта DDY и STAT
Лицензия текущего метапакета	GNU Affero General Public License 3.0
Цена Ladybug Tools	Бесплатно; отдельного платного Pro-режима для lbt-grasshopper нет
Дополнительные расходы	Для графического Grasshopper-сценария нужна лицензия Rhino; облачные продукты Pollination являются отдельными сервисами
Интернет	Нужен для загрузки, обновлений, получения погодных файлов и некоторых внешних сервисов; локальные расчёты с установленными движками и локальными файлами не требуют постоянной облачной сессии
Язык компонентов	Английские названия и параметры, например LB Import EPW, HB Model to OSM, HB Annual Daylight, DF Model to geoJSON

Совместимость в линии 1.10.x определяется не одной цифрой Rhino. Актуальная матрица Ladybug Tools связывает базовый выпуск 1.10.0 с Python 3.10.10, Radiance 5.4, OpenStudio 3.10.0, OpenStudio App 1.10.0, URBANopt CLI 1.1.0 и Rhino 8.28, но отдельно предупреждает: номер Rhino в строке — это распространённая версия на момент выпуска, а не жёсткий минимальный порог. Поэтому при обновлении рабочего места важнее совпадение линии Ladybug Tools и расчётных движков, чем буквальное повторение номера Rhino из таблицы.

Что именно входит в продукт и чем модули отличаются

Ladybug отвечает за климатические данные, базовую солнечную геометрию, тепловой комфорт и визуализацию. Его типичный вход — EPW-файл, из которого извлекаются температура, влажность, скорость и направление ветра, радиационные величины и географическая привязка. Эти данные можно фильтровать по периоду, связывать с геометрией и превращать в диаграммы, карты и пространственные графики.

Honeybee Core формирует расчётную модель здания: Rooms, Faces, Apertures, Shades и связанные свойства. В отличие от обычной геометрии Rhino, Honeybee-объект хранит семантику, необходимую симулятору. Например, Room должен быть замкнутым объёмом; из него затем выводятся зоны, ограждения, проёмы, граничные условия, материалы и другие параметры для энергетического или светового расчёта.

Honeybee Energy связывает Honeybee-модель с OpenStudio и EnergyPlus. Компонент HB Model to OSM пишет Honeybee JSON, OSM и IDF, при необходимости OSW, а после запуска возвращает SQL, CSV с детальными нагрузками, RDD и HTML-отчёт. Встроенный Annual Loads предназначен для ранней оценки нагрузок и прямо отделён в документации от полноценной оценки годового энергопотребления: для детального HVAC, расходов энергии, стоимости и выбросов требуется полная модель через HB Model to OSM.

Honeybee Radiance формирует сетки сенсоров и запускает рецепты Radiance. Актуальные компоненты охватывают Daylight Factor, Annual Daylight, Annual Irradiance, показатели daylight autonomy, ASE, пространственную автономность дневного света и импорт почасовых результатов. Сетка Sensor Grid from Rooms строится по полу Honeybee Rooms и задаёт пространственное разрешение исследования.

Dragonfly переносит логику с отдельного здания на квартал или район. Он умеет сериализовать Dragonfly Model в URBANopt-совместимый GeoJSON, создавать связанные Honeybee JSON для отдельных зданий, запускать URBANopt через EnergyPlus, а также работать с электрическими сетями OpenDSS, дорожной сетью RNM и районными тепловыми системами. Эти функции нужны не для каждой архитектурной модели: они становятся оправданными, когда объект исследования — множество зданий и инфраструктура.

Fairyfly — новый участник текущего метапакета. Его репозиторий включён в зависимости lbt-grasshopper, а актуальный Primer описывает THERM-ориентированные объекты, в том числе FF Boundary с температурой, коэффициентом плёночной теплоотдачи и тегом U-factor. В 2026 году Fairyfly получил компоненты для выявления проблемных областей, управления сеткой и Model Exposure. Он не заменяет Honeybee Energy: это более узкий слой для двухмерного теплопереноса и ограждающих конструкций.

Butterfly по-прежнему существует в экосистеме и в отдельном Primer связывается с OpenFOAM, однако его компоненты не перечислены в текущем requirements.txt метапакета lbt-grasshopper. Поэтому ставить знак равенства между «Ladybug Tools 1.10.x» и «Ladybug + Honeybee + Dragonfly + Butterfly» уже некорректно: современный агрегированный Grasshopper-набор содержит Fairyfly, а Butterfly следует рассматривать как самостоятельный OpenFOAM-путь.

Платформы, установка, требования и цена

Основная графическая среда Ladybug Tools — Rhino и Grasshopper. На Windows официальная wiki рекомендует бесплатный Pollination Grasshopper installer как самый простой путь: для его загрузки требуется учётная запись Pollination, а сам установщик ставит совместимые копии Ladybug Tools, Radiance и OpenStudio изолированно от других установок этих движков. Ручной путь через installer.gh остаётся документированным и полезен тем, кому нужен полный контроль над расположением библиотек.

Для macOS в официальной wiki сохранена отдельная ручная инструкция. Она также строится вокруг загрузки Ladybug Tools и выполнения installer.gh в Grasshopper; Windows-описание single-click Pollination installer не распространяется автоматически на Mac. Точная совместимость конкретной сборки Rhino и конкретной версии macOS должна оцениваться вместе с текущими требованиями Rhino и линией Ladybug Tools, поскольку матрица LBT не объявляет номер Rhino строгим единственным порогом.

Разные типы расчёта требуют разных движков. Для климата, sun path, psychrometric chart, wind rose и части геометрических анализов достаточно базового Ladybug. Для daylight и пространственных солнечных рецептов Honeybee нужен Radiance. Для расчёта годовой энергии и HVAC Honeybee использует OpenStudio/EnergyPlus. Для DF Run URBANopt нужен URBANopt CLI. Такое разбиение помогает не устанавливать всё подряд на компьютер, где выполняется только один класс исследований.

Лицензионная стоимость самого lbt-grasshopper равна нулю: это открытый проект, текущий метарепозиторий публикуется под AGPL-3.0. У Ladybug Tools нет отдельного ограниченного Free-тарифа, платной Pro-редакции или пробного периода, потому что основной пакет уже бесплатен. Практическая стоимость рабочего места складывается вокруг хоста Rhino, времени на освоение Grasshopper и, при необходимости, внешних коммерческих сервисов вокруг экосистемы. Pollination не является платной «редакцией Ladybug Tools» и не должен смешиваться с лицензированием открытого плагина.

Регистрация не обязательна для самого открытого кода и ручной установки, но нужна для загрузки бесплатного single-click Pollination installer. Это различие важно для приватности: базовые модели, EPW, JSON, OSM, IDF, SQL и другие результаты пишутся в локальные каталоги, а использование облачных функций Pollination — отдельное решение пользователя и организации.

Интерфейс: Rhino, Grasshopper и расчётные представления

У Ladybug Tools нет единого главного окна. Рабочая область разбита между полотном Grasshopper и viewport Rhino. На canvas находятся компоненты, числовые параметры, переключатели, списки и проводники данных; в Rhino показываются геометрия модели, цветовые поля, sun path, пространственные сетки и другие результаты. Поэтому интерфейс ближе к визуальному программированию, чем к классическому инженерному приложению с меню «Файл — Расчёт — Отчёт».

Вкладка Ladybug организована по категориям. Актуальный Primer перечисляет 0 :: Import, 1 :: Analyze Data, 2 :: Visualize Data, 3 :: Analyze Geometry, 4 :: Extra и 5 :: Version. Такая структура задаёт понятную семантику: сначала поступают климатические данные, затем они фильтруются и анализируются, после чего переводятся в графику или связываются с геометрией. Honeybee и Dragonfly используют собственные вкладки с похожим разделением на создание объектов, свойства, сериализацию, симуляцию и результаты.

Параметрическая природа интерфейса — одновременно главное достоинство и основной порог входа. Компонент не хранит «готовый ответ» сам по себе; ответ получается из связей. Один EPW может кормить несколько графиков, один Honeybee Model — энергетический и Radiance-рецепты, а один Analysis Period — одновременно фильтровать климат, солнце и итоговые метрики. Изменение геометрии или исходного параметра проходит по графу и обновляет зависимые узлы.

Для презентации данных используется объект VisualizationSet. Многие современные визуальные компоненты имеют выход vis_set; его можно передать в LB Preview VisualizationSet, выбрать viewport и 2D-легенду, затем запечь результат в Rhino или выгрузить набор в файл .vsf через LB Dump VisualizationSet. В отличие от простого preview сетки, VisualizationSet хранит сведения о типах линий, прозрачности, режимах отображения и легендах.

Названия компонентов и большинство официальных учебных материалов англоязычные. Это не косметическая деталь: диагностика почти всегда сводится к пониманию того, что именно подано на inputs и что вернул outputs. Термины rooms, apertures, sensor grids, simulation parameters, analysis period, vis_set и geoJSON регулярно встречаются прямо в графе. Пользователю без знакомства с английской инженерной терминологией придётся освоить её хотя бы на уровне названий объектов.

Основные функции и рабочая логика

Климатические данные и фильтрация периодов

Ladybug читает стандартные EnergyPlus Weather (.EPW) и превращает погодные ряды в типизированные Data Collections. Из одного файла извлекаются местоположение и погодные величины; Analysis Period позволяет ограничить год нужными месяцами, днями и часами. Это основа для сезонного анализа, когда проектное решение оценивается не по усреднённому году, а по конкретному рабочему периоду.

SunPath, ветровой и психрометрический анализ

LB SunPath строит солнечные положения по location и часам года, выдаёт векторы, азимуты, высоты солнца, геометрию и VisualizationSet. Масштаб по умолчанию соответствует радиусу 100 м в единицах текущей модели Rhino при scale=1. Климатические данные можно привязать к точкам солнца и получить не просто геометрический календарь, а карту температурных или иных условий на траекториях.

Ветровые диаграммы показывают распределение направления и скорости, а psychrometric chart связывает температуру и влажностное состояние воздуха. Это не отдельные симуляторы здания: они помогают сформировать климатическую гипотезу до детального моделирования — например, понять сезонность ветра, диапазоны комфортности и ориентацию по солнцу.

Геометрический солнечный и радиационный анализ

В разделе Analyze Geometry есть компоненты для direct sun hours, incident radiation и других пространственных операций. Ladybug строит анализ на геометрии Rhino и небесных/солнечных данных. Для лучевого расчёта, требующего физического Radiance, рабочий процесс переходит в Honeybee Radiance; простые геометрические задачи остаются внутри базового Ladybug.

Honeybee-модель здания

Honeybee переводит Rhino-геометрию в расчётные сущности. Room from Solid принимает замкнутые polysurface или mesh и создаёт Rooms; документация подчёркивает, что Room должен оставаться закрытым объёмом, иначе нарушаются расчёты объёма и появляются light leaks в Radiance. В модель можно добавлять apertures, shades, программы помещений, construction sets и radiance modifier sets.

Энергомоделирование через OpenStudio и EnergyPlus

HB Model to OSM сериализует Honeybee Model в промежуточные и расчётные форматы, затем при включённом запуске передаёт модель в EnergyPlus. Simulation Parameter задаёт run period, timestep, terrain, shadow calculation, sizing и набор выходов. Через OpenStudio Measures можно расширять модель без ручного редактирования итогового IDF; меры подключаются к тому же компоненту экспорта.

Дневной свет и годовые Radiance-рецепты

Для grid-based расчётов Sensor Grid from Rooms строит точки по полу с задаваемым размером ячейки и высотой над полом. Годовой рецепт возвращает файлы результатов, из которых считаются DA, cDA, UDI, ASE и другие метрики. Сетка — часть модели исследования, а не просто способ отрисовки: без неё годовая метрика не получает пространственных точек, которым можно назначить освещённость.

Районные модели Dragonfly

Dragonfly Model может быть записан в URBANopt-совместимый GeoJSON, где здания связываются с детальными Honeybee JSON. При запуске URBANopt модель проходит через OpenStudio/EnergyPlus, а на выходе формируются сценарий CSV, OSM/IDF, SQLite/SQL, зональные CSV, RDD и HTML-отчёты. Дополнительные ветви Dragonfly охватывают электрические сети и district energy, поэтому этот модуль ориентирован на масштаб квартала и инфраструктуры.

Параметрическая автоматизация

Автоматизация строится средствами Grasshopper: один граф может принять набор геометрий или сценариев, изменять параметры и передавать результаты дальше. В DF Run URBANopt есть настройка количества CPU; по умолчанию она использует на один процессор меньше доступного числа, оставляя минимум один. В Honeybee есть пакетные компоненты вроде Run OSM, принимающие несколько файлов. Поэтому пакетность здесь является свойством графа и конкретного simulation component, а не отдельной очереди задач в центральном интерфейсе.

Облако, мобильность и ИИ

Основной lbt-grasshopper — настольный Grasshopper-процесс. Он не является мобильным приложением и не требует обязательной облачной обработки для локальных расчётов. Pollination предоставляет отдельные облачные продукты и установщик, но эти сервисы не превращают открытый плагин в SaaS. В актуальной документации основного Grasshopper-набора нет встроенного генеративного ИИ-ассистента; описанные функции основаны на параметрическом графе, физических движках и детерминированных расчётных рецептах.

Задача → инструмент → результат → что проверить

Задача	Инструмент	Результат	Что проверить
Разобрать климат площадки	LB Import EPW, Analysis Period, климатические диаграммы	Типизированные погодные ряды и графики	Город, часовой пояс, период, единицы величин
Оценить солнце по ориентации	LB SunPath и солнечные векторы	Солнечные положения и траектории во viewport Rhino	North, location, выбранные HOY, масштаб
Оценить облучение геометрии	Ladybug Analyze Geometry / Radiance-рецепт по требуемой точности	Значения радиации на сетке или поверхностях	Контекст, направление нормалей, небесные данные, единицы
Собрать расчётную модель здания	HB Room from Solid, HB Model и свойства Honeybee	Honeybee Model с Rooms, проёмами и параметрами	Замкнутость Rooms, имена, adjacencies, construction/program assignments
Посчитать энергию	HB Model to OSM + OpenStudio/EnergyPlus	OSM, IDF и при запуске SQL/CSV/RDD/HTML	EPW, Simulation Parameter, совместимость OpenStudio, отчёт EnergyPlus
Посчитать годовой daylight	HB Sensor Grid from Rooms + HB Annual Daylight	Annual Radiance results и производные метрики	Наличие grids, размер ячейки, настройки Radiance, фильтр сеток
Моделировать квартал	DF Model to geoJSON + DF Run URBANopt	GeoJSON, Honeybee JSON, сценарий и пакет EnergyPlus-результатов	Location, корректность footprints, CLI URBANopt, число CPU
Подготовить теплотехническую границу	FF Boundary	Fairyfly Boundary для THERM-сценария	Планарность линии, температуры, film coefficient, U-factor tag
Сохранить графику отдельно от расчёта	LB Preview VisualizationSet / LB Dump VisualizationSet	.vsf или baked-геометрия Rhino	Выбранный data set, viewport, 2D/3D legend parameters

Эта карта показывает, почему Ladybug Tools нельзя оценивать только по количеству компонентов. Один и тот же объект может пройти несколько стадий: климат задаёт граничные условия, Honeybee формирует физическую модель, внешний движок выполняет расчёт, а Ladybug возвращает визуализацию. Ошибка на ранней стадии распространяется дальше, поэтому итоговый график всегда нужно связывать с исходным EPW, геометрией и настройками рецепта.

Карта форматов и совместимости

Формат	Роль	Редактируемость	Что теряется или сохраняется
EPW	Основной погодный вход Ladybug и EnergyPlus-сценариев	Текстовый погодный формат; обычно используется как исходник	Сохраняет почасовую погоду и location; не хранит геометрию проекта
DDY	Design-day данные для расчётных условий	Импортируется отдельным Ladybug-компонентом	Хранит расчётные дни, а не полный почасовой климат
STAT	Статистическая климатическая информация	Читается компонентом Import STAT	Дополняет EPW, но не заменяет часовой погодный ряд
Honeybee JSON	Сериализация Honeybee Model и Simulation Parameter	Структурированный JSON, пригодный для обмена между библиотеками	Сохраняет семантику расчётной модели; не является Rhino-моделью оформления
OSM	OpenStudio Model после HB Model to OSM	Открывается средствами OpenStudio	Содержит энергетическую модель, но не заменяет исходный параметрический граф Grasshopper
IDF	EnergyPlus Input Data File	Текстовый формат EnergyPlus	Сохраняет вход EnergyPlus; параметрические связи Grasshopper в нём отсутствуют
OSW	OpenStudio Workflow	JSON-процесс OpenStudio	Создаётся при мерах или некоторых стандартизированных workflow; описывает цепочку, а не итог симуляции
SQL / SQLite	Результаты EnergyPlus/URBANopt	Машиночитаемая база результатов	Хранит численные выходы; не содержит исходный дизайн как редактируемую CAD-модель
CSV	Зональные нагрузки, URBANopt-сценарии, результаты сетей	Открывается таблицами и скриптами	Удобен для передачи чисел, но теряет объектную структуру Honeybee/Dragonfly
RDD	Словарь доступных EnergyPlus outputs	Текстовый справочный результат	Помогает выбрать переменные; не является итоговым отчётом проекта
HTML	Summary Reports EnergyPlus	Просмотр в браузере	Сохраняет отчётное представление, но не предназначен для обратного редактирования модели
ILL и папки Radiance results	Почасовые годовые daylight/irradiance результаты	Читаются компонентами HB-Radiance	Сохраняют данные сенсоров; пространственный смысл зависит от исходных sensor grids
GeoJSON	Импорт/экспорт Dragonfly и URBANopt	Структурированный GIS-совместимый текстовый формат	Сохраняет полигоны зданий и свойства; детальные модели связываются отдельными Honeybee JSON
VSF	Файл Ladybug VisualizationSet	Загружается обратно в Preview VisualizationSet	Сохраняет визуальное представление и data sets, но не заменяет симуляционную модель

Для архивирования проекта одного итогового HTML или скриншота недостаточно. Наибольшую переносимость даёт сохранение исходной параметрической схемы вместе с погодой, сериализованной Honeybee/Dragonfly-моделью и сырыми результатами. OSM и IDF полезны для независимой проверки EnergyPlus/OpenStudio, GeoJSON — для районной геометрии, а VSF — для повторного воспроизведения визуального слоя.

Жизненный цикл Ladybug Tools

Проект начался в 2012 году как работа Mostapha Sadeghipour Roudsari, а первая Ladybug-версия для Grasshopper вышла в январе 2013 года. Honeybee появился в 2014 году как связка с более детальными движками моделирования. В августе 2017 года Mostapha Sadeghipour Roudsari и Chris Mackey основали Ladybug Tools LLC, чтобы поддерживать развитие открытого проекта коммерческими услугами, не закрывая код и не превращая плагины в собственнический продукт.

Старые Legacy-компоненты и современная 1.x-линия отличаются архитектурой. Текущие библиотеки разделены на Python core и интерфейсные Grasshopper-пакеты, а версии всего набора координирует метарепозиторий lbt-grasshopper. Это объясняет две системы номеров, которые встречаются рядом: например, общий выпуск Ladybug Tools имеет номер 1.10.54, тогда как пакет ladybug-grasshopper выпускается собственной серией 1.72.x, а компоненты внутри показывают совместимую общую линию 1.10.0.

В линии 1.6 современная визуализация получила VisualizationSet с отдельным preview, bake и форматом .vsf. В 2026 году текущий агрегированный пакет включил Fairyfly, а его компоненты были подняты до общей линии 1.10.0. Последний подтверждённый выпуск lbt-grasshopper 1.10.54 опубликован 3 сентября 2026 года; сама матрица совместимости обновлялась 25 августа 2026 года. Это подтверждает активный статус проекта на дату обзора.

Для старых Grasshopper-файлов предусмотрен LB Legacy Updater: он ищет Legacy Ladybug/Honeybee components на canvas и размещает предлагаемые современные LBT-компоненты рядом. Документация самого updater предупреждает, что прямое соответствие есть не всегда: современные workflow часто переработаны и могут требовать другого количества узлов. Поэтому миграция Legacy-файла — это реконструкция связей, а не автоматическое обновление формата «одной кнопкой».

Что перестанет работать первым при потере зависимостей

Зависимость	Что ломается	Что остаётся доступным
Rhino/Grasshopper	Графический интерфейс lbt-grasshopper и Rhino viewport	Отдельные Python-библиотеки Ladybug Tools могут использоваться программно там, где поддерживается соответствующий API
Radiance	Honeybee daylight и spatial solar recipes, которым нужен Radiance	Базовый климатический Ladybug и энергетические расчёты через OpenStudio/EnergyPlus
OpenStudio/EnergyPlus	Полные HB-Energy simulations и генерация их результатов	Климатические, солнечные и Radiance-задачи, не использующие EnergyPlus
URBANopt CLI	DF Run URBANopt и зависящие от его сценария районные процессы	Создание Dragonfly Model и GeoJSON как структурированной модели
Fairyfly/THERM-связанные библиотеки	Соответствующие двухмерные теплотехнические операции Fairyfly	Ladybug, Honeybee и Dragonfly независимо от этого модуля
Интернет	Загрузки, обновления, single-click installer, получение внешних данных и облачные сервисы	Уже установленные локальные components, локальный EPW и локальные движки продолжают использовать локальные файлы
Учётная запись Pollination	Доступ к загрузке Pollination Grasshopper single-click installer	Открытый код Ladybug Tools и ручная установка не становятся платными или закрытыми

Такое устройство уменьшает «точку единого отказа», но повышает требования к версии окружения. Поломка Radiance не должна мешать чтению EPW, а отсутствие URBANopt не должно мешать обычной Honeybee-модели. Поэтому диагностику полезно начинать с определения конкретной ветви — climate, daylight, energy, district или THERM — а не с переустановки всей экосистемы.

Как пользоваться программой — советы гика

Ниже собран расширенный практикум по основным рабочим ветвям современной версии. Все названия компонентов оставлены в том виде, в котором они ищутся в Grasshopper. Для воспроизводимости перед любым расчётом полезно сохранить отдельную копию Rhino/Grasshopper-проекта и не перезаписывать единственный исходник результатами эксперимента.

1. Проверить установку и версии через HB Config

Цель. Убедиться, что Grasshopper видит Python-библиотеки и те внешние движки, которые нужны конкретному исследованию.

Подготовка. Запустите Rhino, откройте Grasshopper и создайте пустой документ. На canvas дважды щёлкните свободное место и найдите HB Config. Для проверки совместимости добавьте также HB Check Versions.

1. Разместите HB Config и посмотрите его outputs: пути к Python, библиотекам, Radiance, OpenStudio/EnergyPlus и ресурсам.
2. Для полной установки все требуемые вашим сценарием пути должны содержать реальные каталоги, а не Null. Для чисто daylight-задачи отсутствие OpenStudio не блокирует Radiance; для чисто энергетической задачи отсутствие Radiance не блокирует EnergyPlus.
3. Разместите HB Check Versions и запустите проверку установленных движков.
4. Сверьте семейство версий с линией 1.10.x: матрица для 1.10.0 использует Python 3.10.10, Radiance 5.4 и OpenStudio 3.10.0 как совместимую базу.

Проверка результата. Пути соответствуют реально установленным каталогам, а компонент версий не сообщает о несовместимом движке.

Типичная ошибка и откат. ImportError означает, что Rhino не находит core libraries. Не меняйте системные пути наугад: вернитесь к последнему рабочему окружению или повторите официальный установочный workflow той же линии, затем снова проверьте HB Config.

2. Импортировать EPW и ограничить анализ нужным периодом

Цель. Получить погодные ряды и географию, с которыми будут согласованы остальные компоненты.

Подготовка. Сохраните проверенный .epw в постоянную папку проекта; перенос файла после сборки graph нарушит путь.

1. Добавьте LB Import EPW и передайте ему полный путь к .epw.
2. Используйте outputs location и нужные Data Collections — dry bulb temperature, relative humidity, wind speed, radiation и другие доступные поля.
3. Для сезонного исследования добавьте LB Analysis Period и задайте начало, конец и диапазон часов.
4. Передайте полученный период в компоненты, которые принимают analysis period или HOYs, вместо ручного обрезания списков.

Проверка результата. Location соответствует площадке, а временные коллекции имеют ожидаемое число записей для выбранного периода.

Типичная ошибка и откат. При переносе EPW на другой диск компоненты теряют источник. Верните файл по сохранённому пути или заново укажите новый полный путь; сам Grasshopper-граф менять не требуется.

3. Построить SunPath и проверить ориентацию здания

Цель. Получить траектории солнца и векторы для выбранных часов года.

Подготовка. Нужен location из LB Import EPW или LB Construct Location.

1. Добавьте LB SunPath и подключите location.
2. Для конкретного периода подключите HOYs от LB Analysis Period; без них компонент строит годовой набор по собственным значениям по умолчанию.
3. Задайте north как угол от положительной оси Y против часовой стрелки или как вектор направления севера.
4. При необходимости измените center_pt и scale. Значение scale=1 соответствует радиусу 100 м в текущей системе единиц Rhino.
5. Для более детального отображения подключите vis_set к LB Preview VisualizationSet.

Проверка результата. Стороны света совпадают с ориентацией модели, а vectors направлены вниз к земле для выбранных солнечных положений.

Типичная ошибка и откат. Неверный north разворачивает весь вывод. Верните north к 0 и сопоставьте положительную Y Rhino с севером, затем вводите реальный поворот модели.

4. Выполнить базовый incident radiation анализ

Цель. Сопоставить геометрии распределение падающей солнечной радиации, не подменяя этим полноценный daylight-рецепт.

Подготовка. Подготовьте анализируемую mesh/геометрию, контекст затенения и климатическую sky matrix подходящего периода.

1. В Ladybug 3 :: Analyze Geometry найдите компонент incident radiation и подключите анализируемую геометрию.
2. Передайте небесную матрицу, сформированную из погодных данных и нужного периода.
3. Добавьте контекст, который реально должен блокировать небосвод, а не весь CAD-мусор из файла.
4. Используйте результат вместе с analysis mesh или VisualizationSet для пространственного отображения.

Проверка результата. Единицы согласованы с выбранной матрицей, а ориентация нормалей и тени соответствуют геометрии.

Типичная ошибка и откат. Случайный контекст или перевёрнутые поверхности искажают поле. Отключите дополнительный context и сравните базовый результат, затем возвращайте объекты по одному.

5. Создать Honeybee Rooms из замкнутой Rhino-геометрии

Цель. Превратить CAD-объёмы помещений в семантические Honeybee Rooms.

Подготовка. Каждое помещение должно быть замкнутой polysurface или закрытой mesh без щелей.

1. Добавьте HB Room from Solid и подключите геометрию к geo.
2. Задайте осмысленное name, чтобы результаты можно было сопоставить помещениям.
3. При энергетическом расчёте подключите нужные construction set и program; без них применяются generic defaults.
4. Если помещения соприкасаются, используйте Honeybee-инструменты adjacency, чтобы внутренние границы не остались наружными.
5. Соберите Rooms, Shades и прочие объекты в HB Model.

Проверка результата. Компонент возвращает Rooms без геометрических предупреждений, а визуализация model показывает ожидаемые комнаты и проёмы.

Типичная ошибка и откат. Незамкнутый solid нарушает объём и создаёт light leaks. Вернитесь к Rhino-геометрии, исправьте щель и создайте Room заново; не пытайтесь скрыть дефект материалами или настройками симулятора.

6. Запустить энергетическую модель через HB Model to OSM

Цель. Получить EnergyPlus-расчёт и сохранить машинные и отчётные результаты.

Подготовка. Нужны Honeybee Model, EPW, совместимый OpenStudio/EnergyPlus и при необходимости HB Simulation Parameter.

1. Добавьте HB Simulation Parameter, если требуется изменить run period, timestep, outputs, terrain, sizing или shadow settings.
2. Добавьте HB Model to OSM, подключите model и epw_file.
3. Передайте Simulation Parameter в sim_par; OpenStudio Measures подключайте только те, чьи аргументы полностью понятны и воспроизводимы.
4. Задайте отдельную folder для результатов проекта.
5. Сначала включите write, чтобы получить Honeybee JSON, OSM и IDF/OSW; затем включите run для симуляции.

Проверка результата. report не содержит фатального завершения, а outputs sql, rdd и html появляются после run. OSM и IDF остаются доступными для независимого контроля.

Типичная ошибка и откат. При неверной версии OpenStudio симуляция может остановиться до SQL. Отключите run, сохраните исходные JSON/OSM, восстановите совместимую версию движка и повторите только расчётную стадию.

7. Выполнить годовой daylight расчёт в Honeybee Radiance

Цель. Получить почасовую освещённость на пространственной сетке и вычислить годовые метрики.

Подготовка. Нужен Honeybee Model с корректными Rooms и проёмами, установленный Radiance и погодный вход для годового рецепта: объект Wea, файл .wea или EPW.

1. Добавьте HB Sensor Grid from Rooms и подключите Rooms или целый Model.
2. Задайте grid_size и высоту dist_floor; значение по умолчанию для dist_floor — 0,8 м.
3. Прикрепите полученные SensorGrid к модели средствами Honeybee Radiance.
4. Добавьте HB Annual Daylight, подключите model и вход wea. На wea допускается передать Wea object, путь к .wea или путь к .epw; для рецепта требуется Wea с timestep 1. Подключите HB Recipe Settings к run_settings и включите run.
5. Используйте прямые выходы DA, cDA и UDI компонента HB Annual Daylight. Сырые .ill при отдельном постпроцессе можно передать в HB Annual Daylight Metrics; ASE рассчитывается отдельным компонентом, когда эта метрика входит в принятую методику.

Проверка результата. Количество значений соответствует sensor grid, единицы illuminance — lux, а spatial metrics считаются по нужным помещениям и occupancy schedule.

Типичная ошибка и откат. Слишком мелкий grid_size резко увеличивает число сенсоров и объём вычислений. Вернитесь к сохранённому graph, увеличьте шаг сетки на ранней итерации и только после проверки модели повышайте разрешение.

8. Подготовить квартал в Dragonfly и экспортировать GeoJSON

Цель. Преобразовать районную модель в URBANopt-совместимый GeoJSON и связанный набор Honeybee JSON.

Подготовка. Нужны Dragonfly Model и корректный location с широтой/долготой.

1. Соберите Dragonfly Buildings/Room2D и объедините их в Model.
2. Добавьте DF Model to geoJSON, подключите model и location.
3. Проверьте point, который связывает географическое положение с координатами Rhino.
4. Определите use_multiplier, plenum и shade_dist в соответствии с задачей района, а не оставляйте их случайными.
5. Задайте folder и включите write. Для URBANopt не используйте режим write=2, потому что он создаёт GeoJSON без связанных Honeybee Model JSON и не является полноценным URBANopt-входом.

Проверка результата. На выходе есть geojson и hb_jsons; свойства building footprints и detailed_model_filename сохранены.

Типичная ошибка и откат. Неверный location/point сдвигает географию. Верните point к origin Rhino и проверьте координатную привязку до запуска районной симуляции.

9. Создать граничное условие Fairyfly для THERM-сценария

Цель. Описать температурную границу для двухмерной теплотехнической модели Fairyfly.

Подготовка. Подготовьте planar Polyline или Line, которая представляет нужную границу сечения.

1. Добавьте FF Boundary и подключите геометрию к geo.
2. Задайте temperature в градусах Цельсия.
3. Задайте film_coeff в W/m²·K согласно принятому расчётному условию.
4. При расчёте U-factor укажите u_factor_tag; при необходимости подключите FF Radiant Environment.
5. Передайте созданные boundaries в последующий Fairyfly/THERM-модельный workflow.

Проверка результата. Компонент возвращает Fairyfly Boundary без геометрического report-ошибки, а температура и коэффициент соответствуют принятому стандарту исследования.

Типичная ошибка и откат. FF Boundary требует планарную линию или полилинию. Если исходная геометрия неплоская, вернитесь к двумерному сечению и не проецируйте его автоматически без проверки масштаба и длины.

10. Сохранить воспроизводимый результат: сквозной сценарий

Цель. Завершить типовой проект так, чтобы климат, модель, расчёт и графика открывались независимо друг от друга.

Подготовка. Создайте отдельную папку проекта с подкаталогами weather, model, simulation и visuals.

1. Откройте Rhino/Grasshopper и укажите локальный EPW через LB Import EPW.
2. Подключите location к LB SunPath и проверьте north; климатические данные визуализируйте wind rose или psychrometric chart.
3. Преобразуйте замкнутые помещения через HB Room from Solid, соберите HB Model и проверьте геометрию.
4. Для energy подключите HB Model to OSM, задайте папку simulation и выполните сначала write, затем run.
5. Для daylight добавьте sensor grids и HB Annual Daylight, сохраняя Radiance results отдельно от EnergyPlus outputs.
6. Для презентации подайте vis_set нужных компонентов в LB Preview VisualizationSet; при необходимости используйте Bake или LB Dump VisualizationSet для .vsf.
7. Сохраните Honeybee JSON, OSM/IDF, SQL/CSV/HTML и .vsf рядом с исходным Grasshopper-документом и EPW.

Проверка результата. Итог можно проверить минимум тремя независимыми способами: визуально во viewport Rhino, численно по SQL/CSV/Radiance results и структурно по JSON/OSM/GeoJSON. Такая триада защищает от ситуации, когда красивый скриншот остался, а исходные допущения и расчётные файлы потеряны.

Типичная ошибка и откат. Нельзя считать единственным архивом baked-геометрию или HTML-отчёт. Если проект ещё открыт, сохраните параметрический graph и исходные сериализованные файлы до любых дальнейших правок; для нового варианта создайте отдельную копию папки simulation.

Плюсы и минусы

Плюсы

• Бесплатный открытый код. Текущий метапакет публикуется под AGPL-3.0, а базовые компоненты не делятся на урезанный бесплатный и платный функционал.
• Интеграция расчёта с параметрической геометрией. Изменение модели Grasshopper может проходить до климата, симуляции и визуализации без отдельной ручной перестройки промежуточной CAD-модели.
• Связка с профильными движками. Для daylight используется Radiance, для энергии — OpenStudio/EnergyPlus, для района — URBANopt; Ladybug Tools не пытается заменить их самописным универсальным solver.
• Разделение на модули. Ladybug, Honeybee, Dragonfly и Fairyfly решают разные классы задач, поэтому можно ограничить окружение нужными зависимостями.
• Открытые и проверяемые форматы. EPW, JSON, OSM, IDF, SQL, CSV, GeoJSON и HTML позволяют выносить результаты за пределы Grasshopper и проводить независимую проверку.
• Глубокая визуализация. VisualizationSet связывает данные с Rhino DisplayPipeline, поддерживает 2D/3D легенды, bake и отдельный формат .vsf.
• Активная разработка. В 2026 году линия 1.10.x продолжает получать зависимости и исправления, а Fairyfly вошёл в текущий aggregate.

Минусы

• Высокий порог освоения Grasshopper. Пользователь должен понимать data trees, типы объектов и логику связей, иначе сложная схема быстро становится непрозрачной.
• Несколько независимых версий. LBT, отдельные Grasshopper-пакеты, Rhino, Radiance, OpenStudio и URBANopt имеют собственные циклы выпуска; несовпадение линий даёт реальные ошибки окружения.
• Нет автономного GUI. Для обычного графического сценария требуется Rhino/Grasshopper, а Rhino лицензируется отдельно.
• Часть задач вычислительно тяжёлая. Годовой Radiance, EnergyPlus и районные пакеты зависят от размера модели, числа сенсоров и детализации; универсального «быстрого» режима без компромиссов нет.
• Англоязычная терминология. Компоненты, параметры и официальные Primers используют английские названия.
• Старые учебные материалы легко спутать с актуальной архитектурой. Legacy, Butterfly и старые версии установщика встречаются в сети рядом с 1.x-документацией, хотя текущий метапакет устроен иначе.

Кому подойдёт и кому не подойдёт

Кому подойдёт

• архитекторам и computational designers, которые уже используют Rhino/Grasshopper и хотят связать форму с климатическими метриками;
• специалистам по building performance, которым нужен открытый фронтенд к Radiance, EnergyPlus и OpenStudio;
• исследователям и преподавателям, которым важны воспроизводимые параметры, открытый код и доступ к промежуточным данным;
• городским аналитикам, работающим с несколькими зданиями, URBANopt, GeoJSON и районными энергосценариями;
• пользователям, которым нужно создавать собственные parametric workflows вместо фиксированного мастера расчёта.

Кому не подойдёт

• тем, кому нужен автономный drag-and-drop GUI без Rhino и без визуального программирования;
• пользователям, ожидающим автоматическую генерацию корректной физической модели из любой произвольной 3D-геометрии;
• командам, которым важнее централизованный коммерческий desktop-пакет с одним поставщиком, одной лицензией и одним циклом поддержки всех движков;
• тем, кто ищет мобильное приложение для быстрых расчётов на телефоне или планшете;
• пользователям, которым требуется готовый ИИ-ассистент вместо построения и проверки параметрического graph.

Для интерьерного проектирования без инженерной симуляции Ladybug Tools избыточен: в таком сценарии полезнее отдельный материал про бесплатные программы для дизайна интерьера. Ladybug Tools раскрывается именно там, где геометрия должна быть связана с климатом, светом, теплом или энергией.

Сравнение с другими аналогами

Аналоги ниже сопоставлены по одинаковым критериям: основная задача, платформа, порог освоения, форматы, автоматизация, модель оплаты, ограничение и подходящий сценарий. Это не рейтинг: каждый вариант выигрывает в своём типе процесса.

Решение	Задача	Платформа	Порог	Форматы и обмен	Автоматизация	Оплата	Главное ограничение
Ladybug Tools	Климат, daylight, energy, районные модели в параметрическом CAD-процессе	Rhino/Grasshopper; Python-библиотеки отдельно	Высокий: Grasshopper + физика расчёта	EPW, JSON, OSM, IDF, SQL, CSV, GeoJSON, VSF	Глубокая через Grasshopper и scriptable components	Плагин бесплатно; Rhino отдельно	Сложное окружение и несколько движков
ClimateStudio	Daylight, electric lighting, thermal/energy analysis внутри Rhino	Windows + Rhino 6/7/8; macOS Rhino не поддерживается	Средний: более цельный специализированный интерфейс	Работа внутри Rhino/Grasshopper, отчётные outputs и моделирование	Полностью параметрические Grasshopper-workflows поддерживаются	Коммерческая подписка; доступен trial по заявке	Проприетарная лицензия и отсутствие macOS-версии
OpenStudio Application	Создание и редактирование OpenStudio/EnergyPlus energy models	Windows, macOS, Linux	Средний/высокий: инженерная BEM-модель без Grasshopper	OSM, EnergyPlus и OpenStudio workflow	OpenStudio SDK, CLI, Measures, bindings	Бесплатно и open source	Не является CAD-ориентированной climate/daylight средой уровня Ladybug
DesignBuilder	EnergyPlus-моделирование, HVAC, CFD и визуализация в едином GUI	Windows 10/11	Средний: традиционный инженерный интерфейс	gbXML, IDF, CSV, DXF и собственная модель	Parametric/optimization функции внутри продукта	Коммерческие лицензии на 1, 2 или 3 года; 30-дневная evaluation	Windows-only и коммерческая модель
Autodesk Forma Site Design	Раннее site/massing моделирование, солнце, daylight potential, wind, noise, carbon	Облачное браузерное приложение	Ниже для ранней стадии: меньше ручного graph-программирования	IFC, OBJ и связи с Revit, Dynamo, Rhino	Облачные быстрые analyses, включая отдельные AI-based rapid analyses	Отдельная подписка или состав AEC Collection	Не даёт открытого локального simulation graph и глубины Honeybee/Radiance

ClimateStudio рациональнее там, где команда хочет остаться в Rhino, но предпочитает коммерческий цельный продукт с готовыми workflow для daylight, lighting и thermal analysis. Ladybug Tools выигрывает открытостью, переносимостью промежуточных данных и свободой строить нестандартный graph, но требует большего контроля версий и компонентов.

OpenStudio Application ближе всего к энергетическому ядру Honeybee Energy, но решает другую задачу: это GUI для самой OpenStudio-модели, а не экологический toolkit внутри Grasshopper. Он полезен для независимой проверки OSM и для специалистов, которым CAD-параметрика не нужна.

DesignBuilder удобнее для команды, которая предпочитает традиционную оболочку вокруг EnergyPlus с модульным коммерческим набором. Ladybug Tools лучше вписывается в computational design и исследовательскую автоматизацию, DesignBuilder — в контролируемый GUI-процесс без необходимости собирать Grasshopper graph из компонентов.

Autodesk Forma ориентирована на ранние городские и site decisions и переносит большую часть вычислительной инфраструктуры в браузер. Она содержит rapid analyses и отдельные AI-based варианты, тогда как Ladybug Tools оставляет пользователю открытый локальный параметрический процесс. Для глубокой настройки Radiance/EnergyPlus LBT гибче; для быстрого cloud-first massing Forma требует меньше инженерной сборки.

Типичные проблемы и диагностика

1. Компоненты становятся оранжевыми и показывают ImportError

Симптом: Grasshopper видит компонент, но выполнение останавливается на импорте ladybug/honeybee library. Причина: Rhino не находит core libraries в установленном окружении — это прямо отмечено в инструкции проверки установки. Диагностика: HB Config должен возвращать реальные пути к Python и библиотекам. Исправление: восстановите официальный installation workflow той же линии и не смешивайте случайные Python-каталоги. Проверка: HB Config больше не возвращает Null для core paths, а новый компонент выполняется без ImportError.

2. HB Config возвращает Null для Radiance или OpenStudio

Симптом: климатические компоненты работают, но daylight или energy recipes не запускаются. Причина: соответствующий внешний движок не установлен или не найден. Диагностика: определите, какой именно output HB Config равен Null. Исправление: установите совместимую версию только нужного движка либо используйте Windows Pollination installer с включёнными совместимыми Radiance/OpenStudio. Проверка: путь появляется в HB Config, а HB Check Versions распознаёт движок.

3. HB Check Versions сообщает несовместимую версию движка

Симптом: внешняя программа установлена, но recipe завершается до расчёта или version checker предупреждает о mismatch. Причина: LBT и engine принадлежат разным compatibility lines. Диагностика: сопоставьте общую версию LBT с текущей compatibility matrix, а не с произвольной «самой новой» версией OpenStudio. Исправление: выровняйте движок по совместимой строке. Проверка: HB Check Versions перестаёт отмечать конфликт.

4. SunPath смотрит не в ту сторону

Симптом: траектории солнца и стороны света не совпадают с проектной ориентацией. Причина: вход north интерпретируется относительно положительной оси Y Rhino. Диагностика: временно установите north=0 и сравните компас с осью модели. Исправление: задайте реальный угол или вектор севера. Проверка: компас, азимуты и архитектурная ориентация совпадают.

5. Honeybee Room не создаётся или даёт световые утечки

Симптом: Room from Solid выдаёт геометрический report, а Radiance показывает свет там, где должны быть закрытые границы. Причина: Room требует замкнутый Rhino solid/mesh; документация отдельно предупреждает о light leaks при некорректном объёме. Диагностика: проверьте замкнутость исходного объёма и стыки поверхностей. Исправление: устраните щели в Rhino до преобразования. Проверка: новый Room проходит без геометрического предупреждения и имеет корректный объём.

6. HB Model to OSM создаёт OSM/IDF, но SQL остаётся пустым

Симптом: экспортированные модельные файлы есть, но output sql равен None. Причина: SQL появляется только после фактического EnergyPlus run; один write создаёт входные файлы. Диагностика: посмотрите состояние run и report. Исправление: после успешного write запустите симуляцию в совместимом окружении. Проверка: появляется SQL, а также ожидаемые RDD/HTML outputs.

7. Annual Daylight возвращает пустые или бессмысленные пространственные результаты

Симптом: recipe запускается, но метрики нельзя сопоставить помещению или сетка отсутствует. Причина: grid-based Radiance study требует SensorGrid, назначенный модели. Диагностика: проверьте output HB Sensor Grid from Rooms и количество sensor points. Исправление: создайте сетку с физически осмысленным grid_size/dist_floor и прикрепите её к модели. Проверка: число метрик соответствует сенсорам, а heatmap совпадает с их mesh.

8. DF Run URBANopt не стартует

Симптом: Dragonfly Model и GeoJSON создаются, но районная симуляция не выполняется. Причина: DF Run URBANopt требует установленный URBANopt CLI. Диагностика: HB Config/version tools и environment должны видеть CLI совместимой линии. Исправление: установите совместимый URBANopt и повторите запуск с уже проверенным GeoJSON. Проверка: компонент создаёт scenario CSV и возвращает списки OSM/IDF/SQLite/HTML.

9. FF Boundary выдаёт ошибку геометрии

Симптом: Fairyfly не принимает контур в boundary. Причина: FF Boundary ожидает planar Polyline или Line. Диагностика: проверьте, что точки контура лежат в одной плоскости и представляют двухмерное сечение. Исправление: подготовьте корректное плоское сечение и повторно создайте boundary. Проверка: output boundaries формируется без report-ошибки и сохраняет заданные temperature/film_coeff.

10. После обновления часть старого графа работает иначе

Симптом: файл, собранный на Legacy или другой линии, открывается с предупреждениями, а прямой замены некоторых components нет. Причина: современная архитектура переработала ряд workflow; LB Legacy Updater сам предупреждает, что количество и поведение новых components может отличаться. Диагностика: отделите Legacy nodes от current 1.x и сопоставьте их назначение, а не только имена. Исправление: перестройте конкретную ветвь на современных components и сохраните старую копию для сравнения. Проверка: итоговые inputs, outputs и единицы новой ветви документированы и воспроизводимы.

При тяжёлом расчёте сначала отделяйте проблему модели от общей производительности компьютера. На Windows системные причины тормозов удобно проверять отдельно; для этого на GeekHow есть материал о том, как ускорить работу Windows 10. Внутри Ladybug Tools главный способ уменьшить вычислительную нагрузку — контролировать число sensor points, детализацию геометрии, период и количество параллельных задач, а не отключать проверку модели.

Безопасность и приватность

Открытый характер Ladybug Tools упрощает аудит: исходный код компонентов и библиотек размещён в публичных репозиториях, а текущий lbt-grasshopper использует AGPL-3.0. Это не означает автоматическую безопасность любого пользовательского graph: Grasshopper-документ способен содержать Python-компоненты, OpenStudio Measures и другие исполняемые элементы. Чужой файл стоит рассматривать как кодовый проект, а не как безобидную картинку.

Основные расчётные файлы работают локально. HB Model to OSM пишет JSON/OSM/IDF и результаты в выбранную folder; Dragonfly аналогично пишет GeoJSON и связанные модели. Для такой локальной ветви данные проекта не обязаны отправляться в облако. Облачная обработка начинается только там, где команда сознательно использует соответствующие Pollination или другие внешние сервисы.

Single-click Pollination installer требует учётную запись для загрузки, но это требование относится к способу установки, а не к самой лицензии Ladybug Tools. Организации с жёсткими правилами доступа к проектным данным могут использовать ручную установку и локальные engines, при этом им всё равно нужно отдельно контролировать источники EPW, Measures и сторонних Grasshopper-компонентов.

FAQ

Ladybug Tools — это одна программа или несколько?

Это коллекция библиотек и плагинов. В Grasshopper текущий metapackage lbt-grasshopper объединяет Ladybug, Honeybee Core, Honeybee Radiance, Honeybee Energy, Dragonfly и Fairyfly. Внешние engines устанавливаются по задаче.

Можно ли использовать Ladybug Tools без покупки отдельной лицензии плагина?

Да. Сам lbt-grasshopper бесплатен и открыт. Для привычного интерфейса Rhino/Grasshopper требуется лицензия Rhino, потому что это отдельный коммерческий CAD-продукт.

Нужно ли устанавливать и Radiance, и OpenStudio одновременно?

Нет. Radiance нужен для daylight и spatial solar simulations Honeybee, OpenStudio/EnergyPlus — для energy simulations. HB Config используется именно для проверки того набора engines, который нужен конкретной ветви.

Почему в интернете много уроков с Ladybug Legacy?

Проект существует с 2012–2013 годов и прошёл крупную архитектурную переработку. Legacy-компоненты относятся к старой ветви. Современная линия 1.x использует разделённые core libraries и новые Grasshopper packages; LB Legacy Updater помогает сопоставить старые nodes, но не гарантирует буквальную замену каждого.

Почему номер lbt-grasshopper 1.10.54 не совпадает с ladybug-grasshopper 1.72.5?

Метапакет и отдельные packages имеют свои release numbers. lbt-grasshopper координирует совместимую общую линию компонентов, а конкретный repository может выпускать исправления под собственным номером. Поэтому при диагностике нужно смотреть и общую LBT-линию, и package dependency.

Поддерживает ли Ladybug Tools генеративный ИИ?

В текущем документированном Grasshopper-наборе нет встроенного generative-AI assistant. Автоматизация основана на Grasshopper graphs, Python-библиотеках и simulation engines. Это отличает LBT от cloud-first альтернатив, где отдельные rapid analyses используют AI.

Можно ли передать результаты человеку без Rhino?

Да, если сохранить переносимые outputs: HTML reports, CSV, IDF/OSM, JSON, GeoJSON или другие результаты конкретного recipe. Для полного воспроизведения именно параметрической логики получателю потребуется совместимое окружение Grasshopper либо доступ к core libraries/API.

Подходит ли Ladybug Tools для официальной сертификации daylight?

Honeybee Radiance содержит метрики, используемые в стандартизированных daylight-workflows, но соответствие зависит от setup. Например, документация ASE прямо предупреждает, что LEED-compliant результат требует расчёта с операбельными shading devices в нужном состоянии; Spatial Daylight Autonomy имеет собственные требования LM-83. Сам факт получения процента в Grasshopper не заменяет проверку методики.

Можно ли использовать только климатические диаграммы без модели здания?

Да. Ladybug импортирует EPW и строит климатические/солнечные visualizations независимо от Honeybee Model. Это один из самых лёгких способов использовать пакет на ранней стадии, когда помещения и constructions ещё не определены.

Чем Fairyfly отличается от Butterfly?

Fairyfly включён в актуальный lbt-grasshopper и связан с THERM-ориентированными двухмерными теплотехническими объектами. Butterfly — отдельный проект Ladybug Tools для OpenFOAM/CFD и не входит в текущий requirements метапакета lbt-grasshopper. Их нельзя считать двумя названиями одного и того же модуля.

Итог: когда Ladybug Tools оправдан

Для ранней климатической оценки Ladybug Tools оправдан уже без тяжёлых engines: EPW, SunPath, wind rose, psychrometric chart и базовая геометрия дают связанный с CAD контекст. Это хороший сценарий для команды, которая хочет принимать решения об ориентации, затенении и климатической стратегии внутри того же параметрического файла, где развивается форма.

Для детального building performance преимущество появляется, когда Honeybee Model становится единым источником для EnergyPlus и Radiance. Здесь цена гибкости — необходимость следить за корректностью Rooms, grids, schedules, constructions, versions и simulation parameters. Пользователь получает прозрачные промежуточные форматы, но обязан понимать их смысл.

Для районного анализа Dragonfly делает Ladybug Tools заметно шире обычного «плагина солнца»: GeoJSON, URBANopt, электрические и district-energy ветви позволяют переносить параметрическую логику на множество зданий. Этот сценарий имеет смысл только при готовности работать с инфраструктурными зависимостями и более сложным контролем данных.

Для пользователя без Grasshopper Ladybug Tools не является коротким путём. Готовый GUI вроде ClimateStudio, DesignBuilder, OpenStudio Application или cloud-first Forma даст более линейный процесс. Ladybug Tools следует выбирать не ради бесплатности как таковой, а когда открытость, параметрическая автоматизация, доступ к проверяемым formats и связь моделирования с CAD действительно важнее простоты единого интерфейса.