Тема возникла из споров о преимуществах MicroFe над строительными собратьями.
Поясню, что я понимаю под макроязыком.
Это (в моем частном определении) есть совокупность команд, позволяющая управлять процессом построения, расчета и анализа модели плюс обычные программные конструкции (условия, циклы, переменные, массивы и т.д.).
C помощью языка можно управлять не только нумерованными наборами примитивов (узлы 1, 3, 10; элементы 2,9,6), но также и наборами описанными логически
(например
set1="узлы с координатой Y в диапазоне a...b*sin(alpha), где a, b - заданные пользователем переменные)
или
set2 ="элементы с типом сечения 2, но не смежные с узлами номер 1,2,3"
и так далее - все мыслимые варианты
(за эталон берется APDL).
Если да, то какой синтаксис лучше взять за основу (фортранообразный, питонообразный, бейскообразный и т.д.?)

[p_sh]

бейскообразный (просто, но м.б. в других местах сложно)

[Дмитрий]

Если уж делать что-то, то не просто запись сценария или автоматизация каких-то стандартных действий пользователя, а возможность создания полноценных пользовательских функций, а вообще, как мне кажется, надо сделать такую платформу:
1. пользовательские функции с доступом к результатам стандартных расчетов (усилия там, перемещения и т.п.) и прочим данным
2. возможность добавления полей пользовательских данных к стандартным объектам (например, указать к какому конструктивному элементу относится данный КЭ)
3. визуализация и документирование программой пользовательских данных/результатов работы пользовательских функций

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

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

[holstenman]

Упомянутый APDL - это главная причина, почему пользователи ANSYS до сих пор не переходят полностью на ANSYS Workbench. Действительно, очень удобная штука. А вот какой синтаксис будет - это уже второй (третий, четвертый и т.д.) вопрос, больше относящийся ко вкусовым пристрастиям пользователя, - кто-то с бейсиком связался, кто-то с лиспом, кто-то без фортрана жить не может, - проще было бы использовать и то и другое и третье, не так уж это и сложно.
Создание пользователем элементов интерфейса должно быть обязательно, - ежедневный поиск созданного "на днях" макроса где-то в пыльных уголках харда еще никому не нравился. Кстати, интерфейс ANSYS доступен пользователю на уровне исходных кодов - менять можно что угодно, было бы желание.

Макрос в текстовом файле все же в каком то смысле незаменим.
Как пользователи ACAD - зашел с утра =скачал лиспик, посмотрел-разобрался, добавил в копилку или выкинул. в расчетных программах макроязык помимо таких не особо нужных вещей как оптимизация и собственная библиотека типовых параметризированных конструкций дает на мой взгляд еще один плюс - приспособить алгоритм анализа по своему вкусу или в соответствии с традициями организации. Любая строительная софтина все же навязывает пользователю свой собственный подход к анализу, форму отчета и т.д. Иногда выдаваемая документация недостаточно подробная, иногда - наоборот - излишне подробная, а регулировать по своему вкусу немного возможностей. То, что нерально сделать гибким через интерфейс на самом деле возможно через несколько программных конструкций.

[Дмитрий]

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

Истину глаголите... :idea:

[Profan]

О чем здесь идет речь? О программировании интерфейса или о программировании расчетных процессов? Второе, по-моему, ересь.

[Дмитрий]

Сообщение от Profan О программировании интерфейса или о программировании расчетных процессов? Второе, по-моему, ересь.

А что понимать под "расчетными процессами"? В формирование и решение СЛАУ, насколько я понимаю, лезть никто не собирается, а вот такие вещи как задание и изменение каких-либо свойств конечных элементов, отображение и подача результатов, проверка прочности и подбор армирования - почему бы и нет? Скажите, какие МКЭ-комплексы корректно считают поперечное армирование в хотя бы в балочных элементах, трещиностойкость в ж/б плитах, продавливание, предварительно-напряженные конструкции и т.д.?

Сообщение от Profan О чем здесь идет речь? О программировании интерфейса или о программировании расчетных процессов? Второе, по-моему, ересь.

Гм. Встречный вопрос: что вы подразумеваете под расчетными процессами? Если вмешательство непосредственно в процесс решения СЛАУ МКЭ, то пожалуй. А если управление программой (в дополнение к обычным возможностям) посредством команд - то удивительно. Например перед вами узел номер 5. Вам надо дать закрепление по X: вы вместо того чтобы а) открывать соотв. закладку (в СКАДе) б) кликать по соотв. кнопке в) кликать по форме г) выделять узел д) подтверждать выделение - просто машинально вводите команду типа "d 5 ux", ну или там через запятую ? Это конечно самый элементарный и тупой пример. Я то подразумевал например вот что: для неких однообразных изо дня в день действий записывать макрос и запускать его потом посредством скрипта с начальными параметрами и диалогами (если нужно). А пользовательские отчеты? Сцепить необходимые данные с произвольеным текстом, как самое элементарное ? Я вижу только одно осложнение - недостаточно широкие возможности самих строительных софтов, для того, чтобы в полной мере можно было использовать макроязык... Например в том же SCADе - то что касается стержневых элементов - в принципе со скрипом но наверно можно. Правда потом сразу захочется еще с десяток дополнительных функций по тому же препроцессингу, но вот и будет повод их дописать!

[novinkov]

По крайней мере, наша фирма готовы платить вдвойне, если в составе комплекса будет язык макрокоманд. Подобие APDL, PCL, TCL-TK или Femap-Basic абсолютно без разницы (за API на основе С++ платить не готовы :))

[Profan]

Для The_Mercy_Sea.
Ну, вы как раз говорите о программировании интерфейса. Вопрос в том, нужно ли это проектировщику - изучать языки программирования и сочинять скрипты и программы. К тому же, расчетная программа должна иметь открытую архитектуру, наподобие AutoCAD'а. Пойдут на это разработчики программных комплексов? Что-то сомнительно.
А для развитого оформления результатов расчета возможно применение более мощных средств, чем доморощенные макросы. Я, например, использовал для этого CorelDRAW.
Для Дмитрий.

Скажите, какие МКЭ-комплексы корректно считают поперечное армирование в хотя бы в балочных элементах, трещиностойкость в ж/б плитах, продавливание, предварительно-напряженные конструкции и т.д.?

Так это проблемы разработчиков, на них надо давить. Неужели вы думаете, что обычный проектировщик более успешно решит эти проблемы на программном уровне, чем разработчики?
Конечно, если кто-то работает в конторе типа ЦНИиСК, то ему, видимо, уместно иметь возможность вмешиваться в процесс расчета.

Сообщение от Profan Для The_Mercy_Sea. Ну, вы как раз говорите о программировании интерфейса. Вопрос в том, нужно ли это проектировщику - изучать языки программирования и сочинять скрипты и программы. .

Вот это я пытаюсь выявить опросом. Безусловно что не 100% проектировщиков !!! Но мне кажется, что по крайней мере 1/3 это нужно. Тем кто пользует программу раз в полгода - не нужно на самом деле, они никогда не обучатся. А тем кто ежедневно - много лет работает в одной прграмме, любит ее и желает улучшить?
Да и обучение кстати таким вещам происходит элементарно: просто работаете сначало интерактивно но иногда поглядываете в лог на появляющиеся там использованные вами команды (и возможно - комментарии). Это не язык программирования о котором вы говорите а гораздо элементарнее (хотя и с выходом на программирование).
И потом - не обязательно придумывать свои программы, можно же как те же лиспы находить их на форумах в процессе общения с коллегами.
Есть масса рутинных ежедневных операций, которые появляется возможность автоматизировать.
Например вы считаете что то находитесь в стадии подбора сечений и вас спрашивают выборку массы и длинн по профилям (хотя бы без фасонок) и объем бетона. С макроязыком такая задача решается элементарно - небольшим скриптом, содержащим цикл по типам сечений, раз - и перед вам отчет с подробной таблицей или наоборот с одной-двумя цифрами. И нажимать нужно одну кнопку - вывод на печать.
А сбор нагрузок по СНиП (ветровой, полезной) не проще ли программировать в той же программе, куда эти нагрузки потом прикладываешь? Любая удобная алгоритмическая штуковина подсмотренная в какой то другой (не вашей программе) быстро превращается в макрос и работает в вашей. И не надо ничего докупать или ждать у моря погоды - когда разработчки снизойдут до ваших желаний и прикрутят очередную конопочку (они это делают по закону редких явлений).
Да даже просто умножить 25,68 на 106 например? Открывать калькулятор или ввести в строку "aaa=25.68*106" надавить Enter и посмотреть в комменте принятое значение параметра?
Но термин "программирование интерфейса" на мой взгляд не особо удачен, т.к. предполагает подчинение команд интефейсу. На самом деле IMHO все должно быть с точностью до наоборот. команды гораздо гибче и функциональнее (в таком языке как APDL во всяком случае).

[Дмитрий]

Сообщение от Profan Так это проблемы разработчиков, на них надо давить. Неужели вы думаете, что обычный проектировщик более успешно решит эти проблемы на программном уровне, чем разработчики?

Неужели Вы думаете, что если "эти проблемы" я успешно решаю на бумажке или в собственной утилитке, то в макросе не получится? Просто на многие вещи приходиться забить болт, поскольку на нет и суда нет...
А мое глубокое убеждение - строительные программы делают не инженеры, потому и недопонимание.

[Profan]

