Доклад «Автоматизация создания геометрии в AutoCAD/DXF с помощью Python» на Autodesk University 2013

Доклад на Autodesk University будет интересно посетить профессионалам, работающим в области анализа конструкций, и вообще всем, кого интересует автоматизация обработки инженерных моделей с геометрическими данными. Помимо специалистов, интересное для себя найдут САПР-эксперты и технологические евангелисты — потому что из доклада будет что почерпнуть с точки зрения подхода к пользовательской автоматизации.

Введение на примере прикладной задачи

Рис. 1. Проблема моделирования: получение геометрии модели

1) главным требованием к реализации модели очень часто является использование конкретного ПО из области CAE (инженерного анализа);
2) информационное наполнение модели (исходные данные) можно грубо разделить на геометрические данные и другую инженерную информацию; причем инженерная информация ассоциирована (привязана) к геометрии.

Начнем с геометрии. В сложных моделях, будь то модели конструкций или механизмов, геометрия может быть нетривиальной. Так получилось и в нашем случае. Мало того, что у модели есть области двойной кривизны, нам требуется ещё и учесть систему предварительного напряжения, которая представляет из себя стальные канаты, проложенные по сложным геликоидальным траекториям в толще бетона по пластиковым каналам, позволяющим канатам свободно двигаться:

Рис. 2. Модель (красным показана система канатов внутри бетона) и цилиндрическая развертка её стенки

Я выбрал третий вариант исходя из принципа о том, что следует использовать самый подходящий специализированный инструмент из возможных, а не самый многофункциональный. Следование этому принципу позволяет не терять в производительности при переходе на модель-ориентированные рабочие процессы, такие, например, как информационное моделирование, а также позволяет экономить рабочее время персонала, который может использовать знакомые продукты и приёмы работы.

И вот здесь начинается интересное. На рисунке 2 не зря изображена развертка модели: хорошо видно, что при смене точки зрения на модель (а точнее, при смене пространства моделирования) построения перестают быть трудоёмкими на грани невозможного. При такой точке зрения значительная часть геометрии может быть построена в виде плоских разверток:

Рис. 3. Плоские развертки конструкций

Построение такого модельного процессора — это несколько нетипичная задача, относящаяся к области пользовательского программирования. Существуют похожие по смыслу решения из области процедурного генерирования форм для архитектуры, в том числе разрабатываемые в Autodesk (см. рис. 4).

Рис. 4. Существующие процессоры геометрии

Рис. 5. Не ясно, что делать с обработкой связанных с геометрией неграфических данных

Планирование процессора инженерных данных

Рис. 6. Преимущества Python как языка для пользовательского программирования

Рис. 7. Рабочий процесс с учетом инженерных данных

Создание предметного языка моделирования

Существуют разные варианты формализации инженерных данных (например, можно строить объектные модели в рамках технологии BIM, можно использовать возможности CAD по обогащению примитивов метаданными). Универсальный ответ, на мой взгляд, основан на том же принципе, по которому CAD был выбран для подготовки графических данных. Если геометрические данные мы представляем в виде графики, то негеометрические данные мы должны представить в виде текста. А именно, следует использовать такое понятие, как DSL (Domain-Specific Language), предметно-ориентированный язык. DSL — это ограниченный в возможностях язык программирования или моделирования, спроектированный специально под конкретную предметную область и потенциально используемый непрограммистами. (Подробнее о предметных языках можно почитать на Википедии.)

На рис. 8 перечислены основные преимущества использования DSL. Их можно обобщить так: поскольку любая инженерная модель — лингвистическая (см. статью «Введение в модельную парадигму»), то для её формализации желателен язык. Именно таким языком формализации модели и должна стать реализация DSL для нашего процессора.

Рис. 8. Аргументы в пользу использования DSL

Рис. 9. Логика модельного процессора, управляемого DSL

Рис. 10. Детали реализации DSL

Некоторые результаты разработки модельного процессора

Рис. 11. Обработка модельных абстракций

Рис. 12. Реализация сеточного процессора на примере стилизованного логотипа Python

Рис. 13. Слияние данных из разных источников (фильтров) для получения общей модели

Рис. 14. Процессор позволяет учитывать подробную инженерную информацию

Рис. 15. Обработка сложных правил и отношений

Выводы и оценка принесенной пользы

Рис. 16. Выводы

• реализация показанных в докладе функций заняла около 1 человеко-месяца;
• время освоения не умеющими программировать интернами разработанного процессора и предметного языка составило 2-3 дня;
• когда глубоко в процессе разработки понадобилось добавить совершенно не запланированную и затрагивающую большую часть внутренней логики функцию интерактивной работы (то есть исполнение процессора прямо из графической среды AutoCAD), её проектирование заняло не больше недели, а ожидаемая реализация займет ещё неделю.