每页:
搜索

集群计算和云计算 博客文章

数字孪生模型和基于模型的电池设计

2019年 2月 20日

通过将高保真多物理场模型与轻量级模型以及实测数据相结合,工程师可以创建数字孪生模型,进而去理解、预测、优化并控制现实界系统。

如何使用 COMSOL Multiphysics® 中的集群扫描节点

2018年 6月 12日

在之前的一篇博客文章中,我们解释了如何在 COMSOL Multiphysics® 软件中直接从 COMSOL Desktop® 环境实现在集群上运行作业,而无需与 Linux® 操作系统终端进行任何交互。由于这种终端有时需要使用者具有足够的操作技能,因此能够直接从图形用户界面启动集群作业便是 COMSOL® 软件最有用的功能之一。欢迎了解更多强大功能……。我们首先来看看集群扫描 节点。

COMSOL Desktop® 环境如何实现在集群上运行

2018年 3月 9日

在高性能计算(HPC)硬件上运行 COMSOL Multiphysics® 软件对许多类型的分析都非常有利,这是创建集群计算 节点的主要原因之一,该节点有助于将 COMSOL® 软件与任何类型的 HPC 基础设施无缝集成,同时保持图形用户界面的便利性。在本篇博客文章中,我们将学习如何直接从 COMSOL Desktop® 图形环境在 HPC 硬件上远程运行大型仿真。

使用云计算运行 COMSOL Multiphysics®

2015年 2月 20日

我们以前写过一篇有关 HPC 与 COMSOL Multiphysics® 软件、集群、以及混合计算的博客。但并非所有人的办公室中都有集群可用,或者有可用于构建 Beowulf 集群的硬件,如果我们确实需要集群所能提供的额外计算资源,有哪些可用的选择呢?其中一个解决方案便是云计算,这是一项提供临时性计算能力的服务,可以帮助提升计算能力及生产力。

求解大型 COMSOL 模型需要多少内存?

2014年 10月 24日

COMSOL Multiphysics能求解多大的模型是我们最常碰到的问题之一。这个问题其实很难直接回答,因此在本篇博客中,我们将讨论内存需求、模型大小、以及用户如何预测在求解大型三维有限元问题时所需的内存量。

建立贝奥武夫集群加速多物理场仿真

2014年 4月 11日

很多人都需要最新的软件和硬件来提升工作效率,因此,我们要紧跟科技发展的步伐。但如何处理过时的硬件呢?将它们报废或是扔在角落,这都显得有点浪费。其实我们可以利用这些废旧硬件来组建一个贝奥武夫集群,以提升计算速度与生产率。

借助 COMSOL API for use with Java® 实现建模任务的自动化操作

2014年 3月 27日

如今新产品的研发周期越来越短,为了在市场竞争中抢占先机,研发工程师和科学家们需要一件高效的工具,来帮助他们最快地获取计算结果,并摆脱重复性的例行工作。COMSOL Multiphysics® 正是他们需要的!COMSOL 软件拥有参数化扫描等多种内置功能,可帮助用户提高仿真工作效率。除了能够实现图形建模之外,它还拥有应用编程接口(Application Programming Interface,简称 API)。借助 API,用户便能对任意重复的建模步骤实现自动化操作。下面我们来了解一下 COMSOL API for use with Java®。

批处理扫描中任务并行的附加值

2014年 3月 20日

到目前为止,我们在混合建模系列博客中还没有详细讨论的一件事是,当向我们的计算中增加更多计算资源时,我们可以期待怎样程度的加速。今天,我们考虑一些解释并行计算局限性的理论研究,并将介绍如何使用 COMSOL 软件的批处理扫描 选项。这是一个内置的、令人尴尬的并行计算功能,可在达到极限时提高性能。 Amdahl 定律和 Gustafson-Barsis 定律 我们之前已经提到过的如何通过增加计算单元来提高速度是基于算法的(在这篇文章中我们将使用术语 进程,但添加的计算单元也可以是 线程 )。一个严格的串行算法,像计算Fibonacci 数列的元素,完全不能从增加过程中受益,而并行算法,如向量加法,可以利用与向量中的元素一样多的处理器。实际中的大多数算法都介于这两者之间。 为了分析一个算法可能的最大加速,我们将假设它由一小部分完全并行化的代码和一小部分严格串行化的代码组成。我们调用并行代码 \varphi 的分数,其中,\varphi 是介于(包括) 0 和 1 之间的一个数字。这自动意味着我们的算法有一个等于 (1-\varphi) 的串行代码片段。 考虑 P 个活动进程的计算时间 T(P),从 P=1 开始,我们可以使用表达式 T(1) = T(1) \cdot(\varphi + (1-\varphi))。当运行 P 个进程时,代码的串行部分不受影响,但完全并行化的代码的计算速度将提高P倍。因此,P进程的计算时间为 T(P)=T(1) \cdot (\varphi / P + (1 -\varphi)),加速度为 S(P):=T(1)/T(P)=1/(\varphi/P+(1-\varphi))。 Amdahl 定律 这个表达式是Amdahl 定律的核心。对于不同的值 \varphi 和 P 绘制图 S(P) ,我们现在在下图中看到一些有趣的东西。 为可并行化代码的不同部分增加进程数的加速比。 对于 100% 并行化代码,极限是不存在的。然而,我们发现对于 \varphi<1,渐近极限或理论最大加速比为 S{max}(\varphi):=\lim{P\to \infty} S(P)=1/(1-\varphi)。 对于 95% 并行化的代码,我们发现 S{max}(0.95)=20,即使我们有无限数量的进程,最大加速也是 20 倍。此外,我们有 S{max}(0.9)=10, S{max}(0.75)=4, 和 S{max}(0.5)=2。当减少并行化代码的比例时,理论最大加速比会迅速下降。 但不要现在就放弃回家! Gustafson-Barsis 定律 Amdahl 定律没有考虑到一件事,那就是当我们购买一台速度更快、内存更大的计算机来运行更多进程时,通常不是想更快地计算之前的小模型。相反,我们想要计算新的、更大(更酷)的模型。这就是Gustafson-Barsis 定律的全部内容。它基于这样一个假设,即我们要计算的问题的规模随着可用进程的数量线性增加。 Amdahl 定律假定问题的大小是固定的。当添加新的处理器时,它们处理的是最初由较少数量的进程处理的部分问题。通过添加越来越多的进程,我们并没有充分利用所添加进程的全部能力,因为最终它们能够处理的问题大小达到了下限。然而,假设问题的大小随着添加的进程数量的增加而增加,那么我们就将所有进程利用到假设的水平,并且执行计算的加速是无限的。 描述这种现象的方程是 S(P)=\phi\cdot P-(1-\phi),这为我们提供了一个更为乐观的结果,即所谓的 缩放加速(类似于生产力),如下图所示: 当考虑到工作的规模通常会随着可用进程的数量而增加时,我们的预测就更加乐观了。 通信成本 Gustafson-Barsis 定律意味着,我们拥有的能添加到进程中的资源才能限制我们可以计算的问题的大小。然而,还有其他因素会影响加速。到目前为止,我们在这个系列博客中试图强调的一点是,通信成本较高。但是我们还没有谈到它有多贵,所以让我们看一些例子。 […]


第一页
上一页
1–8 of 12
浏览 COMSOL 博客