Действительно, строительные программы делают не инженеры (а сукины коты), а считают не программисты - вот ведь беда какая. :twisted:

[Operkot]

Однозначно ДА!

[Евгений, Екатеринбург]

Несомненно в достойной программе должен быть язык программирования. Однако для простых программ, которые находятся в большом общепользовании наличие такого серьезного инструмента очень опасно (это ведь не лисп где результат виден). Появится куча прожек в инете с описанием типа - считает арматуру в плитах и попадется куча ленивых товарищей которые насчитают по ней (хоть и никто ее не тестировал и не знает как она работает).
Часто в лире не хватает (кажется а вот щас бы написал да получил арматуру по усилиям), а нету.
В общем да, язык необходим (несмотря на явный минус указанный выше).

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

Почему, собственно, опасней чем вообще программа, сама по себе? Перед запуском на счет здравомылящий человек обязательно проверит схему по факту того что задано (через листинг и визуализацию того сего). Напортачить можно и без языка - даже больше вероятность (выделил лишние узлы при задании ГУ или наоборот они не выделились).
А макросы всего лишь инструмент - не может же быть опасна отвертка или плоскогубцы сами по себе?
Опасно, как я считаю, это то, когда сама базовая программа считает неправильно, с внешне правдоподобным результатом. Т.е. в ситуации когда ожидаешь получить верный результат - получаешь неверный. Такое бывает.
А пользовательские методики инженерного расчета - почему? Там же собственно тоже легко сделать результат прозрачным. Сначала выводим в отчет исходные данные, потом выкладки типа "c=1+1*3=4" а потом и результат. Как раз все проверябельно, гораздо прикольнее "коэффициента использования", который - когда верный, а когда и нет. даже если методика вполне сертифицированная госстроем...

[Евгений, Екатеринбург]

Сообщение от The_Mercy_Seat Почему, собственно, опасней чем вообще программа, сама по себе? Перед запуском на счет здравомылящий человек обязательно проверит схему по факту того что задано (через листинг и визуализацию того сего). Напортачить можно и без языка - даже больше вероятность (выделил лишние узлы при задании ГУ или наоборот они не выделились).

дело в том, что здравомыслящих не так уж и много. Так же сам по себе АК-74 не опасен, опасен в руках неадекватного человека. Программы вообще (типа лиры) имееют защиту от дураков неслабую, а то что сделает чел с таким мощным инструментом как макросы предусмотреть нельзя.
зы. Сам с удовольствием пользуюсь :-)

[novinkov]

to Евгений, Екатеринбург:

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

Сообщение от novinkov А для защиты от дурака должен быть другой инструментарий (лицензирование, экспертиза, внутренний контроль фирмы, инстинкт самосохранения, наконец, и пр.).

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

[Евгений, Екатеринбург]

Сообщение от novinkov А для защиты от дурака должен быть другой инструментарий (лицензирование, экспертиза, внутренний контроль фирмы, инстинкт самосохранения, наконец, и пр.).

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

[novinkov]

Дополнительный инструментарий (на выбор):

Для людей с полностью отстутствующим инстинктом самосхранения - Уголовный Кодекс.
Для людей с ограниченным инстинктом самосохранения - Гражданский Кодекс
При отсутствии квалифицированных инженеров КСС>10.0 с плавным вытеснением с рынка

[Евгений, Екатеринбург]

Сообщение от novinkov Дополнительный инструментарий (на выбор): Для людей с полностью отстутствующим инстинктом самосхранения - Уголовный Кодекс. ...

Тогда УК должен обязательно входить в состав справочной системы программы и при установке нужно ставить крыжик мол прочитал и согласен :-).

[Lamer Inc..]

Следовало бы добавить вариант ответа: "Необходим".
Что касается бейсико- и прочей фортраноподобности - пусть хоть что-нибудь разработчики сделают. Хоть кобол. Выучим.
В идеале - ООП на VBA.
С лириками общались лет 7 назад по поводу консоли,нас даже слегка обнадежили. Но, как показало время, не более того.

А то приходится заниматься написанием поделух для чтения текстовых файлов исходных данных и результатов расчета. Анахронизм.

[Profan]

Еще день-два и голосовавшие "Да" сообразят, что полноценный макроязык в High-End расчетных программах (комплексах) не нужен и даже вреден как проектировщику, так и производителю. Он нужен только тем, кто, по выражению ShaggyDoc, "тараканятся" на этом форуме.

[novinkov]

ShaggyDog - почетный филолог форума!!

Сообщение от Profan Еще день-два и голосовавшие "Да" сообразят, что полноценный макроязык в High-End расчетных программах (комплексах) не нужен и даже вреден как проектировщику, так и производителю .

Гммм. может быть где то или даже много где не нужен, но со "вреден" вы явно преувеличиваете.


Евгений,Екатеринбург
Да, макросы могут быть и удачными и неудачными. Могут содержать какие то скрытые ошибки или даже и не ошибки, а неувязки того что той или иной командой декларируется с тем, что фактически делается. Да и так называемые "строительные программы" если взглянуть на них с точки зрения программирования, в основном - как наряженная елка или салат "Оливье" - не имеют достаточной математической стройности и структурированности, что создало бы по всей видимости немалые затруднения для подведения под них макроязыка.
Но, если идея хорошая, то почему бы им (разработчикам) не захотеть ее реализовать? Хотя бы частично, хотя бы бедное подобие ... :?:

[Дмитрий]

Сообщение от The_Mercy_Seat Но, если идея хорошая, то почему бы им (разработчикам) не захотеть ее реализовать? Хотя бы частично, хотя бы бедное подобие ...

Да не будет этого, даже не обольщайтесь, дискутировали уже на эту тему:

Сообщение от Разработчик А пользовательское программирование... "догнать Савранского - это утопия" (с) "Покровские ворота". Если пользователь может писать алгоритмы расчетов, то это пользователь не SCADов-Лир-ПРУСКов и пр., а Delphi, Visual C++, ну на худой конец какого нить Basic.

Сообщение от Дмитрий Да, если пользователь умеет писать на "Delphi, Visual C++, ну на худой конец какого нить Basic", то это - не наш пользователь "Наши люди в булочную на такси не ездят!" - позиция понятна Тут уж позвольте с Вами не согласиться: возьмите пользовательское программирование в AutoCAD, Word, EXEL. Масса людей пишут по-маленьку для себя и других (причем безвозмездно) и отнюдь не от переизбытка свободного времени...

Сообщение от Разработчик Не надо передергивать. Во-первых ни одна из этих программ не занимается серьезными расчетами. Представить себе, что пользователь будет править на свой вкус наш, хотя бы даже алгоритм поиска положения нейтральной линии, могу только в кошмарном сне. И во вторых, >90% пользователей Word даже не подозревают о возможности программирования в нем а половина оставшихся пишет вирусы. И уверен, что подавляющее большинство пользователей двух других систем предпочитает получать (за деньги или "безвоздмездно") готовые таблицы или лиспы, а не заморачиваться с программированием и отладкой.

Так что пользовательское программирование - это не в нашу песочницу

Сообщение от Дмитрий

Меня MikroFe в принципе не особо волнует, как программа. Хотя может быть она неплохая но я не считаю ее чем то выдающейся по сравнению со SCAD и Лира - другими дешевыми программами занимающими строительную нишу.
У нас пользуются SCAD, и в ближайшее время вряд ли на что то другое перейдут. Хотя, думаю что и мнение разработчиков СКАДа не сильно отличается.
Просто есть такая фактическая вещь, как макроязык. Существующая в природе объективно, независимо от сознания Разработчика, Profan-а и еще кого бы то ни-было. Насладиться им в полной мере более чем элементарно, москвичам по крайней мере - конечная метро, "Щелчек" , бывший НИИ "ЦИКЛОН" = версия ANSYS ED до 1000 узлов. Для ознакомления и прорешивания всего Биргера с Тимошенкой и Власовым вполне хватает.
Есть другие программы с аналогичным преимуществом.
Я преследую только одну цель - выявить мнение форумчан и убедится что по крайней мере не один я так думаю ....

ЗЫ Пример Разработчика о том что 90% пользователей MS Office не нужно программирование явно нелеп. 90% пользуются не MS Office а содержимым диска "Золотой Софт" - в объеме не превосходящем WordPad. Я скажу честно - не видет ни одной серьезной конторы, где бы был легальный, настоящий "офис" где бы не использовали в той или иной мере VBA.
Если так рассуждать - что программа с базара тоже программа - следует поставить на рабочее место одновременно: СКАД_Робот_Лира_Микрофе = все вместе обеспечивает достаточную гибкость - в одной лучше одно, в другой - другое.
Ну и конечно же MS Офис (или даже Open) - весьма и весьма серьезные программы, по трудозатратам и проработанности МикроФе с ними даже рядо не стояло, но тут просто сравнения не уместны - т.к. функции разные.

[Lamer Inc..]

Евгений, Екатеринбург

Так же сам по себе АК-74 не опасен, опасен в руках неадекватного человека. Программы вообще (типа лиры) имееют защиту от дураков неслабую.

Неадекватный человек легко накосячит и в Лире, и в SCADе, и в COSMOSе - невзирая на "защиту от дурака". За примерами далеко ходить не надо - каждый 3-й топик этого форума, посвященный расчетным программам, обусловлен косяком при создании расчетной модели.
Почему же практически в любом промышленном западном комплексе имеет место быть и консоль, и макроязык?
Такое подозрение, что дело все-таки в деньгах. Написание языка макрокоманд, увязка с внутренней структурой данных и процедур потребует значительных усилий. А сколько в настоящий момент программистов у тех же лириков? Кто этим будет заниматься?

