Как отметить инструмент обработки научных данных для обеспечения воспроизводимости
мы разрабатываем инструмент обработки данных для извлечения некоторых научных результатов из данного набора необработанных данных. В науке о данных очень важно, чтобы можно было повторно получить результаты и повторить вычисления, которые привели к набору результатов
Так как инструмент развивается, нам нужен способ узнать, какой пересмотр/сборка нашего инструмента генерировал данный набор результатов и как найти соответствующий источник, из которого инструмент был сборкой.
Инструмент записан в C++ и Python; склеивание частей C++ с помощью Повышения:: Python. Мы используем CMake в качестве системы сборки, генерирующей Make-файлы для Linux. В настоящее время проект хранится в подверсии repo, но некоторые из нас уже используют мерзавца resp. hg, и мы планируем переместить целый проект в одного из них в самом ближайшем будущем.
Каковы лучшие практики в сценарии как это для получения уникального отображения между исходным кодом, двоичным и набором результатов?
Идеи мы уже обсуждаем:
- Так или иначе вводя глобальное число пересмотра
- Используя генератор номера сборки
- Хранение целого исходного кода в самом исполняемом файле
2 ответа
Это проблема, над которой я трачу много времени. К тому, что уже написал @VonC, позвольте мне добавить несколько мыслей.
Я думаю, что тема управления конфигурацией программного обеспечения хорошо изучена и часто тщательно практикуется в коммерческих средах. Однако этого общего подхода часто не хватает в средах обработки научных данных, многие из которых либо остались в академических кругах, либо выросли из них. Однако, если вы находитесь в такой рабочей среде, есть легкодоступные источники информации и советов, а также множество инструментов, которые могут помочь. Я не буду подробно останавливаться на этом.
Я не думаю, что ваше предложение о включении всего исходного кода в исполняемый файл является необходимым, даже если это возможно. В самом деле, если вы правильно понимаете SCM, то одним из важнейших тестов, которые вы выполнили и продолжаете делать, является ваша способность восстанавливать «старые» исполняемые файлы по запросу. Вы также должны быть в состоянии определить, какая ревизия источников использовалась в каждом исполняемом файле и каждой версии. Это должно сделать ненужным включение исходного кода в исполняемый файл.
Тема привязки наборов результатов к вычислениям также, как вы говорите, важна. Вот некоторые из компонентов решения, которое мы создаем:
Мы уходим от традиционного неструктурированного текстового файла, который характерен для вывода многих научных программ, к структурированным файлам, в нашем случае мы ищем в HDF5 и XML, в которых хранятся как интересующие данные, так и метаданные.Мета-данные включают в себя идентификацию программы (и версии), которая использовалась для получения результатов, идентификацию наборов входных данных, параметры задания и множество других вещей.
Мы рассмотрели использование СУБД для хранения наших результатов; мы хотели бы пойти по этому пути, но у нас нет ресурсов для этого в этом году, возможно, и в следующем. Но предприятия используют СУБД по разным причинам, и одна из причин - их способность выполнять откат, предоставлять контрольный журнал и тому подобное.
Мы также внимательно изучаем, какие наборы результатов необходимо сохранить. Хорошим подходом было бы хранение только исходных наборов данных, полученных с наших полевых датчиков. К сожалению, для выполнения некоторых наших вычислений требуется 1000 процессорных часов, поэтому невозможно воспроизвести их ab-initio по запросу. Однако в будущем мы будем хранить гораздо меньше промежуточных наборов данных, чем в прошлом.
Мы также значительно усложняем пользователям (я бы хотел думать невозможным, но я еще не уверен, что мы к этому пришли) непосредственное редактирование наборов результатов. Как только кто-то это сделает, вся информация о происхождении в мире неверна и бесполезна.
Наконец, если вы хотите узнать больше по этой теме, попробуйте поискать в Google похожие темы «научный рабочий процесс» и «происхождение данных».
РЕДАКТИРОВАТЬ: Из того, что я написал выше, не ясно, но мы изменили наши программы так, чтобы они содержали свою собственную идентификацию (мы используем возможности ключевых слов Subversion для этого с одним или двумя собственными расширениями) и пишем это в любой результат, который они производят.
Вам нужно рассмотреть git submodules из hg subrepos.
Лучшая практика в этом сценарии - иметь родительское репозиторий, который будет ссылаться на:
- исходные тексты инструмента
- набор результатов, сгенерированный этим инструментом
- в идеале компилятор c++ (не будет развиваться каждый день)
- в идеале дистрибутив python (не будет развиваться каждый день)
Каждый из них является компонентом, то есть независимым репозиторием (Git или Mercurial).
Одна точная ревизия каждого компонента будет ссылаться на родительский репозиторий.
Весь этот процесс является представителем компонентного подхода, и является ключевым в использовании SCM (здесь Software Configuration Management) в полной мере.