Тема возникла из споров о преимуществах 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 Евгений, Екатеринбург:

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