[novinkov]

Технических проблем не бывает. Есть проблемы финансирования.

1. Цена вопроса для разработчиков. В одной из веток, я задавал вопрос о том, проводились ли маркетинговые исследования по необходимости введения языка программирования. По-видимому, нет. Так как отсутствуют серьезные (то бишь, финансовые) аргументы "за" или "против". Наверное, у разработчиков свое видение ситуации. К тому же им некогда тараканиться (классное слово, молодец ShaggyDog!) на флуд-форумах - они на передних рубежах науки делают замечательные комплексы..

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

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

STAAD Pro с его VBA стоит как раз ровно в 2 раза больше :!: Но там в свою очередь привязанность к нашим нормам на базовом уровне хуже. Плюс конечно же это "легкий" софт - не типа ансис. А надо так чтобы , как говорил Шариков - "как у людей" - и то и это: и ноги не кривые и физиономия стоящая ...

[Дмитрий]

Сообщение от Lamer Inc.. Такое подозрение, что дело все-таки в деньгах. Написание языка макрокоманд, увязка с внутренней структурой данных и процедур потребует значительных усилий. А сколько в настоящий момент программистов у тех же лириков? Кто этим будет заниматься?

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

Все таки для пользователей строительных программ (любых) было бы хорошо, если бы их разработчики по крайней мере переменили свое мнение относительно пользительности взаимодействия с программой на уровне макроязыка (слово программирование я не употребляю намеренно). По сути дела фичей в каждой из них затолкано немало, но если так разобаться - больше половины из них действительно нужны мало кому повседневно (модули типа "МОНТАЖ" и т.д.).
Предлагаю просто голосовать за первый пункт. Vox populi - vox dei.

[Rotfeder]

А вот взгляд с другой стороны.
Если бы я был маркетологом и посмотрел этот опрос, то какие выводы я бы мог сделать.
Вроде 60% голосует за макроязык.
Однако. Всего проголосовало 28 человек. Это при 770 просмотрах темы. Даже если учесть, что кто-то смотрит эту тему 20 раз в день, а таких вряд ли много, то все равно, уникальных просмотров примерно 100. Значит 100-228=72 человека, которые не имеют никакого мнения на сей счет - то есть им это по барабану.

Кроме того тема висит вверху форума уже сутки и ее заголовок видело предположим еще 100 человек, которые в нее даже не зашли. То есть им тоже макроязык на фиг не нужен.

The_Mercy_Seat
Word использую уже наверно лет 15. Макросами при работе в Word пользовался некоторое время, но давно. При этом Wordpad моим потребностям не удовлетворяет.
Должен честно признаться, VBA используюется для вывода результатов из MicroFe, однако это уже не совсем тот случай, о котором мы говорим.

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

[Rotfeder]

Да! Совсем забыл. Кроме затрат на разработку есть еще затраты на поддержку. И мне почему-то кажется, что они будут даже более существенны.

Сообщение от Rotfeder Вроде 60% голосует за макроязык. Однако. Всего проголосовало 28 человек. Это при 770 просмотрах темы. Даже если учесть, что кто-то смотрит эту тему 20 раз в день, а таких вряд ли много, то все равно, уникальных просмотров примерно 100. Значит 100-228=72 человека, которые не имеют никакого мнения на сей счет - то есть им это по барабану. Кроме того тема висит вверху форума уже сутки и ее заголовок видело предположим еще 100 человек, которые в нее даже не зашли. То есть им тоже макроязык на фиг не нужен. .

Это не совсем верный подход. Во первых просмотры засчитываются кратно - только я заходил раз 50. Для тех кому по барабану есть в принципе позиция 2 и позиция 3. Каюсь, забыл про лопату.
Но на сайте dwg.ru есть вообще то говоря и чертежники и таких большинство. Мне не нужен макроязык при черчении и я тоже не захожу в опросы чертежного направления. В общем, опрос составлен досотаточно корректно, и коль вы были маркетологом - не мне вам это объяснять. Кто хотел выразить своем мение - тот его выразил.

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

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

Сообщение от Rotfeder Да! Совсем забыл. Кроме затрат на разработку есть еще затраты на поддержку. И мне почему-то кажется, что они будут даже более существенны.

Вот тут я категорически не согласен. За курсы берутся бабки. И будет лишний повод организвать дополнительные курсы.
Необходимость в поддержке возникает по большей части из-за куцей справки и программных косяков. И я не заметил чтобы например "кое где" поддержка была сильной стороной: на вопрос "почему у вас косяк" встречный вопрос "а у вас все модули лицензионные" (мордой в гавно, что называется) а второй "вы сами дураки, отвлекаете нас великих по пустякам". Нет, я согласен с Дмитрием, и может это крамольная мысль (про менталитет), но в совке нет пока ни бизнеса, ни поддержки, ни программ - ничего кроме желания срубать и срубать бабки.

[C1]

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

Похоже ANSYS делают плохие маркетологи.

Сейчас новый язык делать не обязательно. ANSYS начинали делать десятки лет назад, когда не было VBA. Нужно только открыть библиотеки объектов для возможности использования извне. Конечно придется все хоть немного задокументировать.

[holstenman]

Действительно, строительные программы делают не инженеры

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

а считают не программисты - вот ведь беда какая

- но и не секретарши...

Я так думаю, что игнорирование требований пользователей, - это лишь еще одно свидетельство того, как те или иные разработчики к этим самым пользователям относятся. А разговоры, что "как же им можно доверить модифицировать наш код", - можно рассматривать как оценку iq пользователей разработчиками. Объективна такая оценка или нет - не знаю, т.к. расчетных программ без макроязыков до сих пор серьезно не использовал и с людьми, которые такие программы используют, особо не общался.
Может быть, действительно следует сделать вывод, - у пользователей программы ANSYS IQ выше, чем у пользователей программы Скад-Лира и т.д.? Или у пользователей программы Autocad IQ выше, чем IQ пользователей аналогичной программы без встроенного языка (задолбался вспоминать, есть ли такое вообще) ?

Сообщение от holstenman

Инженер - это инженер, а программист - это программист. Если люди работают в смежных сферах, то нормально, когда инженер является программистом любителем, а программист - инженером любителем. Мнение программиста о процессе проектирования и о работе конструкций чаще всего с налетом ламерства (типа - это ерунда, чего там не понимать, я все знаю - по ТУиТП у меня было пять). То же и наоборот: инженер, освоивший какой-нибудь VBA на уровне одной книжки иногда имеет неосторожность судить о всем программировании легкомысленно.
Профессионалом обязан стремится стать каждый в своей сфере. Пользователи общестроительных программ чаще всего хорошие инженеры, и с интеллектом у них в целом нормально все.
О модификации кода речи даже не идет - только об использовании этого самого - построчного - ну, я называю его макроязыком.
Я не испытываю личного антагонизма и к разработчкам (уважаемому Разработчику в частности - это IMHO очень умный дядька). Но спор есть спор- должен быть с элементами остервенения - по всем правилам. Я говорю, давайте ребята, шевелите задницами - не одним пиаром жив человек, капитализм на дворе - улучшайте качество, расширяйте возможности, догоняйте акул. Они говорят - зачем, если и так жизнь прекрасна, и так у нас все не хуже, а акулы они и не акулы - а так себе? Лучше мы потравим байки про то про се - глядишь вы о своих желаниях забудете и побежите нас покупать.
Я программирование знаю в целом на уровне гимназического курса, но все же сам допираю, что написание интерпретатора не может быть очень сложным, и более того - речь даже идет не о написании, а об адаптировании уже какого то имеющегося. Но то, что я писал выше - о стройности. Вот ANSYS - стройная программа. Нет там конечно ни снипов ни наших ни американских ... но она, как это скзать - красивая. Там все логично, математично выстроено, когда начинаешь разбираться, сначала все кажется сделано очень неудобно, но потом осознаешь что все именно так, как должно быть почти в идеале. И ничего лишнего. ACAD тоже стройная - причем это даже лучше видно в старых версиях, где нет безумного нагромождения волшебных кнопочек а только чистый лисп. А строительные, если начать в них вталкивать макроязык придется ну если не переписывать, то перекладывать и что то добавлять в существующие детали. А кому интересно перетряхивать старый хлам?
А вы как думаете?

[Rotfeder]

Сообщение от The_Mercy_Seat Это не совсем верный подход. Во первых просмотры засчитываются кратно - только я заходил раз 50. Для тех кому по барабану есть в принципе позиция 2 и позиция 3. ... Кто хотел выразить своем мение - тот его выразил.

Я про это писал и на всякий случай разделил число просмотров на 7. Предположим, я не прав и делить нужно на 27. Это будет значить только то, что в эту тему мало заходят. Почему? Тема висит в топе и заголовок понятен. Значит, просто по барабану. Тот кому по барабану - он просто не голосует.

Сообщение от The_Mercy_Seat А чья то окупаемость меня в общем и целом - тоже не волнует ... ничего кроме желания срубать и срубать бабки

Меня тоже не волнует чья-то окупаемость. Мы, конечно, занимемся благотворительностью, но в ограниченных размерах.
Делать что-то, что никому не нужно, можно из научного интереса, в свободное от работы время. А один из основных показателей того, что это что-то нужно и есть окупаемость. Может непонимание таких простых вещей тоже признак совкового мышления?

