使用HPC进行生物医学建模的实际挑战

精准医学的基本概念是通过了解个体患者特征的影响，可以改善癌症等病理的预防，诊断和治疗。预测医学寻求通过机制模型得出这种理解，该模型描述了特定个体内疾病的原因和（潜在的）进展。这代表了计算生物医学的巨大挑战，因为它需要将高度变化的（并且可能是巨大的）定量实验数据集整合到复杂生物系统的模型中。

越来越清楚的是，这种挑战只能通过使用结合了不同分析的复杂工作流程来解决，而且由于对预测的了解，其设计必须伴随对不确定性的估计。通常，这种工作流程中的每个阶段都具有非常不同的计算要求。如果资助机构和HPC社区认真支持这种做法，他们必须考虑便携式、持久性和稳定性工具，这些工具旨在促进这些工作流程的广泛长期开发和测试。

从模型开发人员的角度来看，界面和超级计算机政策的巨大差异可能是创新最大的障碍。

计算生物医学的介绍
计算生物医学的目标是从人类生物学的复杂数学模型中获得见解，能够发现新疗法和改进现有疗法。这项工作包括从大范围的时间和空间尺度的整合数据。在精确医学的背景下应用这种建模需要在模型中包括足够的细节以区分个体患者。分化的来源取决于感兴趣的疾病和正在考虑的干预类型。

例如，脑肿瘤中存在的突变极有可能影响药物的选择，同时对手术切除肿瘤的效果影响较小。在这里，我们认为在这个多变且具有挑战性的领域中开发仿真和建模不仅仅是方法开发，还可以提高代码性能和可扩展性。科学家们首先概述计算生物医学所面临的具体问题，并将它们置于HPC生态系统的背景下，来表明对医学工作的影响（脑血流和小分子药物选择）。

需要处理大量不同的数据

指定感兴趣的系统所需的数据可以跨越许多数量级的尺寸，并且参数维度可以同等地变化。 这自然导致输入的预处理和随后的模拟之间的计算要求非常不同。许多计算建模工作输入数据的预处理可能与模拟本身一样或更多，在计算上要求很高。此外，自动化需要可靠的数据清洁应用，以及在检测到“坏”数据时（具有临床或实验用户可理解的错误消息）早期和早期失败的能力。

复杂的工作流程

典型的生物医学模拟不是一个步骤，而是完整的工作流程，摄取数据和预处理以指定感兴趣的系统，然后进行大规模模拟，最后进行分析。这种有向非循环工作流程作为计算的基本描述是常见的，但是以稳健的方式处理不确定性量化，自适应采样或模型失效可能导致更复杂的工作。

经历挑战的多样性
项目职责的一部分是了解社区的各种需求，并与HPC提供商合作彼此适应对方。

A.绑定无效计算器

结合功能计算器（BAC）自动化分子动力学（MD）模拟的系统构建、执行和分析，以便计算药物与药物结合蛋白质的强度。虽然BAC支持一系列模拟方案和分析方法，但工作流程对所有人来说都很常见。从单个输入结构开始了许多相同蛋白质——药物复合物的“复制”模拟，每个输入结构由许多连续步骤组成。一旦模拟完成，就执行分析步骤。使用多个副本模拟仿真作为采样策略并提供不确定性估计。

BAC可以用于根据患者（或病原体）内蛋白质的基因序列，以及药物发现情景，对药物结合进行个体化。在这两种情况下，可能需要大量的运行，以解开突变的相互作用或扫描大的化学空间。通常，基于BAC的MD模拟使用少于几百个核心（或节点的价值加上GPU），并且需要6到12个小时才能完成。大多数超级计算机的政策迫使这些工作捆绑在一起，以便按照规定的规模运行。这是由于队列中每个用户允许的作业数量的限制或者特定作业大小的要求允许运行足够长的时间来完成模拟。为了促进这些运行，我们最近开发了HTBAC，它标准化了可以访问的超级计算机管理副本的方式。此外，通过使用工作流中间件，我们有可能使用自适应执行模式（例如，一旦达到收敛就终止模拟，并将释放的核用于其他系统）。

