МКЭ в моей судьбе :)
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 29.10.05 14:48
Оценка: 64 (10)
Здравствуйте, fplab, Вы писали:

F>В общем я "заразился" программированием. Завод в конце-концов практически загнулся и свалил я в местный университет считать по договорам подряда (на СМ-4) всякие конструкции методом конечных элементов (тоже я вам скажу, математика там будь здоров). Правда, СМ-4 в отличие от "Электроники" настоящий гигант . Ну а потом повалили персоналки, что уже совсем не интересно


Да, метод конечных элементов -- это да! Сразу на воспоминания потянуло. Был у меня в университете мой звездный час, как раз связанный с расчетами методом конечных элементов. Итак, осень 1993-го, первый семестр четвертого курса, математический факультет, специальность 22.04 "ПО ВТ и АС", наша группа специализируется по кафедре Вычислительной Математики и Программирования. Нужно еще сказать, что переход на четвертый курс на нашем факультете -- это как переход в другую лигу, лигу бессмертных (вылететь с четвертого и пятого курсов нужно постараться). А вот к четвертому курсу отсев был довольно солидный. Например, на педагогическом потоке первые три курса было три группы, 75 человек, а на четвертом оставалось только две. Да и наша группа на первом курсе была 18 человек, а к четвертому -- только 12.

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

И вот в таких условиях начинается у нас новый спецкурс «Методы конечных элементов» (МКЭ). Читал нам его доцент, к.т.н. Быховцев Виктор Емельянович, который, наверное, лет двадцать рассчитывал этим методом ленточные фундаменты. Даже какую-то разновидность этого метода придумал. Собственно, в той математике, которая нам читалась, я совершенно ничего не понимал. Но все дело в том, что для получения оценки нашей группе совместными усилиями нужно было написать программу для расчета деформаций чего-то там МКЭ. Что-то типа прямоугольной области, которая покрывается сеткой треугольных элементов. Для отдельных узлов задаются значения нагрузки или параметры среды. Затем должен запускаться расчет. В идеале, должна была быть графическая интерпретация, но это уже как бонус.

Ну а мы решили, что все должно выглядеть по-другому. Что задавать исходные параметры в консоли в виде “Введите нагрузку для точки [3,7]: “ не только не удобно, но и некрасиво. Что графическая интерпретация должна быть обязательно. Ну и вообще, конфетку нужно сделать. К тому времени у меня и моего друга-сокурсника был уже небольшой опыт программирования под Windows. И мы уже не только понимали, что такое check button, а что такое edit-box, но и почувствовали, насколько это удобно. Так что какие-то ориентиры по внешнему виду и удобству использования программы у нас были.

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

Особенность СЛАУ в МКЭ был в том, что матрица СЛАУ была, во-первых, симметричной и, во-вторых, не нулевые значения содержались только в узкой ленте вдоль главной диагонали. А поскольку размерность матрицы была не маленькой, то хранить в ОП нужно было только т.н. полуленту – не нулевые элементы, лежащие выше главной диагонали. Ну хранить-то ладно, это не сложно. Основная проблема в том, что при работе с ней уже нельзя использовать обычные индексы [i,j] – они должны преобразовываться довольно хитрым образом. А если учесть, что формулы для аппроксимации совсем не маленькие (и там нет учета особенностей хранения матрицы СЛАУ), да и расчет СЛАУ активно индексы применяет, то браться за программирование всей этой бодяги было очень невесело. Да и преподаватель нас предупреждал, что при реализации МКЭ львиная доля ошибок как раз и связана с тем, что где-то какой-то индекс вычисляется неправильно.

Но к тому времени я уже хорошо представлял себе возможности C++. В частности, преимущества, предоставляемые перегрузкой операторов. Поэтому я решил избавиться от проблемы неверных индексов самым кардинальным образом – создав класс для матрицы и перегрузив для нее операторы []. Дел оказалось-то на день-два проектирования и на пару часов реализации. И все. Во всей сделанной нами программе не было ни одной ошибки, связанной с неверным вычислением индекса при обращении к хранящейся в памяти полуленте.

Ну а дальше уже дело техники . Была сделана библиотека для работы с мышью (на машинах, где мыши не было курсор мыши рисовался вручную и передвигался от клавиатуры), библиотека разных widget-ов (push button, check box, radio button, edit box), графическая интерпретация и даже экспорт/импорт начальных данных в/из текстовых файлов. Хотя с чем-то пришлось помучаться. Например, мне с моим штатным заданием, расчетом СЛАУ. Оказалось, что большинство элементов на главной диагонали были нулевыми, поэтому метод Гаусса не получилось применить. Метод квадратного корня не подошел т.к. часть элементов были отрицательными, метод итераций сходился очень долго (из-за большого объема матрицы). Единственный метод, которым удалось это СЛАУ разрешить – это метод Халецкого, хотя он и был самым расточительным по памяти. Но вот опробовать все эти методы мне удалось именно благодаря своему классу матрицы – программирование каждого метода было совсем не сложным занятием. В общем, потрудились мы на славу, получилась действительно конфетка. Вся кафедра была под впечатлением. Жалко screenshot-ов не осталось