Сообщение от The_Mercy_Seat И я не заметил чтобы например "кое где" поддержка была сильной стороной: на вопрос "почему у вас косяк" встречный вопрос "а у вас все модули лицензионные

Техподдержка осуществляется не на этом форуме. Нормальный пользователь задает вопросы по телефону или электронной почте. И получает на них ответ. В большинстве случаев - что поделаешь у всех бывают проблемы.

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

Сообщение от The_Mercy_Seat мордой в гавно

интернет-форумы они такие, все друг друга подначивают - это нормально. Если же кто-то начинает хамить - то пусть не обижается.

[Rotfeder]

Насчет легкости написания интерпретатора.
Сам лично не писал. Однако тема это хорошо разаработана и принциапиальных сложностей нет. Только интерпретатор - это может быть 1 процент работы.
Понятно, что есть функции типа довать узел, добавить элемент, взять усилие в узле и т.п. Для предоставления к ним доступа, с каждой из них нужно сделать какую-то операцию - условно говоря добавить интерфейс, который будет понимать интерпретатор языка. Теперь представьте себе сколько этих функций всего.
Проблема номер два. Каждая из этих функций вызывается в каком-то контексте, в котором она протестирована и нормально работает. Лишних проверок в них нет, хотя бы потому, что любой оператор if замедляет работу программы.
При использовании ее извне надо обеспечить целостность данных, что является нетривиальной задачей - разбираться надо будет с каждой функцией по отдельности.

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

[C1]

Сообщение от The_Mercy_Seat А строительные, если начать в них вталкивать макроязык придется ну если не переписывать, то перекладывать и что то добавлять в существующие детали. А кому интересно перетряхивать старый хлам?

Другой причины почему строительные программы у нас закрыты для пользовательского программирования не вижу. Спешка. Безсистемность. Делались совсем за другие деньги нежели ANSYS и пр.

[Дмитрий]

Сообщение от Rotfeder Делать что-то, что никому не нужно, можно из научного интереса, в свободное от работы время. А один из основных показателей того, что это что-то нужно и есть окупаемость. Может непонимание таких простых вещей тоже признак совкового мышления?

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

[holstenman]

Сообщение от Дмитрий Потом, как знать, какие новые перспективы может открыть появление макроязыка в вашей программе?

-ой, ну его... это ж надо еще спрос изучать, интересы пользователей, оценивать, - насколько этот макроязык вообще нужен пользователям того же ansys'a, patran'a и прочих... может они его и не используют вовсе и не пишут эти свои макросы... а потом каждую функцию протестируй, задокументируй. Это ж все так непросто. Это ж чего-то там делать надо, в книжку лезть, третий курс вспоминать, все эти "лексические анализаторы", "синтаксические анализаторы", "семантические анализаторы"... готовый макроязык использовать, - так с ним еще разбираться придется. Функции свои встраивать... А потом - ну, реализуем, ну и что дальше - техподдержку вопросами завалят, им же кроме кнопок ОК и Отмена ничего доверить нельзя, криворуким...

Сообщение от Rotfeder

Вы меня не поняли. Я думаю, что тот, кому эта тема (расчеты или расчетные программы) не интересны или малоинтересны просто не голосует. Как я не голосую в опросах посвященных AutoCAD. У меня даже нет AutoCAD, ибо я почти не черчу, не в большом курсе всяких тонкостей и новинок и не желая показать свою неосведомленность (даже анонимно) - не голосую про то, что меня напрямую не касается.

Про поддержку я говорил не имея ввиду форум - конечно емейл, и программа лицензионная. И какая не скажу - вполне нормальная, и поддержка может быть даже в целом нормальная, просто я так неудачно на м$даков попал.
Да это все и неважно. Как и то сколько процентов стало бы обсуждаемый инструмент использовать. По моему - где то около одной трети из продвинутых пользователей. Т.е. тех кто по гроб жизни будет вашу программу приобретать, обновлять и т.д., и кого по идее разработчики должны любить, жаловать, устраивать им конкурсы с хаспами в качестве приза.
А не случайно-удачно-разведенных на бабки, кому и программа то не слишком нужна и правильно пользоваться они ей так и не научатся - даже если таких большинство. IMHO - это и есть самый что ни есть голимый и прагматичный маркетинг в европейском или американском например стиле. а не в стиле отечественных торговцев арбузами ...
А вот то что сложно сделать из того что есть - это уже конкретная информация, за которую спасибо.

[Lamer Inc..]

...позволю себе предположить, что отечественные комплексы несут в себе весьма солидный кусок процедурного программирования прошлых лет. Я имею в виду те времена, когда Лира и Скад еще были одной программой. Далее, с появлением Windows, производилось приспособление комплекса под новые возможности ОС. При этом структура данных осталась тоже прежней. Отсюда следует, что и полноценная поддержка того же VBA повлечет за собой переработку всего комплекса на ООП. А это не то же самое, что привесить окно текстового ввода с процедурой вызова соответствующих функций dll. Так что проблема может оказаться и более серьезной, чем обрисовал ув. Rotfeder.

Сообщение от Lamer Inc.. ....

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

[EXZet]

Сообщение от Rotfeder Да! Совсем забыл. Кроме затрат на разработку есть еще затраты на поддержку. И мне почему-то кажется, что они будут даже более существенны.

Да, нужно много чего доделать и кроме создания макроязыка, но, как компромисс, вполне безболезненно можно открыть ВСЕ исходные и выходные данные в для обработки пользователем, а для бинарных файлов предоставить описание формата или организовать экспорт в доступную форму.

Сообщение от C1 Другой причины почему строительные программы у нас закрыты для пользовательского программирования не вижу. Спешка. Безсистемность. Делались совсем за другие деньги нежели ANSYS и пр.

А как же то, что при закрытости комплекса за дополнительные фичи можно брать деньги за обновления, указывая их в анонсе?


Вообще, макросы при работе с большими объемами данных актуальны лишь на уровне интерфейса, более "красивый" подход - поддержка "модульности", проще говоря плагинов, которые можно вызвать из программы, кроме того реализация этого подхода ИМХО связана с гораздо меньшими затратами. Ну, скажем в одной программе, которой я пользуюсь :wink: упаковки схемы к сожалению нет, а при наличии возможности написал DLL-ку, повешал кнопку на тулбар препроцессора и проблема решена. Организация обмена данными м/у графическим препроцессором и подключаемой DLL, обратный обмен для вывода данных из плагина на расчет в сущности необходимая и достаточная работа. Возможно, что при подобном подходе времени на доработку расчетных модулей и реализацию новых неформальных идей появится больше. "Открытые" или "частично открытые" продукты обычно завоевывают немалую популярность и программы, не имеющие такой возможности, как правило, оцениваются пользователями ниже.

P.S. Мысли по-поводу "всем по барабану" мне непонятны, плагины обычно пишут несколько десятков/сотен пользователей, остальные ими пользуются, причем за хорошие работы и денег создателю плагина не грех заплатить. В итоге популярность продукта растет без раскрытия основных ноу-хау разработчиками.

Сообщение от EXZet Вообще, макросы при работе с большими объемами данных актуальны лишь на уровне интерфейса, более "красивый" подход - . .

А по моему это уже слишком. Макроязык то в общем хорош тем, что предельно прост для рядового пользователя (в том числе и не имеющего серьезных навыков программирования).
Но кому то и это нужно (добавлять плагины), и в этом тоже нет ничего плохого.

[C1]

Резюме:
Товарищ, верь! Придет она
В строительство программа с макросами!
И на могилу скада с кактусами
Придет довольная страна.

Сообщение от The_Mercy_Seat Макроязык то в общем хорош тем, что предельно прост для рядового пользователя (в том числе и не имеющего серьезных навыков программирования)

Просто это устарело лет на 15. Макросов и интерпретаторов от разработчиков не дождетесь. А к версии 111.1 SCAD вполне возможно будет в Visual Basic сделать ссылку на scad.dll и написать
Set ScadApp = Scad.Application и т.д.
Ну если и Visual Basic сложен для пользователя. О чем тогда говорить.

[Profan]

Чувствуется, что люди, ратующие за внедрение макроязыка в расчетные программы - суть "чистые" расчетчики, которые не озабочены выпуском рабочих чертежей, что и является основной работой проектировщиков-конструкторов. The_Mercy_Seat так прямо об этом и сказал, упомянув, что у него даже AutoCAD не установлен. Или же являются ГИП'ами, что маловероятно. Сам продукт подсознательно их интересует больше, чем результаты работы этого продукта. Поэтому им и хочется "усовершенствовать" этот продукт, особенно, если речь идет о полуфабрикате типа ANSYS, страшно далеком от повседневных забот проектировщика.

Сообщение от C1 А к версии 111.1 SCAD вполне возможно будет в Visual Basic сделать ссылку на scad.dll и написать Set ScadApp = Scad.Application и т.д. .

Не о себе пекусь, а о начинающих.
Макроязык есть непревзойденная в простоте и силе вещь!

Visual Basic есть гуд, и бесплатный VB.NET 2005 Express тут вроде как в помощь. только бы задокументировать функции в этих самых dll не мешает.

Profan
Я расчетчик с элементами конструирования. и попутно гип в нескольких мелких конторах. чертежи я проверяю за другими с таким чудным инструментом как The Pencil. а расчеты стараюсь усовершенствовать, хоть где - чтобы делать дневную норму за полчаса и валять дурака остальное время А AutoCAD-а нет, потому что он есть у коллег, которые специализируются по части черчения и тоже ошиваются на сем форуме целыми днями.

