Комментарий к статье Ямпольского

На Изикаде опубликована статья А. Ямпольского о “расчетно-ориентированной модели”.

Статья, по идее, должна продолжать БИМ-дискуссию на Кофесе, Изикаде, Автодеск-форуме, в твиттерах и тэдэ, которой уже больше годика. У неё это, скажу прямо, ни разу не получается.

Больше того, я испытываю по отношению к ней смешанные чувства: с одной стороны, отлично, что поднята тема расчетных моделей, а с другой стороны, за ТАКОЙ подъем темы спасибо не скажешь: того и гляди, БИМ-евангелисты запишут расчетные модели в расстрельный список ВЕЩЕЙ, КОТОРЫЕ СУТЬ НЕСОГЛАСНЫЕ С НАШИМ BIM ИДЕОЛОГИЧЕСКИЕ ВРАГИ.

Скажу, пользуясь случаем, что тема расчетных моделей и техник работы с ними в контексте БИМ мне очень близка; ни по одной другой теме я не лелею столько идей, которые стоит как-то систематизировать и добиваться воплощения, конечно.

Но хватит о моих личных тараканах в голове. Вот комментарий для Изикада.

***

БИМ-евангелистам, конечно, не понравится то, что это, видите ли, не bleeding edge.

Но тут другая проблема на самом деле, даже целый ряд их.

1. Для концептуального объяснения методологии описывать все эти виды и первые-третьи совершенно излишне; это же не инструкция для чертежника, а (по идее) объяснение концепции должно быть, в формате статьи?

2. Насчет БИМ. В самой статье БИМ никак упоминается; это понятно: сравнивать с современным БИМ такую концепцию бессмысленно. Однако в контексте предыдущей дискуссии такое сравнение напрашивается и это очень хорошо читается у комментаторов (и будет только сильнее сквозить в комментариях по мере скатывания дискуссии в склоку). Так что важно было бы подробно очертить области применения (назначение, цели, ниши - а концепция очевидно нишевая, гораздо более нишевая, чем БИМ), а этого не сделано. Вследствие этого (и в контексте дискуссии о БИМ) у читателя появляется искушение сравнивать с флагманской технологией, т.е. БИМ, "в целом", по совокупности возможностей и без оглядки на другие факторы кроме технологической продвинутости (например, технология могла бы быть востребованной при наличии реализаций с открытым кодом и с ГОРАЗДО большей гибкостью номенклатуры объектов).

3. Самое главное. Даже если некритично принять содержание статьи и отказаться от сравнений с технологией из другой весовой категории, то проблема, вынесенная в заголовок, остаётся нерёшенной. Лично я ориентированности на расчеты здесь не вижу - только базовый набор инструментов для минимальной автоматизации 3Д-моделирования на базе планов. Между тем для "ориентированности" модели на расчеты и в особенности - общедоступности и "кросс-вендорности" таких моделей и технологий (а эти два качества являются залогом здорового развития технологии и сообщества специалистов вокруг неё) нужно решать огромный диапазон проблем, большинство из которых остаются очень болючими даже во флагманском БИМ. Одна из таких проблем (сеточный препроцессор) очень-очень вскользь упомянута в статье.
Другая проблема, просто для примера неспециалистам: одну и ту же задачу бесшовно транслировать в разные МКЭ-пакеты (и между ними) сейчас практически невозможно. Бывает так, что реализация одинаковой по механическому смыслу конфигурации элементов в разных пакетах концептуально различна. Т.е. редко когда можно смоделировать необычный элемент конструкции, перебросить его между системами и надеяться на корректную его работу.
То есть существует потенциально огромный объем не столько технической работы по программированию транслятора, сколько по систематизации, формализации практик реализации тех или иных конфигураций элементов расчетной модели.

И последнее. Похожее по концепции (опять же из моих некритичных догадок, потому что концепция плохо выписана в статье) моделирование реализовано, кстати, в некоторых достаточно известных профильных продуктах, и разработчики этих продуктов, в общем-то, пока что в упор не видят заявления БИМ-энтузиастов про каменный век.