LINUX.ORG.RU

Как храните результаты расчётов и экспериментов?

 , ,


0

2

Привет, вопрос к исследователям и им подобным. Когда запускаете бенчмарки, расчёты, вычисления - то обычно накапливается куча файлов с результатами, всякие логи и т. п. Легко в них запутаться или что-нибудь потерять. Как решаете проблему?

Сейчас пишу скрипты, которые запускают расчёты с разными параметрами, а потом всё раскладывают по нужным каталогам. И с помощью rsync синхронизирую каталогопомойку между машинами. Но это как-то колхозно. Есть ли какие-то стандартные workflow и стандартные инструменты? Что-то вроде БД, в которую всё складывается, и в которой можно всё легко найти по ключам или фильтрам. И какая-то запускалка, которая сама всё складывает в БД. И чтоб была какая-то распределённая репликация, примерно как в DVCS. И в идеале чтобы можно было через 10 воспроизвести расчёт одной командой типа «experiment rerun 2004-12-14-09-23», а не впоминать две недели, как там звёзды лежали во вторник 14 декабря 2004 года. Короче, рассказывайте, как у вас всё круто автоматизировано.

P.S. Я джва года жду такую тулзу.

Мне всегда хватало батникоподобных настроек. В смысле не «experiment rerun 2004-12-14-09-23», а «/home/experiment/2004-12-14-09-23/run». С другой стороны мне не приходилось запускать с разными параметрами из скрипта, новый запуск = «cp -a /home/experiment/template /home/experiment/$DATE; cd /home/experiment/$DATE; vi run; ./run».

Поиск через grep «^VAR=» /home/experiment/*/run. Или grep по промежуточным результатам.

С БД проблема в том, что никогда не знаешь, что может понадобиться. Разложишь параметры запуска по колонкам, а потом понадобится найти по какому-то условию в промежуточных расчётах. К файлам можно и одноразовую программку прикрутить, если даже grep'а не хватит, а БД в такой ситуации дампить придётся целиком.

Кроме того параметры в виде массивов очень плохо на колонки ложится

monk ★★★★★
()

Короче, рассказывайте, как у вас всё круто автоматизировано.

Максимально, т. е. никак. На одном из используемых кластеров меня просто забанят за автоматизированный «experiment rerun». Просто помойку не развожу и все. Когда результаты в файлах (особенно бинарных и >гига штука), то база нахрен не нужна. «впоминать две недели, как там звёзды лежали во вторник 14 декабря 2004 года» незачем, так как в каждой директории есть конфиг, с которым считал + параметры для генерации входных данных. Запутаться нелегко, потерять тоже, проблемы нет.

t184256 ★★★★★
()

P.S. Я джва года жду такую тулзу.

а корованов всё нет ?

зы. у меня создалось устойчивое впечатление что каждая группа сама себе под свои задачи и особенности делает некие decision cube, и все довольны. А потом набигают всякие из ентерпрайз и результаты становятся хламом, но доступным по какому-нить rest из облаков.

MKuznetsov ★★★★★
()

как движение в сторону

http://www.nature.com/nature/journal/v482/n7386/full/nature10836.html

крайне эффективно работать с помощью техники «Литературное программирование», она сразу позволяет и автоматизировать все процессы и сохранить ход и логику проводимой работы.

как средство ведения можно например использовать org-mode babel

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

вовсе не в сторону, а очень даже по теме:

reproducible research, и вообще google://«reproducible research»

курс на Курсере

а org-mode babel да, наиболее простой из вариантов организации такой штуки. например, вот описание настроек — статья и репозиторий «replication materials» (здесь org-mode babel запускается через емакс, который запускается в batch mode, через главный Makefile, хотя в общем-то можно и сам Makefile генерировать из главного «литературного» грамотного org-файла) .

anonymous
()

Да, это жесть. Хорошо, если надо прошлогоднее поднять. И то иной раз проблемы бывают. А 2-3 и больше лет давности — бесполезняк. Не найти никак в тоннах файлов нужные ☹

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

Результаты надо для воспроизводимости хранить в виде образов VM. Других вариантов нет вообще.

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

образ памяти интерпретатора не всегда воспроизводим из исходных данных :) основная проблема разработки через slime

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