Comments 12
Эх, вспомнились студенческие годы, когда мы решали задачи МКЭ на C++ и сравнивали результат с Ansys… Да, много чего было.
Главное в таких задачах — верификация. Как вы её проводите?

Что дальше? Это достаточно узкоспециализированная обоасть, которая относится к разного рода машино-строительных предприятий. А там много отраслевых решений. Не потрачено ли ваше время в пустую при создании велосипеда?
Что вы понимаете здесь под верификацией? В последнем примере, решение я сравнил с решением Abaqus'а, получил 100% совпадение. А сам метод уже давно математически обоснован, проверен на практике и имеет хорошо известные ограничения и особенности.

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

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

При этом, метод имеет свой потенциал и в игровой индустрии для создания деформируемого/разрушаемого окружения.

Почему пример простейшей реализации, написанный для целей объяснить принцип работы метода — велосипед? Тогда можно каждый туториал велосипедом назвать.
Давайте еще велосипедом назовем пример реализации МКЭ в книге Зенкевича? Только он там на фортране пример привел.

Метод старый, все примеры реализации как правило на фортране, вот я и решил восполнить этот пробел.
Что вы понимаете здесь под верификацией?

Именно верификацию. Вы создаете программное средство, которое используя МКЭ проводит приблизительный расчет. Именно приблизительный. И какова предметная область? Насколько физический эксперимент конкретно взятой задачи соответствует численному решению?

В последнем примере, решение я сравнил с решением Abaqus'а, получил 100% совпадение.

100%? Вы шутите? Один приближенный расчет вы сравниваете с другим? И говорите про 100%?

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

Я не спорю с этим. Но вы его применяете для вполне конкретной предметной области.

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

Вы преследуете конкретные цели? Или создали программу просто потому, что можете это сделать? Или вы сделали данную реализацию лучше, чем ANSYS, Abaqus?

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

Здесь тоже нет сомнений. Применение МКЭ широко. Достаточно взять области применения ANSYS — всё станет ясно. Я имел в виду, что если вы решились на собственную реализацию МКЭ — должны быть причины. Каковы они?

При этом, метод имеет свой потенциал и в игровой индустрии для создания деформируемого/разрушаемого окружения.

А причем здесь ваша реализация? Вы решаете стационарную задачу? А то, что лихо разрушается и эффектно деформируется в игре — для этого больше подойдет высоконелинейный расчет, вроде того, как его выполняет ANSYS LS-DYNA. Или вы имели в виду совсем другое? Есть ссылки применимости МКЭ в этой области (игр)?

Почему пример простейшей реализации, написанный для целей объяснить принцип работы метода — велосипед?

Очень хорошо объясняется метод в соответствующей литературе. Просто реализовать что-то и выставить на показ? А дальше? Будете реализовывать CFD? Второй ANSYS CFX? Tesis FlowVision? CD-adapco Star-CCM+?

Только он там на фортране пример привел.

А вы не задумывались, почему на Фортране? Что есть Фортран и для чего он был создан?
верификация модели {model verification}. Процесс, имеющий целью определить, правильно ли отображает данная вычислительная модель искомую концептуальную модель или математическую модель.
О терминах «верификация» и «валидация»

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

если вы решились на собственную реализацию МКЭ — должны быть причины. Каковы они?


  • Написать максимально простой, но выразительный код на современном языке реализующий простершее применение МКЭ.
  • На примере кода постараться кратко изложить суть метода.


Я написал несколько велосипедов по МКЭ. В одном из случаев даже не совсем бесполезную. Делал я это исключительно из моего любопытства к методу. Не всегда легко читать литературу насыщенную математикой из теории упругости и затем думать как же это реализовать на практике. Информацию я собирал из нескольких источников, в основном из книги Зенкевича, что в итоге позволило мне написать несколько программ реализующих данный метод.

Здесь я просто решил поделиться собранным мною опытом и я постарался написал максимально краткий, простой и выразительный код. Насколько у меня это получилось судить вам.

