Реферат Инженерные методы эксперимента и САПР. Реферат(ИМЭиСАПР). Caе системы автоматизации инженерных расчётов

• Название: Caе системы автоматизации инженерных расчётов
• Анкор: Реферат Инженерные методы эксперимента и САПР
• Дата: 09.06.2021
• Размер: 135.75 Kb.
• Имя файла: Реферат(ИМЭиСАПР).docx
• Тип: Контрольная работа; #215954

ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ

ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

«ДОНЕЦКИЙ НАЦИОНАЛЬНЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ»

Кафедра промышленной теплоэнергетики

КОНТРОЛЬНАЯ РАБОТА

по дисциплине «Инженерные методы эксперимента и САПР»

на тему: «CAЕ – системы автоматизации инженерных расчётов»

Выполнил: ст. гр. ТПз-18

Зарипов М.Ш.

Проверил: доцент,к.т.н.

Гридин С. В.

Донецк 2021

СОДЕРЖАНИЕ

ВВЕДЕНИЕ………………………………………….…..……………….………...3

1. СПОСОБЫ ОПИСАНИЯ ЗАДАЧ………………….…………………...…..5

2. 
   МНОГОДИСЦИПЛИНАРНАЯ ОПТИМИЗАЦИЯ…….………………….7
   
3. 
   ПРЕДЛАГАЕМАЯ МОДЕЛЬ……………………………………………….9
   
4. 
   ПРИМЕНЕНИЕ К ЗАДАЧЕ МДО…………………………………………11
   

ВЫВОД…………………………………………………………………………….13

СПИСОК ЛИТЕРАТУРЫ…………...……………………………………………14

ВВЕДЕНИЕ

Проектирование современных высокотехнологичных изделий представляет из себя сложный многоэтапный процесс, который просто невозможно представить без использования специализированного программного обеспечения. Инструментарий инженера-проектировщика обычно состоит из системы автоматизированного проектирования (CAD), системы моделирования и инженерного анализа (CAE) и системы управления данными об изделии (PDM). Система автоматизированного проектирования позволяет в удобной визуальной форме описать разрабатываемое изделие, например задать его трехмерную геометрию, описать материалы из которых оно должно быть изготовлено и т.д. Системы инженерного анализа позволяют провести моделирование и предсказать основные технические и эксплуатационные характеристики изделия задолго до изготовления прототипа. Система управления данными об изделии — организационно-техническая система, обеспечивающая управление всей информацией об изделии. Следует заметить, что обычно CAD и PDM системы входят в состав единого программного комплекса. В то же время, для моделирования и инженерного анализа применяется множество различных программных пакетов, включая проприетарные программные пакеты разработанные непосредственно на предприятии занимающимся проектированием. С точки зрения используемого ПО, типичный процесс разработки изделия выглядит следующим образом. С помощью CAD системы инженерпроектировщик описывает параметры разрабатываемого изделия. После того, как первый вариант изделия готов, с помощью CAE системы инженер получает предсказание характеристик изделия. Далее, инженер снова возвращается в CAD систему, где изменяет изделие с целью улучшения его характеристик. Этот процесс повторяется многократно до тех пор, пока не будут удовлетворены все технологические и экономические требования. Важно заметить, что на протяжении всего процесса инженеру приходится выполнять множество однотипных рутинных действий, таких как преобразование описания изделия в один из переносимых форматов (например IGES или STEP), подготовка конфигурационных файлов для CAE системы, запуск и отслеживание выполнения программ входящих в состав используемой CAE системы (обычно это — препроцессор, генератор сетки, модуль расчета, постпроцессор). Только после всех этих действий инженер может перейти к анализу получившихся характеристик. Очевидно, что необходимость выполнения множества рутинных операций, с одной стороны, повышает риск ошибки, а с другой — приводят к нецелевому использованию дорогостоящих специалистов. Другой важной особенностью описанного процесса проектирования, является то, что поиск оптимальной конфигурации изделия производится специалистом исключительно на основании накопленных знаний, опыта и профессиональной интуиции. К сожалению, для решения современных задач этого не всегда достаточно. Во многих случаях (например, разработка крыла или двигателя современного пассажирского авиалайнера) изделия настолько сложны, что улучшение их характеристик (уменьшение массы и увеличение эффективности) на проценты или даже на доли процента является чрезвычайно сложной задачей, требующей от специалистов высочайшей компетенции. Более того, часто для получения желаемых характеристик требуется оптимизировать изделие в целом, а не отдельные его части. Т.е. составляется единая многодисциплинарная модель изделия. Оптимизация такой составной модели выходит за рамки компетенции отдельных специалистов. В подобных случаях, наиболее эффективным подходом к решению задачи является использование формализованных методов оптимального проектирования, то есть определение проектных параметров изделия с помощью формальных математических методов оптимизации. Очевидно, что для применения подобных методов описанный выше процесс изменения параметров и расчета характеристик должен быть полностью автоматизирован. Конечно, разработать единую последовательность действий, которая бы подходила для решения всего многообразия инженерных задач не представляется возможным. Тем не менее, разработка удобных средств автоматизации для построения расчетных цепочек инженерных расчетов — задача вполне решаемая. Это подтверждается появлением на рынке инженерного ПО соответствующих программных продуктов: Isight, ModelCenter, modeFRONTIER, Optimus. Перечисленные системы позволяют описать процесс решения конкретной инженерной задачи при помощи своего рода языка визуального программирования. В основе любой из перечисленных систем лежит формализм описания потока работ (workflow). Рассмотрим подробнее существующие способы описания потоков работ.

