Метод конечных элементов. Русская и свободная программа.

[ryazanov]

Я не смогу оценить новизны Вашей книги, если сами не выделите отличия от уже существующей литературы, а ее довольно много. Повторять уже достигнутое и пройденное может и нужно хотя бы для себя. Для других писать есть смысл, если удастся изложить материал более доходчиво, чем в остальных книгах. Наши руководители начинают поговаривать о необходимости отечественной операционной системы, но они тоже, наверно, не представляют масштабов работ и величины затрат. Идея отечественного банка программного обеспечения погибла почему-потому что востребованное программное обеспечение надо поддерживать, а редко применяемое лучше разработать вновь с применением новых методов.
С другой стороны не добивается ничего тот, кто ничего не делает. Это зависит от амбиций и возможностей. Когда начинали Linux будущие проблемы представляли с трудом, но дело пошло. А сколько подобных начинаний зависло, не получив распространения. Так что выходов три: либо начинать как свободное ПО, либо найти сторонников и продать идеи мощной компании, либо писать учебники (комментарии к предлагаемым решениям)-может кто нибудь заинтересуется. Чтобы попасть в разряд учебной литературы придется пройти рецензирование в специализированном УМО (учебно-методическое объединение). Каков там порядок можно, наверно, узнать из интернета). Если утвердят, то и с изданием проблем не будет, но в интернет уже не выложишь (будет защищено авторским правом).
В любом случае без учета результатов работ Петрова Ю.П. никаких книг или программ писать лучше не стоит, так как эта идиотская приписка "компания, разработавшая программу не несет ответственности за результаты ее применения" может быть легко опровергнута, если выпадет случай, связанный с результатами работы Петрова Ю.П.
Если бы собирались писать программу, то можно было бы что то сказать о совместимости программ CAD и расчетных программ в отношении передачи данных для расчетной модели (влияет на "приживаемость" или адаптацию нового решателя). О разнообразии расчетных программ я уже писал и каждая нужна сейчас, сегодня. .. Не сказал еще о расчетах на сейсмическое нагружение, нагружение в условиях воздействия как температуры, так и сил и т.д. Мне хотелось на программе, аналогичной ANSYS, проверить результаты, полученные, например, А.В. Андреевым экспериментально (книга "Передача трением" , М., Машиностроение, 1978) . В.З. Власов считал свою теорию тонкостенных конструкций недостаточно совершенной. Работы, претендующие на новизну в этом деле есть, причем с экспериментальными данными, но все висит в воздухе и в учебники не идет. Решается просто, например, в отношении двухбалочного моста мостового крана: отрезаем поперечные балки, вводим граничные условия на концах и выясняем прочность каждой продольной балки отдельно. Это можно делать и вручную. Может я упрощаю, но расчет рамы-траверсы никто не в состоянии делать, нет таких расчетов ни в вузовской программе, ни в их олимпиадах. Не способны решать (и не научат). А выглядит не сложно (и есть на станциях перегрузки контейнеров). Контейнер цепляется за четыре угла , тросы вертикально идут к углам траверсы (О-образной с прямыми углами), от углов траверсы другими четырьмя тросами обеспечивается связь с крюком крана через соединительное звено. Всего восемь тросов: четыре вверху, четыре внизу. Согласно правилам Госгортехнадзора расчетными можно считать только два вверху и два внизу (при обеспечении устойчивости , а это достигается, если расчетные пары тросов расположить по диагонали в разных плоскостях). Вот эту траверсу приходилось точно так же, как и мост крана, как то резать и условно нагружать. Это не говоря уже о том, что вдруг придется посчитать и контейнер-там конструкция объемная и прибавляются стенки-пластины. Другая проблема-расчет захватов для железобетонных плит. Вот там то и получается компактная конструкция с минимальным приближением как сил, так и реакций опор к одной (с отверстием для клина-замка) детали.

[Esp_]

