科学计算：平衡自足和重用？ [关闭]答案

【问题标题】：Scientific Computing: Balancing Self-Contained-ness and Reuse? [closed]科学计算：平衡自足和重用？ [关闭]
【发布时间】：2011-07-06 22:16:12
【问题描述】：

我编写科学研究代码，特别是在生物信息学方面。当然，在科学中，结果应该是可重复的。不定期参与项目并且不详细了解基础架构的人可能会合法地希望查看我的代码以重现结果。问题是使代码自包含足以轻松地向这样的人提供/解释似乎严重限制了可能的重用量。

将多个相关项目中使用的功能分解到个人库中通常很方便，但将所述库与 5,000 行（诚然文档不足，因为它不打算用于生产/发布）转储并不方便质量）与想要快速重现结果的人手头的问题无关的代码。
在您的系统上安装一组几个关键库并且无需三思而后即可使用通常很方便，但向主要是科学家而非程序员的人解释您的设置方式并不方便所有这些东西。如果您自己不记得某些细节，则尤其如此。（请注意，尽管所讨论的细节是与科学无关的技术细节。）
将研究项目的多个相关方面的所有代码保存在一个具有大量选项的大程序中通常很方便，而不是为您尝试的每个细微变化/事物编写完全独立的代码，但同样，将所有这些都转储给只想重现结果的人并不方便。

有哪些方法可以处理这些问题，以便我可以重用代码，但仍允许想要重现我的结果的人通过合理的努力来启动和运行我的代码？请注意，我的问题的核心是创建可重用代码库的可能性，但还不是很成熟。

【问题讨论】：

我喜欢这个……计算机科学中的经典问题……像艺术一样的主观部分。

标签： libraries scientific-computing readability maintenance

【解决方案1】：

这应该是cmets，但我不能把它们全部放在那个小盒子里……

我编写科学研究代码，特别是在生物信息学方面。当然，在科学中，结果应该是可重复的。不定期参与项目且不了解基础架构的人

您是在谈论编程方面的基础设施，对吧？

可能希望看到我的代码来重现结果。问题在于，让代码自包含足以轻松地向这样的人提供/解释似乎严重限制了可能的重用量。

我不明白。为什么他们不能重现结果？还是您的意思是说他们希望重用您的程序？

将多个相关项目中使用的功能分解到个人库中通常很方便，但将 5,000 行 (诚然文档不足，因为它不打算成为生产/发布质量）与手头的问题无关的代码，对于想要快速重现结果的人。

（除了“结果复制”，但这可能是我这边的语言问题）；问问自己有多少人会真正使用你的图书馆。如果像在许多情况下一样，只有一两个，那么我认为为了他们而改变它是不合理的。

我通常以适合我思维方式的方式制作库供我私人使用。为他们调整它，纯粹是为了他们的方便（即没有专门为此而获得报酬，我假设你不是）实际上是他们说“我不想写自己的，并且我不想思考你是如何创作的，所以去重构它，这样我就可以不假思索地轻松使用它。

在您的系统上安装一组关键库并随时可用通常很方便，无需三思而后行，但向主要是科学家而非程序员的人解释并不方便你是如何设置所有这些东西的。如果您自己不记得某些细节，则尤其如此。（请注意，尽管所讨论的细节是与科学无关的技术细节。）

将研究项目的多个相关方面的所有代码保存在一个具有大量选项的大型程序中通常很方便，而不是为您尝试的每个细微变化/事物编写完全独立的代码，但同样，将所有这些都转储给只想重现结果的人并不方便。

当然。 “科学编码”的问题（我多么不喜欢这种表达方式）是程序只是处理其他事情的过程中的一个工具，这意味着你正在制作它而不真正希望自我包含它，因为它是预期的随着工作的进行而修改。

有哪些方法可以处理这些问题，以便我可以重用代码，但仍允许想要重现我的结果的人通过合理的努力来启动和运行我的代码？

针对特定情况在 VCS 中对代码进行分支，然后为某人提供最接近他们需要的版本，这对我总是有用的。

【讨论】：

【解决方案2】：

我认为回答这个问题的一种方法是考虑科学编程世界中的其他工具如何做到这一点。我将把这个答案变成一个社区维基，人们可以用他们知道的代码添加到它；那么也许我们可以最终得到一个想法和示例列表，我们都可以用于这些事情。

“无数选项”方法
1. 具有大量菜单和子菜单的 GUI：
2. 带有许多参数的命令行工具，希望其中许多是可选的
  - 很多很多！使用PETSc 的工具使用它来控制他们的线性代数
3. 工具、命令行或其他方式，其配置文件包含许多希望是可选的参数
  - Gadget SPH 代码采用这种方法；
  - MESA 恒星演化也是如此
  - ADIOS parallel I/O library 也是如此，它使用 XML 作为配置文件。
UNIX 小工具方法 - 构建许多小工具，这些小工具可以串在一起构成复杂的工具。如果你的工具可以这样分解，那么效果很好。
- 分子动力学包Gromacs
- NEMO 恒星动力学工具箱
- 许多可视化包也以这种方式工作；在 GUI 中，定义了一系列小工具。 ParaView, OpenDX, VisIT
- 对于一般的 Python 计算，Ruffus 可用于将小工具组织到更大的工作流中
从例程中构建一个工具：这里的程序作为一个工具包分发，该工具包附带一个脚本（和一些示例），该脚本从零碎中构建了一个特定于问题的应用程序。
- FLASH 代码就是这样做的。
将功能公开为一个或多个可以链接到的库：
- 工具，通常是数学性质的，例如FFTW、PETSc、GSL...
与 3+4 相关：一种插件类型的方法，其中工具（通常但不总是 GUI）公开插件功能，可以轻松合并到更大的工作流程中
- 很多可视化包，比如ParaView
与 2 相关：该工具不是在命令行调用工具，而是有自己的命令行，可以在其中调用许多单独的例程；拥有自己的命令行允许您对环境进行更多的控制，而不仅仅是将其留给 shell（但当然，需要更多的工作）。
- 古老的 n 体可视化工具Tipsy
- 大量通用分析工具 - Octave、SciLab、IDL

【讨论】：

这是一个有趣的答案，但没有抓住重点。关键是：1.) 我的代码远没有这些项目那么成熟。 2.) 目标是了解它的工作原理，而不仅仅是将其用作黑匣子。
很多科学家都问过自己同样的问题；以上是他们答案的部分列表。这不是代码成熟度的问题，也不是“黑匣子”的问题（你不会并行使用 FLASH，或 ADIOS，Ruffus，甚至 ParaView/VISIT，将它们视为黑匣子）；这是一个以适合科学的有组织、可重构、可扩展、可理解的方式展示功能的问题。
更重要的是——这可以让你交出代码并说——“在这里；运行这个脚本（或这个设置），你会看到我得到的答案。”它们都允许最终用户尝试“..如果我尝试 this 会怎样？”。它们都可以非常清楚地了解使用了哪些代码，因此如果需要，他们可以只查看相关的代码。他们之所以允许这样做，是因为自从计算机普及以来，所有领域的科学家都希望用他们的工具来做这种事情。