[vv_77]

Может не в тему, но лично мне в расчетных программах при создании 3д модели очень не хватает командной строки (как в Автокаде) и возможности задавать свои псевдоимена командам (тоже как в Автокаде).

Слишком много приходится щелкать кнопками мыши.

[MMV]

" ANSYS, страшно далеком от повседневных забот проектировщика."

Ну... не так уж он и страшно далек, как раз благодаря APDL...

Сообщение от Profan Поэтому им и хочется "усовершенствовать" этот продукт, особенно, если речь идет о полуфабрикате типа ANSYS, страшно далеком от повседневных забот проектировщика.

ансис не надо усовршенствовать, это бессмысленно. И потом практические расчеты я делаю либо в SCAD, либо в самопальных программах, а ANSYS - что то вроде справочника. Это действительно очень хорошая самодостаточная программа. В ней сравнительно легко воспроизвести практически любое положение СНиП "Стальные конструкции" (коэффициенты табл. 74, 75, формы сечения, влияния пластиности - причем в легальной образовательной версии). Это конечно практически не надо делать, так как есть СНиП, но просто полезно для общего развития.
я если хотите пропагандирую не ANSYS, Abacus или Nastran (они действительно не рассчитаны изначально на массовое строительное проектирование), а инженерное творчество с использованием ПК.
ЗЫ
И вообще - довольно обидные ваши слова. Вы вроде автокадчик, лиспщик (если я не путаю), а тут такие исключения. Почему при черчении нужен, а при построении и анализе модели нет ? И тем более - вы расчетчик в прошлом (вроде как лировец?)... и не можете не понимать, что чем меньше время тратися на рутину, тем больше его остается на конструкторский анализ. Или вы против потому что фишка такая - ругать все чего нет у нас. вроде как влияние запада тлетворное, ну типа политика?

[Дмитрий]

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

Отечественные (да и не только) стоительные ПК, по-существу, хороши лишь двумя вещами - наличием годами "устаканенного" инструментария для хрестоматийных случаев (коих где-то процентов 70-80, хотя, конечно у всех по-разному) и бесспорной (в первую очередь - с точки зрения экспертизы) поддержкой требований СНиПов. Однако если задача выходит за рамки "поточной" работы - начинается секс и гимор, и ничего с этим не сделаешь, а разработчики, если и соблаговолят, новую кнопку прикрутят только в новой версии, годика через два-три...

[Rotfeder]

Сообщение от Дмитрий какие-то вещи должны делаться ради науки, престижа что ли

Абсолютно согласен. Только вот какой же престиж можно заработать на
задачке, которую способен решить студент-третьекурсник
А если серьезно - посмотрите к примеру список организаторов конференции BEM-FEM. Среди НИИ и университетов есть одно ООО - вы знаете какое.

Сообщение от Дмитрий Потом, как знать, какие новые перспективы может открыть появление макроязыка в вашей программе?

И с этим я спорить не буду. Пользовательское программирование - это в перспективе куча дополнительных примочек, которые живут своей жизнью и повышают интерес к программе.
Только делать все нужно хорошо, а то вы же первый плюнете нам в морду.
Про трудности первоначальной разработки я уже писал. А ведь еще есть трудности дальнейшей разработки - если сделал публичный интерфейс, этот интерфейс должен потом быть всегда - нужно юлюсти его совместимость. Два примера: в MicroFe есть вывод в Word. Написан он был еще тогда, когда в ходу были Word95 и Word97. Word97 предоставлял более удобный и человечный интерфейс. Но Word95 был еще в ходу. Вывод написали под него. Сколько версий Word сменилось - все до сих пор работает - спасибо Microsoft за наше счастливое детство.
Пример два - есть в MicroFe конвертер из Архикада. Использует он официальную Архикадовскую библиотеку. Но работает он только под версией 6.5 (могу ошибаться - точно номер не помню). Вышли новые версии Архикада - интерфейс у них поменялся, а старый интерфейс не поддерживается.

[Rotfeder]

Сообщение от EXZet как компромисс, вполне безболезненно можно открыть ВСЕ исходные и выходные данные в для обработки пользователем, а для бинарных файлов предоставить описание формата или организовать экспорт в доступную форму.

А вот с этим я согласен, только опять же одна проблема - формат иногда меняется. Хотя это конечно не страшно.
Вот мне интересно, если вести речь не о макроязыке, а о COM-модели, к которой можно обращаться из VBasic или из C. А предоставляемые функции будут ограничиваться только чтением данных кэ-модели и результатов расчета (это существенно проще для реализации). Много ли найдется пользователей такой фичи?

[p_sh]

Сообщение от Rotfeder о COM-модели, к которой можно обращаться из VBasic или из C. А предоставляемые функции будут ограничиваться только чтением данных кэ-модели и результатов расчета (это существенно проще для реализации).

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

оффтоп по gen3_dim
отмечу что и сам ввод модели еще может быть улучшен:
- логика ввода rigi. Я полагаю что полезно сделать кнопки: ввод/удаление узлов в группу, И добавление групп на одной панели, чтобы не делать таких длительных манипуляций. Сейчас приходится сначала добавлять N групп, затем добавлять узлы в группу и переключатья по группам, А можно было бы: нажать на кнопку НОВАЯ ГРУППА, нажать на кнопку(и) добавление/ удаление узлов. - получается всё в одном месте и никаких лишних телодвижений.

Сообщение от Rotfeder Вот мне интересно, если вести речь не о макроязыке, а о COM-модели, к которой можно обращаться из VBasic или из C. А предоставляемые функции будут ограничиваться только чтением данных кэ-модели и результатов расчета (это существенно проще для реализации). Много ли найдется пользователей такой фичи?

Немного конечно. Т.к. все таки VBasic и тем более C знают небольшое количество инженеров. И за неделю им не научишься, по вечерам, как основам apdl (где практически все распространенные задачи решаются набором из нескольких групп команд: "select", "get" + операции с массивами + фортранообразные "do", "if"). И вы конечно правы в том, что уж если что то создавать,то это должно быть более или менее функциональным и одновременно простым. И помимо собственно интерпретатора и взаимодействия с имеющимися функциями придется написать новые функции.

[Дмитрий]

Сообщение от Rotfeder Только вот какой же престиж можно заработать на задачке, которую способен решить студент-третьекурсник А если серьезно - посмотрите к примеру список организаторов конференции BEM-FEM. Среди НИИ и университетов есть одно ООО - вы знаете какое.

Наверное, подобные мероприятия весьма полезны для развития отечественной расчетно-теоретической мысли, однако, на мой взгляд, результаты подобных мероприятий "страшно далеки" от широкой инженерной общественности, так сказать, наука ради самой науки. Да и сами публикации вряд ли можно просто так найти...
Как как-то обмолвился Разработчик (не ручаюсь за дословность) "наши сотрудники катаються на международные симпозиумы и широко раскрывают глаза буржуям - чего же вы еще хотите от наших программ"

Сообщение от Rotfeder Пользовательское программирование - это в перспективе куча дополнительных примочек, которые живут своей жизнью и повышают интерес к программе.

Ну, в перспективе может быть и использование вашей программы и в каких-то серьезных работах, как тот же ANSYS.
Да и упорядочивание структуры программы для доступа к данным извне, вероятно, опять же пойдет на пользу, хотя как я могу судить о таких вещах?

Современная расчетная мысль насколько я помню лежала в области параллелизации вычислений,
в США сейчас предвосхищается переход к квантовым компьютерам для вычислений - это сулит для вычислителей колоссальные перспективы.
Все, что сейчас используют расчетные строительные программы - это современный уровень науки для 60-70-хх годов. А им больше и не надо. Все действительно новинки - это для атомной физики, астрономии, машиностроения.
А строительных программ назначение - не науку двигать а жизнь проектировщика облегчать.
И макроязык это вообще утилитарная вещь, к науке не имеющая никакого отношения.

[p_sh]

Сообщение от The_Mercy_Seat Т.к. все таки VBasic знают небольшое количество инженеров.

это вы зря про VB, он довольно прост т.к. лишен мудренного синтаксиса, имеет много справочников и примеров по сети.

проверено на себе.

Сообщение от p_sh

Да, я согласен, он прост (для вычислительных задач во всяком случае), мной лично любим, справочников и примеров много, экспресс_ 05.net еще и бесплатен. Но просто доступ к библиотекам из vb по моему не есть лучшее решение вопроса.
Ну вот откроют библиотеки, даже пускай - задокументируют их нормально и разработают примеры. Начнете писать - нет того, нет другого. Самому дописать - времени нет, когда другие напишут - неизвестно.
И разработка приложений на VB есть все же программистская работа. непрофильная для инженера.
А на apdl-подобном языке (к сожалению незнаком с аналогичными языками других пакетов, скачанная демка абакуса например так и не встала у меня) разработка макросов осуществляется также естественно, как построение модели в программе. Т.е. вы строите в программе модель, потом копируете фрагмент лога и немного его правите. Добавляете еще процентов 5-10 строчек кода и программа готова. Без отрыва от основного производства так сказать.
И вообще - сама программа при такой разновидности пользовательского программирования, вынашивается и рождается в процессе работы...

[Lamer Inc..]

