读LS-Dyna历史我的感悟
最近在看接触算法的时候，看到了一篇讲LS-Dyna历史的ppt，作者是David J. Benson，Dyna的非常早期的工程师之一，写接触算法的人应该也不会陌生，他提出了很多影响深远的显式动力学相关的算法，特别是接触搜索之类的那些。
Benson大概就是介绍了LS-Dyna从美国劳伦斯利弗莫尔（Lawrance Livermore NL）实验室出来的日子，作为非常有激 情的程序员/工程师与Hallquist （Dyna创始人）共事的一些故事。具体Dyna的历史我不想多讲，今天的大家都知道这是一款在商业上获得了成功的显式动力学程序，对于汽车碰撞、电子产品、成型都有很多应用。这里我想说的是，其中说的他们一些成功的路径，在此以此与诸君共勉：
这是Benson描述当时大家的工作环境，翻译过来：
开发者可以直接与用户一起 不用管理学大师，开发日程由开发者和用户共同制定 理论与实现都是同一波人来做 没有里程碑（没有管理学大师大概率没有里程碑） 资金虽然少但是够用
在我看来这些对于一款能走向商业成功的CAE软件都是非常重要的，比如与用户一起，这些年我看了太多空中楼阁的研发方向，结果在实现的时候无法串成完整的逻辑链条，在客户根本没法用，从算法实现到UI逻辑都是这样。在我的团队我努力的做到了1-3点，但是4，5点由于并不受我的控制，我也没法保证。
还有就是他说的关于开发的流程，
具体来说翻译过来就是：
没有任何方法在所有应用场景中都是最好的 新算法开发需要时间去获得接受与变得成熟 用户的需求需要给到最高的优先级 准确、速度、可扩展性是大模型仿真非常重要的考虑因素 新的发布一定要不需要转义的兼容以往的所有输入文件 开发者用户应该直接沟通
我觉得上述都说到我心坎里面去了，很多算法号称优秀也顶多在一个小小的领域，弯道超车大概率是扯淡，只有死磕算法、打磨程序最后才能真正满足客户的需求，而客户的需求一定是大于企业管理层自己构建的空中楼阁。另外对于兼容过往输入文件，我认为也是在当今时代一个正常软件开发所必须的。最后一条，我个人认为如果开发者不愿意和用户直接沟通，而得到的是比如技术支持、产品人员的二手信息，对于这样一个技术水平要求很高，同样问题有n种实现方法的行业，也很难作出一款杰出的产品。
今天就先说到这，我个人感觉很有意义，工程师是一种气质，希望大家共勉。当然如果听了不做也没啥意义。