У меня вопрос к участникам темы: а какой пакет (или библиотека) предоставляет самый удобный API и при этом является бесплатной?

Цитата:

Так вот, я считаю, что Российской Федерации, пока она еще большая и цельная, и пока в ней есть как-то работающие заводики и еще пока технические втузы, нужен свой программный комплекс конечно-элементного анализа, причем свободный (бесплатный, с открытым исходным кодом, двойная лицензия) и отлично документированный. И чтобы работал в основном под Linux (гнать американщину Майкрософт из РФ!). С полной поддержкой ГОСТов.

На мой взгляд, Россия тут не причем: как только кто либо делает открытый продукт - он мировой. Почему он должен работать в основном под Linux - для меня тоже загадка.

[meteese]

Esp_ в сообщении #712810 писал(а):

У меня вопрос к участникам темы: а какой пакет (или библиотека) предоставляет самый удобный API и при этом является бесплатной?

Трудно сказать какой, для этого нужно знать все пакеты сразу. Если Вы спросили библиотеку для программирования, то начать рассмотрение стоит с FEniCS, хотя бы из-за наличия python-интерфейса (при сохранении C-интерфейса) и наличия достойной документации в виде pdf-книги.

Цитата:

На мой взгляд, Россия тут не причем: как только кто либо делает открытый продукт - он мировой. Почему он должен работать в основном под Linux - для меня тоже загадка.

Для мирового продукта открытости кода еще недостаточно. Он должен быть от начала и до конца сделан на английском языке: с английским интерфесом пользователя, английскими комментариями кода, английской документацией, английским форумом поддержки, и т.д. Вот, например, для немцев это вообще не проблема: там все образованные специалисты владеют английским как украинцы русским. В России -- проблема. Типичная отмазка: "а я в школе учил немецкий". С другой стороны, это может привлечь иностранных специалистов, которые "больше в теме", чем русские. Но тогда нет большого смысла создавать новый решатель, достаточно самому присоединиться к готовому мировому проекту. Задумывалось, что организация нового проекта, ориентированного на русскую речь, подстегнет русских специалистов быть "больше в теме", т.е. знать больше о МКЭ и развивать его и подобные ему методы. Если это будет просто студенческая поделка, то и в этом случае проект должен принести большую пользу. Когда я начинал эту тему, я был патриотом России. Сейчас мои взгляды стали умеренными, я не особо патриот, но пока живу в этой стране, хочу ее улучшить.

Опечатался. Не "в основном под linux", а "в первую очередь под linux (т.е. гарантированно под нее, а под остальные ОС -- не гарантированно, второстепенно)". Если у пользователя будет вполне современный компьютер, то, если он не использует linux, а разработчики поддерживать Windows не захотят, проблема легко решается с помощью виртуальной машины (VirtualBox). Поддерживать сразу несколько ОС и архитектур труднее, чем одну. Полностью отлаженная на одной архитектуре программа может делать трудно уловимую ошибку на другой. Где-то жаловались, что написанные на Python программы в Windows работают ощутимо хуже, чем в Linux. К Java это относится в меньшей степени, но она медленно работает. То, что здесь постоянно звучит Linux, объясняется больше тем, что я уже лет 7 являюсь ее постоянным пользователем, чем ее технологическими преимуществами. Хотя, если бы Вы тоже являлись ее постоянным пользователем, Вы бы, скорее всего, уже через пару минут без какого-либо поиска в интернете имели бы FEniCS установленным и готовым к программированию. Он есть в репозиториях популярных deb-based дистрибутивов Linux, как и многое полезное для МКЭ-программиста. Что очень удобно.

[Esp_]

meteese в сообщении #712861 писал(а):

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

По поводу комментариев кода: на первом этапе это не столь принципиально, главное чтобы были комментарии к сигнатурам методов). Есть полно открытых продуктов, где далеко не весь код прокомментирован, я бы даже сказал никрена не прокомментирован местами.

Цитата:

Поддерживать сразу несколько ОС и архитектур труднее, чем одну. Полностью отлаженная на одной архитектуре программа может делать трудно уловимую ошибку на другой. Где-то жаловались, что написанные на Python программы в Windows работают ощутимо хуже, чем в Linux. К Java это относится в меньшей степени, но она медленно работает. То, что здесь постоянно звучит Linux, объясняется больше тем, что я уже лет 7 являюсь ее постоянным пользователем, чем ее технологическими преимуществами. Хотя, если бы Вы тоже являлись ее постоянным пользователем, Вы бы, скорее всего, уже через пару минут без какого-либо поиска в интернете имели бы FEniCS установленным и готовым к программированию. Он есть в репозиториях популярных deb-based дистрибутивов Linux, как и многое полезное для МКЭ-программиста. Что очень удобно.

А скажите, вы все таки библиотеку хотите делать или прямо софт с UI ?
Данная проблема разрешима: можно сделать несколько проектов, библиотека будет кроссплатформенной, UI же для каждой ОС можно сделать свой (но это дополнительные затраты, поэтому проще всего его сделать на QT или Java). Библиотеку же, я бы порекомендовал сделать на С++: код будет кроссплатформенным, никаких трудноуловимых багов не будет, за исключением, может быть, файловой системы, но это легко решается. Таким образом, достаточно будет создавать билды для своих ОС, но код будет одним и тем же.

По поводу Linux: я не являюсь активным пользователем одного из Линуксов и уж точно уверен, что target платформой надо делать не его, а MacOS и Windows, при условии, что софт будет направлен не на большие объемы данных.

[meteese]

Цитата:

А скажите, вы все таки библиотеку хотите делать или прямо софт с UI ?
Данная проблема разрешима: можно сделать несколько проектов, библиотека будет кроссплатформенной, UI же для каждой ОС можно сделать свой (но это дополнительные затраты, поэтому проще всего его сделать на QT или Java). Библиотеку же, я бы порекомендовал сделать на С++: код будет кроссплатформенным, никаких трудноуловимых багов не будет, за исключением, может быть, файловой системы, но это легко решается. Таким образом, достаточно будет создавать билды для своих ОС, но код будет одним и тем же.

Свободные библиотеки для этого уже имеются, как мировые, так и наши (здесь был McLay, написал свою на С++ по Windows, только пропал куда-то). А вот нормального готового софта нет, причем и среди мировых проектов тоже. Хочется иметь свободный MSC.MARC+MENTAT. Нужен решатель на базе готовых библиотек, и оболочка с графическим интерфейсом для работы с ним. Этап построения геометрии и сетки можно пропустить, свалив эту работу на Gmsh. Этап визуализации результатов тоже можно пропустить, свалив это дело на Paraview. Но тогда стоит включить Gmsh и Paraview как составные части в конечный продукт и вплотную их интегрировать с решателем, чтобы пользователю не было видно, что это разные проекты.

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

Цитата:

По поводу Linux: я точно уверен, что target платформой надо делать не его, а MacOS и Windows.

А почему ?

[Esp_]

meteese

Да потому что если мы ориентируемся на запад - там популярны Макбуки.
Если же мы ориентируемся на РФ и СНГ, то здесь популярен Windows.
Необходимость в linux возникает обычно, если пишется софт для сервера.

-- Сб апр 20, 2013 16:55:12 --

meteese в сообщении #713095 писал(а):

Нужен решатель на базе готовых библиотек

А как так? Библиотеки решатель не содержат?

[meteese]

Решатель -- это исполняемый файл, программа без графического интерфейса пользователя. Он обрабатывает входящий текстовый файл и выдает файл с результатами. Nastran.exe и Marc.exe -- решатели. Elmer -- инструмент с графическим интерфейсом для МКЭ анализа, а ElmerSolver -- его компонент-решатель, который можно использовать отдельно от всего. Библиотеки они и есть библиотеки. Они созданы для программистов.

Цитата:

Да потому что если мы ориентируемся на запад - там популярны Макбуки.
Если же мы ориентируемся на РФ и СНГ, то здесь популярен Windows.
Необходимость в linux возникает обычно, если пишется софт для сервера.

Вот если бы я хотел бабло заколачивать, то повелся бы на популярность макбуков и винды. А для академического свободного софта linux -- отличная target-платформа, тем более что она уже давно десктопная. Решатель я изначально планировал для сервера, даже если никто не будет запускать его на сервере. Решатели вообще стараются делать независимо от графических оболочек в первую очередь для того, чтобы иметь воможность запустить их на сервере (кластере) и работать с ними через ssh-консоль (или вообще web-браузер, как в проекте Sage (матпакет типа maple)).

[Esp_]

meteese

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

meteese в сообщении #713224 писал(а):

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

Так программы никто не делает. Поскольку здесь обсуждается UI, то к нему нужно цеплять динамическую библиотеку, а не какой-то там другой exe файл, интеграция с которым была бы устроена через диск. (Это, к слову, не единственный вариант, можно сделать client-server взаимодействие, о котором вы уже писали, это еще куда не шло). Производительность, которая будет получена, не будет достаточной для решения многих графических задач. Поэтому, если такой exe файл (который берет текстовый файл) и будет, то он должен являться всего лишь фасадом к вышеупомянутой библиотеке.

meteese в сообщении #713224 писал(а):

Elmer -- инструмент с графическим интерфейсом для МКЭ анализа, а ElmerSolver -- его компонент-решатель, который можно использовать отдельно от всего.

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

meteese в сообщении #713224 писал(а):

Библиотеки они и есть библиотеки. Они созданы для программистов.

Вы что этим хотите сказать, что не нужно делать библиотеки, или что? :)

meteese в сообщении #713224 писал(а):

Вот если бы я хотел бабло заколачивать, то повелся бы на популярность макбуков и винды. А для академического свободного софта linux -- отличная target-платформа, тем более что она уже давно десктопная. Решатель я изначально планировал для сервера, даже если никто не будет запускать его на сервере. Решатели вообще стараются делать независимо от графических оболочек в первую очередь для того, чтобы иметь воможность запустить их на сервере (кластере) и работать с ними через ssh-консоль (или вообще web-браузер, как в проекте Sage (матпакет типа maple)).

Позвольте высказать мое мнение, как профессионального Software Developer'а получившего академическое образование и занимающегося research'ем :

1) программное обеспечение должно по возможности работать
на максимальном количестве платформ. Искусственно ограничивать целевую аудиторию каким-либо образом, при возможности ее не ограничивать в рамках те же трудозатрат, не только не стоит, но и для open source проекта, которому нужно активное community, вообще крайне нерационально.

2) Большинство открытых проектов никуда не годятся по многим критериям качества. Это относится как к general purpose проектам, так и к более специализированным программам. Основной критерий, который интересует всех без исключения пользователей - это время, потраченное с момента установка того или иного пакета (в данном случае - математического пакета) , до получения каких либо базовых результатов с его помощью. Такие слова как usability, наличие вообще какого-либо адекватного графического интерфейса, возможность интегрировать пакет со своим существующим кодом и , конечно, наличие адекватной и понятной документации - это именно то, на что будут смотреть серьезные пользователи обсуждаемого здесь ПО. Сейчас время быстрых и удобных инструментов. К тому же, исследователям не хочется заниматься установкой линуксов на виртуальные машины (Вернее, может и хочется, но это вопрос времени как минимум, которого никогда не хватает). Им, грубо говоря, хочется, чтобы они могли открыть свой ноутбук (будь то Макбук или windows laptop) и моментально испробовать пришедшую в голову идею в софте. Соответственно, никакого прямого отношения к тому , что вы написали со словами "бабло заколачивать" этот вопрос не имеет. Если вы хотите, чтобы пакет кто-то использовал и он развивался- нужно иметь все вышеописанное в виду.