Вот мне интересно, если вести речь не о макроязыке, а о COM-модели, к которой можно обращаться из VBasic или из C. А предоставляемые функции будут ограничиваться только чтением данных кэ-модели и результатов расчета (это существенно проще для реализации). Много ли найдется пользователей такой фичи?

Это уже будет большой шаг. Только полный доступ (чтение/запись) к КЭ-модели лучше сразу открыть.

[EXZet]

Сообщение от Rotfeder А вот с этим я согласен, только опять же одна проблема - формат иногда меняется. Хотя это конечно не страшно. Вот мне интересно, если вести речь не о макроязыке, а о COM-модели, к которой можно обращаться из VBasic или из C. А предоставляемые функции будут ограничиваться только чтением данных кэ-модели и результатов расчета (это существенно проще для реализации). Много ли найдется пользователей такой фичи?

Да, для передачи данных из утилит в расчетный модуль можно ограничиться экспортируемыми функциями, но для полноценного обмена действительно нужно создавать сервер.
"функции будут ограничиваться только чтением данных кэ-модели и результатов расчета" не совсем, чтобы было понятней опишу как мне видится практическое применение на утрированном примере. Допустим, работаю я в программе, из нее нажатием кнопы на тулбаре вызываю свою утилиту, при помощи которой можно выделить в автоматическом режиме элементы с определенными параметрами, отсортировав их по группам (распознавание колонн, балок, составление групп конструктивных элементов и т.п.), после этого отправляю все это добро на конструктивный расчет, т.е. расчетный модуль получает в привычном ему формате элементы которые нужно обсчитать. Ну или так: "препроцессор" -> "плагин" -> "расчет" - "результаты".
Вобщем имеется в виду свобода в обработке исходных и выходных данных, автоматизация некоторых рутинных интерактивных процессов.
P.S. Думаю, что наличие COM-технологии пригодится не только пользователсям.

[Rotfeder]

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

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

Сообщение от Дмитрий Ну, в перспективе может быть и использование вашей программы и в каких-то серьезных работах, как тот же ANSYS.

А что вы назывете серьезными работами? Если расчеты ракет - то это не наша специфика, а вот серьезные расчеты строительных конструкций - так это наш хлеб.

Сообщение от Дмитрий Да и упорядочивание структуры программы для доступа к данным извне, вероятно, опять же пойдет на пользу, хотя как я могу судить о таких вещах?

Вы правы, хотя упорядочивание и так постоянно идет - иначе за 5-10 лет программа превращается в хлам, который легче выкинуть, чем править.

[Rotfeder]

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

Ну астрономия и квантовая физика - это из другой оперы. А у строительства и машиностроения разная специфика. И науке (механике и, в частности, вычислительной механике) найдется дело и там, и там.

[Rotfeder]

The_Mercy_Seat
Lamer Inc..
Вопрос. Для чего нужна пользовательская постпроцессорная обработка результатов я понимаю. А вот какие данные вы собрались вводить в модель?
Нет, я конечно понимаю, что можно проводить нелинейные расчеты, использую итеративный процесс - посчитать, исправить модель, опять посчитать - но это, как мне кажется, для простого инежнера уже сложновато. А что еще?

p_sh
А вот про настраиваемый интерфейс есть мнение, что это полная фигня, которая свидетельствует прежде всего о беспомощности разработчиков - они не могут решить как сделать лучше и перекладывают отвественность за решение на пользователей. А пользователь - он не обязан быть спецом по интерфейсам.
Только сразу скажу - это восе не мое мнение, а Джефа Раскина - одного из призннных гуру в области программных интерфейсов (Apple Maсintosh) - книжку вот почитал на досуге

[C1]

Сообщение от Rotfeder мне кажется, для простого инежнера уже сложновато.

Программировать будут единицы, а использовать многие.

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

И гибкость и жесткость интерфейса можно довести до абсурда. А настраиваемые кнопки вещь полезная.

[Lamer Inc..]

А вот какие данные вы собрались вводить в модель?

Например,имеет место быть задачка расчета крупнопанельного здания. Жесткостей порядка 80 шт. Множество вспомогательных элементов сравнительно небольшой длины. Делать все это в 3D - жестоко. Очень много времени уйдет на отлов ошибок. В COSMOS задача решается более системно: рисуется плоский чертеж в ACAD, своеобразная "свертка", по слоям загоняется в COSMOS, попутно преобразуя 2D в 3D, тут же задаются нагрузки. Кроме собственно рисования 2D в ACAD, все остальное делается "кнопкой".
Теперь представим, что возникла необходимость корректировки. В данном случае, думаю сравнение не в пользу т.с. "классического" метода.

Как повторить подобную методу в отечественных строительных расчетных комплексах?

[EXZet]

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

Если имеется в виду GUI, то получается, что секретарь - суперспец по интерфейсам, кнопки и панельки в Word двигает - мама не горюй
С такой устаревшей позиции твердолобой архитектуры мака каждую программу нужно начинать с написания своей ОС. Наверняка и Вы не променяете VC с его гибкостью и дополнениями на какой-нибудь редактор с припаянными к координатам кнопками и кривым компилятором.

Сообщение от Rotfeder Вопрос. Для чего нужна пользовательская постпроцессорная обработка результатов я понимаю. А вот какие данные вы собрались вводить в модель?

Строить, корректировать модель. Вводить нагрузки, жесткости и т.д.. Создавать параметрические модели, да все что угодно.

[СергейД]

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

[Rotfeder]

Сообщение от Lamer Inc.. А вот какие данные вы собрались вводить в модель? Например,имеет место быть задачка расчета крупнопанельного здания. Жесткостей порядка 80 шт. Множество вспомогательных элементов сравнительно небольшой длины. Делать все это в 3D - жестоко. Очень много времени уйдет на отлов ошибок. В COSMOS задача решается более системно: рисуется плоский чертеж в ACAD, своеобразная "свертка", по слоям загоняется в COSMOS, попутно преобразуя 2D в 3D, тут же задаются нагрузки. Кроме собственно рисования 2D в ACAD, все остальное делается "кнопкой". Теперь представим, что возникла необходимость корректировки. В данном случае, думаю сравнение не в пользу т.с. "классического" метода. Как повторить подобную методу в отечественных строительных расчетных комплексах?

В MicroFe вводится модель здания не по конечным элементам, а по плитам, стенам и т.п. Кроме того, вы рисуете типовой этаж и размножаете его сколько угодно раз. При добавлении этажей можно часть типового этажа (например, отверстия, не переносить) и т.п.
В вашем случае - полный аналог - нарисовали один этаж, потом кнопкой добавили еще 15. Потом генерируете сетку - можно несколько раз - с разными шагами и прочими опциями.

[Rotfeder]

Сообщение от EXZet Если имеется в виду GUI, то получается, что секретарь - суперспец по интерфейсам, кнопки и панельки в Word двигает - мама не горюй С такой устаревшей позиции твердолобой архитектуры мака каждую программу нужно начинать с написания своей ОС. Наверняка и Вы не променяете VC с его гибкостью и дополнениями на какой-нибудь редактор с припаянными к координатам кнопками и кривым компилятором.

Я же говорил, что это не мое мнение. А Раскин, конечно, выражает довольно специфические взгляды, но во многом он прав - долго объяснять - лучше читать книжку. Хотя бы чего стоит в Windows панель с конпкой Пуск и иконками приложений. Неоднократно наблюдал, как достаточно продвинутые пользователи случайно перемещали ее снизу вверх или вправо и не могли потом вернуть на место. Или, например, плавающее меню, сделанное по аналогии с плавающими тулбарами - зачем оно нужно?

Настраиваемость среды Visual Studio мне была бы на фиг не нужна, если бы от версии к версии не менялся интерфейс. Я привык, что окно с файлами проекта находится слева, а не справа. Ну и еще к паре мелочей из старой версии 6.0. Опять же, куда-то исчезли горячие клавиши Ctrl-J, Ctrl-K и я никак не могу найти им замену - никакя гибкость интерфейса и макрокоманды не помогают.

[Rotfeder]

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

Я уважительно отношусь к ансис, но не уверен, что стоит тратить несколько месяцев жизни на его освоение. А то что освоить его непросто, видно даже по соседним ветками форума Ну то есть, с одной стороны имело бы смысл, а с другой - время - это ограниченный ресурс, и есть масса вещей, которые я еще не знаю.
К тому же есть знакомые проектировщики, которые на ансисе работали, и на микрофе работали.
Что касается алгоритмов, то может ли, к примеру, рядовой проектировщик в ансис технологично посчитать металлоконструкцию из стержней тонкостенного профиля. С учетом пластичности, устойчивости стенок, задавая при этом каждый отдельный стержень оболочками. В MicroFe может, благодаря Разработчику.
Понятно, что в ансисе при помощи макроязыка можно задавать параметрические конструкции. То есть, можно сделать, параметрическую конструкцию - стержень из оболочек. А потом из этих стержней собрать общую конструкцию. А потом еще результаты обрабатывать при помощи команд на птичьем языке. Понятно, что все возможно, но стоит ли .
Я так понимаю, что ансис - это инструмент широкого применения. А микрофе - более специализированный. Можно построить дом одним топором, но при наличии пилы, рубанка, молока и гвоздей как-то проще.

[Lamer Inc..]

В MicroFe вводится модель здания не по конечным элементам, а по плитам, стенам и т.п.

