首页/文章/ 详情

CAE漫谈之二次开发(一)

8月前浏览2630

在《CAE漫谈之CAE应用》一文中详细阐述了本人对CAE业务特点及成为一名合格CAE工程师必备的基本素质的观点,阅读量已过6000+,也有不少读者表示赞同和喜欢。本文将在此基础上做进一步延伸讨论,来深入分析CAE业务未来发展趋势、当前时代背景下的新需求、新挑战及对应的解决方案。以下分别从个体即CAE工程师和团体即企业两个角度分别分析二次开发业务应发挥的作用和扮演的角色。

一、二次开发的作用

在《CAE漫谈之CAE应用》一文中本人将CAE业务能力水平划分为5个level。当仿真精度达到一定程度足以指导产品开发并解决工程实际问题时,接下来面临的新挑战就是如何提高仿真效率和降低成本(此处的效率主要指仿真周期的缩短,即能够更快地完成仿真任务;成本包括时间成本和人力成本)。

解决上述问题的有效途径之一就是在现有通用化的工业软件基础上进行定制化的二次开发,大部分的成熟商业软件都提供大量丰富的API(Application Program Interface,应用程序接口),各自支持的开发语言可能会有区别,例如HyperWorks支持Tcl/Tk而StarCCM+则支持java,ANSA是python。具体分析如下:

a)单项目仿真周期的缩短。由于二次开发工具可以通过运行代码来自动执行部分操作,代替了部分或大部分人工的操作,速度更快,最直接的好处就是带来周期的缩短。例如在做几何清理时,人工操作时要不断旋转模型靠人眼去寻找、判断哪些几何线是自由边、哪些倒圆角特征需要删除等,但如果几何清理的规则足够明确,只要通过循环语句遍历全部几何线和按半径大小搜索指定特征的倒圆角,找出后及时执行处理操作,就实现了一键完成。例如原来一人需要做5天的任务借助二次开发工具可以缩短到3天内完成,此为最直接的好处。

b)人力成本的降低。首先,单项目仿真周期缩短的同时间接实现了人力成本的下降,因为在不明显增加工作量的前提下单人可同时承担项目数量增加了,例如原来一人可同时做2个项目的分析任务现在可以同时做4个;也就意味着原来需要增加人员数量才能满足项目需求,而现在可以保持人数不变。其次,部分的自动化建模可以让CAE分析工程师从繁重的重复性劳动中解放出来,将更多的精力投入到制定方案、结果解读、调试差错等需要一定主观经验和专业理论的工作中去,甚至全身心投入到全新课题中去,充分发挥个人的才干,毕竟一般做CAE分析的工程师门槛相对较高,需要一定的专业经验积累和理论知识储备,招聘这类的人才的成本也水涨船高。

通过自动化、流程化的二次开发,完全可以将其中部分工作从专业的CAE分析手中转到网格工程师完成,只要培训时把规则明确即可,对于网格工程师而言他们只需做些机械重复性的操作而无需理解背后的计算原理就可以得到准确的结果。例如,在后处理和出报告环节中,计算完成后只要让网格工程师负责将云图的视角调整好(如果最佳视角算法不成熟),单击保存按钮,剩下的截图、贴图以及填写数据的操作全部由自动化工具来完成,而门槛和成本相对较低的网格工程师并不需要理解当前操作的云图是代表的是温度场还是应力场,因此这个环节对人的依赖性大幅降低,人员的替代性增强。甚至借助二次开发可以将过程封装成自动化黑箱、结果做进一步的转换,例如模态频率不再以数值形式显示,直接通过红色或绿色展示出来,设计工程师就能直观地判断结果是否合格,设计早期(粗略)的模态分析就交由设计工程师自行完成。

二、个体视角看开发-CAE工程师层面

从供给端来看,目前世界上强大的CAE软件厂商如Simens、Altair、ANSYS、达索等为了尽可能获得更多用户,提供了通用性极强的软件产品,应用范围基本不受行业限制,无论是汽车船舶、航空航天还是半导体、医疗器械等行业都有他们的产品可用。强大的通用性覆盖了更多客户,也带来了更多利润,这是一个显著的优势。但从需求端来看,这种通用性的强大就成了一把双刃剑,因为一个特定的用户或企业应用软件时所涉及的产品类型有限,要分析的工况类型和软件功能往往也是在有限的范围内变化。以本人经历为例,近八年的从业时间里所有项目要做的分析工况无非就局限于模态、频响、随机振动和G-Load、热力耦合等这几个;但是为了能够熟练使用软件,不得不学习各种复杂的操作,了解各种新增的功能,安装文件也眼看着从几个G逐渐扩大到几十个G,有时为了完成固定的某项建模也是频繁进行重复性的操作。此外,虽然维护费每年都按时交,代理商也及时提供新版本,但实际使用到的新功能却始终变增加有限。因此从需求端来看,针对特定企业、特定规模、特定产品、特定工况的角度来看定制化的需求大于通用化。

