Когда человек начинает писать программу с использованием инструментов графической библиотеки OpenGl, то рано или поздно он понимает, что стандартных средств интерфейса совершенно недостаточно для построения графического объекта хоть сколько-нибудь приемлемой сложности. Много ли можно сделать из прямоугольников и треугольников? Много, совершенно справедливо ответите вы. И будете правы, ибо полигональные модели как раз и формируются из этих самых треугольников. Собственно, полигон – это и есть многоугольник, причем чаще всего используются как раз треугольники или прямоугольники[2]. Вот только вручную просчитать расположение сотен (а то и тысяч, и сотен тысяч) полигонов – занятие, конечно, реализуемое, но маловероятное. Нет, конечно же, еще фигуры можно задавать массивами координат, но высчитать подобный массив – задача не намного легче.

Как поступает студент в таком случае? Он использует 3D-редакторы для отрисовки сложных 3D-объектов. 3D-редакторы обладают удобным графическим интерфейсом, интуитивно понятным даже для новичка, и научиться создавать с их помощью достаточно сложные объекты, а затем переводить их в понятные для OpenGl списки координат, не составит для увлеченного человека особого труда. И вот тут разработчика ожидает серьезная проблема: к сожалению, OpenGl не содержит встроенных средств для чтения 3D-моделей. Поэтому  реализовывать такое приложение приходится самому.

Нет, с одной стороны, координаты – это всегда координаты, и вроде бы ничего сложного в переносе нет. В крайнем случае, можно взять массив координат, полученный в редакторе, и вручную вставить его в код. Можно даже перенести 10 тысяч полигонов из 3D-редактора в код. Но сколько времени займет данная операция?

Для решения этой проблемы можно избрать следующий путь:  привлечь «автозамену», встроенную в любой текстовый редактор, и с помощью неё постараться подогнать форматы. Но это тоже не избавит вас от огромной ручной работы. Да и «автозамена» никогда не была интеллектуальным алгоритмом, и гарантии, что после такой длительной работы у вас все заработает, никто не даст.

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

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

Рассмотрим процесс создания алгоритма для конвертирования 3D-моделей из 3D-редактора в программный код. Для начала выберем исходный формат файла-источника. Предлагаю использовать OBJ-формате, и для этого есть две веские причины. Во-первых, это один из самых распространённых форматов хранения данных, а во-вторых (и это главное в нашем случае), он текстовый и, как следствие, более понятный для восприятия.

Но для начала немного уточним терминологию. Как в OpenGl, так и в OBJ есть координаты и индексы [3]. Координата – это расположение точки на виртуальной координатной плоскости в программе (по трем измерениям). Тут все просто. А вот с понятием «индекс» могут возникнуть сложности.  В нашем случае «индекс» – это номер координаты в массиве координат. Поясним ситуацию на примере: допустим, дан массив из 4-х наборов координат по трем осям X, Y, Z:

          (x, y, z)

    1)    1,  3, 5

   2)   -2, 7, 9

    3)   -5, 4, -7

     4)    8, -6, -1

И координата некоторой точки, указанная в индексах:

Точка 1: 4, 3, 2

В этом случае значения индексов точки означают номер ряда из массива, по соответствующей оси. В нашем случае, индекс по оси X равен 4, следовательно, необходимо взять координату оси Х из четвертого ряда (у нас это 8). Точно так же восстанавливаем координаты по оси Y (третий ряд, вторая цифра – 4) и Z (второй ряд, третья цифра – 9).

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

Точка 1: 4, 8, 9

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

Также необходимо учитывать, что для описания модели используют три типа координат: координаты модели (то есть самого объекта), координаты нормалей (необходимы для распределения освещенности в сцене) и координаты текстур (при наличии текстур в модели).

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

# Max2Obj Version 4.0 Mar 10th, 2001

v  10.4335  217.914  7.80485

v  -8.02548  219.079  6.90515

v  -8.22437  219.042  6.90515

v   4.414604  70.340584  7.308666

# 4 vertices

vn  0.000000 0.000002 -1.000000

vn  -1.000000 0.000000 0.000000

vn  0.000000 0.000000 1.000000

# 3 vertex normal

vt  0.47683 0.51250

vt  0.46556 0.50879

vt  0.46335 0.50876

# 3 texture vertices

f  1/1/1  1/2/1  2/3/1

f  4/2/1  3/1/3  4/1 1

f 3/1/3  2/3/1  3/1/2

# 3 faces

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

v  10.4335  217.914  7.80485

v  -8.02548  219.079  6.90515

v  -8.22437  219.042  6.90515

v   4.414604  70.340584  7.308666

Это описание каркаса нашей модели (точнее, массив координат каркаса, помним про индексы). Он есть в любом файле.

Затем указаны координаты нормалей:

vn 0.000000 0.000002 -1.000000

vn -1.000000 0.000000 0.000000

vn 0.000000 0.000000 1.000000

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

Далее перечисляются координаты текстуры:

vt 0.47683 0.51250

vt 0.46556 0.50879

vt 0.46335 0.50876

Поскольку текстура сама по себе двухмерная, третья координата обычно либо не указывается, либо равна 0 (vt 0.46335 0.50876 0). Данного блока может не быть, если у модели нет текстур.