Доступ к объектам MicroFe лично мне не представляется необходимым. Это все равно что требовать доступа к объектам Мономах или Форум - особенного смысла нет. Я подразумевал доступ к объектам Stark - элементам КЭ-модели (узлы, элементы, связи, и.т.д.).
(В задаче расчета крупнопанельного здания мне не нужны "плиты", "стены", "подбалки" и проч. Мне нужна конкретная КЭ-модель. В данном случае, подбор необходимых шагов разбиения может оказаться сизифовым трудом. Кроме того, мне что, кучу вспомогательных элементов весьма незначительной длины вводить "балками" вручную? Пробовали. Количество ошибок неимоверное. Результаты автомеша впечатляют... Нет, я наверное слишком слабонервный для этого..)
Собственно, один вывод из обсуждения уже можно сделать - люди, имеющие возможность повлиять на интересующее дополнение к MicroFe, не видят в этом перспективы. Соответственно, в ближайшем будущем ждать в этом комплексе макроязыка/VBA не приходится.

[Profan]

Да блин, ну и взяли бы конкретную программу и обсасывали ее и так и сяк. А то разговор идет вообще о ВСЕХ расчетных программах. Не фига. Много лет назад задание исходной информации для расчета было сродни программированию. Может, кто-то застал тот период, когда исходные данные записывались на бланках чуть ли не в машинных кодах, в восьмеричной системе (программы КАРРА, Экспресс). Потом много лет в той же Лире информация заносилась в компьютер в текстовом виде. И вот, когда графический интерфейс практически исключил эту нудную работу (а чего стоила только отрисовка вручную расчетных схем), кому-то захотелось развалить все эти достижения и вернуться к ручному, текстовому заданию исходной информации. Недоделан ANSYS до уровня проектировщика - ну и говорите только об нем. Безмерно громоздкие расчетные схемы, слепленные из КЭ - это сущий бред. Вот такая аналогия прослеживается. AutoCAD - универсальный графический редактор, любой опытный пользователь может приспособить его для своих нужд с помощью программирования, тем более, что AutoLisp - родной язык AutoCAD'а. А много ли мы знаем пользователей, которые программируют для ADT? В том же ANSYS'е, видимо, можно было бы использовать элементы программирования, только совершенно ни к чему это делать в МОНОМАХ'е. МОНОМАХ - программа для проектировщиков, ANSYS - программа для научных работников. Им важно моделировать модель, а не нудно чертить в AutoCAD'е. Вот что действительно нужно для ВСЕХ расчетных програм - это доведение до ума графичекого могдуля формирования рабочих чертежей. Если такого модуля вообще нет к какой-нибудь программе, то эта программа - дерьмо.

[СергейД]

чтобы судить об ансис, нужно просмотреть поверхностно хотя бы хелп. это 80-100 мб . но он хорошо структурирован.
откуда же еще узнавать о современных тенденциях? подстегивает, знаете ли...
как можно считать, что работаешь на серьезном уровне, не зная этого уровня. Если уж изобретать велосипед, то такой, которого ни у кого еще не было.
если уж спрашиваете...
в ансис можно тонкостенные стержни произвольного сечения с учетом пластичности и депланации считать (проектировать и оптимизировать) как раз стержневыми Кэ (типы 188 или 189). что и делалось напрмиер для покрытий "Крылатское" и "ходынка".

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

Сообщение от Profan МОНОМАХ - программа для проектировщиков, ANSYS - программа для научных работников. .

ansys - универсальный КЭ пакет для инженеров (машиностроителей в первую очередь). Для многих научных работников (не инженерных наук) он тоже кажется не слишком удобной программой.
Насколько я представляю, что делает МОНОМАХ - с точки зрения ansys (abacus etc) это простая твердотельная модель. Там нет конечно "плит" и "балок" - есть примитивы типа Area и line. Строите дом из "плит" воодите команду AMESH,ALL и все это дело покрывается сеточкой. Притом - весьма и весьма аккуратной оптимизированной и легко изменяемой. И то это вчерашний день - сетка впомогательный инструмент, и будущее за "живыми" сетками - подстраивающимися под НДС - таковые тоже я видел только в ansys.
Для быстрого построения КЭ модели в ansys (abacus etc) есть ВСЕ. Чего там нет - так это инженерных расчетов и проверок по любым нормам. И не будет никогда, т.к. для этого и есть тот самый макроязык которому посвящен опрос .

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

Речь в опросе идет не о текстовом задании информации (правке текстового файла, который в том же ansys есть помимо макроязыка), а о дополнении интерфейса (служащего заданию информации через экран и клаву - вручную же) логическим способом задания, который являет собой макроязык. Т.е. вы не ищете например перекрытия 2-го этажа на экране (чтобы выделить их и перезадать толщину), а пишете простой командой в двух строчках - "задать перекрытию второго этажа толщину h1". А h1 например у вас также получено в результате выполнения каких то предыдущих команд...

[C1]

Ансис легально в Росии куплен наверное только одной строительной фирмой. Маловато это. Цена выходится за психологический барьер. А на нелегальном серьезная фирма считать не станет. Как на него ссылаться? Хотя он конечно и стоит таких денег. Но доступным он никогда не будет.

[p_sh]

Сообщение от Rotfeder Настраиваемость среды ...

возможно не было бы столько вопросов если бы не чрезмерно вложеное главное меню (ятд 2 уровня это уже очень далеко), возможно оно и вполне упорядочено и логично, но далековато.

ps.
на счет плавающих туллбаров, то есть мнение (и не только моё) что такая фишка удобна:
http://dwg.ru/dnl/344 правда в чертилке, но м.б. при соответственной доработке можно заточить её и под расчетную программу.
Представляете какой я "ленивый" до лазания по менюшкам .

pps. по поводу вывода в WORD из gen3_dim под vba. Моя практика показывает что если сделать application.show (для ворда) после формирования документа (в самую последнюю очередь) то длительность процесса формирования документа сокращается в разы.
Уж не знаю от чего так тормозит отрисовка буков.
Однако тому есть реальный пример для экселя:
Если проводить расчет из вкладки "Учет влияния прогиба 3.24" кнопка "РАСЧЁТ сечения" то он пройдет в разы быствее чем из вкладки "расчет сечения п. 3.28" кнопка "Расчет". а разница по поему только в отображении/скрытии вводимого/изменяемого текста.

Правда при каком-нибудь фатал ерроре не знаю чем дело кончится.
[ATTACH]1179724113.rar[/ATTACH]

[EXZet]

Сообщение от Rotfeder 1. Хотя бы чего стоит в Windows панель с конпкой Пуск и иконками приложений. Неоднократно наблюдал, как достаточно продвинутые пользователи случайно перемещали ее снизу вверх или вправо и не могли потом вернуть на место. Или, например, плавающее меню, сделанное по аналогии с плавающими тулбарами - зачем оно нужно? 2. Настраиваемость среды Visual Studio мне была бы на фиг не нужна, если бы от версии к версии не менялся интерфейс. Я привык, что окно с файлами проекта находится слева, а не справа. Ну и еще к паре мелочей из старой версии 6.0. Опять же, куда-то исчезли горячие клавиши Ctrl-J, Ctrl-K и я никак не могу найти им замену - никакя гибкость интерфейса и макрокоманды не помогают.

Прошу прощения у посетителей ветки за излишнюю конкретику, но, думаю, что аналогия будет нелишней.
1. Для решения проблемы запутавшихся пользователей в некоторых GUI имеется неперемещаемая кнопка aka "Panic!" - прекращение всех пользовательских операций, можно повешать и сброс на стандартное положение контролов.
2. Окна перемещать в IDE VS можно как угодно, комбинации клавиш и в вашем продукте придется менять если будет реализована поддержка такого количества технологий, тем более в MSDN прекращение поддержки привычных шоткатов указано. Возможность подключания дополнений рождает такие вот, возможно знакомые, но порой совсем нелишние вещи: http://www.wholetomato.com/ представте, какие возможности открываются (в хорошем смысле) для пользователя и сторонних кулибиных с реализацией такой поддержки.
Довольно печально, что в XXI веке на нашем рынке присутствует только одна расчетная программа, поддерживающая отечественные стандарты, с развитым Win интерфейсом, не буду уточнять какая. Да и тот писали не наши разработчики.

Profan
Эх, я тоже хочу "Большую кнопку", но из средств автоматизации черчения использую лишь акад+надстройки. РМ и чертеж - вещи на сегодняшний день несопоставимые, почеркушки автоматики ни один нормальный ПТО у нас в городе не примет.

[EXZet]

И за тавтологию тоже извините, работа

Сообщение от C1 Цена выходится за психологический барьер.

Конечно это не массовый продукт (и никогда не будет массовым).
Но про ED (образовательную) я писал выше. Любая программа требует обучения, а многофункциональная - подавно. Обучиться и поддерживать навыки на ED можно вполне.
Для исследовательских и научных целей - университетская, сравнительно недорого (все функциональные ограничения с нее недавно сняли). Коммерческая лиц. - самая дешевая квартальная 8 т.у.е. (можно например взять под конкретную крупную работу).
Как в нашей тьмутаракани - даже лиц. SCAD вызывает всеобщий фурор. А в Москве по моему больше десятка организации владеет комм.версией А., притом давно. Когда в конторе появляется такого рода софт и есть чел. им владеющий все расчеты начинают крутиться вокруг него, естественным образом.