以结构力学分析过程为例,整个仿真分析过程可分为数据准备、几何清理、网格划分、定义材料属性、定义连接和加载、求解计算、结果评估与提取、编辑报告(分析原因并制定优化方案)等8-9个步骤。在此过程中人工耗时最长的当属几何清理和网格划分两个环节(计算求解虽持续时间长,但主要占用机器时间,人工较少,不再此讨论范围;后处理虽然涉及大量的数据和图片操作,但结果出来后更为紧急的是人为解读结果和制定方案,编辑报告一般更多是归档和走流程用,优先级也不高)。如果能够通过二次开发来缩短此环节的时间,效率提升效果也最为显著。因此,如果将以上环节按优先级排序,本人认为首先需要提升前处理(尤其是网格划分和连接加载)的效率。

主流的前处理软件如HyperWorks和Ansa都提供的丰富强大的API来支持二次开发,如Hyperworks支持tcl/tk语言的API,Ansa为Python语言,Simcenter StarCCM+为java语言。将常用操作的命令按照一定的逻辑和算法封装到一起实现某一具体的功能。根据分析工况类型、标准化程度、产品类型复杂性等情况的不同,定制化的二次开发大致可分为3种不同模式,分别匹配不同的应用场景,而每种模式又各有优缺点,以下按照自动化程度高低分别阐述:

1)流程化全自动模式。

该模式是指在一开始就上传必要的数据和计算所需的全部参数,后续的全部分析过程均在后台自动运行,中间无需人工干预。主要特点有:

a,效率最高。人和机器可以并行工作,即机器运行期间CAE工程师可以做其他事情;b,对于具体的分析工况,标准化程度要求最高,不确定因素最少,编写的程序足以涵盖不同的项目需求;c,对用户的专业素质要求最低,由于自动运行,只要用户会基本操作即可;d,开发难度最大,自动执行过程需预先制定处理各种异常因素的方案,否则一旦出错,查错及修改难度大。f,硬件资源利用率最高,在自动运行过程中主要是机器工作,不受工作时间限制。

2)流程化半自动模式。

对于某些特定的工况而言,如果建模步骤中大部分的操作都能够固化下来,只有少部分不确定因素存在,需要用户根据实际情况做出主观判断再操作,这种场景就适用于该模式。在软件中做一独立和内嵌式界面,按照固定的分析步骤来排布各种组件(按钮、输入框、checkbox等),用户建模时按照预定义流程从上到下按依次操作即可。到每一步时,可能借助工具按钮实现一键完成,也可能完全手工操作,但总体的流程相对固定,对用户自身的专业素质要求较低。例如,做车门下垂下掉分析时,首先裁剪整车模型,用户只要选定裁剪的基准点,后续的网格删除和对称面上节点约束都自动完成;然后用户再选择加载点和门轴铰链,工况加载则由工具自动完成等等。只有当前步骤达到下一步输入状态时才能继续往下进行,否则工具就要保错,并给出报错原因。简而言之,建模时是手自一体式操作。

该模式的主要特定有:

a,效率较高。人和机器交互式操作,比全自动模型慢,但比纯手工操作快;b,对于具体的分析工况,标准化程度要较高,允许存在少量不确定因素,不确定的因素由手工操作完成;c,对用户的专业素质要求较低,流程相对固化,用户按照流程依次操作,上手门槛低;d,开发难度较大,自动执行的部分要充分考虑各种可能由于人为操作不充分导致的异常情况,并允许用户返回修改。f,硬件资源利用率一般,人和机器交互操作,受工作时间限制。

3)工具箱模式。

该模式适用于建模规范化、标准化程度最低,存在大量不确定因素需要人为判断的情况,但对于其中部分的复杂操作单独做成各种特定工具的自动化小工具,需要用时则去调用该功能,不需要时仍然按照原来手工操作的方式进行。何时使用什么功能的工具,建模流程先后顺序等全部由用户来决定。类似于汽车修理师傅事先并不知道故障在哪里,先带着一个庞大的工具箱放在旁边,到现场做了诊断后根据实际情况需要用哪个工具就取哪个。

该模式的主要特定有:

a.效率仅高于原来的纯手工模式;b.对用户的专业素质要求最高,因为该模式仅仅是在原来纯手工操作的基础上提供了一些快捷工具,建模流程上不具备任何指导功能;c.开发难度相对以上2中模式最低,每个工具只要实现特定的功能即可,当前模型的状态与前后工具功能的关系完全由用户把握,无输入输出关系存在;d.硬件资源利用率一般,人和机器交互操作,受工作时间限制。

以上3种开发模式各有优缺点,至于哪个最优无法一概而论,需综合考虑特定工况的人员配备情况、建模标准化、规范化程度高低、复杂程度、输入信息数据的结构化程度、仿真能力的成熟度等因素。因此,对于特定的用户群体而言应最合适的就是最好的。

(未完待续,本人原创文章,如需转载请注明来源)

二次开发汽车流体基础结构基础HyperWorks设计与仿真平台HyperViewHyperMeshStar-CCM+
著作权归作者所有,欢迎分享,未经许可,不得转载
首次发布时间:2023-09-04
最近编辑:8月前
A-长空之狐
签名征集中
获赞 8粉丝 2文章 2课程 0
点赞
收藏
未登录
还没有评论

课程
培训
服务
行家

VIP会员 学习 福利任务 兑换礼品
下载APP
联系我们
帮助与反馈