Научные вычисления: балансирование автономности и повторного использования? - PullRequest
10 голосов
/ 02 марта 2011

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

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

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

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

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

Ответы [ 2 ]

4 голосов
/ 02 марта 2011

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

  1. Подход "bazillion options"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

...