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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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