用户主要是大学/科研机构和航空航天、汽车、电子/高科技、船舶、土木工程、制造和生物工程，包括汽车碰撞、爆炸反应，甚至血液泵送时主动脉人工心脏瓣膜的复杂开关。
1976年，LS-DYNA由美国Lawrence Livermore国家实验室J.O.Hallquist博士主持发展。1988年，LSTC（Livermore Software Technology Corp.）公司成立，LS-DYNA开始商业化。
1996年，LSTC与ANSYS合作推出ANSYS/LS-DYNA，。2019年，Ansys收购LSTC。
今天，我们通过一个实证来回答用户的使用LS-DYNA上云过程中的这些关键问题。
某车企CAE当地机房建设部门，。
随着公司业务的发展，CAE在不久的将来，部门将面临更大的业务压力，部门负责人打算将部分部门投入使用LS-DYNA任务扩展到云，但由于。
fastone企业版产品
LS-DYNA MPP版本
Linux CentOS7.4
SLURM
模拟材料在承受碰撞、坠落、金属成型等短时高强度载荷时的响应
计算优化实例
通用型实例
内存优化实例
网络强化实例
LS-DYNA支持，分为MPP（Massively Parallel Processing）版本和SMP（Symmetric Multi-Processing）版本。
是多个CPU共享相同的内存总线等资源，一般只能在单机上运行，受单机影响CPU性能及CPU核数限制。
是每个CPU内存总线等独家资源，CPU通过网络通信交换信息，可以在计算机集群大提高计算速度。
在《》解释得很清楚。
虽然应用不同，但原理是一样的。
，造成信息延迟。
下图这张PingPong测试(顾名思义，就是找一个数据包，在两个节点之间不断丢失，就像打乒乓球一样。)从16可以看出 cores到240 cores，随着核数量的增加，信息延迟明显高于数量级。随着通信数据的增加，信息延迟将爆炸性增长。
为了充分回答用户的疑问，我们，验证了以下场景。
1.本地64核计算资源运算一组LS-DYNA439分钟的任务；
2.云调度64计算优化实例运算一组LS-DYNA任务，375分钟；
3.云调度64核通用实例运算一组LS-DYNA任务需要506分钟；
4.云调度64核内存优化实例运算一组LS-DYNA任务需要533分钟；
5.16.本地单独使用32、48、64、96、128核计算资源运算同一组LS-DYNA任务，耗时分别为1404、821、566、439、321、255分钟；
6、云端分别调度16、32、48、64、96、128核计算优化型实例运算同一组LS-DYNA任务，耗时分别为1269、662、458、375、299、252分钟。
可以看到当核数较少时，计算优化型实例的耗时要明显少于本地资源，但随着核数的增加，两者的耗时逐渐接近，尤其是在128核时，计算优化型实例几乎已经丧失了所有的优势。
1、本地分别使用16、32、48、64、96、128核计算资源运算同一组LS-DYNA任务，耗时分别为1404、821、566、439、321、255分钟；
2、云端分别调度16、32、48、64、96、128核计算优化型实例运算同一组LS-DYNA任务，耗时分别为1269、662、458、375、299、252分钟；
3、云端分别调度16、32、48、64、96、128核新款计算优化型实例运算同一组LS-DYNA任务，耗时分别为1088、569、391、320、255、216分钟。
我们来感受一下不同云厂商多款计算优化型实例的价格差异：
比如我们之前在运算Amber任务时，NVIDIA Tesla K80（2014年上市）的耗时是V100（2017年上市）的约5-6倍，价格却只有后者的三分之一。
这种时候，。详细可以看这里
这个问题的解决方案在哪里？
我们看下一个场景：
1、本地分别使用16、32、48、64、96、128核计算资源运算同一组LS-DYNA任务，耗时分别为1404、821、566、439、321、255分钟；
2、云端分别调度16、32、48、64、96、128核计算优化型实例运算同一组LS-DYNA任务，耗时分别为1269、662、458、375、299、252分钟；
3、云端分别调度16、32、48、64、96、128核新款计算优化型实例运算同一组LS-DYNA任务，耗时分别为1088、569、391、320、255、216分钟；
4、云端分别调度16、32、48、64、96、128核网络加强型实例运算同一组LS-DYNA任务，耗时分别为1202、603、404、307、209、163分钟。
从上表中可以明显地观察到，网络加强型实例虽然在低核数下的表现并不起眼，但随着核数的增加，性能提升幅度相当大，在128核的环境下相比本地资源的性能提升将近一倍，线性表现堪称完美。
在之前的Fluent实证中，我们也验证了这一点。
这次我们换一个角度——
不论是单机模式还是使用服务器集群，用户只需要把数据传到本地机器或服务器上，便可以直接跑任务，当然后面可能有IT部门会完成服务器端数据管理工作。
用户将数据传到本地机器或服务器之后，还需要在云端开启资源、搭建环境，手动进行数据的上传和下载。
和本地一样，用户只需要把数据上传到我们的DM（Data Manager）工具上，就可以直接使用数据来跑任务了。
对于用户而言，使用我们的DM工具至少有三大优势：
用户无需在多套认证系统之间切换，使用统一的身份认证即可传输数据，并自动关联云端集群进行计算，不改变其原有的使用习惯。
数据只需上传一次即可多次使用，其他用户在经过统一认证后也可随时共享，极大提升团队协同能力。
关于这点，我们在这篇《》里有提到，
而且，随着任务的调整，有大量小文件需要增量上传。在这个实证中，用户需要上传9600个任务文件，每个几十MiB不等。
我们的DM工具能很好地满足用户需求，支持全自动化数据上传，可充分利用带宽，帮助用户快速上传、下载海量数据。
同时，利用fastone自主研发的分段上传、高并发、断点续传等数据传输技术，优化海量数据的传输效率。
本次CAE行业云实证系列Vol.8就到这里了。
下一期的CAE云实证，我们聊COMSOL。
请保持关注哦！