B. HemeLB

HemeLB是一种3D计算流体动力学求解器。在X射线CT扫描（或不太常见的MRI扫描）期间拍摄患者大脑的图像被分段并组合以形成血管网络的3D表面。还可以将流动转向支架引入该网状物中。在准备使用LBM进行模拟时，表面内部以所需的分辨率（通常为10μm或更低）离散化。这种网格化过程可能带来很高的计算成本，通常占用很大一部分的成本。

工作流程中的每个步骤都可以并且确实具有非常不同的资源要求，并且如果通过I/O完成，则步骤之间的数据传输可能是昂贵的。这些不同的计算需求，特别是在核心数量方面，意味着在单个作业提交中启动给定的工作流并不总是可行或实际的，而是通过调度多个顺序作业而产生额外的排队时间。

工作流程要求
计算生物医学工作流程的开发，验证和验证代表了一项重要的投资。因此，工作流程的便携性和可重复性对于保持低成本是至关重要的。不幸的是，开发人员目前面临两个空间（在具有不同架构和策略的不同计算机上运行）和时间（在同一台计算机上进行系统更新，影响可重复性）的可移植性问题。

空间方面在决定是否依赖特定中间件工具时尤其重要，这些工具可能在给定的超级计算机上节省时间，而在另一个超级计算机上被安全策略完全或部分禁止。该领域缺乏标准，增加了应用程序开发人员对使用某些类型的中间件（例如工作流引擎）的沉默。在相关的说明中，中间件的第三方性质意味着支持的责任既不是用户也不是超级计算人员。人们可能不希望投资开发依赖于一个或多个第三方工具的工作流程，这些工具在两三年内可能会或可能不会维持。不幸的是，这种工作流程的发展时间规模至少为几年。

用于大型数据集的工具

用于精确医学工作流程（作为输入或中间步骤）的大型数据集的一组标准工具很快就会变得必不可少。来自下一代测序和医学成像的数据集可能导致异常大的文件。例如，在HemeLB内输入数据文件可以是几十TB的量级。这导致创建了定制的文件读取代码，其中这些文件在多个存储目标上条带化以增加带宽并允许同时访问多个进程的相同文件。此代码的创建需要多种解决方法来限制库的限制，例如MPI和系统特定的优化（例如条带计数）。维护此代码代表了相当大的开销，需要远离科学的努力，以及额外代码脆弱性的来源。用于此类任务的标准化工具或库将有助于更好，更强大的仿真代码开发。

由于超级计算机的软件和策略可能在没有足够警告的情况下发生变化，因此工作流和中间件层能够实现具有不同计算要求的步骤的流水线操作，因此容易出现不稳定性。认识到超级计算平台通常位于用户部署的非常复杂的软件堆栈的底部，并且考虑到这一点，采用适当的变更管理策略（例如由ITIL管理）在这里是非常宝贵的。

未来发展方向
常用和常用标准

通过考虑过多的现有工作流程工具，可以识别应用程序开发人员最需要的功能，并从那里开发一个标准API或一组工具，以暴露所需的功能 通过将责任从第三方开发人员转移到最熟悉自己机器的员工，跨越不同的HPC站点。它不足以定义标准，必须以鼓励用户（和开发人员）购买的方式使其可访问和支持。

社区管理

一个可能的解决方案是社区组织，例如欧盟H2020资助的卓越中心，以维护中心工具，以适合其用户群的方式实现工作流程。这需要伴随特定HPC中心的一些链接，但不要将维护者绑定到特定机器应该减少每个超级计算中心的“岛效应”，只为用户提供它想要的环境。

容器化

许多可移植性问题可以通过使用容器来解决。但是，当应用于极大或复杂的HPC系统和应用程序时（例如，与云服务上执行的典型作业相比），这种方法可能会呈现出自己独特的能力。