作为一枚动力学仿真人员,Simpack是我赖以生存的饭碗。
在艰辛的讨饭过程中,经常会遇到仿真试验对比的世纪难题。
这一世纪难题存在两条公理:
除了仿真人员外,没人相信仿真结果;
除了试验人员外,没人怀疑试验数据。
基于以上两条公理,最终得到的结论是:肯定是仿真人员的错,虽然没人能说出你错在哪里,但是每人都说出就是你错。
好吧,仿真人员开始找错……
碗(软件)肯定是没问题,用它吃了这么多年饭了,每年靠它吃饭的人可以围绕地球两圈,作为一枚久经沙场的饭碗,它是不会出错的。
难道是饭(模型)有问题?把饭倒出来,一粒一粒地扫描,先正着检查三遍再倒着检查三遍,然后想尽办法变着花样抽查,结果没发现任何错。在沮丧懊恼的同时竟有点情不自禁地佩服当初那个建模的自己。
既然饭没有问题,碗也没有问题,那么,莫非是我吃饭的姿势不对?
真是无巧不成书,我手头恰好有这么一个栗子,闲话不多说,举之。
话说故事的开始,我拿到了一份列车过曲线时的车体加速度实测数据,然后我不自量力地拿仿真数据去对。如果你认为两者对不上,那你还是太简单了,事实是两者严重对不上。
当然,故事的最后,肯定是两者对上了,要不然我还在这显摆个啥劲呢。剧透一下解决方法,问题出在车体加速度的输出方式上。鉴于工作单位的保密要求,实测数据和实际模型肯定是不能展示的,不过既然选择了码字装逼这条不归路,终究还是要给诸位看客一个交代,于是乎我建了个简易车辆模型来复现一下解决思路及方法。
首先,我们需要有辆车。本着少占用业余时间能简化则简化的敷衍了事原则,本次的仿真车辆是一节低配高丐版的A型地铁车。
接下来,在车体中部建个marker。
出于对比目的,建了两个sensor,命名为Sensor1和Sensor2,设置如下:
其中上图中的$M_Isys_Track_Moved 标记点的定义为:
本着由易到难的原则,我们先设置一条平面无超高无激励曲线,然后随便给个速度(比如30m/s)点击离线积分。
查看两个sensor的y向加速度结果。
造成上图差异的原因是两个sensor的参考坐标系不同。
显然在此轮PK当中,sensor2凭借其与时俱进的参考坐标系获得了最终的胜利。为下文埋个伏笔,我们看到sensor2在曲线上的稳定加速度值是2.25,套用一下初中物理的离心加速度公式就会发现。看上去只要注意sensor的参考坐标系就万事大吉了,果真如此吗?
现在让我们把刚才的曲线设置一下超高,如下图所示。
再建一个新的sensor3如下。先建立$M_Isys_Track_H 标记点(注意:这里的参数4设置为Yes),再利用该标记点创建新的sensor。
车速仍然是30m/s,一切准备就绪,老司机要开车了。
终点到了,结果如下。
从上图可以看到,sensor3的值略大于sensor2,两者的数值都在2.25m/s2附近,示意图如下。
由上图可知,sensor2的加速度应为:
我们在后处理里面验证一下z向加速度,果不出其所以然。
问题来了,sensor2的结果就是我们实测结果吗?没错,肯定不是。
初中物理老师在黑板上画出了下面的图。
然后以恨铁不成钢的语调告诉我们:
试验人员则补充到,试验物理量应该是:
等一下,Simpack把重力加速度忽略了?好吧,让我们来查一下帮助文档。
这是几个意思啊,好像明白了什么,又好像完全糊涂了。
捋一捋思路,其实就一句话一个表。话是这样说的:对于列车过曲线工况而言,sensor2的设置是最合适的。
表是这样画的:
现在的问题变成了,怎么样把吃饭姿势由Simpack Result变成Test Result。
我企图从前处理找到方法,未果。好吧,那就曲线救国,从后处理里面下手吧。
从公式来看,我们只要找到角度α就行了,其实这个角度就是sensor3的alpha角,可以直接输出。接下来就是反复的用filter加加减减了,过程繁琐而枯燥,本文乃乘兴而写,兴尽自然止笔,不忍话吐一半,留个框图结尾。
装完收工!
关于达索系统:
达索系统成立于1981年,作为一家为全球客户提供3DEXPERIENCE解决方案的领导者,达索系统为企业和客户提供虚拟空间以模拟可持续创新。其全球领先的解决方案改变了产品在设计、生产和技术支持上的方式。达索系统的协作解决方案更是推动了社会创新,扩大了通过虚拟世界来改善真实世界的可能性。达索系统为140多个国家超过22万个不同行业、不同规模的客户带来价值。