Интересные последствия были у этой работы. Ну то, что репутация у нашей группы после этого выросла до заоблачных вершин, это само собой. Я за курс МКЭ получил оценку автоматом. В следующем семестре нам опять пришлось использовать МКЭ, но уже для расчета распределения температур по различным поверхностям (мне, например, досталась круглая поверхность, которую нужно было аппроксимировать треугольниками – интересная инженерная задачка, я даже по собственной воле с полярными координатами разобрался, т.к. в них она решалась гораздо проще ). У каждого из нас условия задачи и некоторые особенности были свои, но за основу всеми была взята сделанная нами раньше программа. По слухам, мы тогда стали чуть ли не единственной группой, которая реально рассчитывала свои задачи, говорят, что многие сдавали эту работу с помощью «пустышек» -- программ, которые реальных расчетов не проводили, а показывали только правдоподобную имитацию расчета. Для одного из моих сокурсников наша разработка стала основой для его последующих курсовых и диплома.

Года через два мне довелось поговорить с четверокурсниками, который проходили у того же Быховцева тот же курс МКЭ. И получили ту же самую задачу. Он им показал несколько фрагментов нашей программы, в частности, класс для работы с мышкой. Было забавно, как они обсуждали увиденный код, не зная, что я его автор. Помню, они удивлялись, как можно было создать класс для работы с мышью, объем которого был 5 или 6 страниц распечатки. А еще больше они удивились, когда я им поведал, что этот класс на самом деле умеет делать на машинах без мышки . А еще через пару лет сам Быховцев мне рассказал, как он показал нашу разработку на геологическом факультете, где тогда подобралась сильная группа студентов-программистов. Эти студенты не поверили Быховцеву, что программу написали такие студенты, как они, только математики. Сказали, что это он за деньги у какой-то конторы разработку заказывал. Приятно было такие вещи слушать, тем более, что круче нас эту задачу так никто и не решил.

Я же помню, как после этого курса я еще больше убедился в мощи языка C++. Это было, пожалуй, второе сильное впечатление от C++. Первое – это когда в C++ средствами самого языка оказалось можно сделать тип «множество» (которого мне после Паскаля в C и C++ очень не хватало).

Еще запомнилось впечатление от якобы командной разработки. Это только на бумаге у нас было четыре или пять миникоманд, и двенадцать разработчиков. На самом деле всю разработку тянули два человека – я и мой друг, с которым мы до этого под Windows упражнялись. Не то, чтобы никто ничего не делал. Совсем нет. Например, две наши девушки супер-математика всю аппроксимацию реализовали. Все что-то делали по чуть-чуть. Но все это было настолько разношерстным, что приходилось много чего доделывать, чтобы все вместе объединить. Как мне потом, после университета, в конструкторском бюро объяснили – это обычная практика совковых команд: в отделе 25 человек, из которых 3-4 реально все делают, а остальные на окладе сидят, массовость создают.

Ну и еще тогда мне стало интересно заниматься не столько прикладными задачами, сколько инструментами, которые значительно упрощают решение прикладных задач. Хотя это уже совсем другая история.

Но вот, что интересно. Техника тогда у нас в распоряжении была – i286, 640Kb, MS-DOS 5-й или 6-й уже не помню. Компилятор, кажется, Borland C++ 2.0 и библиотека BGI для графики. Т.е. сам бог велел об эффективности заботиться. Ан нет, не помню я, чтобы мы там байты или такты считали. Ведь даже метод Халецкого, если не ошибаюсь, требовал вдвое больше памяти, чем метод Гаусса. Для нас на первом месте функциональность была. Например, чтобы на машине без мышки можно было легко точки на сетке конечных элементов выбирать. Чтобы начальные данные можно было из заранее подготовленного файла загрузить. Чтобы при просмотре результатов между графическим и табличным представлением можно было переключаться. Эффективность там рассматривалась как составная часть функциональности. Задача должна была решаться в конкретных условиях. Она решалась. Поэтому больше мы об эффективности не заботились.

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

Хотя, может мы тогда и не задумывались о таких вещах серьезно, поскольку молодые очень были. Да и программировали на C++, у которого проблем с эффективностью никогда и не было. Но мне кажется, что к эффективности нужно относиться как к функциональности: есть задачи (например, hard real-time), где эффективность – это краеугольный камень (наряду с предсказуемостью). А есть задачи (таких большинство), где эффективность – это одно из конкурентных преимуществ. Если есть заинтересованность в таком преимуществе, то эффективности уделяется внимание. Если нет – значит, нет. Долгие годы программирования на C++ и опыт участия в разработке real-time проектов лично меня сделали приверженцем эффективных решений. Но без фанатизма. Если мне сейчас нужно за короткое время написать сложную обработку гигабайтных логов, то я без угрызений совести делаю это на Ruby, т.к. проще это. А то, что Ruby скрипт будет считать в пять раз дольше, чем C++ программа… Ну и что? Где эта C++ программа? Нет ее, и не будет, т.к. писать ее слишком долго. Нет конкуренции, нет у эффективности и преимущества. Вот такие дела.
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.