Вы создаете программное средство, которое используя МКЭ проводит приблизительный расчет. Именно приблизительный. И какова предметная область? Насколько физический эксперимент конкретно взятой задачи соответствует численному решению?

  • Я взял самый классический случай реализации МКЭ. Я не придумал ничего нового. Здесь я сжато изложил (возможно немного своеобразно, но именно так я хотел его преподнести) суть МКЭ, которая ничем не отличается от его изложения во многих классических книгах по МКЭ.
  • Если реализация классическая, проверенная временем, использованная множество раз на практике, к чему вопросы по соответствие с физическим экспериментом? Или вы не верите таким авторам как Olgierd Zienkiewicz? Vj
  • Вопрос по верификации, самого метода здесь поднимать я думаю не уместно. Как и любой метод решение прикладных задач, он также работает с упрощенной моделью. Поэтому здесь ответ на вопрос про соответствие с экспериментом зависит от того, что именно и для каких целей мы хотим получить.
  • Да расчет приблизительный. Но, если говорить о соответствии с экспериментом, то тут все упираться будет не в МКЭ, а в физическую модель. Мы можем сделать мельче сетку, использовать элементы более высокого порядка и получить решение заданных дифф. уравнений с требуемой точностью. А вот насколько хорошо данные дифф. уравнений моделируют реальность, это уже отдельный вопрос. В рамках рассмотренной задачи, как показала практика, достаточно хорошо.


100%? Вы шутите? Один приближенный расчет вы сравниваете с другим? И говорите про 100%?


А что тут плохого? Или вы хотите сказать, что в Abaqus'e неправильно реализован МКЭ?

  • Я реализовал классическую схему.
  • Расчет совпадает с расчетом Abaqus'а.
  • Следовательно, ошибок в программной реализации хорошо известной математики нету.
  • Раз совпадение 100%, то в Abaqus'е с большой долей вероятности реализована абсолютно точно такая же математика для этого типа задачи и элемента.


Подчеркну, я говорю про 100% совпадение с расчетом Abaqus'а, не более (но именно этого и достаточно).

Одна и та же сетка, решение совпадает, что еще надо? Я провел больше тестов, здесь привел только один.
Я говорю, что решение проверенной реализации МКЭ совпадает с моим решением (в рамках данной задачи). Я не в коем случае не говорю, что оно должно совпадать с экспериментом или еще с чем. Но если вам интересно, то аналитическое решение задачи о пластине с отверстием дает коэффициент концентрации — 3, у меня — 3.05152.
А вы не задумывались, почему на Фортране? Что есть Фортран и для чего он был создан?

Уточню, в книге пример приведен на очень старом диалекте фортрана — FORTRAN 66. Более того, тот пример намного боле громоздкий и трудно читаем.

Вообще тема фортрана уже настолько избита и не раз поднималась на хабре, что обсуждать ее еще раз, ну не знаю.
Основные причины почему он до сих пор востребован(и скорее всего еще долго будет) это:
  • Наличие большого числа очень сложного софта, работа которого проверена временем.
  • Наличие большого числа талантливых людей, для которых фортран является основным языком.
  • Для людей науки, которые не связаны с программирование, фортран проще в освоении.
  • Скорость фортрана на уровне C/C++ (что весьма не плохо).


То, что фортран производительнее C/C++ — это уже давно не правда.
На мой взгляд, код на С++ получается(при использовании соответствующих инструментов) намного выразительнее и компактнее.

В фортране нету шаблонов, на мой взгляд это существенный минус.
Приведу не слишком очевидный пример(очевидные и так понятны), есть такая штука как Symbolic Pre-computation for Numerical Applications, SEMT. Позволяет делать просто потрясающую вещь, можно записать функции формы для элементов высокого порядка и не брать большое число частных производных вручную(или с помощью стороннего инструмента).
  1. Ну, не будем сравнивать C и FORTRAN. Это отдельная тема для разговора. Скажу лишь, что ANSYS до сих пор позволяет создавать пользовательские модули к своему Mechanical APDL именно на FORTRAN
  2. всё-таки сравнивать результаты работы двух CAE-систем «в лоб» и говорить, что они равны на 100% — не корректно. Вы же не сравниваете на равенство значение двух переменных типа double, а используете конструкцию abs(a1-a2)<eps… Так и здесь — одно решение приближено к другому с точностью до… Но никак не 100%


В любом случае — спасибо Вам за статью и Вашу точку зрения!
В качестве продолжения работы рекомендую открытые библиотеки Code_Aster и OpenFOAM, правда в OpenFOAM нет МКЭ — только Метод Конечных Объёмов.

Модуль Юнга для стали 200 ГПа
Из файла вы берёте значение не в системе СИ и работаете с ним без преобразования. Так что не понятно, в каких единицах получился результат или для какого материала проводились расчёты.

Спасибо за Вашу работу, очень надеюсь увидеть продолжение в котором будут рассмотрены не вошедшие в эту статью аспекты.

Only those users with full accounts are able to leave comments. Log in, please.