Зачастую между блоками встречаются комментарии с указанием количества этих самых блоков ( # 3 texture vertices). Также можно уточнить, что количество точек каркаса, текстур и нормалей не всегда соответствует друг другу. Это совершенно нормально и  приводится в соответствие с помощью индексов.

Какую же полезную информацию может почерпнуть разработчик из представленных массивов данных?

1. В пределах одной модели порядок массивов координат всегда сохраняется: сначала указывается блок V (координаты моделей), потом блок VT (текстуры), затем блок VN (нормали). Блоки никогда не перемешиваются и не меняются местами (то есть, блока текстур может не быть вообще, но если он есть, то идет всегда после массива координат каркаса).

2. Между собой данные разделяются пробелом.

Эти два факта мы будем активно использовать  для реализации конвертера 3D-моделей.

Но это еще не все содержимое obj-файла. За блоком текстур располагается блок, строки которого начинаются с буквы f:

f  1/1/1  1/2/1  2/3/1

f  4/2/1  3/1/3  4/1 1

f  3/1/3  2/3/1  3/1/2

Это массив индексов. И составные элементы этого блока очень важны для понимания работы алгоритма конвертера, поэтому мы рассмотрим их подробнее. Буква f, как уже было сказано,  обозначает начало строки с индексами. Далее идут числа с разделителями, значения которых расшифровываются следующим образом: пробелом разделяются оси (соответственно, блоков чисел всегда 3: ось х, ось y, ось z), а внутри каждого блока допускается существование от 1 до 3 цифр, разделенных знаком «/» (или «//»):

f  1//1//1  1//2//1  2//3//1

f  4 3 4

f  3/1  2/2  3/1

Каждая тройка чисел несет следующую информацию: индекс каркаса//индекс текстуры//индекс нормали. Соответственно, если у модели нет текстур или нормалей, то и соответствующих индексов в блоке не будет.

Например,  рассмотрим одну из точек, строка индексов которой указана последней в блоке f:  f  3/1/3  2/3/1  3/1/2. Индекс координат данной точки: 3, 2, 3 (первые цифры каждого блока), следовательно, значения её координат мы выбираем из массива координат модели v из третьего, второго и снова третьего ряда: -8.22437,   219.079, 6.90515. Индекс текстур точки: 1, 3, 1 (вторые цифры блока). Следовательно, текстурные координаты данной точки 0.47683, 0.50876. Нормали выбираются по тому же принципу.

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

Рассмотрим  теперь способ записи координат в OpenGl проекте.  В общем виде описание изображения с использованием массивов выглядит, например, так:

glEnableClientState(GL_VERTEX_ARRAY);

glEnableClientState(GL_NORMAL_ARRAY);

glEnableClientState(GL_TEXTURE_COORD_ARRAY);

GLfloat pVerts1[]= {

-610.2380, 0.0000, 1368.7837,

-610.2380, 0.0000, 504.9502

};

GLfloat pNorm1[]= {

0.0000, -1.0000, -0.0000,

0.0000, 1.0000, -0.0000,

0.0000, 0.0000, 1.0000

};

GLfloat pTexCoord1[]= {

1.0000, 1.0000,

0.0000, 0.0000,

};

glVertexPointer(3, GL_FLOAT, 0, pVerts1);

glNormalPointer(GL_FLOAT, 0, pNorm1);

glTexCoordPointer(2,GL_FLOAT, 0,  pTexCoord1);

glDrawArrays(GL_TRIANGLES,0,3);

glDisableClientState (GL_VERTEX_ARRAY);

glDisableClientState (GL_NORMAL_ARRAY);

glDisableClientState (GL_TEXTURE_COORD_ARRAY);

Первые три строки необходимы для указания того, что будут использоваться 3 массива: массив вершин (GL_VERTEX_ARRAY),массив  нормалей (GL_NORMAL_ARRAY) и массив текстур (GL_TEXTURE_COORD_ARRAY). Далее указывается непосредствнно массив координат модели pVerts1[], который, в отличие от блока в OBJ, хранит уже готовые координаты, по которым строится каркас (напомним, что в OBJ каркас модели строился по индексам). При этом координаты в массиве pVerts1[] разделяются не пробелом, как в obj-файле, а запятыми. Затем инициализируются массив нормалей pNorm1[] и массив текстур pTexCoord1[].

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

• glVertexPointer(3, GL_FLOAT, 0, pVerts1) –  определяем, что массивом вершин будет именно массив pVerts1, определяем тип значений этого массива «float», и количество координат на одну вершину (по три, то есть три оси);
•  glNormalPointer(GL_FLOAT, 0, pNorm1) –  массив нормалей называется pNorm1 и также хранит значения типа «float»;
•  glTexCoordPointer(2,GL_FLOAT, 0,  pTexCoord1) – текстурный массив с именем pTexCoord1 и количеством переменных на точку – 2 (текстуры у нас двумерные).Далее переходим к отрисовке самой модели: glDrawArrays (GL_TRIANGLES,0,3). Здесь GL_TRIANGLES указывает, что рисовать будем треугольники; 0 – выборку координат из массива начнем  с нулевого элемента; 3 – на одну вершину будем считывать по три значения. Данная команда выводит треугольники по нашим координатам, пока они (координаты) не кончатся. Последние три строки примера необходимы для отключения установленных режимов обработки массивов. Эту функцию  необходимо  задавать в конце всего процесса вывода, но не обязательно для каждой модели.Перейдем теперь непосредственно к процессу перевода одного формата в другой. При этом при создании OBJ файла по умолчанию считаем, что отрисовывать будем треугольники. Не будем останавливаться на таких проблемах, как разные разделители координат (в файлах пробелы, в коде запятые), или отличающийся вид самих массивов (в файле каждая строка обозначается буквами, в коде достаточно фигурной скобки в начале блока), и прочем. Это можно достаточно просто исправить простейшими текстовыми преобразованиями (типа «автозамены»). Но вот об одной проблеме поговорим подробнее.

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

  Итак, для начала нам требуется считать файл. Чтение файла происходит построчно. При этом индексы в конце файла указывают на массив координат в его начале. Появляется проблема: или перечитывать файл на каждый индекс (что не слишком эффективно, учитывая, что точек – тысячи), либо сначала считывать и обрабатывать файл (и распределять по массивам в памяти), а потом уже формировать код. Поэтому выбираем второй способ. Так же необходимы места для хранения считанного массива. Будем использовать двухмерные массивы (код на Си):

  float coord_vert [1000000][2];

  float coord_ norm [1000000][2];

  float coord_ tex [1000000][2];

  Здесь мы объявили три массива типа «float», в которых будем хранить массивы вершин, нормалей и текстур соответственно. Количество элементов в массиве: миллион строк (что для высокополигональных моделей имеет смысл) и по 3 элемента в каждой строке (оси X,Y,Z). По умолчанию будем считать, что первая цифра – это номер самого массива, вторая – номер элемента в этом массиве.

  Таким же образом создаем массивы для хранения трех индексов, но с учетом того, что индексы у нас целочисленные (тип int):

  int  ind_vert [1000000][2];

  int  ind _ norm [1000000][2];

  int  ind _ tex [1000000][2];

  Тогда конвертация трехмерной модели будет проходить в два этапа:

1. считывание и обработка исходного файла;
2. построение файла с кодом.На первом этапе мы считываем одну модель и распределяем её по массивам. Далее осуществляем обработку массивов по отдельности: массивов координат и массивов индексов. Сначала ищем в строке символы “v”, “vt”, “vn”,  и, в случае обнаружения, следующие 3 координаты записываем в соответствующий массив под соответствующими номерами. И увеличиваем номер этого массива на 1.Когда мы доходим до массива индексов (символ “f”), мы должны отключить поиск координат (если этого не сделать, то к нам может попасть массив координат от следующей модели). Считывание индексов происходит по следующему алгоритму:

1. читаем первое число за пробелом, вносим его в массив индексов  каркаса (под соответствующим номером) как первый элемент массива (координата Х);
2. проверяем на наличие знака разделителя: «/» или «//» (т.к.  мы не знаем вид исходного файла);
3. если знак разделителя найден, то проверяем, есть ли у нас структура с координатами текстур (как  уже говорилось ранее, в индексах координаты идут по порядку (вершины/текстуры/нормали), но если текстур нет, то и текстурных индексов соответственно не будет, и без этой проверки мы можем выполнить запись индексов «не по адресу»);
4. записываем число после знака разделителя в массив с индексами текстур (или нормалей, если текстур нет) в первый элемент массива;
5. снова проверяем на наличие разделителя, и, при его обнаружении,  формируем массив нормалей;
6. выполняем поиск пробела;
7. число, следующее за пробелом, записываем в массивы с тем же номером и в том же порядке (сначала вершины, потом текстуры, потом нормали), но уже во второй элемент массива (т.е. формируем координаты оси Y);
8. повторяем те же действия для оси Z.Выполняем вышеуказанные действия до обнаружения знака начала комментариев (#), новых координат вершин (v) или конца файла. Затем  осуществляем  вывод нужного кода в следующем порядке:

• сначала выводим оформление кода: GLfloat pVerts1[]= {
• затем выводим координаты (по три в строке,  что удобнее для восприятия).Вывод координат осуществляется следующим образом: запускаем цикл (от нуля до того количества индексов, которое мы записали); выводим первый элемент массива; в качестве номера самого массива берем значение из массива индексов:for (int i=0; i<kol_vo_indexov_vert; i++)

  coord_vert [(ind_vert[i][0])-1] [0] «,»

  coord_vert [(ind_vert[i][1])-1] [1] «,»

  coord_vert [(ind_vert[i][2])-1] [2]  «,»

  В качестве индекса текущего элемента указываем формулу, с помощью которой можно будет сортировать значения: второй индекс равен 0, следовательно,  мы работаем с осью Х;  для оси Y второй индекс будет равен 1, а для оси Z – 2. Вычитание же единицы из индекса производится потому, что в Си индексация элементов массива начинается с нуля,  а в ob- формате – с единицы. Таким образом, происходит построение нового файла с кодом, включая вывод блоков текстур и  нормалей.

  Затем в конвертер 3D-моделей добавляется вывод:

  glVertexPointer(3, GL_FLOAT, 0, pVerts1);

  glNormalPointer(GL_FLOAT, 0, pNorm1);

  glTexCoordPointer(2,GL_FLOAT, 0,  pTexCoord1);

  glDrawArrays(GL_TRIANGLES,0,3);

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

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

- Вид детали;

- Способ получения заготовки;

- Точный размер обрабатываемой поверхности (согласно чертежа);

- Маршрут обработки данной поверхности;

- Способ крепления и базирования для каждой операции металлообработки.

После ввода исходных данных программой будет проведен выбор из базы данных таких параметров как:

- Высота неровности профиля обрабатываемой поверхности (шероховатость) для каждого перехода;

- Глубина дефектного поверхностного слоя для каждого перехода;

- Наибольшая величина кривизны (ρк);

- Значение смещения оси заготовки при погрешности центрирования (ρц);

- Значение погрешности базирования (εб);

- Величина погрешности закрепления (εз).

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

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

Алгоритм работы программы

 Страница 1

Страница 2

Страница 3

Страница 4

Страница 5

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

Алгоритм, лежащий в основе архиватора. Ядром архиватора является метод BWT лексикографической сортировки матрицы циклических перестановок входной строки, который позволяет эффективно раскрывать энтропийные взаимозависимости входных данных. Для устойчивости сортировщика на высокоизбыточных данных ведущими специалистами в области сжатия предложен алгоритм сортировки удвоением, который на данный момент используется в большинстве современных архиваторов. После глубоких теоретических и практических исследований данного алгоритма, было установлено, что он достаточно неэффективен на типичных данных. Поэтому нами был разработан уникальный в своем роде метод позволяющий эффективно сортировать типовые файлы и не теряющий своей эффективности на вырожденных данных. Он основан на сортировке Бентли-Седжвика с использованием авторской технологии Pixar. Отличительной его особенностью является интенсивное использование сверхбыстрой кэш-памяти CPU, что обуславливает высокую скорость сортировки, несмотря на нелинейную зависимость последней от размера блока. Важным преимуществом выбранного метода является высокий потенциал в поддержке современных аппаратных инноваций, таких как 64-битность архитектуры процессоров и Hyper-Threading .

В решении проблемы эффективного сжатия BWT-выхода ключевым моментом является LUP (List Update Problem). Эта проблема заключается в выборе способа эффективного обновления списка символов для лучшего предсказания однородности контекстов в исходном файле. Нами было разработано собственное решение, gmtf, которое сочетает в себе простоту алгоритма и сложное моделирование. Для улучшения энтропийных характеристик выхода gmtf был предложен специализированный метод кодирования длин повторов, который позволяет более эффективно использовать контекстную избыточность в преобразованном файле.

Последним этапом BWT-преобразования является использование энтропийного order-0 кодера, который в отличие от традиционных кодировщиков избыточности позволяет наиболее близко подойти к идеальному кодеру Шеннона. По результатам наших последних исследований именно он позволяет наилучшим образом интерпретировать выявленные BWT логические взаимозависимости данных.

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

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

Описание реализованных алгоритмов.

• HydraY codename “Windforce” – BWT processor:

В отличие от большей части современных BWCA архиваторов мы не используем преимущества концепции сортировки удвоением. В результате её глубокого исследования был обнаружен серьёзный недостаток – она не позволяет использовать следующее важное свойство BWT: для получения последнего столбца не обязательно иметь всю матрицу перестановок. Другими словами, нам не обязательно упорядочивать набор рядом стоящих строк(группу), если все они заканчиваются одним и тем же символом – это не повлияет на выход BWT. Это положение легло в основу нашей технологии PiXar. Она позволяет значительно ускорить обработку высоко избыточных данных, предоставляя возможность использовать алгоритм Бентли-Седжвика для сортировки строк матрицы перестановок. Предварительно список строк сортируется расстановкой по первым 4-м символам.

• Lynx – gmtf+grle processor

В качестве подходящего решения LUP был разработан собственный метод gmtf. Он заключается в том, что найденный символ перемещается не в начало списка, а к ближайшей границе. Массив границ был подобран экспериментально и является константой алгоритма, хотя возможность его динамической адаптации к входному потоку имеет большие перспективы для улучшения сжатия. Тестирование показало явное превосходство данного метода над известными решениям List Update Problem: MTF,MTF0 и др. Длинные последовательности нулей выхода gmtf эффективно кодируются grle. Этот метод, отдалённо напоминающий RLE – кодирование длин повторов, позволяет наиболее эффективно кодировать так называемые “хорошие” фрагменты gmtf-выхода.

• Order0 – arithmetic coder

В результате вышеописанных преобразований получаются два потока разной статистики: gmtf и grle ранги. Заключительной стадией сжатия является их обработка энтропийным кодером. В качестве такового был выбран адаптивный арифметический кодер Дмитрия Субботина и Владимира Семенюка.

1. Ptax – distance coder

Этот метод не вошел в текущую реализацию, но был активно используемым нами ранее. Он был реализован в высокоэффективном двухпроходном варианте. Асимптотическая сложность порядка O(N). Для непосредственного кодирования расстояний использовалась техника представления числа в виде суммы некоторых элементов последовательности Фибоначчи. Метод был отстранён на второй план в связи с малой эффективностью с точки зрения степени сжатия.

• Warden/Sylph – Intel 32 Architecture Preprocessor (7-15% compression gain).

Общая идея данного метода состоит в переходе от относительных адресов к абсолютным, например, при кодировании команд E8h и E7h (“CALL” и “JUMP” соответственно). Таким образом, слабо предсказуемые относительные смещения в коде программы преобразуются в абсолютные адреса в данном сегменте кода, что позволяет предсказывать старшие байты смещения. По теоретическим оценкам и практическим выводам аналогичное кодирование для команды “JUMP” проводить не стоит. Важное практическое применение имеет разработка технологии вычленения команд из сегмента кода для более точного определения команд, подлежащих кодированию. Эта технология в данный момент находится в альфа-тестировании.

Lich/Vampire/Wraith – Length-Index Preserving Transformation (5-10% compression gain)

Связка данных программ реализует LIPT-препроцессор для улучшения сжатия текстовых файлов. Основная идея заключается в построении словаря некоторого языка на основании анализа множества файлов на определенном языке, причем внутри словаря фразы разбиты на группы по длине, а внутри каждой такой группы отсортированы по частоте использования в языке (эту часть метода осуществляет Wraith). Далее слова обрабатываемого файла заменяются на строки следующего вида: <escape><word length><word index><flags>, где длина слова и его индекс в словаре кодируются с помощью записи в позиционной системе счисления, цифрами которой являются фиксированные символы, а флаги обозначают начинается ли слово с большой буквы или состоит из произвольно капитализированных символов (в последнем случае нужно записывать маску капитализации), определяющую какие из символов слова капитализированы).

Таким образом, в файле создаются искусственные, но стабильные контексты, что обуславливает высокий прирост сжатия. Важно отметить, что словарь является фиксированным и в архиве не передается, т.е. словарь задается заранее.

Алгоритм программы. Показан на рис.1.

Рис. 1. Алгоритм программы

Интерфейс программы. Интерфейс программы довольно прост и эргономичен. В оболочке программы отсутствуют пестрые краски что положительно сказывается на глазах и не вызывает усталость (Рис. 2).

Рис 2. Интерфейс программы

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

Каждый человек должен спать не менее 5 – 8 часов в сутки. Сегодня это является большой проблемой. По статистике дорожно-транспортных происшествий, фактором большого количество аварий является физиологическое состояние автомобилиста.

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

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

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

Устройство нацелено на дальнобойщиков, водителей различного транспорта и т.д., не исключает эксплуатацию на серьезной деятельности в ночное время, однотонной обстановке. Описываемая система безопасного движения «Антисон» основана на  определении степени закрытости глаза, что обозначает, на сколько открыт глаз пользователя от его привычного состояния.

Перемена освещения, тип лица не  влияют на степень распознавания. Она подстраивается под определенное лицо. Имеет инфракрасную подсветку, что позволит отслеживать состояние пользователя и в ночное время. Уведомление о засыпании может производиться звуковым, световым знаком.

Для описания общих требований к системе, а так же для минимизации появления ошибок при проектировании и моделировании системы используется унифицированный язык моделирования UML, применение данного языка более полно описано в [4-7]. Более широкое представление построения и действия информационной системы рассмотрим на UML – диаграммах.

Для предоставления процессов, происходящих  в предметной области, рассмотрим диаграмму последовательности (Рисунок 1).

Рисунок 1 – диаграмма последовательности

Основными элементами диаграммы являются: видеорегистратор, ЦОС, нейронная сеть. Видеорегистратор непрерывно получает сигнал, который передает следующему объекту (ЦОС). Тот в свою очередь его обрабатывает (находит область интересов, производит фильтрацию) и передает нейронную сеть, где происходит идентификация. В случае, если нейросетевая идентификация выявила момент засыпания, то пользователю подается сигнал.

Для проектирования процедуры хода операций рассмотрим диаграмму деятельности (Рисунок 2).

Рисунок 2 – диаграмма деятельности

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

Сам же результат может привести к изменению состояния системы или возвращению некоторого значения.

В диагpaммe деятельностей испoльзуeтся cocтояние, связаннoe с принятием решения. Решение применяется в тех случаях, когда в зависимости от требования перехода, может быть выбран тот или иной переход на диаграмме. В нашем случае решение заключается в «>50%» и «≤50%». В случае, когда отклонения ≤50%., система продолжает видеофиксировать данные. Если система зафиксировала отклонения >50%, то подается сигнал без прекращения видеофиксации.

На рисунке 3-7 показаны входные кадры разных уровней состояния глаз (соответственно): открытые, прищуренные, закрытые.

Рисунок 3 – входной кадр открытых глаз

Рисунок 4 – входной кадр открытых глаз

Рисунок 5 – входной кадр прищуренных глаз

Рисунок 6 – входной кадр закрытых глаз

Рисунок 7 – входной кадр закрытых глаз

Результат работы системы представлен в таблице 1.

Таблица 1 – Соответствия показаний дисплея и величины отклонения

Таким образом, по величине отклонения мы можем судить, в какой стадии бодрствования находится пользователь. Если отклонение меньше 50%, то перед нами относительно бодрый человек, больше – уровень утомляемости критичен.

По нашим показаниям видно, что первый сигнал принадлежит бодрому человеку, третий сигнал говорит о том, что пользователь засыпает или уже спит. Результат распознавания достигает 99,8%.

В настоящее время области применения систем визуализации охватывают самые различные сферы деятельности человека – от отображения виртуальных миров в компьютерных играх и системах виртуальной реальности до визуализации результатов компьютерного моделирования в серьезных научных и военных приложениях, а также в системах автоматизированного проектирования. Полупрозрачность используется при визуализации стеклянных поверхностей, природных явлений (применяются системы частиц), а также в системах автоматизированного проектирования (САПР). В САПР полупрозрачность позволяет наглядно представить внутреннюю структуру проектируемого изделия [1,2].

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

Рисунок 1. Комплексное использование  опций ContourStyle и Opacity для функции ContourPlot3D:

Достаточно эффективно визуализация используется для представления информации, которая зрительно не воспринимается, либо воспринимается опосредованно через приборы, приспособления или вычисления (напр. температуры, плотности населения, распределения уровней электромагнитных полей и т.д.). В современной науке и технике визуализация — неотъемлемый элемент обработки сложной информации о пространственном и пространственно-временном строении и изменении объектов [3].

Визуализация в компьютерной технике в настоящее время описывается словом рендеринг (от англ. rendering — изображение, перевод, переложение, интерпретация). В зависимости от цели, различают пре-рендеринг, как достаточно медленный процесс визуализации, применяющийся в основном при создании статических изображений и анимаций, и рендеринг в реальном режиме, применяемый в компьютерных играх, который, как правило, использует специальное оборудование – 3D-ускорители.

Под визуализацией в режиме реального времени понимается процесс отображения трёхмерных данных при интерактивной частоте кадров (более 15-20 кадров в секунду) [4], в котором соблюдаются жёсткие ограничения на временные характеристики функционирования. Обычно изображение выводится на двухмерный экран, дисплей компьютера, но также широко применяется стереоскопическая визуализация, и в последнее время получают распространение трёхмерные дисплеи.

Для достижения необходимой для отображения в режиме реального времени частоты кадров и получения качественных изображений приходиться прибегать к компромиссам. Сейчас самым быстрым способом получения изображений является заполнение полигонов с интерполяцией атрибутов пикселей между вершинами графического примитива (rasterization, polygonfilling). При этом получаемое изображение не является полностью фотореалистичным, гораздо лучших результатов можно достичь, применяя более приближенные к реальности физические модели распространения света, которые и требуют гораздо больше вычислительных ресурсов (globalillumination, radiosity, pathtracing, photonmapping и т.д.) [4, 5]

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

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

1.      Растеризация (англ. rasterization) и метод сканирования строк (англ. scanlinerendering). Данных подход подразумевает проецирование всех объектов моделируемой сцены на экран, при этом эффект перспективы относительно наблюдателя не учитывается. На сегодня растеризация является основным способом визуализации в режиме реального времени.

Метод не имеет каких-либо строго определенных путей для вычисления цвета пикселей. Процесс растеризации 3D модели в двумерное пространство часто выполняется с помощью специальных функций аппаратного обеспечения в графическом конвейере (graphic pipeline).

2.      Метод бросания лучей (рейкастинг) (англ. ray casting). Алгоритмы этой группы рассматривают сцену из одной точки, которая является и источником лучей, направляемых на объект для определения цвета пикселя. Отличие от метода трассирования заключается в том, что данные лучи прекращают своё распространение как только достигают любой объект сцены либо же её фона. При этом есть возможность использования простейших техник добавления оптических эффектов в отрисовываемую сцену. А эффект перспективы возникает естественным образом при запуске лучей под углом, зависящим от положения пикселя на экране и максимального угла обзора камеры.

3.      Трассировка лучей (англ. raytracing). Метод очень похож на начальном этапе на рейкастинг, однако, лучи, с помощью которых определяется цвет пикселя на двумерном экране, при достижении объекта останавливаются. В общем виде идея метода трассировки лучей незамысловата: к каждому пикселю на дисплее проводится прямой луч от глаза наблюдателя или камеры к элементу выводимой сцены. В результате мы имеем несколько типов лучей [6]. Первичные лучи используются как определители видимости объекта и являются своего рода Z-буфером, который используется в растеризации. Что же касается вторичных лучей, то они разделяются на следующие (рис.2):

•        лучи тени/освещения;

•        лучи отражения;

•        лучи преломления.

Рисунок 2. Классический алгоритм трассировки лучей

Несомненным преимуществом метода трассировки лучей является качественная обработка эффектов прозрачности.

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

4.      Трассировка пути. Одна из разновидностей трассировки лучей, а точнее – метод просчёта глобального освещения brute-force. Методику рендеринга в компьютерной графике можно охарактеризовать как, стремящуюся имитировать физическое поведение светового луча максимально близко к реальному. Трассировка пути является обобщением теории традиционной трассировки лучей (англ. ray tracing), алгоритм которой как бы отправляет лучи света в от виртуальной камеры вперед, сквозь пространство; луч же как бы отскакивает (отражается) от предметов пока полностью не рассеется или не поглотится [7]. Что касается качества изображений, которые получены при помощи этого метода, зачастую, лучше, чем изображения, полученные при использовании других методов рендеринга, правда именно трассировка пути наиболее затратная методика.

Необходимо также отметить, что трассировка пути – это наиболее простой, наиболее точный с физической стороны и наиболее медленный по производительности метод рендеринга. Методика трассировки пути наиболее естественным образом позволяет воспроизводить большинство оптических эффектов, тогда как при использование других методик рендеринга либо вовсе невозможно получение желаемых эффектов, либо весьма сложно [8].

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

Рисунок 3. Чтобы получить фотореалистичный рендеринг, необходимо сочетать несколько технологий. Трассировка лучей сама по себе недостаточна для симуляции сложных взаимодействий между материалами разных типов и света.

 Но, кроме перечисленных основных четырех методик, существуют и другие.

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

1. Метод трафаретных масок Основная идея метода заключается в использовании маскирования пикселей для разделения их на слои прозрачности [11]. При этом применяется тест и буфер трафарета. В буфер предварительно записываются номера выделяемых слоев прозрачности, а на этапе визуализации выполняется проверка текущих значений на равенство нулю. Если тест пройден, то значение перезаписывается на 255, если нет – уменьшается на единицу. Таким образом, в буфер цвета попадают только пиксели, соответствующие маскам слоев прозрачности. Пиксели различных слоев при этом записываются по соседству и образуют группы. В итоге, разрешение получаемого изображения получается меньше. Дополнительно используется еще один буфер. В него производится запись значения z-координаты (в пространстве наблюдателя) соответствующего пикселя.

Сохранение разрешения финального изображения обеспечивается за счет использования буферов большего размера, чем размеры формируемого кадра (применяется supersampling). В этом случае, N-кратное увеличение буфера результата растеризации позволяет выделять до N слоев прозрачности без потери разрешения. Далее, отдельным проходом постобработки, выполняется его чтение и сортировка. Полученные слои прозрачности упорядочиваются по z-координате, и значения их цветов смешиваются по формуле альфа-смешивания [12].

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

2. Метод динамических списков слоев прозрачности Рассматриваемый далее метод является более универсальным по сравнению с методом трафаретных масок [13]. Он не требует дополнительной фильтрации и использует меньше памяти под хранение слоев прозрачности. Экономия памяти достигается благодаря построению динамических списков поверх линейной памяти. Ее заполнение выполняется на этапе визуализации полупрозрачных объектов и реализует концепцию А-буфера (рис.4).

Рисунок 4. Правильная обработка эффектов прозрачности с помощью растеризатора требует использования сложных алгоритмов, например, A-буферов

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

Общая схема работы алгоритма построения динамических списков описывается следующими шагами:

• Атомарно увеличить счетчик занятой памяти.

• Атомарно обновить текущую ячейку буфера индексов начал списков предыдущим значением счетчика.

• Записать в память цвет, глубину и адрес следующего элемента, который соответствует предыдущему значению в текущей ячейке буфера индексов начал списков.

В качестве оптимизаций, используется один дополнительный буфер для хранения длины списка и память под требуемые буферы выделяется на видеокарте в виде объектов 2D- текстур [14]. Для доступа на запись используется технология UAV (unordered access view), входящая в состав DirectX версии 11. Кроме этого, для синхронизации операций между потоками, применяются атомарные операции. Использование метода на современном аппаратном обеспечении позволяет эффективно обрабатывать до 64 слоев прозрачности. В большинстве случаев этого более чем достаточно.

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

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

Среди игр, использующих рейкастинг, следует отметить Comanche 3 (1997), DeltaForce (1998) и Outcast (1999).

Рисунок 5 – Снимок экрана игры Outcast. Изображение получено

с помощью raycasting без использования графического акселератора

Только через несколько лет в играх, использующих растеризацию, стали возможны эффекты, которые присутствовали в Outcast: bump-mapping, shadows, depthoffield, reflections, self-occlusion, bloom.

Raytracing, несмотря на свою трудоёмкую с вычислительной точки зрения природу, сегодня переходит в разряд интерактивных методов визуализации [15]. Существуют рендеры, работающие в реальном или почти в реальном времени. Он всегда являлся одним из самых популярных методов, используемых в демосцене. В лабораториях Intel и NVidia созданы многопроцессорные машины, позволяющие достичь интерактивной частоты смены кадров при трассировке лучей.

Рисунок 6. Изображение с полупрозрачными объектами, полученное с помощью Araunareal-timeraytracer

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

Начиная еще с 2009 года, поскольку развитие  графических процессоров было поистине феноменальным, а точнее многократно увеличилась их многофункциональность и гибкость, стали разрабатываться и использоваться графические библиотеки “реального времени”, благодаря которым успешно используются мощности GPU для необходимых профильных расчётов. Обычно, такие визуализаторы реализуют освещение посредством метода трассировки лучей, а сама геометрия бывает представлена  не полигонами, а вокселями. Эти библиотеки предназначены для работы не только в компьютерных играх, но и в других весьма серьезных интерактивных и неинтерактивных приложениях, в том числе и для научных расчётов.

OptiX — это графические библиотеки “реального времени”, разработаны nVidia, и использующие CUDA, работающие только на графических процессорах производства nVidia и предназначены для различных исследований, вычислений и моделирований. «OptiX» – это гибридный рендер — основноее отличие которого – не только  использование трассировки лучей, но, также, присутствует и растеризация.

OctaneRender — графическая библиотека реального времени, разработанная компанией RefractiveSoftwareLTD, использующая CUDA и работающая на всех графических процессорах nVidia, начиная с 8Х00. Использует трассировку лучей idTech 6 будет использовать трассировку лучей и воксели.

Современные технологии производства метанола (СМ) основываются на его синтезе, главным образом, из смеси СО + СО₂ + Н₂  + инертные компоненты, на оксидных медьсодержащих низкотемпературных катализаторах при 200 – 290 °С под давлением 5,0 – 10,0 МПа. Синтез проводят в проточных многополочных реакторах, которые располагают в циркуляционных схемах [1]. Сложность процесса синтеза, наличие нескольких возможных механизмов и многих кинетических уравнений обусловливают альтернативные подходы к виду математической модели и способов ее решения.

Анализ литературы

На протяжении длительного времени считалось, что углерод в молекуле CH₃ОН происходит из молекулы оксида углерода (II) [2]. Однако в 1975 году Розовским А. Я. и Лин Г. И. [3] на основе фундаментальных исследований с помощью методов относительных селективности, меченых атомов, а также прямого эксперимента установлен иной макромеханизм процесса образования метанола, который не предусматривался классическими концепциями. Этими учеными доказано, а затем другими исследователями подтверждено: на оксидных катализаторах собственно СМ протекает путем гидрирования СО₂ (а не СО, как это считалось ранее) с образованием метанола и воды:

Наиболее популярными направлениями моделирования СМ является оптимизация работы реакторов, модернизация технологических схем и разработка систем управления промышленным процессом. Так, в работах зарубежных авторов [4 – 6] моделируется работа многотрубного и радиального реакторов СМ и изучается влияние изменения структуры потоков на производительность по целевым компонентом. Отметим также разработку системы управления процессом синтеза метанола с комбинированной моделью для внедрения на ОАО «Северодонецкое объединение Азот» [7].

Более близкими к нашему исследованию являются работы [8 – 11]. Работы [8 –10] содержат информацию об адаптации и использования одной из кинетических моделей образования CH₃OH из СО и данные о составе промышленного технологического газа. Кроме того, в работе [9] предложены варианты учета степени дезактивации катализатора и реконструкции установки с внедрением в технологическую схему реактора предкатализа. Авторы статьи [11] для расчетов использовали кинетическую модель, предусматривающую образование метанола из СО₂. Ими предложены и математически подтверждены незначительные модернизации технологической схемы и изменения направлений газовых потоков.

Постановка задачи

Наши расчеты основаны на модели авторов [3], что предусматривает образование метанола из СО₂. Уравнения скоростей СМ и конверсии СО в СО₂ имеют вид, соответственно:

где  W_M – скорость синтеза метанол, моль/(т∙с);

W_K – скорость образования диоксида углерода, моль/(т∙с);

m_кam – масса катализатора, т;

τ– время, с;

n_CH3OH , n_CO2 – количество вещества СН₃ОН и СО₂, соответственно, моль;

k_M , k_K – константы скоростей реакций образования метанола и диоксида углерода, моль/(т∙с∙МПа);

K₁, K₂ – константы равновесия стадий адсорбции СО₂ и H₂O, соответственно, МПа^‑1;

P_i – текущие парциальные давления участников реакций, МПа.

Материалы исследований

Задачей осуществляемого расчета является определение объема катализатора, необходимого для получения заданного выхода метанола. Первым шагом к решению этой задачи является определение времен контакта газовой смеси со слоями катализатора, необходимых для достижения определенного значения содержания метанола на выходе каждой из четырех полок. Эта цель достигается путем решения системы дифференциальных уравнений (1) и (2). Для проведения численного интегрирования этой системы необходимо осуществить математические преобразования с правыми и левыми частями этих уравнений таким образом, чтобы остались только два неизвестных (не считая время τ).

Одним из вариантов такого преобразования есть такой, при котором левые части составят выражения  dxCO2/dτ и dxCO/dτ, а все парциальные давления после знаков «равно» будут выражены через эти две степени превращения по диоксиду xCO2 и оксиду углерода xCO, соответственно.

Для реализации этого замысла выполняются следующие шаги:

- обе части уравнения (1) умножаются на массу катализатора m_кaт;

- из выражения текущего количества метанола, моль:

получаем: .

После подстановки полученного выражения в уравнение скорости образования метанола и деления обеих его частей на исходную концентрацию n⁰CO₂ получаем искомую левую часть:

Аналогичным образом проводим преобразования с кинетическим уравнением (2) образования СО₂. В результате получаем:

Текущие парциальные давления участников преобразований, если пренебречь изменением объема газовой смеси, выражаются через степени превращения СО₂ и СО следующим образом:

где  N_i⁰– молярные доли участников процесса в исходной смеси;

P– давление процесса, МПа.

Величины, фигурирующие в уравнениях (1) и (2), представляют собой количества (моль) СО₂ и СО, соответственно, контактирующих с катализатором в каждый момент времени  τ для заданного расхода газовой смеси и значений начальных концентраций:

,

где  R⁰CO₂, R – расход диоксида углерода и исходной газовой смеси, соответственно, при нормальных условиях, м³/с;

V_кат, m_кат, ρ_кат — соответственно объём, масса и насыпная плотность катализатора загруженного в реактор, м³, т, т/м³;

V_т — молярный объём идеального газа, м³/моль (V_т = 0,0224).

Выражение для количества  n⁰CO получено  аналогично:

После соответствующих замен в уравнениях (3) и (4) и несложных упрощений получаем окончательный вариант системы, который можно использовать непосредственно для расчетов:

где                                                          

.

Численное интегрирование полученной системы уравнений (10 – 11) с помощью функции MathCAD rkfixed дает возможность построить графики  xCO₂ = f(τ) и xCO = f(τ)  на одной координатной плоскости и N(CO2)= f(τ), N(H2) = f(τ), N(CH3OH) = f(τ), N(H2O) = f(τ),  N(CO)= f(τ) на другой. Из второго графика определяем время контакта, необходимое для обеспечения заданной объемной (молярной) доли метанола на выходе из полки.

По времени контакта рассчитывается объем катализатора на каждой из полок с учетом степени использования поверхности η, м³:

После этого, используя уравнения (5 – 9), рассчитываем состав (% об.) газа на выходах из полок. Значения степеней превращения берутся из таблицы результатов работы функции rkfixed – соответствующие определенному из графика времени контакта. Из-за пренебрежения изменением объема системы рассчитанная молярная доля метанола на выходе из полки может отличаться от ожидаемой концентрации. В таком случае надо корректировать значения времени и по тому же принципу найти новые значения степени превращения.

Результаты исследований

Проведен расчет по следующим исходным данным, при этом состав газа (табл. 1) по полкам взят из материального баланса, составленного авторами данной статьи: давление процесса, МПа – 5; насыпная плотность катализатора, т/м³ – 1,3; степень использования поверхности катализатора, доля – 0,5. Постоянные кинетических уравнений (10) и (11) при температуре синтеза 240 °С и при 30% степени дезактивации катализатора [3]:

k_M = 4,1 мкмоль СН₃ОН/(г кат-ра∙с∙МПа);

k_K = 4,15∙ мкмоль СО₂/(г кат-ра∙с∙МПа);

K₁ = 18 МПа^-1;  = 23 МПа^-1.

Таблица 1 – Исходные данные

Полученные результаты сведены в табл. 2. В статье [8] авторами приведены промышленные данные и данные собственного адекватного расчета работы установки М-750 ООО «Сибметахим», г. Томск. Эти данные (табл. 3) были использованы нами для апробации созданной программы на альтернативных исходных условиях синтеза. В табл. 3 приведены результаты проведенного нами расчета по вышеприведенному алгоритму и сопоставлены с литературными и промышленными данными.

Таблица 2 – Результаты расчета

Таблица 3 – Сравнение результатов собственного расчета с литературными и промышленными данными

Сравнение результатов расчета с промышленными и литературными данными [8] показывает возможность адекватного использования созданных нами алгоритма и программы.

Выводы

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

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

В данной работе рассматривается возможность разработки алгоритмов для реализации оперативного контроля за работой маслоохладителей и мониторинга за тепловым состоянием обмотки трансформаторов. В качестве примера взяты охладители трансформаторов ОРЦ-533000/500, используемые энергетической компанией на гидроэлектростанции.

Работа алгоритмов основана на анализе тенденции изменения исследуемого параметра.

Система охлаждения типа OFWF предназначена для отвода тепловых потерь трансформатора блока и состоит (на каждой фазе) из:

• 3-х маслоохладителей (2 рабочих, 1 резервного);
• 3-х электронасосов (2 рабочих, 1 резервного);
• пускового электронасоса;
• патрубков забора горячего масла из верхней части бака трансформатора;
• патрубков нагнетания охлажденного масла в нижнюю часть бака трансформатора.

Для обеспечения работоспособности и обслуживания системы охлаждения имеются:

• термометры и манометры для определения температуры и давления воды и трансформаторного масла на входе и выходе каждого маслоохладителя;
• абсорбционные фильтры для регенерации трансформаторного масла;
• фильтр очистки масла от механических примесей;
• шкафы питания и управления охлаждением (ШПОТ, ШОТ, ШОМ).

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

В данной работе представлено три алгоритма оперативного мониторинга и контроля:

• мониторинг за рабочим состоянием маслоохладителей;
• мониторинг за состоянием температуры обмотки трансформатора;
• слежение за состоянием давления воды и масла в каждом маслоохладителе.

Во всех алгоритмах величины уставок и задержек необходимо уточнить по результатам опытной эксплуатации.

Разработка алгоритма оперативного мониторинга за рабочим состоянием маслоохладителей.

Рисунок 1. Схема алгоритма оперативного мониторинга за рабочим состоянием маслоохладителей

Показания датчиков температуры нижних слоёв масла в баке трансформатора (Т_a) сравниваются с температурой уставки (Т_уст), которая выбирается из диапазона температуры масла при нормальном режиме работы системы охлаждения трансформатора. Температура масла у трансформаторов (с системой охлаждения OFWF) не должна превышать 70ºС [1, с. 8]. Ввод этой уставки необходим для реализации мониторинга тенденции изменения температуры в пределах нормальной работы, что позволит вовремя обнаружить зарождение дефекта и запланировать ремонт, предотвратив аварийный и внеплановый вывод оборудования. При превышении уставки проверяется наличие нагрузки на трансформаторах. При присутствии таковой, сравнивается температура на входе в маслоохладитель и выходе из него. По полученным результатам производится либо сброс сигнала, либо вывод его на монитор АРМ в виде сигнала «Неисправная работа маслоохладителей». Этот сигнал не является аварийным. Он предназначен для того, чтобы обслуживающий персонал обратил внимание на проблему в работе системы охлаждения трансформатора и успел вовремя разработать и предпринять ряд определённых действий, не допускающих перехода оборудования в предаварийное и аварийное состояние.

Принцип работы алгоритма изложен ниже. Для примера выберем фазу А. Показания датчика температуры Т_а сравниваются с температурой уставки Т_{уст а}. Если значение температуры, снятое с датчика не превышает уставку (логический «0»), сигнал сбрасывается через логический элемент «ИЛИ» в начало алгоритма. Если значение температуры выше или равно температуре уставки (логическая «1»), сигнал проходит к сумматору. Затем проводится проверка нагрузки трансформатора. Значение с датчика нагрузки (Р) сравнивается со значением уставки (Р_уст). Р_уст принимаем равное нулю. Если Р=Р_уст, сигнал сбрасывается через логический элемент «ИЛИ» в начало цикла. Если Р>Р_уст, сигнал проходит к сумматору.

Если выявлено, что трансформатор находится под нагрузкой и температура масла после прохождения маслоохладителей выше принятой уставки, проверяется разность температур масла на входе и выходе каждого маслоохладителя. Критерием нормальной работы маслоохладителя является снижение в нем температуры на 10ºС при номинальной нагрузке трансформатора [1, с. 15]. Исходя из этого, уставку принимаем равную 10ºС. При |ΔТ| ниже установленного критерия у всех охладителей подаётся сигнал «Неисправная работа маслоохладителей» на АРМ обслуживающего персонала, при учёте исправности всех датчиков. Если хотя бы один охладитель имеет приемлемое значение температуры охлаждающего масла, сигнал сбрасывается в начало алгоритма.

Разработка алгоритма мониторинга за состоянием температуры обмотки трансформатора.

Рисунок 2. Схема алгоритма мониторинга за состоянием температуры обмотки трансформатора

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

Принцип работы предложенного алгоритма представлен ниже. Температура обмоток трансформатора не должна превышать 100ºС. На каждой фазе блочных трансформаторов имеются индикаторы температуры (2 шт.) наиболее горячей точки обмоток, которые при достижении обмоткой температуры 105ºС действуют на сигнал, а при достижении обмоткой температуры 115ºС – на отключение трансформатора через МП защиты. Предлагается ввести уставку 80ºС.

Показания датчика температуры Т_об сравниваются с температурой уставки Т_уст. Если значение температуры, снятое с датчика не превышает уставку (логический «0»), сигнал сбрасывается через логический элемент «ИЛИ» в начало алгоритма. Если значение температуры выше или равно температуре уставки (логическая «1»), сигнал проходит к сумматору. Затем проводится проверка нагрузки трансформатора. Значение с датчика нагрузки (Р) сравнивается со значением уставки (Р_уст). Р_уст принимаем равное нулю. Если Р=Р_уст, сигнал сбрасывается через логический элемент «ИЛИ» в начало алгоритма. Если Р>Р_уст, сигнал проходит к сумматору.

Если температура обмотки, снятая с индикатора температуры, превысила уствку и трансформатор находится под нагрузкой, проверяется наличие изменения исследуемого параметра и определяется скорость этого изменения. Если скорость роста температуры меньше скорости уставки, сигнал сбрасывается через логический элемент «ИЛИ» в начало алгоритма. Если скорость изменения температуры больше или равна скорости уставки, импульс направляется к сумматору. Вместе с тем анализируется изменение контролируемого параметра. Текущее значение (Т_t.об) сравнивается с сохранённым значением (Т_с.об), выданным с задержкой по времени. Если разница температур превышает установленную ∆Т_об или равна ей, импульс проходит к сумматору. При ∆Т<∆Т_уст происходит сброс через логический элемент «ИЛИ» в начало алгоритма. Процесс сравнения повторяется заданное количество раз (n) с определённой задержкой по времени. Если данный процесс выявил рост скорости нагрева обмотки или рост температуры с постоянной скоростью, то с учётом исправности датчиков Т_об и Р подаётся сигнал «Ненормальное изменение температуры в маслоохладителе» на пульт управления. Это необходимо для того, чтобы обслуживающий персонал обратил на это внимание и успел разработать ряд действий для устранения неисправности, пока она не переросла в аварийный дефект.

Алгоритм слежения за состоянием давления воды и масла в каждом маслоохладителе.

Рисунок 3. Схема алгоритма слежения за состоянием давления воды и масла в каждом маслоохладителе

В системе охлаждения трансформаторного оборудования имеются барометры, предназначенные для измерения давления воды и трансформаторного масла на входе и выходе каждого маслоохладителя. При масловодяном охлаждении трансформаторов давление масла в маслоохладителях должно превышать давление циркулирующей в них воды не менее чем на 0,1 кгс/см² (10 кПа) при минимальном уровне масла в расширителе трансформатора [2, с. 93]. Исходя из этих требований и для обнаружения несоответствия до аварийного срабатывания системы защиты, примем уставку разности давлений равную 0,2 кгс/см² (20 кПа). При необходимости значение задаваемой уставки корректируется.

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

Работа алгоритма заключается в следующем. Значения с барометров Р_1м (давление масла) и Р_1в (давление воды) сравниваются в реальном времени. Затем полученную разность параметров сравнивают с ∆Р_уст (уставка превышения). Если разница между снятыми показаниями превышает уставку, сигнал сбрасывается в начало алгоритма. Если разница между снятыми показаниями меньше или равна уставке и датчики Р_1м и Р_1висправны, тогда после временной задержки подаётся сигнал на монитор АРМ «Ненормальное изменение давления в маслоохладителе».

Данный алгоритм можно применять как для контроля давления охлаждающих сред на входе в маслоохладитель, так и на выходе из него.

Выводы.

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

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

Применение предложенных алгоритмов позволит:

1) Повысить эффективность управления и исключить работу оборудования в режимах с перегревом масла или обмотки;

2) Выявлять дефекты системы охлаждения на начальных стадиях развития не доводя до предаварийного и аварийного состояния оборудования;

3) Уменьшить количество аварийных отключений оборудования.