1. 
   СПОСОБЫ ОПИСАНИЯ ЗАДАЧ
   

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

Известно несколько подходов к автоматизации инженерных расчетов. Во-первых, можно описать процесс с помощью языка программирования высокого уровня, например, C++, Fortran, Python. Однако, написание подобных программ требует от конструктора умения программировать и существенных дополнительных трудозатрат. Более подходящим способом описания инженерного расчета является формализм потока работ (workflow). Формализм потока работ позволяет описать некоторый процесс в терминах отдельных действий, которые выполняются в рамках процесса, и связей между действиями, задающими последовательность их выполнения. Например, процесс, описанный во вступлении, можно было бы описать следующим образом.

1. Запросить параметры геометрии.

2. Запустить CAD систему и перестроить геометрию модели изделия.

3. Выписать модель в переносимый формат.

4. Последовательно запустить программы входящие в состав CAE (препроцессор, сеткопостроитель, модуль расчета, постпроцессор).

5. Выдать подсчитанные характеристики изделия.

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

Можно выделить два принципа, на основе которых строятся модели потоков работ: поток управления и поток данных. Поток управления в явном виде определяет последовательность запуска блоков, входящих в состав потока работ. Например, утверждение «блок B выполняется после блока A» — описание потока управления. Стоит отметить, что данное утверждение не означает, что блок B как-то использует результаты работы блока A. Поток данных, напротив, не определяет в явном виде последовательность запуска блоков, но определяет зависимость между ними по данным. Например, «блок B получает данные от блока A» — описание потока данных. У обоих подходов есть свои достоинства и недостатки. В частности, с помощью потока управления удобно задавать ветвящиеся и циклические процессы. С другой стороны, потоки данных являются более интуитивно понятными и естественным образом позволяют распараллеливать выполнение независимых частей процесса.

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

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

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

2. 
   МНОГОДИСЦИПЛИНАРНАЯ ОПТИМИЗАЦИЯ
   

Многодисциплинарная оптимизация (МДО, MDO) является одним из наиболее актуальных и активно развивающихся подходов в современном процессе проектирования.

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

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

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

Будем считать, что модель лопатки устроена следующим образом — параметрически задается геометрия, затем выбирается расположение отверстий для охлаждения и их размер. Выбор параметризации сам по себе представляет из себя чрезвычайно сложную задачу, однако для наших целей мы можем считать ее уже решенной. Предположим, что геометрию было решено задавать 7 параметрами, а для охлаждения использовать два круглых отверстия, что дает еще 6 параметров. На основе этой модели будет создаваться детальное описание вначале лопатки, а затем и целой ступени турбины, после чего можно использовать то или иное программное обеспечение для инженерного анализа (CAE) для расчета КПД, температуры и напряжений.

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



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

3. ПРЕДЛАГАЕМАЯ МОДЕЛЬ

К рассмотрению предлагается модель описания потока работ, которая, по мнения авторов, позволяет описывать сложные циклические и ветвящиеся процессы решения инженерных задач наиболее интуитивным способом. Модель также позволяет максимально эффективно использовать вычислительные ресурсы благодаря естественному параллелизму, свойственному концепции потока данных. В основе предлагаемой модели описания потока работ лежит принцип потока данных. Поток данных представляется в виде ориентированного графа, вершинами которого являются блоки. Блок реализует некоторую отдельную задачу. У каждого блока существуют наборы входных и выходных портов. Порты блока — это входные и выходные каналы данных. Блок получает данные через входные порты и выдает данные через выходные. Например блок, осуществляющий запуск системы инженерного анализа, может получать на вход файл с описанием геометрии модели, а выдавать через выходные порты предсказание ее характеристик. Алгоритм выполнения данной модели потока работ выглядит следующим образом. Пусть в начальный момент времени известны условия запуска всех блоков. Условие запуска — это набор входных портов, на которые необходимо подать данные чтобы блок запустился.

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

