Розглянуто подальший розвиток сервісно-орієнтованого портального рішення для надання послуг метеорологічного прогнозування. Зокрема, виконано реалізацію тривимірного алгоритму вирішення задачі моделювання циркуляції атмосфери з використанням графічних прискорювачів в якості обчислювального пристрою як для чисельного розрахунку прогнозу, так і для його візуалізації. Ключові слова: паралельні обчислення, метеорологічне прогнозування, інтернет-портал, мережа, графічний прискорювач, візуалізація. Рассматривается дальнейшее развитие сервисно-ориентированного портального решения для предоставления услуг метеорологического прогнозирования. В частности, выполнено реализацию трехмерного алгоритма решения задачи моделирования циркуляции атмосферы с использованием графических ускорителей в качестве вычислительного устройства как для численного расчета прогноза, так и для его визуализации. Ключевые слова: параллельные вычисления, метеорологическое прогнозирование, интернет-портал, сеть, графический ускоритель, визуализация. The article deals with the further development of a service-oriented portal solution for providing meteorological forecasting services. In particular, the three-dimensional algorithm for solving the task of circulation atmosphere modeling was implemented using graphics processing units (GPU) as a computing device for forecast calculation as well as for its visualization.
Це обумовлено складністю математичних моделей, що описують циркуляційні процеси в атмосфері. Через наявність малого параметра при старших похідних ці рівняння можуть змінювати свій тип (еліптичний, гіперболічний або параболічний) залежно від режиму руху в атмосфері, що моделюється. Крім цього треба відзначити, що математична модель циркуляції атмосфери та процесів в ній, яка сформульована на базі повних рівнянь Нав’є-Стокса та тепло-масопереносу, описує широкий спектр рухів: мезомасштабні процеси, баротропні та бароклінні хвилі Росбі, інерційно-гравітаційні хвилі, квазістаціонарні струминні течії.
Просторова дискретизація з грубим розподіленням веде до того, що вплив багатьох мезомасштабних метеорологічних процесів втрачається, оскільки у такому разі вони опиняються у класі процесів підсіткового масштабу. Ресурси сучасних ЕОМ поки що не дають змоги здійснювати просторову дискретизацію моделі атмосфери з високим розподіленням. Крім того, значною проблемою при прогнозуванні погоди на основі реалізації математичних моделей є обмеження на час розв’язання, оскільки прогноз погоди потрібно отримувати завчасно. Навіть сучасні потужні обчислювальні машини не дозволяють використовувати дрібну просторову сітку в області розв’язання задачі і часову дискретизацію та ітераційні методи, що дало б можливість підвищити точність прогнозу.
Стан атмосфери в просторі r = (λ ,ϕ ,σ ) макромасштабної області G(r) ⊂ G(r) визначається вектором
ℜ(r,t) = (u,v, w,π ,T , q, qL , qW , k,ε ) дискретних значень аналізу і прогнозу ℜ(r,t m ) = ℜm (r), отриманих на основі
макромасштабної моделі в моменти часу t = t m (m =0,1,..., M ) з кроком τ = t m − t m−1 , де t – час; λ – довгота;
ϕ – широта; σ – приведена вертикальна координата, що відслідковує рельєф; u,v, w – складові швидкості
вітру по довготі, широті і вертикальній координаті відповідно; π = C p ( p p0 )R Cp – приведений тиск;
T – температура; q – вологість, qH – вологість у стані насичення; qL – вода у рідкому стані; k –
території G при ∀t ∈ [t m−1,t m ] виконується розв’язання задачі, що у векторному виразі має вигляд:
турбулентна кінетична енергія; ε – турбулентна дисипація. Для визначення стану атмосфери на обмеженій
∂ℜ = Dℜ , ∀t ∈[t m−1,t m ] , ∀r ∈ G ,
∂t
ℜ(r,t m ) = ℜm (r) , m = 0, 1,..., M .
(1)
Для розв’язання задачі (1) в роботі застосовується інтерполювання функції за декількома значеннями
самої функції (передісторією) та похідних від неї першого порядку за допомогою алгебраїчного поліному.
Використовується інтерполяція з кратними вузлами при кратності три. Виконується також апроксимація
правих частин диференціальних рівнянь моделі у вузлах просторової сітки. Детальний опис застосованого
чисельного методу наведено в монографії [
З метою підвищення точності прогнозу, що вимагає подрібнення просторової сітки в області
розв’язання задачі і часу дискретизації, було реалізовано систему прогнозування [
В рамках даної роботі з метою надання публічного доступу до користування цими розробками, було створено сервісно-орієнтований портал, що дозволяє користувачу отримати доступ до локального прогнозу погоди в межах території України.
Початкові дані об’єктивного аналізу стану атмосфери (тиск, температура, вологість та горизонтальні
компоненти вітру) для території Європи надано німецькою національною службою DWD Offenbach [
Поточна робота продовжує розвиток реалізованої раніше сервісно-орієнтованої системи
метеорологічного прогнозування [
Рис. 1. Схема розроблюваної системи метеорологічного прогнозування
У даній системі вирішено використовувати REST-сервіси [
Слід зазначити, що увесь «бекенд» системи розробляється мовою Java з використанням фреймворку
Spring [
Інтернет-портал реалізований за допомогою відкритого програмного продукту Liferay [
Сервіс надання метеорологічних прогнозів поділяється на декілька функціональних блоків, його схема зображена на рис. 2.
«Фронт-сервлет» – об’єднує обробку запитів шляхом їх направлення через єдиний об’єкт-обробник. Цей об’єкт реалізовує загальну поведінку, яка може бути змінена під час виконання за допомогою шаблону декоратор. Після цього «Фронт-сервлет» створює потрібні об’єкти відповідно до запиту та викликає методи для реалізації конкретної задачі. Запит по створенню задачі на прогноз повертає орієнтовний час очікування та ідентифікатор замовлення, через який можна буде отримати будь-яку інформацію про замовлення та його результат.
Рис. 2. Схема сервісу надання метеорологічних прогнозів «Черга задач» – блокуюча черга реалізована на базі LinkedBlockingQueue пакету java.util.concurrent, що реалізує алгоритм «two lock queue»: одне блокування на додавання, інше на діставання елемента. Елементи черги – це задачі, які відрізняються між собою типом задачі (розрахунок метеоданих чи генерація зображення). Для кожної задачі зберігається інформація про статус (“NOT_CREATED” – задача на прогноз очікує доступу до черги (в разі її заповнення), “IN_QUEUE” – задача перебуває в черзі на виконання, “IN_PROCESSING” – задача на прогноз виконується в даний момент, “READY” – готовий результат).
«Процесор задач» – реалізований на базі інтерфейсу ExecutorService з пакету java.util.concurrent бере на себе роботу по запуску і зупинці потоків. Дана реалізація в найбільшій мірі підходить для паралельного асинхронного обрахунку прогнозів. Розмірність пулу автоматично вважається як 100 % завантаженості GPU. Відповідно кожна із задач має орієнтовний відсоток навантаження на GPU, що вказується у конфігураційному файлі.
Після виконання задачі обрахунку метеорологічного прогнозу, автоматично створюється задача на генерацію зображення та кладеться у чергу задач. Після виконання задачі на генерацію зображення на диску зберігається тимчасовий файл зображення як результат прогнозування.
Сервіс управління метеорологічними прогнозами виконує функцію зв’язкового між порталом та сервісом із GPU. Окрім того він зберігає у себе на дисковій системі результати усіх замовлень, що дає можливість отримати їх вдруге вже без створення виклику на сервіс обрахунку метеорологічних прогнозів.
В рамках даної роботи проведено порівняння швидкодії тієї частини програми, що виконувалась на графічному прискорювачі, із відповідною частиною, виконаною на центральному процесорі.
Випробування проводились із використанням процесора Intel Core i5-2500 (у 64-бітному режимі) та графічного прискорювача NVIDIA GeForce GTX 560, що має наступні характеристики: • 336 stream-процесори (CUDA-ядра), базова частота 810 МГц; • обсяг глобальної пам’яті 1024 МБ; • базова частота пам’яті 2002 МГц.
Обчислення в експериментальній задачі для підрахунку часу виконання проводились для сіток локальних карт у вузлах просторової сітки розмірами 101×101×41, 111×111×45, 121×121×49, 131×131×53, 141×141×57, 151×151×61, 161×161×65, 171×171×69 та 191×191×77 частин. На рис. 3 показано графік залежності часу виконання обчислень послідовної та паралельної програм від розміру задачі (кількості вузлів розбиття розрахункової сітки). Відносне прискорення (відношення часу виконання послідовної до часу виконання паралельної програм, рис. 4) зростає від 11.6 для найменшої до 32.5 для найбільшої із роглянутих сіток. Таким чином, перехід на нову обчислювальну платформу з використанням GPU дозволив збільшити продуктивність виконання обчислень. Рис. 3. Графік залежності часу виконання від розміру задачі Рис. 4. Графік залежності відносного прискорення від розміру задачі 3. Візуалізація результатів обчислень
Існує чимало готових рішень для візуалізації масивів даних. Проте, провівши ретельний аналіз, можна стверджувати, що наразі відсутні он-лайн сервіси, які мають необхідну функціональність. Більшість представлених на даний момент програмних продуктів є платними рішеннями з закритим вихідним кодом.
Важливо зазначити, що масиви даних, отримані в результаті метеорологічного прогнозування, мають формат, що не відповідає існуючим програмних продуктам, а саме ці масиви містять лише значення досліджуваних величин в текстовому або бінарному форматі і не містять жодних координат. З урахуванням вище описаного, було створено новий програмний засіб, що дозволяє побудувати та візуалізувати такі об’єкти метеопрогнозування як ізолінії. Він виконує генерацію статичного зображення карти з нанесеними на неї позначками, за допомогою відеографічного прискорювача та зберігає його у файл. Для побудови ізоліній необхідно описати масив даних поверхні, а також вказати рівні ізоліній які необхідно побудувати. Ця інформація передається програмному засобу, що далі виконує алгоритм обчислення відрізків, які складають криву ізолінії. Потім необхідно візуалізувати ці відрізки на будь-якому доступному графічному пристрої, використовуючи певний графічний програмний інтерфейс.
Розроблене програмне забезпечення використовує OpenGL [
Більшість алгоритмів побудови ізоліній розглядають прямокутну сітку даних по чотири точки за один раз, а саме прямокутник з вершинами d(i,j), d(i+1,j), d(i,j+1), та d(i+1,j+1). Особливістю алгоритму CONREC є те, що центру кожного прямокутника присвоюється значення, що відповідає середньому арифметичному значенню чотирьох вершин, а кожен прямокутник, в свою чергу, ділиться на чотири трикутні області, отримані розрізанням уздовж діагоналей. Кожна з цих трикутних областей може бути розділена горизонтальною площиною ізолінії. Перетин кожного трикутника з площиною ізолінії є прямим відрізком – частиною кривої ізолінії на поточному рівні ізолінії. Також реалізовано оптимізацію шляхом початкової перевірки того, чи проходить певна ізолінія через поточний прямокутник, а вже потім перевіряється проходження ізолінії через кожен з чотирьох трикутників.
Для створення файлів зображень візуалізації метеорологічного прогнозу використовується бібліотека DevIL, що підтримує велику кількість форматів зображень. Проте доцільно використовувати BMP, PNG або JPG. Налаштування засобу візуалізації здійснюється за допомогою файлу конфігурації у якому, зокрема, вказуються такі параметри як кількість рівнів ізоліній, найменше та найбільше значення рівня ізоліній і т. ін.
В реалізованому засобі візуалізації використовуються шейдери двох типів – вершинні та фрагментні. Всього розроблено шість шейдерних програм – по одному вершинному та фрагментному шейдеру для візуалізації, ізоліній та текстури. В якості текстури використовується карта, наприклад, карта України чи світу. На рис. 5 показано результат роботи засобу візуалізації.
Рис. 5. Мапа 13 ізоліній в інтервалі від 15°C до 30°C Обраний підхід має як свої переваги, так і недоліки. Серед недоліків можна вказати його статичність та необхідність виконання запиту на генерацію і пересилку нового зображення при бажанні отримати прогноз для іншої області. Але серед переваг можна зазначити можливість формування зображення будь-якої складності та використання будь-яких об’ємів даних, нанесених на мапу. Аналогічна процедура для динамічного відображення у попередньому підході була б проблематичною через обмеження ширини каналу, об’єму доступної пам’яті, та значне навантаження на процесор клієнтської машини. Тому при виборі підходу відображення метеорологічних даних кінцевому користувачу потрібно виходити з поточних цілей донесення бажаної інформації та можливостей технічного забезпечення серверної та клієнтської сторін.
Рис. 6. Зміна метеорологічних показників у часі
У роботі розглянуто подальший розвиток реалізованого раніше сервісно-орієнтованого портального
рішення для надання послуг метеорологічного прогнозування [
Представлену систему реалізовано за допомогою сучасних провідних технологій, таких як інтернетпортали та мікро-сервіси. Завдяки сервісно-орієнтованій архітектурі вона інтегрує різноманітні незалежні сервіси.
В подальшому планується розвивати цю систему покращуючи її розширювальну здатність, додаючи нові сервіси, нові більш складні та потужні обчислювальні алгоритми та моделі та функціонально збагачувати існуючі сервіси.