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

[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 не приходится.