软件开发，科学和生活中的中央原则之一就是“谦虚”。在软件开发中，这意味着你总是假设你的代码是错误的。它几乎从不与编译器，框架或其他东西吻合。大部分时间，它是你。这是它不是你的稀有病例之一。
与许多研究组一样，我们喜欢使用Compute Clusters in命令并行地进行复杂计算。我们的大学在一些额外的资源下提供了一个使用IBM Spectrum LSF.EMPLION各种专用命令的群集，此框架允许您与群集内存。例如，您可以提交一个新作业，该作业是在某些计算节点上执行的，具有一组副资源。尽管是个人喜好，但框架正处于非常伟大的作文会，任何人都可以将Python脚本或其他命令转换为在Checluster上执行的作业。作为一个简单的例子，这里是如何提交命令ls的：
这是在许多情况下的容易程度。如果需要更多高级呼叫，如果需要诸如内存或CPU内核的其他资源。在群集本身的配置上进行了配置，则可以为基于GPU的计算提供特殊节点，这是overopossbossible。但是，主要思想是，BSUB和LSF应该使您能够在Somenode的某个点运行'和忘记'工作。节点的确切选择无关紧要 - 或者我认为！
正如我们致力于截止日期，我注意到间歇性工作，但我并没有想到太多。有时，由于硬件问题，计算节点Lodown，因此始终存在概率，因此所有作业都可以正确执行。但是在Offyimportant的结果到期前几天，超过90％的工作开始失败。错误消息在我自己的一个警告之一之前（为清楚起见的文件名）：
快速检查显示该文件在那里;我也能够从其中一个登录节点中读取IT，因此我现在排除了FilePerMissions的任何问题。在代码中添加一些额外的跟踪，我发现它确实始终在尝试打开某种识别时始终失败。有问题的文件甚至不是非常大的 - 只是一个少数人，但在几乎所有情况下都是失败的。这是幽灵般的。我有一个heisenbugon我的双手，因为我无法在控制信因下重现它吗？
经过大量的哀号，哭泣和咬牙切齿，我决定更多地了解创建错误的函数。部分地，这个Wasto分散了我从即将发生的厄运，但我也很好奇在这里。我正在使用os.path.exists（）来查询文件的存在，所以我认为咨询其手册可能是一个智能理念。我发现了以下说明：
如果路径引用现有路径或打开的文件识别本，则返回True。返回虚假的符号链接。在某些平台上，如果未在物理存在的路径上，此函数可能会返回false。
这似乎暗示该函数可能返回错误的否则以指示无法访问该文件。我之前已经统治过突出的问题，但现在他们突然回到了菜单上。可能是这种权限间歇性改变吗？我被愚弄了intothing，登录节点上的权限与thecompute节点相同吗？我当然没有以任何方式改变权限，但是ASA最后一段努力我决定通过评估我的用户的一部分来编写一个检查Permissions的脚本。 Scriptlooked这样的东西：
＃！/ usr / bin / env for index $ $（seq 0 99）; do bsub -w 00:05 -o＆＃34; debug_％J.OUT＆＃34; -r＆＃34; rusage [mem = 128]＆＃34; Groupsdone.
请注意，我如何尝试提交大量工作，以便取消计算节点状态的清晰。我希望在群集中很好地分布在群集中，我焦急地审视了他们完成跑步。最后一份工作终于完成，我收集了我的结果：
但相反，我收到了不同群体的绝对热处理; Insome案件，我的用户是几乎没有群体的一部分。群集，就像我之前的几分钟一样，被打破了。这些新闻，严峻的哮喘可能是行政人员，为我来说，因为一次，一切都在宇宙中 - 有一个解释！就像Harlanellison的故事中的角色一样，我的标题我屠杀了这个拼点，我被电脑欺骗了。我没有群体，我必须欣赏。
与埃里森的故事不同，我的结局很好：调试脚本是支持人员的覆盖，问题在几天内纠正 - 直到它再次播种，导致较为少量的信息（已经到位了），并默认。这个时候真的。
我的个人课程来自所有这些：我需要训练我的功能。虽然我可以争辩说操作系统.Path.exist应该发生不同的行为 - 当我认为这将始终按预期工作时，所有的IT和所有人都会被调用，函数被称为。知道自己并知道你的职能，即使他们乍一看似乎很无害。