Як боротися із занадто великою кількістю даних?


14

Наші симуляції динаміки плазми часто дають занадто багато інформації. Під час моделювання ми фіксуємо різні фізичні властивості на сітці (x, y, z, t), розміром як (8192x1024x1024x1500), принаймні на 10 властивостей. Ця інформація обробляється після завершення моделювання. З ним ми

  1. робити фільми за властивостями,
  2. провести аналіз Фур'є,
  3. обчислити середні властивості.

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

Ми розпочали процес аналізу Фур’є на ходу і фільтрували лише вибраний діапазон шкал довжини. З числових причин нам іноді потрібно вирішити масштаби довжини, менші, ніж нас насправді цікавить, тому в цих випадках цей фільтр дуже допомагає. Ми також вивчаємо різні паралельні бібліотеки вводу- виводу, наприклад параметри паралельного вводу-виводу, зокрема паралельні HDF5 .

Які стратегії доступні для досягнення максимальної ефективності обробки даних?

Чи є якась користь виконувати весь аналіз (не включаючи пост-обробку, наприклад, фільми та сюжети) під час руху?

Я можу уявити, що це питання виникає в інших сферах досліджень. Наприклад, у вас може бути моделювання молекулярної динаміки, яке має розвиватися протягом тривалого часу, але вас цікавить короткий момент, коли відбувається щось цікаве. Або в CFD, ранній розвиток часу може бути повільним, але, коли виникне турбулентність, вам може знадобитися більш високий часовий дозвіл для моніторингу динаміки.

Чи є у вільному доступі приклади складного збору результатів від моделювання?


Це може здатися широким питанням. Якщо ви відчуваєте це так, будь ласка, підкажіть, як я можу бути більш конкретним.
Янн

1
Подивіться також, як деякі експериментальні групи справляються з цією проблемою. Фізика високої енергії (аль-ЦЕРН) та астрофізика можуть мати ще більші масштаби даних, що надходять, які потрібно зберігати (або навіть фільтрувати перед зберіганням, оскільки дані надходять швидше, ніж можна записати в будь-яке сховище), поширювати та аналізувати.
Брайан Діггс

Відповіді:


10

Я думаю, що вам, можливо, доведеться розділити результати, щоб відповідати вашим цілям:

  1. для фільмів властивостей вам, ймовірно, не потрібна повна просторова роздільна здатність та всі змінні. Уважно виберіть те, що ви хочете показати, і подумайте про остаточну роздільну здатність фільму, який ви будете показувати, він, ймовірно, не буде мати 8 мільярдів пікселів.
  2. Для аналізів Фур'є (або таких як POD), якщо вони тимчасові, ви, ймовірно, можете просто відібрати кілька сотень очок, мудро вибраних у вашому домені. Якщо вони просторові, вам, мабуть, потрібно лише кілька знімків, а не 1500. І знову ж таки, не для всіх властивостей.
  3. Для усереднення часу ви можете просто продовжувати додавати в те саме поле і не потрібно турбуватися про часовий вимір? Просторове усереднення болісно, ​​хоча, якщо ви хочете подивитися на його еволюцію з часом. Але більш обробка в Інтернеті перед скиданням даних може зменшити їх розмір ...

Це означає досить багато роботи, щоб мати виділені результати замість великого загального, але це повинно сприяти зменшенню витрат і розміру. Сподіваюся, це допомагає!

Ще одне, що я хочу додати, загалом повне дозвіл даних потрібне лише для перезавантаження файлів, тобто файлів для перезавантаження моделювання. Вам не потрібно стільки з них для даного моделювання (скажімо 100, так що якщо щось відбувається між двома перезапусками, ви втрачаєте максимум 1% ваших обчислень), тоді як ви, мабуть, хочете збільшити частоту виводу для свого фільми. І це можна зробити, наприклад, лише в 1/64-ій частині роздільної здатності (1 кожні 4 бали в кожному напрямку).