Данная статья посвящена реализации алгоритма прямого вейвлет-преобразования, приведенного, например в работах [1-2], средствами пакета MathCad.

Сначала задано количество реализаций сигнала N и реализован “зашумленный” сигнал f, как показано на рисунке 1 .

Рис.1. Задание исходного сигнала.

Затем задан порядок фильтра n. Так как были выбраны вейвлеты Добеши, в функции Dobesh_hg(n), присваиваются коэффициенты h и g, в зависимости от порядка фильтра n.   Далее, для ускорения расчетов при прямом вейвлет-преобразовании, коэффициенты делятся на √2. Это реализовано в MathCad, как показано на рисунке 2.

Рис.2. Задание коэффициентов Добеши.

Затем в нулевую строку матрицы a1 заносим сигнал f, переменной kk, в которой хранится количество столбцов, присваиваем значение N, уровню m присваиваем значение 0.

Для случая n=2, пока элемент столбца 4n не равен нулю (это определяет наименьший размер сигнала, который можно восстановить), в цикле уменьшаем количество столбцов в два раза, в цикле по k находим коэффициенты аппроксимирующего сигнала a1 и детализирующего сигнала d1 (от 0 до kk-2 столбца) этого уровня разложения, в двух циклах по l находим последние элементы и увеличиваем номер уровня разложения. Реализация в MathCad приведена на рисунке 3.

Рис.3. Разложение сигнала при порядке вейвлета Добеши  n=2.

Если же n=4, аналогично в цикле уменьшаем количество столбцов,  в цикле по k находим элементы от 0 до kk-4 столбца, затем  находим последние три элемента и увеличиваем номер уровня разложения.

Возвращаются из функции коэффициенты a1,d1 и номер максимального уровня разложения m.

Рис.4. Разложение сигнала при порядке вейвлета Добеши  n=4.

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

а) исходный сигнал                                                                                                    б) разложение на уровне 1                                                        в) разложение на уровне 3

Рис.5. Разложение исходного сигнала на различных уровнях

К достоинствам данного алгоритма относится экономия памяти, так как нт необходимости хранить для вейвлет-преобразования всю разреженную матрицу, как это предлагается в [2] .  А также достоинством является решение задачи стандартными средствами MathCad, без использования расширения Wavelet Extension Pack этого пакета, предназначенного для работы с вейвлетами.