2. Запускаются блоки, найденные в п.1. Если таких блоков нет — работа завершается.

3. Ожидается завершение работы любого из запущенных блоков. Как только хотя бы один из блоков завершил свою работу — переходим к п.1.

Отметим, что когда один из блоков завершает работу, он выдает данные через свои выходные порты, что, в общем случае, приводит к запуску блоков зависимых по данным от текущего блока.

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

4. ПРИМЕНЕНИЕ К ЗАДАЧЕ МДО

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


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

Отдельным блоком (buildModel) также представлено построение детальной модели ступени турбины. Подготовленная модель поступает на вход расчетному блоку, который вычисляет интересующие нас отклики – КПД и максимальную температуру на поверхности лопатки.

Здесь используется важное свойство предложенной модели — специальная обработка связи от блока optGeom к блоку buildModel. На одно выполнение блока optGeom приходится множество выполнений блока buildModel, таким образом, данные о геометрии будут выданы только один раз, а потребуются неоднократно. Для корректного выполнения потока работ необходимо определить, что это связь между внешним и внутренним циклами, и обеспечить повторение данных о геометрии на каждом выполнении блока buildModel.

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

Кроме того, блоки buildModel и modelResponse сгруппированны в составной блок response. В данном примере, это не играет роли для выполнения потока работ и приведено для иллюстрации возможности построения иерархических потоков работ. Это важно, например, в том случае, если настройка и подготовка блока response производится отдельно.

Рассмотрим, как происходит выполнение потока работ:

1. Первым начинает выполнение блок optGeom, он не требует никаких входных данных для своего первого шага.

2. Блок optGeom выписывает данные в выход x и для следующего шага требует прихода данных во вход f.

3. Блок optHoles получает сигнал в порт do и начинает свой цикл оптимизации.

4. Блок optHoles выписывает x и ожидает f.

5. Составной блок response получает данные во входы geom и holes и перенаправляет их блоку buildModel. Блок buildModel выполняется и выписывает данные в выход model.

6. Блок modelResponse получает данные в порт model, выполняется и выписывает выход result.

Внутренний цикл оптимизации повторяет шаги 4,5,6, и, после некоторого числа итераций, блок optHoles выписывает выход eff, что соответствует эффективности ступени турбины при оптимальных размере и расположении охлаждающих отверстий. После этого начинается новая итерация внешнего цикла (шаги 2,3) и перезапускается внутренний цикл.

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

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

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

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

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

Предложенная в работе модель была реализована и используется в составе системы для автоматизации инженерных расчетов pSeven (ранее PSE). Кроме того, в составе pSeven было разработано более 40 различных блоков, что показывает универсальность модели. В настоящее время pSeven активно используется для решения инженерных задач, в том числе задач оптимального проектирования.

СПИСОК ЛИТЕРАТУРЫ
1. Bradford Smith, Kalman Brauner, Philip Kennicott, Michael Liewald и Joan Wellington. “Initial graphics exchange specification(IGES) Version 2. 0.” в: NTIS, SPRINGFIELD, VA(USA), 1983, 341 (1983).

2. Michael J Pratt. “Introduction to ISO 10303—the STEP standard for product data exchange”. в: Journal of Computing and Information Science in Engineering 1.1 (2001), с. 102–103.

3. Dassault Syst`emes. Isight / SEE 5.8. 2013. url: http : / / www . 3ds . com / products - services / simulia / portfolio / isight - simulia- execution- engine/latest- release (дата обр. 13.10.2013).

4. Phoenix Integration. PHX ModelCenter. 2013. url: http://www.phoenix-int.com/software/ phx-modelcenter.php (дата обр. 13.10.2013).

5. ESTECO. modeFRONTIER. 2014. url: http : / / www . esteco . com / modefrontier (дата обр. 26.04.2014).

6. Noesis Solutions. Optimus. 2014. url: http:// www.noesissolutions.com/Noesis/ (дата обр. 26.04.2014).

7. Wil Van Der Aalst и Kees Max Van Hee. Workflow management: models, methods, and systems. MIT press, 2004.

8. Juan J Alonso, Patrick LeGresley, Edwin Van Der Weide, JRRA Martins и James J Reuther. “pyMDO: A framework for high-fidelity multidisciplinary optimization”. в: AIAA paper 4480 (2004), с. 2004.

9. Nikola Trcka, Wil van der Aalst и Natalia Sidorova. “Analyzing control-flow and data-flow in workflow processes in a unified way”. в: Computer Science Report 08-31 (2008). [10] Joaquim R. R. A. Martins и Andrew B. Lambe. “Multidisciplinary Design Optimization: A Survey of Architectures”. в: AIAA Journal 51 (2013), с. 2049–2075.