Чому просторове усереднення болісне? Просто зробіть це на ходу і запишіть результат, який повинен бути крихітним.
Девід Кетчесон

@DavidKetcheson Простірне усереднення є болісним, оскільки воно потребує великої кількості комунікацій і на нього може вплинути топологія вашого домену. Ні? Звичайно, якщо у вас чиста ортогональна сітка, вирівняна з вашим еталонним кадром, це не так вже й погано, але вам все одно доведеться зробити розумну комбінацію обчислень та MPI_REDUCE, оскільки з сіткою такого розміру ви не можете просто зробити ALL_REDUCE на 1 процесор Я б подумав ...
FrenchKheldar

1
Гаразд, зараз я розумію ваш коментар. Але спілкування, як правило, не надто погано, оскільки ви можете середньо оцінювати кожен процес на локальному рівні, а потім просто зменшити один проміжок за процес. На мій досвід (на 65K-ядерному BlueGene / P), вартість цього є тривіальною, особливо порівняно з витратами на введення-виведення. Насправді ми робимо ALL_REDUCE на цілих 65K ядер на кожному кроці, і це дуже швидко.
Девід Кетчесон

@DavidKetcheson Насправді я зараз думаю, що я неправильно зрозумів вашу думку, і я також завищував вартість зменшення даних. Я мав на увазі щось подібне до середнього / азимутального усереднення, де вам доведеться зберігати / виводити повні 2D дані, які можуть бути, а можуть і не знаходитися в тій же сітці, що і обчислювальна сітка. Але ви праві, фактична вартість MPI_ALL_REDUCE сама по собі не є проблемою.
ФранцузькийХельдар

8

Я думаю, що нинішні майстри цього мистецтва - це експерименти з фізики великих частинок (я найбільше знайомий з CDF та D0, тому що я старий і працюю в Чиказькому університеті). Вони мають апаратні тригери, які відкидають петабайт (або більше) на рік. Однак це вся тема квантування / дискретизації або "викидання лише того, що вам не потрібно". Я не впевнений, що ви можете дати розумну відповідь загалом. Було б краще звузити проблему до чогось типу: "У мене симуляція PDE дискретизується наступним чином і я б хотів ефективно зменшити вибірку".


3

Пітер ЛеПадж досить відомий у колах грат-QCD тим, що пропонує метод, за допомогою якого неможливо було б зменшити великі ґратчасті сітки шляхом пошуку та застосування хороших аналітичних рішень короткого діапазону.

Це приблизно рівнозначно, що помітити, що набір добре підібраних сплайнів може дозволити точну інтеграцію з меншою кількістю вузлів, ніж трапецієподібний метод (за винятком того, що, як у вашому випадку, ви зможете скористатися ним над чотирма розмірами одночасно).

Результат полягає в тому, що ви торгуєте необмеженим розміром набору даних для більшого обчислення на вузол - крок, але в кінці кінців виходите вперед через високу розмірність вашої проблеми.

Я не є предметом, якого я досить добре знаю, щоб давати будь-які гідні підказки, але він працював у деяких галузях раніше.


3

Питання трохи широке, тому я надам відповідно невиразну відповідь, яка підказує можливі методи в таких випадках.

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

2) Вибір більш збережених даних. На жаль, це дуже специфічно для ситуації.

3) Стислі дані перед зберіганням або використовуйте бібліотеку зберігання з інтегрованими параметрами стиснення, такими як HDF5.

4) Зберігайте регулярні контрольні пункти замість повного виводу. Якщо ви зберігаєте повну контрольну точку кожні N кроків, тобто достатньо даних для перезавантаження моделювання звідти, ви можете реконструювати відсутні дані в дуже паралельний спосіб, якщо і коли це необхідно. Зауважте, що у випадку методів Монте-Карло контрольна точка повинна містити стан генераторів випадкових чисел. Насправді ви можете вважати це методом стиснення, що дуже специфічний для додатків.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.