[meteese]

Цитата:

А что вы думаете вот об этом продукте?

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

Цитата:

Так программы никто не делает. Поскольку здесь обсуждается UI, то к нему нужно цеплять динамическую библиотеку, а не какой-то там другой exe файл, интеграция с которым была бы устроена через диск.

Кто так не делает? Программы этого рода так делают все. Так делают MSC.Nastran&Patran, MSC.MARC&Mentat, Code-Aster, Calculix, Abaqus, Femap и многие другие. Эти программные комплексы состоят из независимого CAD и также независимого консольного решателя. Причем главное -- консольный решатель. Взаимодействие через диск позволяет хранить файлы, полученные на каждом этапе. На авиастроительном заводе в моем городе при каждом расчете все файлы с результатами, все начальные файлы и все промежуточные файлы хранятся как компромат.

Цитата:

Поэтому, если такой exe файл (который берет текстовый файл) и будет, то он должен являться всего лишь фасадом к вышеупомянутой библиотеке.

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

Цитата:

1) программное обеспечение должно по возможности работать
на максимальном количестве платформ.

В принципе, согласен. Хотя, есть такой отличный и популярный проект, как Sage. Он не работает в Windows из-за трудозатрат. Однако, его запустили на сервере и сделали web-интерфейс. Каждый может открыть браузер, зайти на сайт http://www.sagenb.org/, зарегистрироваться, и работать с Sage. Тем, кто хочет работать с ним на своем компьютере, рекомендуют либо установить его в Linux, либо в VirtualBox под Windows.

Цитата:

К тому же, исследователям не хочется заниматься установкой линуксов на виртуальные машины

Я планировал приготовить уже готовый образ для VirtualBox и раздавать его для запуска в любой операционной системе. Весить он будет не слишком много.

Для разработчика Linux-софта (т.е. для себя и своего друга) я уже приготовил специальный образ VirtualBox. Он весит более 22 Гб (в сжатом виде 10 Гб) и уже содержит все инструменты, все библиотеки, всю документацию, все нужные книги и полностью настроен. Я сам работаю в нем и соблюдаю там чистоту и порядок на случай, если нужно будет сделать копию и передать другому. Пускай работает она в два раза медленее, зато один раз всё установил, настроил и носишь ее с собой на флешке, запускаешь везде, где есть VirtualBox, копируешь и даешь другим. Если используется редкое и труднонастраиваемое ПО (в Windows таких хватает), то работать в виртуальной машине очень даже удобно.

Цитата:

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

Крайне не согласен. В данном случае время не имеет значения: задачи решаются неделями, месяцами, годами, не спеша. Основной критерий в данном случае -- правильность расчета. Вот, напимер, случай был: два экземпляра известной программы для МКЭ одной и той же версии один и тот же входной проект на двух разных 32-разрядных компьютерах с одной и той же Windows XP решал, выдавая сильно разные результаты. Этот случай очень сильно подорвал доверие к этой программе и запомнился надолго. Здесь важно не usability, а правдивость результатов. Самое плохое, если программа врет, выдает какой-то результат, но неверный. И пользователь наивно этому результату доверяет (а это как раз те пользователи, которым нужно побыстрее), идет с этими "расчетами" на производство -- и гибнут люди в техногенных катострофах.

Доходчиво о том, что правильность расчета в миллион раз важнее скорости и удобства работы с программой, рассказывается вот здесь: http://www.saprobasni.ru/2011/06/blog-post_21.html

Помимо этого, Вы там же найдете отрывок:

Цитата:

в своей основе они имеют решатель Cosmos/M (он же GEOSTAR), который очень давно и очень хорошо известен в кругах людей занимавшихся расчетами. Особенно в его академических частях. Потому как Cosmos/M имел уникальное свойство - для задач разной размерности были разные исполняемые файлы. Они отличались и по объему и по скорости работы и много еще по чему. Что позволялло людям работающим в ВУЗах, и обладающих не самыми мощными ПК решать вполне веселые задачи.

