Pull to refresh

Comments 11

Мы начали с AutoCAD, но будем делать плагины под все CAD с доступным API. После отладки под AutoCAD на очереди Autodesk Inventor и SolidWorks.
А может через несколько лет мы сами купим Autodesk ;)
Спасибо, интересная разработка, но несколько непонятны условия Вашего эксперимента.

Если мне нужно изменить какой-то параметр в проекте, то я не перетягиваю точки мышкой, а редактирую нужный мне параметр (к примеру, с помощью инструмента Dimension в SolidWorks).

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

Касательно изменения параметра размерности, то все равно для начала нужно собрать схему, а у SolidWorks не получилось это на первых двух примерах, для остальных программ можно будет сделать такое сравнение к следующему материалу.
И ни слова о математике, об алгоритмах. Все настолько супер-секретно? Мы на Хабре или где?

любая современная CAD-система будет использовать процессор где-то на 15%
Этот момент тоже остался нераскрытым для тех, кто на занимается непосредственно CAD. Почему так? Что, никто из основных вендоров до сих пор не озаботился распараллелеить решение СЛАУ? Либо ваше утверждение не совсем верно, либо проблема не столь актуальна в реальной работе.

В общем, осталось ощущение, что статья писалась для инвесторов, а не для Хабра.
И ни слова о математике, об алгоритмах. Все настолько супер-секретно? Мы на Хабре или где?


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

любая современная CAD-система будет использовать процессор где-то на 15%
Этот момент тоже остался нераскрытым для тех, кто на занимается непосредственно CAD. Почему так? Что, никто из основных вендоров до сих пор не озаботился распараллелеить решение СЛАУ? Либо ваше утверждение не совсем верно, либо проблема не столь актуальна в реальной работе.


Вы правы, в сухом остатке мы разработали параллелизуемый алгоритм быстрого решения СЛАУ специфичной для параметрического CAD. Хотя помимо этого для увеличения эффективности мы экспериментируем с различными уравнениями и типами геометрий.
Достоверность утверждения про загрузку процессора на 15% легко проверить самостоятельно, запустив любой CAD.

На самом деле, легко понять откуда берутся эти 15%. Если у вас 4-ядерный процессор Core i7, который с учётом hyper-threading имеет 8 логических процессоров, а солвер работает только в одном потоке (т.е. на одном из этих логических процессоров), то и получаем 12.5% загрузки процессора (100% / 8). Что-то ещё берёт сама CAD-программа, что-то берёт сама Windows – в результате набегает 15-20%. Если же ваш компьютер гораздо лучше – скажем, имеет два процессора Xeon с 12 физическими ядрами (и 24 логическими процессорами) каждый — то загрузка вашей машины будет ещё в шесть раз хуже, т.е. 2-3%.

Актуальна ли эта проблема? И если она актуальна, то почему так происходит? Ответы на эти вопросы могут занять еще одну большую статью, попробую ответить вкратце.

Для начала следует заметить, что решение СЛАУ в общем виде, достаточно сложная (O(n^3)) задача. Стандартные алгоритмы линейной алгебры очень плохо поддаются распараллеливанию.

Естественно производители CAD стараются ускорить расчет. Часто они как могут упрощают задачу, стараясь тем или иным способом отыскивать переменные, которые можно зафиксировать. Однако, как показывают наши примеры, это иногда приводит к крайне неустойчивому поведению (см. пример 4).

Мы заходим с другой стороны. Дело в том, что параметрические ограничения, как правило, применяются к примитивам попарно, первый примитив связан со вторым, второй с третьим и т.д. В результате получается система уравнений с малым количеством значимых переменных для каждого уравнения. У нас может быть ~10^5 уравнений и ~10^6 переменных, но в каждом отдельном уравнении будет участвовать всего 5-8 переменных. То есть матрица СЛАУ будет сильно разрежена. Мы нашли способ использовать эту особенность (что само по себе далеко не тривиально) – наш алгоритм позволяет не обращать всю огромную матрицу, а работать только с маленькими матрицами, и, кроме того, эта работа в значительной степени происходит параллельно.
Почему до этого додумались мы – маленький стартап, а не они – огромные межнациональные корпорации? Во-первых, возможно, мы просто талантливее, почему бы нет? Но есть и второй момент – крупные фирмы, создающие дорогие инженерные программы для профессионалов очень инерционны. Я хорошо знаком с этой ситуацией, до CAD я работал над другим типом инженерных программ – там то же самое. Производители не могут решиться на принципиальные изменения. Они живут по принципу «Работает? Не трогай!» и «Хорошее – враг лучшего», к этому их подталкивают пользователи, которым не хочется переучиваться и привыкать к новому поведению программы. Производители боятся, что резкое изменение программы приведет к разрыву многих контрактов и многомиллионным потерям. Может быть нововведение окажется полезным и, наоборот, программа привлечет много новых пользователей, но риск слишком высок. Каждая следующая версия мало отличается от предыдущей, большинство ресурсов уходят на поддержку и исправление багов, исследованиям уделяется очень мало внимания. Если срочно нужна новая функция, проще поглотить какого-нибудь мелкого производителя и прилепить его программу к основному продукту. За 20-30 лет изначально неплохой продукт превращается в неповоротливого монстра, мысленно живущего еще в 80х – 90х. Например, сейчас в API AutoCAD имеется 4 разных объектных моделей для примитивов. Они содержат одни и те же данные, которые просто унаследовались от разных команд и теперь приходится заботится об их соответствии.

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

