Научные вычисления: балансирование автономности и повторного использования?

Я пишу код научных исследований, в частности, в области биоинформатики. Конечно, в науке результаты должны быть воспроизводимыми. Люди, которые не участвуют в проекте на регулярной основе и не разбираются в деталях инфраструктуры, могут на законных основаниях захотеть увидеть мой код для воспроизведения результатов. Проблема в том, что создание самодостаточного кода, достаточного для того, чтобы легко дать / объяснить такому человеку, кажется, сильно ограничивает количество повторного использования, которое возможно.

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

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

  • Часто удобно хранить весь код для нескольких связанных аспектов исследовательского проекта в одной большой программе с множеством опций, а не писать полностью автономный код для каждого небольшого варианта / варианта, который вы пробовали, но опять же, не удобно сбрасывать все это или объяснить все это кому-то, кто просто хочет воспроизвести результат.

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

Источник

2 ответа

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

  1. Подход "Bazillion Options"

    1. Графические интерфейсы с большим количеством меню и подменю:
    2. Инструменты командной строки с множеством аргументов, надеюсь, многие из них необязательны
      • Очень очень много! Инструменты, которые используют PETSc, используют это для управления своей линейной алгеброй
    3. Инструменты, командная строка или другие, которые имеют файлы конфигурации с большим количеством аргументов, которые, как мы надеемся, являются необязательными

  2. Подход UNIX для небольших инструментов - создание множества маленьких инструментов, которые можно объединить для создания сложных инструментов. Хорошо работает, если ваши инструменты могут быть разложены таким образом.

    • Молекулярно-динамический пакет Gromacs
    • Панель инструментов звездной динамики NEMO
    • Многие пакеты визуализации также работают подобным образом; в GUI определяется набор небольших инструментов. ParaView, OpenDX, VisIT
    • Для общих вычислений на Python Ruffus можно использовать для организации небольших инструментов в более широкий рабочий процесс.

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

    • FLASH- код - это тот, который делает это.
  4. Предоставление функциональности в виде одной или нескольких библиотек, которые могут быть связаны в:
    • Инструменты, часто математические по своей природе, такие как FFTW, PETSc, GSL...
  5. Относится к 3+4: подход типа плагина, где инструмент (часто, но не всегда, GUI) предоставляет функциональность плагина, которая может быть легко включена в больший рабочий процесс
    • Много пакетов визуализации, таких как ParaView
  6. Относится к 2: Вместо инструментов, вызываемых из командной строки, инструмент имеет свою собственную командную строку, в которой можно вызывать множество отдельных подпрограмм; наличие собственной командной строки позволяет вам осуществлять немного больший контроль над окружением, чем просто оставить его оболочке (но, разумеется, требует больше работы).
    • Почтенный инструмент для визуализации n-body Tipsy
    • Множество инструментов общего анализа - Octave, SciLab, IDL
Источник

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

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

Вы говорите об инфраструктуре здесь, в программировании, верно?

в деталях может законно захотеть увидеть мой код для воспроизведения результатов. Проблема в том, что создание самодостаточного кода, достаточного для того, чтобы легко дать / объяснить такому человеку, кажется, сильно ограничивает количество повторного использования, которое возможно.

Я не понимаю Почему они не смогут воспроизвести результаты? Или вы хотели сказать, что они хотят повторно использовать ваши программы?

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

(кроме "воспроизведения результатов", но это может быть языковой проблемой на моей стороне); Спросите себя, сколько людей на самом деле собираются использовать ваши библиотеки. Если, как это во многих случаях, только один или два, то я не считаю разумным менять это ради них.

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

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

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

Конечно. Проблема с "научным кодированием" (насколько мне не нравится это выражение) заключается в том, что программа - это всего лишь инструмент в процессе работы над чем-то другим, то есть вы делаете это, не желая фактически содержать его, поскольку это ожидается быть изменены по мере продолжения работы.

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

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

Источник
Другие вопросы по тегам