ЗЫ Почему то опрос о макроязыке перешел в обсуждение конкретных двух программ - А. и МФ. Я не хочу нарушать правила форума и рекламировать (даже скрыто) тот или иной продукт.
Я просто хотел сказать вот что: в программе претендующей на серьезную макроязык необходим не меньше разного рода нелинейностей и контактов. А т.н. APDL просто удачный пример макроязыка. Хотелось бы чтобы нечто такое появилось когда-нибудь и в "родных" строителям программах.

[Разработчик]

Дмитрий

Наверное, подобные мероприятия весьма полезны для развития отечественной расчетно-теоретической мысли, однако, на мой взгляд, результаты подобных мероприятий "страшно далеки" от широкой инженерной общественности, так сказать, наука ради самой науки. Да и сами публикации вряд ли можно просто так найти... Как как-то обмолвился Разработчик (не ручаюсь за дословность) "наши сотрудники катаються на международные симпозиумы и широко раскрывают глаза буржуям - чего же вы еще хотите от наших программ"

Вот и видно, что прогуливали на льду Волги Вы только Теорию упругости, а лекции по философии (или что там в Ваше время ее заменяпо) усердно посещали. Пост вполне в духе "Материализма и эмпириокритицизма" - передергиваете, батенька .

Rotfeder

А что вы назывете серьезными работами? Если расчеты ракет - то это не наша специфика

Увы, теперь уже да

[Дмитрий]

Сообщение от Разработчик Пост вполне в духе "Материализма и эмпириокритицизма" - передергиваете, батенька

А по-существу имеете что сказать? Даешь макроязык, о котором уже столько страниц твердят большевики!!!

Сообщение от Rotfeder А что вы назывете серьезными работами? Если расчеты ракет - то это не наша специфика

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

[p_sh]

Сообщение от Дмитрий Сообщение от Разработчик Пост вполне в духе "Материализма и эмпириокритицизма" - передергиваете, батенька А по-существу имеете что сказать? Даешь макроязык, о котором уже столько страниц твердят большевики!!!

+
ДАЕШЬ меню "Расчет" и "Фрагмент" на туллбар!
Долой вложеные меню - каждое достойно туллбара! (или контекстной кнопки)

принципиально то всё к тому и шло, но почему-то некоторые меню уважаемым разработчикам показались менее достойными такой чести чем другие...

[Profan]

Программы типа ANSYS выбивают почву из-под ног у любой концепции САПР.

[C1]

Сообщение от Profan Программы типа ANSYS выбивают почву из-под ног у любой концепции САПР.

APDL вещь конечно гениальная. Для своего времени. Но у нас есть фора в новых техногиях. Хотелось бы получить недорогую гибкую программу на основе COM. Разработчикам жестких мостодонтов все равно не охватить всех задач. Например, СНиП Мосты и трубы.

[C1]

Сообщение от The_Mercy_Seat А в Москве по моему больше десятка организации владеет комм.версией А., притом давно.

А строительных из них сколько?

[novinkov]

Программы типа ANSYS выбивают почву из-под ног у любой концепции САПР

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

[Profan]

Для novinkov.
Да ладно, все-то вы поняли. ANSYS - программа для исследования модели конструкции, а не для проектирования. И желание использовать в ней макроязык только это подтверждает. Поэтому как раз непонятны призывы к проектировщикам-конструкторам отбросить Лиру, SCAD и др. и перейти на ANSYS.

ANSYS - это универсальный, "тяжелый" конечно элементный пакет, предназначенный для решения в единой среде на одной и той же конечно-элементной модели задач по прочности, теплу, электромагнетизму, гидрогазодинамике, многодисциплинарного связанного анализа и оптимизации на основе всех выше приведенных типов анализа.

Как это можно вписать в САПР?
А вообще-то, и САПР здесь не причем, тем более, что сам я отношусь к САПР скептически. Если в результате расчета мы получаем ответ в виде "Проходит/Не проходит", то сама по себе программа ущербна, IMHO.

[novinkov]

Нет, здесь Вы не правы.
Мы не призываем отбросить МироФе, Лиру, SCAD и др. отечественные программы. Но на мой взгляд было бы здорово, если бы в них появился макроязык. И многие готовы голосовать деньгами за тот комплекс, где это решение будет предложено первым и на приемлемом уровне.
У строительных программ и ANSYSов - абсолютно разные ниши, они не могут конкурировать. Но недальновидно отметать то хорошее, что есть в "больших" комплексах, если это может быть без большой крови реализовано технически в отечественных программах и найдет спрос на рынке. Макроязык - лишь одно из пожеланий.

[p_sh]

вот простой пример куда можно было бы приспособить пользовательские модули (в gen3_dim предоставленными средствами это очень тяжело):
- сместить все узлы модели на заданные расстояния.
- найти в конце концов расстояние между узлами без помощи сторонних вычислений
- переместить все выбранные узлы в заданную плоскость (это есть в скаде)

и другие.

[Profan]

У строительных программ и ANSYSов - абсолютно разные ниши

С этим я согласен. Однако, мне с самого начала показалось, что "Макроязык" - это только предлог. На самом деле большинство моих коллег-конструкторов могли бы, если бы им растолковали популярно, что такое макросы и зачем они нужны, - могли бы согласиться, что, может, это было бы неплохо, однако про себя подумали бы "На фиг нужно" и тут же забыли бы об этом. Макроязык нужен 5 фанатам из 100 и они погоду не сделают. А я вот 30 лет занимался расчетами всех видов строительных конструкций, но фанатом не стал, осточертело, скучно, одно и то же, никакие макросы не помогут там, где сплошная рутина и ничего уже лучше изополей не придумаешь.

Сообщение от Profan

Мне кажется вы так и не поняли о чем просто речь идет. Изополя, изолинии, пользовательская оцифровка не мешают макроязыку быть в наличии. Как наличие команд и лиспа в ACAD не мешает проставлять размеры. Как в анекдоте - типа жаль что нам так и не удалось послушать начальника транспортного цеха .
Опрос создан не для охаивания SCAD, Лира, МОНОМАХ, МикроФе и призывов срочно надо переходить на ansys всем и поголовно. Просто: вот есть т.н. строительные программы. В них много чего есть полезного. Они продаются, развиваются. Что то новое там будет появляться безусловно. И, соответственно, проводится опрос - хотите ли вы в следующих версиях иметь такой инструмент как макроязык. Кто то хочет, кто то нет. В пользу "да" приведено несколько внятных и конкретных доводов по существу: макроязык позволяет сделать общение с программой более гибким.
В пользу "нет" и "не обязательно" привели более или менее конкретные доводы пока два человека - Евгений,Екатеринбург и Rotfeder.
Тут не в фанатизме все дело а в конкретных выгодах. $$$

[Разработчик]

Дмитрий

Даешь макроязык, о котором уже столько страниц твердят большевики!!!

Тоже мне большевики - 19 человек...

если наши противники, т. е. капиталисты и герои II Интернационала, подчеркивают совершенные нами глупости, то я позволю себе привести здесь для сравнения слова одного знаменитого русского писателя, которые я несколько изменю, тогда они получатся в таком виде: если большевики делают глупости, то большевик говорит: «Дважды два — пять»; а если его противники, т. е. капиталисты и герои II Интернационала, делают глупости, то у них выходит: «Дважды два — стеариновая свечка» (В. И. Л е н и н, IV конгресс Коммунистического Интернационала, Полное собрание сочинений, т. 45, с. 291).

Сообщение от Разработчик Тоже мне большевики - 19 человек...

Пока 57 % из выборки 33, в которую как я понимаю, попали забубенные расчетчики и вообще ваша потенциальная клиентура. Но реально мне кажется что около трети пользователей такой возможностью бы пользовались бы достаточно активно и креативно, до 2/3 - чужими разработками. тут все зависит от реальных возможностей предполагаемого языка. Если очень посредственные - то да, максимум - 1% энтузиастов, котором не лень чужие хвосты подчищать. Если хорошие - то те 1/3 и 2/3 (от общего числа).
В общем и целом, у вас есть список ваших клиентов: можете устроить маркетинговое голосование среди них (только по опыту этого опроса могу судить - лучше описать что это за штука такая, с примерами - исход будет зависеть от этого процентов на 80).

[EXZet]

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

Возвращаясь к старой теме: вот наткнулся на программу интересную именно наличием пользовательского программирования. К скачиванию доступна демка на 1300 узлов (кстати, сама программа стоит около $50 (пятьдесят), что довольно дешево если учесть ее возможности). Но программирование (Active-X) именно то, что показалось в ней наиболее интересным.
Для просмотра справки и верификационных задач после установки программы выберите в меню Help = > Unzip Manual. Там же справка по программированию (Basic, Excel-VBA) с примерами по оптимизации и т.д. - выложил скриншорт, но к сожалению качество тут не очень. Можете скачать посмотреть.
Как вам сама идея? Это же клондайк для всяких любителей побаловаться процедурами армирования и пользовательским оформлением отчетов ?

Таки не выдержал и приобрел себе Лизу за рубль-двадцать.(шоб ансис так продавался )
Не сказать, чтобы она мне очень нужна была (хотя я еще в поиске оптимальной программы для расчетов), Но приято быть в одной компании с R & D scientists at AMD (U.S.A), Weyerhaeuser (U.S.A), Thomson Multimedia (France), Siemens (Austria), Philips (Canada), Schlumberger (U.K), Airbus (U.K), Pratt & Whitney (U.S.A)
Никто не смотрел ее еще? Или я первый юзер в бывшем есесесере?