- Менее оптимистичный взгляд на BIM
- Снова о BIM?
- BIM и анализ конструкций
- BIM и его семь смертных грехов
- Модель-ориентированный подход на примере BIM-моделирования строительных конструкций
- Модельная парадигма: почему рамки BIM тесны для разговора о моделях
Видите, последний из приведенных заголовков отражает прагматичное методологическое соображение: сегодняшняя стадия понимания и развития BIM на реальном рынке может плохо сочетаться с достаточно строгим пониманием концепции моделирования, однако, это вовсе не говорит о некоем конфликте и уж точно не должно тормозить опережающие или параллельные эксперименты по релевантному моделированию. Впрочем, примем во внимание самые последние слова публикуемой сегодня статьи А.Бауска о том, что, в случае успешного развития описанных в статье работ, «...планируется как минимум частичная поддержка технологии BIM и стандарта IFC».
Обращаю внимание некоторых читателей на то, что для оценки любого текста (в частности, для правильной интерпретации жанра и, значит, для выбора правильного угла зрения при чтении) полезно иметь некоторое представление о личности автора, об его образовании, основной работе и т.д. В данном случае, рекомендую посмотреть интервью «Александр Бауск: Не будем ломать стулья, говоря о BIM».
Некоторые читатели IsiCAD наверняка знают, что я большой поклонник пользовательской автоматизации в САПР. Не было такого обсуждения в САПР и моделировании, в которое я не пытался бы ввернуть эту тему. Вот и сейчас на Autodesk University я решил не трогать тему информационного моделирования и модель-ориентированной инженерии, а поработать над инструментом, реализующим некоторые принципы эффективного моделирования. В докладе «Автоматизация создания геометрии в AutoCAD/DXF с помощью Python» я расскажу вам историю одной технологии. Это технология обработки инженерной информации для расчетов, в рамках которой я попытался применить принципы модель-ориентированной инженерии. Надеюсь, что представленные здесь первые результаты этого проекта будут интересны читателю IsiCAD.
Доклад на Autodesk University будет интересно посетить профессионалам, работающим в области анализа конструкций, и вообще всем, кого интересует автоматизация обработки инженерных моделей с геометрическими данными. Помимо специалистов, интересное для себя найдут САПР-эксперты и технологические евангелисты — потому что из доклада будет что почерпнуть с точки зрения подхода к пользовательской автоматизации.
Введение на примере прикладной задачи
Однажды мне понадобилось взяться за построение одной расчетной модели. Постоянные читатели наверняка уже догадались, что это была за модель: железобетонная оболочка разнообразной кривизны с предварительно напрягаемыми канатами внутри.
Рис. 1. Проблема моделирования: получение геометрии модели
1) главным требованием к реализации модели очень часто является использование конкретного ПО из области CAE (инженерного анализа);
2) информационное наполнение модели (исходные данные) можно грубо разделить на геометрические данные и другую инженерную информацию; причем инженерная информация ассоциирована (привязана) к геометрии.
Начнем с геометрии. В сложных моделях, будь то модели конструкций или механизмов, геометрия может быть нетривиальной. Так получилось и в нашем случае. Мало того, что у модели есть области двойной кривизны, нам требуется ещё и учесть систему предварительного напряжения, которая представляет из себя стальные канаты, проложенные по сложным геликоидальным траекториям в толще бетона по пластиковым каналам, позволяющим канатам свободно двигаться:
Рис. 2. Модель (красным показана система канатов внутри бетона) и цилиндрическая развертка её стенки
Я выбрал третий вариант исходя из принципа о том, что следует использовать самый подходящий специализированный инструмент из возможных, а не самый многофункциональный. Следование этому принципу позволяет не терять в производительности при переходе на модель-ориентированные рабочие процессы, такие, например, как информационное моделирование, а также позволяет экономить рабочее время персонала, который может использовать знакомые продукты и приёмы работы.
И вот здесь начинается интересное. На рисунке 2 не зря изображена развертка модели: хорошо видно, что при смене точки зрения на модель (а точнее, при смене пространства моделирования) построения перестают быть трудоёмкими на грани невозможного. При такой точке зрения значительная часть геометрии может быть построена в виде плоских разверток:
Рис. 3. Плоские развертки конструкций
Построение такого модельного процессора — это несколько нетипичная задача, относящаяся к области пользовательского программирования. Существуют похожие по смыслу решения из области процедурного генерирования форм для архитектуры, в том числе разрабатываемые в Autodesk (см. рис. 4).
Рис. 4. Существующие процессоры геометрии
Рис. 5. Не ясно, что делать с обработкой связанных с геометрией неграфических данных
Планирование процессора инженерных данных
Итак, необходимо создать собственный продукт под эту задачу. В качестве рабочего языка я выбрал Python по ряду причин (рис. 6). Подробно на них останавливаться не стоит (в докладе будут приведены доводы и «за», и «против» решения использовать этот язык), а правильность этого решения можно будет оценить по итоговой производительности работы.
Рис. 6. Преимущества Python как языка для пользовательского программирования
Рис. 7. Рабочий процесс с учетом инженерных данных
Создание предметного языка моделирования
Итак, осталось решить самую важную проблему: в какой форме следует представить инженерные данные о модели?Существуют разные варианты формализации инженерных данных (например, можно строить объектные модели в рамках технологии BIM, можно использовать возможности CAD по обогащению примитивов метаданными). Универсальный ответ, на мой взгляд, основан на том же принципе, по которому CAD был выбран для подготовки графических данных. Если геометрические данные мы представляем в виде графики, то негеометрические данные мы должны представить в виде текста. А именно, следует использовать такое понятие, как DSL (Domain-Specific Language), предметно-ориентированный язык. DSL — это ограниченный в возможностях язык программирования или моделирования, спроектированный специально под конкретную предметную область и потенциально используемый непрограммистами. (Подробнее о предметных языках можно почитать на Википедии.)
На рис. 8 перечислены основные преимущества использования DSL. Их можно обобщить так: поскольку любая инженерная модель — лингвистическая (см. статью «Введение в модельную парадигму»), то для её формализации желателен язык. Именно таким языком формализации модели и должна стать реализация DSL для нашего процессора.
Рис. 8. Аргументы в пользу использования DSL
Рис. 9. Логика модельного процессора, управляемого DSL
Рис. 10. Детали реализации DSL
Некоторые результаты разработки модельного процессора
На рис. 11 изображен результат обработки примитивов, моделирующих купол: из плоской абстракции мы получаем сложную криволинейную структуру композитного материала.
Рис. 11. Обработка модельных абстракций
Рис. 12. Реализация сеточного процессора на примере стилизованного логотипа Python
Рис. 13. Слияние данных из разных источников (фильтров) для получения общей модели
Рис. 14. Процессор позволяет учитывать подробную инженерную информацию
Рис. 15. Обработка сложных правил и отношений
Выводы и оценка принесенной пользы
Выводы из проекта (рис. 16) можно будет обсудить на самом докладе.
Рис. 16. Выводы
- реализация показанных в докладе функций заняла около 1 человеко-месяца;
- время освоения не умеющими программировать интернами разработанного процессора и предметного языка составило 2-3 дня;
- когда глубоко в процессе разработки понадобилось добавить совершенно не запланированную и затрагивающую большую часть внутренней логики функцию интерактивной работы (то есть исполнение процессора прямо из графической среды AutoCAD), её проектирование заняло не больше недели, а ожидаемая реализация займет ещё неделю.