LINUX.ORG.RU

[C++][велосипедостроение] свои бинарные форматы хранения данных числ. моделирования vs hdf5?


0

2

Всех с многочисленными праздниками!

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

1) Многие умные люди советовали мне перейти на hdf5. Сейчас данные хранятся в виде: некий заголовок (тип контейнера, размерность и размеры, тип ячейки и т.д.) + с-но массив данных. То, что я про hdf5 знаю (чуть-чуть читал) говорит что я смогу средствами hdf5 организовывать заголовок... и с-но весь профит. Проблем с кроссплатформенностью пока нету, за пределы x86_64 лезть не собираюсь. Проблем записать/распарсить бинарный заголовок тоже как бы нет... хожу в задумчивости, а оно (hdf5) мне надо?

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

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

2) Описание ячейки массива. Я почти реализовал давнюю мечту - хранить в заголовке детальное описание структуры ячейки (хранятся данные вида «имя поля» - «тип поля» - «смещение от начала структуры»). Основной профит - при обработке можно оперировать этими самыми именами полей, и даже задавать некие ф-ии от них, скажем нарисуй ка мне 3D поле вида Ex**2+Ey**2+Ez**2. В hdf5 эти данные тоже можно упихать, но тут другой вопрос - а есть ли бол-мен стандартные решения для описания типов структур и послед работы с ними? Структуры могут быть тоже перекрученные, сожержащие другие структуры, массивы и и т.д. - но все POD ес-но.

★★★★★

Мне в свое время нравился netcdf3. Он проще и нагляднее hdf, как мне показалось.

basp ()

выбирай hdf5. там все что тебе надо есть. читай документацию с их сайта. с кросплатформенностью тоже никаких проблем работаю с hdf5 linux-64, windows-32, windows-64. на счет формата ячеечной топологии посмотри XDMF - xml-описание над hdf5. Этот формат понимает paraview и visit.

marat2345 ()
Ответ на: комментарий от basp

Netcdf4 использует hdf5. Это более высокого уровня библиотека.

Если необходимо хранить чисто массивы, то надо использовать netcdf. Если какие-то более сложные структуры, то hdf.

yvv ★★☆ ()

В общем я в глубоком недоумении - че делать то...

Можно взять и попробовать. Делов-то.

Причём вполне возможно что и более высокоуровневый netcdf подойдёт.

yvv ★★☆ ()
Ответ на: комментарий от marat2345

с кросплатформенностью тоже никаких проблем

Кроссплатформенность это последнее, что меня волнует;-) Кто нить пользовался описанием типов hdf5? Там такая развесистая клюква... с-но мне интересно, вот я описал там структуру ячейки массива, могу я потом каким нить стандартным вьювером отрисовать поле из результатов вычисления выражения для этой структуры? Прямо вот во вьювере ввести выражение (формулы) и получить картинку?

AIv ★★★★★ ()
Ответ на: комментарий от marat2345

Я понимаю. Hdf более низкого уровня, чем netcdf. Соответсвенно менее удобная в использовании, но имеет более широкую область применения.

yvv ★★☆ ()
Ответ на: комментарий от AIv

если ты будешь хранить результаты расчета в формате StructureOfArray(массив coord_x, coord_y, coord_z, coord_xyz, mass, strain11, ..) то никаких проблем + xml-описание XDMF. то в paraview можно посмотреть + там есть возможность создавать вычисляемые поля.

marat2345 ()
Ответ на: комментарий от marat2345

Ок, спасибо, посмотрю. Но с производительностью вопрос остается открытым...

Видимо я таки допилю свое (просто джаст фор фан + нужно что то рабочее таки иметь), а hdf5 буду осваивать в фоновом режиме. Меня там смущает избыточность, понятно что круто иметь произвольную древовидную структуру данных в файле, но если подумать... а нафига? Все таки есть файловая система, зачем дублировать ее возможности? Файл таки вещь с последовательным доступом (произвольный доступ не особо эффективен + проблемы при записи с выделением места). Т.е. я могу понять, когда в один файл ложатся друг за другом массивы для последовательных моментов времени, это удобно... но заводить древовидную шнягу я бы не стал.

AIv ★★★★★ ()
Ответ на: комментарий от AIv

задача: дано N процессоров M-времен выдачи результатов. решение 1: использовать формат VTK. Итого N*M файлов. решение 2: использовать HDF5 + XDMF. Итого N - файлов. каждый процессор пишет в свой файл, каждая выдача в свою подпапку, в папке куча массивов. меньше нагрузка на параллельную файловую систему. HDF5 очень прост, почитай example которые на сайте.

marat2345 ()
Ответ на: комментарий от yvv

на счет производительности HDF5. все американские и ЕС параллельные программы МКЭ расчета прочности используют либо HDF5+XDMF либо надстройку над ним - Silo, MED. да можно реализовать свой бинарный формат, но тогда надо писать программу визуализации. а зачем когда есть Paraview и Visit? сетки по 100 млн. ячеек для видеофайла на ПК можно без проблем создать. да на Python есть две реализации доступа к hdf5 :)

marat2345 ()
Ответ на: комментарий от marat2345

Дык мы так и делаем, и никаких проблем с объединением неск файлов для просмотра нету, все крайне просто... одна строчка в питоне. Не думаю что бы в hdf5 было проще (потому что проще уже некуда;-)).

Меня hdf5 привлекает в первую очередь возможностью юзать сторонние вьюверы/обработчики. С другой стороны, у себя я и так MathGL могу прикрутить (пока обходился, но как газ. динамика пойдет чую придется, лень для векторных полей че то свое писать).

А по производительности мои вьюверы как раз таки весьма шустренькие... вона ребята сваяли шкарный 3D вьювер для какой то медицины, GPU, все дела. Но массив 1000х1000х1000 не тянут;-)

AIv ★★★★★ ()
Ответ на: комментарий от AIv

в hdf5 каждый процессор может писать в свой файл а paraview/visit все сшивает для визуализации. для моих задач время счета >> время записи.

marat2345 ()
Ответ на: комментарий от marat2345

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

С-но вопрос то не втом писать свою библиотеку или не писать (она во первых уже есть, просто я ее сейчас кардинально перепиливаю, во вторых без нее все равно никак) - вопрос в том в каком формате данные на диске хранить. И тут я чем больше думаю, тем меньше вижу выгоды от hdf5. Ну лежит у меня неск массивов в hdf5, толку то, если в них данные локально рекурсивно расположены (и хорошо если просто лок-рек, а то бывает с подвывертом).

AIv ★★★★★ ()
Ответ на: комментарий от AIv

если расчеты для себя то наверно лучше использовать свой формат. если для заказчиков - для hdf5 существует много привязок для всех основных языков программирования. например если заказчику нужен график изменения какойто величины в какойто группе ячеек,узлов т.д. ему ненадо открывать файлы (Гбайты) в paraview, а просто пишет на Fortran/C/python/perl/ruby... и получает то что ему надо. либо использует EnsightGold, IDL...

marat2345 ()
Ответ на: комментарий от marat2345

У заказчиков (тех что хочут даные а не просто картинки) свои форматы, и никак не hdf5. Paraview погляжу, спасибо!

AIv ★★★★★ ()

я за hdf, пользовался в своё время - мне очень понравилось

shty ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.