`

СПЕЦІАЛЬНІ
ПАРТНЕРИ
ПРОЕКТУ

Чи використовує ваша компанія ChatGPT в роботі?

BEST CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Научные вычисления: архитектуры, форматы, инструментарий. Часть 4

+11
голос

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

Говорить о программах научного назначения можно очень серьезно. Им можно посвящать масштабные монографии и даже тематические периодические издания. Но есть и еще одна точка зрения, игнорировать которую нельзя. К сожалению, за прошедшие 10--15 лет ее сторонникам приходилось трудно, по крайней мере, у нас. "Entertainig science" -- вполне четкое определение, данное этой точке зрения в Корнельском университете. Наука -- как бесконечная игра, захватывающая неисчислимым количеством вариантов, непредсказуемой сюжетной линией и "красотой, целостной и всеобъемлющей", но в то же время подчиняющаяся весьма строгим правилам, строгость которых ни в коей мере не ограничивает полета фантазии "игрока". Возможно, сложность игр в мире "Entertainig science" и слишком высока, как и велика цена, которую платят игроки за право участия (измеряющаяся годами учебы и работы)... но разве настоящие удовольствия бывают дешевыми или бесплатными?


Хрустальный шар

Научные вычисления архитектуры, форматы, инструментарий. Часть 4
Максимально упрощенная техника программирования, универсальность встроенных алгоритмов обработки и независимость от класса задач и типов используемых данных -- главные требования к системе научной визуализации
Визуализация научных данных -- область, в которой хорошая программная система играет роль магического хрустального шара, неотъемлемого атрибута всех магов и волшебников, в нем при желании и соответствующей подготовке можно увидеть чуть ли не все, что творится во Вселенной. Естественно, системы научной визуализации подразумевают существование этой Вселенной -- для них она образована на основе результатов расчетов, моделирования, экспериментальных данных. Груды цифр, порожденные вычислительными и натурными экспериментами, таят в себе скрытые знания, позволяющие обоснованно принимать решения, добиваться "малой кровью" улучшения показателей технических систем и даже решать масштабные экологические, социальные и политические проблемы. Но, с одной стороны, "перекапывать" вручную миллиарды цифр для того, чтобы выявить скрытые в них закономерности или особенности, -- задача не то чтобы не из простых; в большинстве случаев она просто неразрешима без применения технологий визуализации. И, естественно, разработчики научного ПО такие технологии использовали практически всегда: включали в свои программы уникальные модули визуализации, каждый раз разрабатываемые "под задачу".

Как и в программах пользовательского назначения, где интерфейсная часть отнимает 90% времени разработки и требует знания программистом сложных библиотек поддержки пользовательских интерфейсов, в научном ПО модули визуализации также были и есть одними из самых сложных и дорогостоящих в реализации. По мере развития инструментальных средств, формирования разнообразных стандартов (в первую очередь связанных с распространением 3D-графики) создание модуля визуализации превращалось в задачу исключительно высокой сложности, решение которой в разумные сроки и при разумных затратах недоступно "обычным" ученым, использующим компьютер как инструмент.

Возникло противоречие, требовавшее некоторого компромисса между желанием "пользователей" создавать примитивные в реализации, но сложные в математических основах алгоритмики расчетные модули и недоступностью этим "непрограммирующим программистам" процессов разработки задач визуализации. Приблизительно по таким причинам и были созданы "магические хрустальные шары" -- мощные комплексы визуализации данных. Существует несколько развитых реализаций таких программ, но в соответствии с критериями отбора, представленными в первой части статьи, автором выбрана только одна система такого класса -- OpenDX, основанная на "освобожденных" корпорацией IBM исходных текстах знаменитой системы визуализации IBM Data Explorer бесплатно доступная разработка.

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

Такое удачное сочетание встречается крайне редко, что подтверждают столь модные массовые обсуждения (осуждения?) насущной темы "Why (Most) Software is so Bad?" ("Почему большинство программ настолько плохи?").

В основе проекта OpenDX лежит развитая концептуальная база -- тоже не частое явление для большинства даже весьма удачных программных проектов. Главная концепция OpenDX, "концептуальная модель процесса визуализации", является результатом продолжительных серьезных исследований (если судить по цитированию, они были начаты еще в 80-х годах). Упрощенно "концептуальная модель" OpenDX состоит из ряда "подмоделей" -- представления данных, принципов пользовательского и интерактивного взаимодействий, вычислительных основ, коммуникационной инфраструктуры, модели высокоуровневого дисплея. Ничего принципиально нового в такой декомпозиции нет за исключением одного важного факта: до появления OpenDX (точнее, IBM Data Explorer) визуализационные программы создавались на основе "слоистой" (layered) архитектуры, каждый из слоев которой овеществлял соответствующую "подмодель". При таком подходе можно было добиться определенной функциональности конкретной реализации, но вот решение проблемы наращивания функциональности во время эксплуатации системы становилось слишком сложным. Создатели Data Explorer пошли по другому архитектурному пути -- в этой системе реализации "подмоделей" представляют собой отдельные почти независимые компоненты. Благодаря удачно выбранной архитектуре, несмотря на сложность, Data Explorer стал долгоживущей разработкой, не утрачивающей своей актуальности.

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

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

Импорт данных -- настолько важная операция, что в Data Explorer для нее выделена специальная отдельная подсистема, позволяющая преобразовывать во внутреннее представление, пригодное для дальнейшей обработки, как файлы в стандартных научных форматах (мы о них вкратце говорили -- HDF и NetCDF), так и электронные таблицы, изображения и даже "просто файлы" (raw data) -- результаты выполнения сторонних расчетов.

Научные вычисления архитектуры, форматы, инструментарий. Часть 4
Неказистый вид пользовательских интерфейсов утилит LASSPTools не должен вводить в заблуждение: идея этого пакета намного обогнала свое время, и, судя по ряду современных разработок, она завоевывает все больше симпатии разработчиков научного ПО
Программа визуализации в Data Explorer задается именно программой на специальном высокоуровневом языке, но для упрощения взаимодействия с пользователем система поддерживает режим визуального программирования, при котором "пользователь" оперирует не исходным текстом, а блок-схемой, задействуя в ней доступные обрабатывающие модули, соединяя их и настраивая параметры обработки каждого модуля с помощью ассоциированных меню. Эта подсистема Data Explorer получила название VPE -- Visual Program Editor. Не забыты и создатели собственно модулей: для них, соответственно, существует и развитая поддержка разработки новых модулей, составляющих основу языка визуализации.

Отображение результатов -- самая важная, финальная подсистема Data Explorer, при работе с которой и происходит то, что в науке называется "Ага!", -- озарение, открытие, получение новых знаний. Соответственно, в реализации этой подсистемы соблюдено одно главное правило -- простота взаимодействия. Интерфейс здесь минимален, точнее -- разумно достаточен.

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

Но некоторым нюансам все же стоит уделить внимание. Во-первых, количество "ключевых слов" языка описания программ визуализации -- модулей -- в доступной реализации OpenDX исчисляется почти сотней. Все они разбиты на 14 категорий, отражающих практически все "подмодели" концептуальной модели визуализации, -- здесь есть категории, связанные и с доставкой, и с импортом данных, и с промежуточной их обработкой (DXlink, Import and Export, Structuring), ответственные непосредственно за визуализацию (Transformation, Realization, Rendering...), и, наконец, служебные. Каждый модуль, кроме программной реализации, визуального представления в виде пиктограммы с выделенными "портами" (графическими моделями интерфейсов программной реализации модуля), содержит встроенный конфигуратор с графическим пользовательским интерфейсом и информативной подсистемой подсказок.


Собирая воедино...

Научные вычисления архитектуры, форматы, инструментарий. Часть 4
Редактор визуальных программ VPE, два окна управления отображением и собственно окно визуализации -- основные элементы пользовательского интерфейса OpenDX
Как уже говорилось ранее, этот цикл статей ни в коей мере не претендует (и не может претендовать) ни на объективность, ни на исчерпывающий характер. И все же к завершающей части мы подходим с некоторым багажом пусть не знаний, но представлений о реально работающих, доступных и надежных программах различных классов, в той или иной мере соответствующих неопределенному термину "ПО научного назначения". Пришло время подвести итоги, а точнее, -- обозначить направление, позволяющее с минимальными затратами, эффективно и относительно просто собрать эти разрозненные представления в нечто целое -- одновременно достаточно удобное и универсальное, но дающее возможность решать вполне конкретные задачи.

Восстанавливая в памяти "пройденное", можно сказать, что путь к достижению такой цели становится вполне очевидным -- максимально "нейтральные" по отношению к уже готовому ПО программные шины (например, Glish), языки быстрого прототипирования/отладки алгоритмов (такие, как Nickle), компактные и удобные расчетные пакеты со встроенной графической подсистемой (Yorick) и, наконец, мощные инструменты визуализации подсказывают вполне очевидный путь. Но вместо высказывания собственных соображений о нем автор обращается к опыту отличной разработки -- пусть несколько устаревшей (она была создана еще до массовой популярности открытых бесплатных Unix-совместимых ОС -- основных массовых инструментальных операционных систем в современной научной среде -- и даже до Internet), но наглядно демонстрирующей возможности и преимущества принципа "простые инструменты + механизм интеграции" в ПО научного назначения.

Речь идет о реализованном в рамках негласного проекта "Entertaining science" в Корнельском университете пакете LASSPTools. Несмотря на преклонный возраст, он до сих пор актуален и сегодня способен работать не только на классических Unix-платформах, но и под управлением ОС Linux и Free/NetBSD.

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

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

Утилитарный набор в LASSPTools достаточно велик: в него входят отдельные программки, например имитирующие аналоговые регуляторы (верньеры, регуляторы и пр.), программы промежуточной обработки (фильтрации) данных, вычислительные утилиты, набор простых "визуализаторов". Как уже говорилось ранее, особенность каждой утилиты LASSPTools -- ее полная независимость и пригодность к самостоятельной работе, при этом обмен данными осуществляется только с помощью простейших базовых механизмов ОС, в данном случае -- с помощью pipes (каналов или "труб"). В первой части статьи мы познакомились с программной шиной (ПШ) Glish и даже с простым примером, позволяющим создать элементарную "облатку" (скрипт), превращающую независимое приложение в элемент распределенной Glish-инфраструктуры. Именно так можно поступить со всеми утилитами LASSPTools, расширив возможности этого и без того не скудного пакета до уровня серьезной среды обработки данных. Интересно, что начальное допущение разработчиков LASSPTools -- "замедленность" реакции системы на действия пользователя -- сегодня практически не играет никакой роли: обеспечиваемая современными программными шинами скорость обмена сообщениями (несколько тысяч в секунд) слишком высока для возможностей человека...


Ресурсы

В четырех статьях нам удалось поговорить только о нескольких достойных научных программах. На самом деле их несоизмеримо больше. Детальный каталогизированный перечень научных программ находится на сайте sal.kachinatech.com ("Научные приложения для Linux"). Библиография по тематике программных шин собрана на странице www.cs.caltech.edu/%7Eadam/isen/event-systems.html, проект Glish располагается по адресу www.cv.nrao. edu/glish/, кроме него, стоит обратить внимание на очень хорошую реализацию программной шины Schooner (www.cs.arizona.edu/schooner/), изящную, использующую для адресации содержимое сообщения ПШ Elvin, и, наконец, на популярную в научном сообществе ПШ XPA (hea). Язык быстрого прототипирования Nickle доступен по адресу nickle.org, а более мощная языковая среда Yorick -- на ftp-сайте ftp-icf.llnl. gov/pub/Yorick/doc/index.html. Существует и обновленная реализация Yorick, разработка которой активно продолжается, -- Yorick-mb, обладающая рядом интересных особенностей, и программа, объединяющая достоинства Yorick с возможностями интерпретируемого языка Tcl и его графической подсистемой, -- Tk (sourceforge.net/project/showfiles.php?group_id=42998). Сайт проекта OpenDX, отсюда можно загрузить как исходные тексты самой "свежей" версии системы, так и исполняемые файлы для разных платформ. Инструментальный набор LASSPTools доступен с сайта Корнельского университета www.lassp.cornell.edu/LASSPTools/LASSPTools.html.

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365

+11
голос

Напечатать Отправить другу

Читайте также

 

Ukraine

 

  •  Home  •  Ринок  •  IТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Мережі  •  Безпека  •  Наука  •  IoT