т. е. мало того, что решатель изолируют от GUI, он может быть вообще представлен в виде нескольких консольных программ: по одному на каждый случай. А Вы говорили, никто так не делает.

[Esp_]

meteese в сообщении #713629 писал(а):

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

И что, взаимодействие через диск это единственный способ интеграции? наверняка , только "один из". Чтобы свой родной CAD отдавал своему родному движку данные через файл - это как же нужно так извратиться то? Возможно, файлы он делает независимо, но отдает через shared memory.

meteese в сообщении #713629 писал(а):

Крайне не согласен. В данном случае время не имеет значения: задачи решаются неделями, месяцами, годами, не спеша. Основной критерий в данном случае -- правильность расчета. Вот, напимер, случай был: два экземпляра известной программы для МКЭ одной и той же версии один и тот же входной проект на двух разных 32-разрядных компьютерах с одной и той же Windows XP решал, выдавая сильно разные результаты. Этот случай очень сильно подорвал доверие к этой программе и запомнился надолго. Здесь важно не usability, а правдивость результатов. Самое плохое, если программа врет, выдает какой-то результат, но неверный. И пользователь наивно этому результату доверяет (а это как раз те пользователи, которым нужно побыстрее), идет с этими "расчетами" на производство -- и гибнут люди в техногенных катострофах.

Доходчиво о том, что правильность расчета в миллион раз важнее скорости и удобства работы с программой, рассказывается вот здесь: http://www.saprobasni.ru/2011/06/blog-post_21.html

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

Цитата:

т. е. мало того, что решатель изолируют от GUI, он может быть вообще представлен в виде нескольких консольных программ: по одному на каждый случай. А Вы говорили, никто так не делает.

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

[meteese]

Цитата:

Чтобы свой родной CAD отдавал своему родному движку данные через файл - это как же нужно так извратиться то? Возможно, файлы он делает независимо, но отдает через shared memory.

Вы просто не работали с МКЭ-программами. Один из неприятных моментов: входной файл весит десятки Мб, выходной -- несколько Гб. Вам хватит shared memory? Второй неприятный момент: программа отказалась считать по непонятной причине. В этом случае нужно смотреть в блокноте входной файл и искать там ошибку. Третий неприятный момент: программа некорректная в данном конкретном случае. Нужно входной файл отправить разработчику на исследование. Это не конец. Обмен данными через файл на диске (текстовый, база данных) -- здравая идея в случае МКЭ.

если мне нужно ждать "годы", я такую программу не возьму и забесплатно

А других то и нет. Разве что те самые express, расчитывающие в три щелчка мыши.

Хрущев вот хотел побыстрее -- и придумал хрущевки. Качество всем известное. Зато не надо ждать месяцы и годы на постройку. Хочешь нормальный дом -- подожди пару лет, пока его просчитают (сначала в компьютерной программе, а потом по-старинке на бумаге), и еще пару лет, пока построят. Вон в Германии поторопились с расчетом -- и крыша обвалилась из-за того, что на нее сугроб снега выпал, не выдержала тяжести. А то, что в КНР высотки заваливаются, все уже видели. Продолжайте экономить время, господа. Compendia sum dispendia

[Esp_]

meteese в сообщении #713658 писал(а):

Вы просто не работали с МКЭ-программами. Один из неприятных моментов: входной файл весит десятки Мб, выходной -- несколько Гб. Вам хватит shared memory? Второй неприятный момент: программа отказалась считать по непонятной причине. В этом случае нужно смотреть в блокноте входной файл и искать там ошибку. Третий неприятный момент: программа некорректная в данном конкретном случае. Нужно входной файл отправить разработчику на исследование. Это не конец. Обмен данными через файл на диске (текстовый, база данных) -- здравая идея в случае МКЭ.

