Как бороться со слишком большим количеством данных?

14

Наши моделирования динамики плазмы часто дают слишком много информации. Во время моделирования мы записываем различные физические свойства в сетке (x, y, z, t), которая равна (8192x1024x1024x1500), по крайней мере, для 10 свойств. Эта информация обрабатывается после завершения моделирования. С этим мы

  1. снимать фильмы о недвижимости,
  2. выполнить анализ Фурье,
  3. рассчитать средние свойства.

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

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

Какие стратегии доступны для максимизации эффективности обработки данных?

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

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

Есть ли в свободном доступе примеры сложных результатов сбора результатов моделирования?

Yann
источник
Это может показаться широким вопросом. Если вы чувствуете это так, пожалуйста, дайте предложения о том, как я могу быть более конкретным.
Янн
1
Также посмотрите, как некоторые экспериментальные группы справляются с этой проблемой. Физика высоких энергий (al CERN) и астрофизика могут иметь еще большие масштабы поступающих данных, которые должны быть сохранены (или даже отфильтрованы перед хранением, поскольку данные поступают быстрее, чем они могут быть записаны в любое хранилище), распределены и проанализированы.
Брайан Диггс

Ответы:

10

Я думаю, что вам, возможно, придется разделить ваш вывод в соответствии с вашими целями:

  1. для фильмов свойств вам, вероятно, не нужно полное пространственное разрешение и все переменные. Тщательно выберите, что вы хотите показать, и подумайте об окончательном разрешении фильма, который вы будете показывать. Вероятно, он не будет иметь 8 миллиардов пикселей.
  2. Для анализа Фурье (или таких вещей, как POD), если они временные, вы, вероятно, можете просто выбрать несколько сотен точек, мудро выбранных в вашем домене. Если они пространственные, вам, вероятно, нужно всего несколько снимков, а не 1500. И опять же, не всех свойств.
  3. Для усреднения времени вы можете просто продолжать добавлять в одно и то же поле и не беспокоиться о временном измерении, верно? Пространственное усреднение болезненно, особенно если вы хотите посмотреть на его эволюцию с течением времени. Но больше оперативной обработки перед сбросом данных может уменьшить их размер ...

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

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

FrenchKheldar
источник
Почему пространственное усреднение болезненно? Просто сделайте это на лету и напишите результат, который должен быть крошечным.
Дэвид Кетчесон
@DavidKetcheson Пространственное усреднение является болезненным, потому что оно требует много общения и потенциально зависит от топологии вашего домена нет? Конечно, если у вас есть чистая ортогональная сетка, выровненная по вашей системе отсчета, это не так уж и плохо, но вам все равно придется сделать некоторую умную комбинацию вычислений и MPI_REDUCE, потому что с сеткой такого размера вы не можете просто сделать ALL_REDUCE для 1 процессор я бы подумал ...
FrenchKheldar
1
Хорошо, теперь я понимаю ваш комментарий. Но связь обычно не так уж плоха, так как вы можете усреднить по каждому процессу локально, а затем просто уменьшить один float на процесс. По моему опыту (на 65K ядре BlueGene / P) стоимость этого тривиальна, особенно по сравнению с затратами на ввод-вывод. Фактически, мы делаем ALL_REDUCE для целых 65K ядер на каждом временном шаге, и это очень быстро.
Дэвид Кетчон
@DavidKetcheson На самом деле, теперь я думаю, что я неправильно понял вашу точку зрения, и я также переоценил стоимость сокращения данных. Я имел в виду что-то вроде продольного / азимутального усреднения, где вам пришлось бы хранить / выводить полные 2D-данные, которые могут находиться или не находиться в той же самой сетке, что и вычислительная сетка. Но вы правы, фактическая стоимость MPI_ALL_REDUCE сама по себе не является проблемой.
FrenchKheldar
8

Я думаю, что нынешние мастера этого искусства - эксперименты по физике крупных частиц (я больше всего знаком с CDF и D0, потому что я стар и работаю в Чикагском университете). У них есть аппаратные триггеры, которые отбрасывают петабайты (или больше) в год. Тем не менее, это весь вопрос квантования / дискретизации или «выбрасывания только того, что вам не нужно». Я не уверен, что вы можете дать разумный ответ в целом. Было бы лучше сузить проблему до чего-то вроде: «У меня есть моделирование PDE следующим образом, и я хотел бы эффективно уменьшить выборку».

Мэтт Кнепли
источник
3

Питер Лепэйдж (Peter LePage) довольно известен в кругах решетчатой ​​КХД, поскольку он предлагает метод, с помощью которого невыполнимо большие решетчатые сетки могут быть уменьшены путем нахождения и применения хороших аналитических решений на короткие расстояния.

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

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

Я не являюсь предметом, который я знаю достаточно хорошо, чтобы давать какие-либо приличные подсказки, но в прошлом он работал в некоторых областях.

dmckee --- котенок экс-модератора
источник
3

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

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

2) Выбор сохраненных данных более тщательно. Это сильно зависит от ситуации, к сожалению.

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

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

khinsen
источник