Это если коротко.
Прежде всего, спасибо, что начали появляться комментарии по существу, от людей понимающих в CAD'е. Ради этого, собственно и писалась статья.

Вопрос «актуальна ли эта проблема?» для нас самих не на последнем месте. Я бы хотел добавить свои 5 копеек к этому вопросу.

Я проработал 3 года в PTC (как раз в группе, занимающейся скетчером и солвером), и я хорошо видел, что там, за 25 лет существования программы Pro/ENGINEER, ничего принципиально не менялось — у моего непосредственного начальника, как основной источник математического вдохновения, на столе лежала книжка небольшого формата «Краткий справочник по высшей математике для ВУЗов и ВТУЗов» (по-моему, 70-какого-то года издания). Я уж не знаю какой частью этого справочника он больше пользовался (для ВУЗов или для ВТУЗов), но математический уровень в компании был, по-моему, ближе к уровню ВТУЗов.

Я уже 5 лет как не работаю в РТС, но могу поспорить что основное изменение, которое случилось с Pro/ENGINEER за эти 5 лет, это то, что программу переименовали в Creo Parametric. Уверен, что внутри там мало что изменилось.

Такова реальность. Большие компании по части инноваций не эффективны. Это относится не только к российским госкомпаниям, но и к большим транснациональных хай-тек компаниям. Всё новое создаётся, как правило, в небольших стартапах (скажем, в таких как наш).

Как там будет дальше, покажет время — может, нас проглотит какая-нибудь большая компания, может, мы сами станем большой компанией, а, может, умрём от недофинансирования. В любом случае, если вы хотите сделать что-то по-настоящему новое, создавайте свой стартап.

Теперь по поводу того, нужно ли кому-нибудь, то что мы делаем.

Мы надеялись услышать какие-то комментарии по этому поводу от специалистов по CAD'у, которых, я уверен, много на Хабре (аудитория инвесторов, нас интересовала в данном случае гораздо меньше — для того, чтобы обратиться к ним есть более прямые методы).

Неужели никому из тех, кто работает с параметрическим CAD'ом не приходилось мучительно долго ждать пока программа пересчитает параметрическую модель (при этом, после долгого раздумья может оказаться, что уравнения решить и не удалось)? Неужели никто не замечал, что его любимая CAD-программа начинает работать всё медленнее и медленнее по мере того, как вы добавляете в чертёж новые примитивы и новые геометрические ограничения, так, что в конце концов вообще зависает (причём не на такой уж сложной модели)? Да, никогда не поверю!

Я видел массу недоумённых вопросов и призывов к производителям CAD'a (на блогах этих компаний) сделать что-то с этой ситуацией. Ни одного вразумительного ответа от них не последовало. Как-будто нет такой проблемы вовсе. И это происходит на протяжении уже двух десятилетий.

Знаете что я думаю? Мне кажется, что основная причина, почему в течение десятилетий нет никакого реального прогресса в параметрическом CAD'e, состоит в том, что у всех основных производителей параметрического CAD'a солверы работают примерно одинаково плохо — у кого чуть лучше, у кого чуть хуже. А раз у всех твоих конкурентов примерно так же плохо как и у тебя, то нет никакого стимула что-то улучшать — и так купят…

Нам в Cloud Invent кажется, что ситуацию пора менять. И у нас большие планы на этот счёт.
Как тут не вспомнить штриховку сложного и не совсем валидного контура в AutoCAD.
Март 2, 2015

Мы выпустили верию Альфа 0.3 нашего Cheetah Solver плагина для Автокада.

В этой версии мы

* Существенно увеличили скорость работы солвера (на некоторых моделях он стал работать раз в 10 быстрее)
* Реализовали работу нашего солвера с блоками
* Исправили массу багов.

Будем рады, если вы скачаете эту улучшенную версию с нашего сайта.
Будем ещё более рады, если вы поделитесь своими комментариями
Sign up to leave a comment.