Не-не-не, это то все понятно.
Я же говорю о вычислениях, близких к realtime. Такие вычисления не проводятся через файлы.
Эти программы другие возможности интеграции поддерживают?

[meteese]

Цитата:

Я же говорю о вычислениях, близких к realtime. Такие вычисления не проводятся через файлы.
Эти программы другие возможности интеграции поддерживают?

Я не встречал других способов интеграции CAD и решателя. Да и это, на самом деле, слишком мелочный вопрос для спора с мировым опытом. Не стоит тратить на него нервы.

Пример более продвинутого вопроса по части технологии счета: этот немецкий гений настаивает, что МКЭ-задачи лучше считать на дискретной видеокарте, чем на процессоре (технология nVidia CUDA). И он прав. Жаль только, что у меня встроенная видеокарта intel hd 3000.

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

Здесь форумчанин ryazanov намекал почитать книгу Ю.П. Петрова "Неожиданное в математике и его связь с авариями и катастрофами". Вопросы, поднятые в этой книге, в триллион раз важнее какой-то интеграции решателя с CAD через диск или оперативу, и userability. В самом деле, как может быть корректной программа для таких сложных расчетов, если сама математика не всегда корректна?! Т.е. она корректна, но мы не всё знаем о математике. В ряде случаев она дает не то, что ожидают. Например, если для решения уравнения вам нужно продифференцировать левую и правую части (что является эквивалентным преобразованием, как умножение левой и правой части равенства на одно и то же число), то решение может потерять устойчивость. В математике есть огромное множество сюрпризов, и если кто-то на 100% доверяет матпакетам, то он мало отличается от верующих (ни кого не хотел обидеть).

P. S. Ответы отнимают у меня время на учебу, которая сейчас поджимает. Я бы хотел уйти с этого форума (возможно до осени).

[Esp_]

meteese в сообщении #713719 писал(а):

Здесь форумчанин ryazanov намекал почитать книгу Ю.П. Петрова "Неожиданное в математике и его связь с авариями и катастрофами". Вопросы, поднятые в этой книге, в триллион раз важнее какой-то интеграции решателя с CAD через диск или оперативу, и userability. В самом деле, как может быть корректной программа для таких сложных расчетов, если сама математика не всегда корректна?! Т.е. она корректна, но мы не всё знаем о математике. В ряде случаев она дает не то, что ожидают. Например, если для решения уравнения вам нужно продифференцировать левую и правую части (что является эквивалентным преобразованием, как умножение левой и правой части равенства на одно и то же число), то решение может потерять устойчивость. В математике есть огромное множество сюрпризов, и если кто-то на 100% доверяет матпакетам, то он мало отличается от верующих (ни кого не хотел обидеть).

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

Как может быть программа для таких сложных расчетов корректной? У меня встречный вопрос: верно ли то, что численные методы на основе FEM являются неустойчивыми для широкого спектра практических входных данных? Например, меня интересуют в этой области системы, состоящие из не более из ~200 конечных элементов, имеющие достаточно простую структуру. Исходя из того, что я знаю про FEM, у меня нет соображений о том, что проблема корректности для таких систем может остро стоять. Соответственно, обеспечить корректность в таком domain'е не составит особого труда.

[ryazanov]

В первую очередь не всегда корректны матричные преобразования. Это мнение Ю.П. Петрова. Он читает спецкурс в Санкт-Петербургском государственном университете. Без обоснованных им проверок программ можно прийти к неверному результату и связанной с этим аварийной ситуации. С этим согласны в РАН.
Вторая ситуация может возникнуть в связи с решением дифференциальных уравнений, результат которого также может оказаться некорректным. Это касается любых расчетных программ, для проверки результатов работы которых Ю.П. Петров рекомендует несложные программы. Аспирантам, если они хотят защититься, работы Ю.П. Петрова приходится учитывать. И расчетчику, если хочет не иметь проблем, тоже. Однако, не все к этому серьезно относятся: вузовскую программу до сих пор не откорректировали в этом отношении.