元组件 低代码 仿真 设计=MCLink
“
摘要 summary
在复杂产品的多学科仿真计算中，各科研机构或主机所都会面临大量的设计资源、设计平台和设计过程需要集成，MCLink立足打造一款低代码仿真软件设计集成开发平台，助力用户解决集成痛点。
近来自主可控的工业软件研发大有星星之火可以燎原之势，各大院所和学校的老师们纷纷撸起袖子加油干，不过在实际的开干中，大家往往会碰到“设计软件集成、设计资源整合、设计过程叠加、设计数据复用”等众多挑战。
1
自研算法和软件如何迅速转换为成熟软件产品？
潜台词：虽然我们专业能力很强，但毕竟不是搞软件工程的，做出的软件界面不好看，甚至没有界面，对用户也不友好，怎么破？
功能强大、上手很难、没有界面的CFD软件OpenFoam
MCLink具备完善的界面扩展机制
如何降低软件集成开发技术门槛，提升开发效率？
2
潜台词：软件集成的开发工作量太大，对系统抽象层次和体系结构的要求又很高，不比算法开发简单，我们实在没有精力去写那么多代码，不知道有没有简化的办法？
低代码 插件体系降低集成开发技术门槛
3
如何提升仿真计算前后处理的效率？
潜台词：我们的自研算法很不错，但缺少前后置功能，只能使用国外的商业软件来连接，这样一来麻烦就多了，不但要投入不少经费，还不能保证自主可控，最重要的是数据传来导去非常麻烦。
价格昂贵、不可控的国外前后处理商业软件
多学科、多专业的耦合仿真和协同优化如何组织？
4
潜台词：我们不同科室和专业之间想要协同设计太不容易了，使用的软件太多太杂，数据形态各样，仿真流程各异，协同过程中存在太多的妥协和简化。
多学科、多专业的耦合仿真和协同优化十分艰难
5
如何提升集成平台的扩展性和开放性？
潜台词：每次立项的时候我们都提出要支持扩展、开放接口，最后总是不了了之，这些扩展方式要么是不好用，要么是不会用，甚至根本就是不能用，这种系统的可成长性实在令人担忧。
基于插件体系的扩展性和开放性至关重要
如何提升数据再利用水平，提升知识挖掘能力，将数据价值最大化？
6
潜台词：我们的仿真和实验数据七零八落，散布在各处，仿真过程数据实在是不好管理，很多都删掉了，仿真计算的结果数据我们都留下了，但好久没人碰，都落灰了。都说数据就是财富，那我们究竟如何变现呢？
数据再利用就是最大限度攫取数据剩余价值的过程
7
如何有效整合超算集群等设计资源，提升仿真计算效率？
潜台词：我们的高学历工程师花了大量时间在**数据、提交作业、监控作业、收集结果等繁杂又容易出错的事务上，实在是浪费人才资源。
仿真效率的底下源于工程师干了太多“杂活累活”
如何在Web上快速发布仿真计算能力，并能多端展示？
8
潜台词：总是让用户安装大型软件用户也受不了，况且还有很多人习惯用手机看东西，如果好的计算结果或模型能一键发布到web端，这些难题就解决了。
Web发布能够迅速实现多端共享
应对不断演进的功能需求导致的持续化增长与集成 ——发展痛点
差异性专业需求导致的不同工具链之间互通与融合——集成痛点
打破多领域工具集成中部署模式和软件形态的壁垒——建设痛点
丰富的工具插件和算法**构建用户基础软件设施——能力痛点
第三方能力便捷集成助力快速验证系统与集成方案——效率痛点
前后置及算法能力网络服务发布解决多端部署难题——发布痛点
要知道，这个平台可是在好几个主机所，以及北航等牛X的单位得到了实际的应用。
典型的算法/解算器集成流程如下：
01
新建快速集成
创建集成封装的工作目录，初始化解算器基本信息，集成产出的相关文件和包都会存放在此目录中。
02
软件目录设置（含参数提取）
将完整算例包导入，定义求解过程中涉及到的文件类型，提取界面参数和后续求解步骤需要引用的变量。
03
文件拷贝设置
若求解过程中需要将某文件拷贝到指定路径，可以在此步骤设置拷贝规则。源文件以{变量名}的形式引用，运行求解器时会拷贝到目标地址，并可执行创建目录、解压操作，linux环境还可以将源文件做成软连接到目标目录。
04
计算步骤设置
创建一个或多个计算步骤，每个步骤可定义本机或集群计算模式（采用进程还是调度器来管理软件），选择在什么路径下运行哪个执行文件，是否在shell解释器执行等。计算步骤可调整顺序。
05
过程监控设置
创建一个多个监控项，每个监控项可定义来自参数或文件的某个值（可以是变量值）为监控对象，解算器运行过程中将定时获取此值。高阶监控可选择“函数”编写Python代码定义更加灵活的监控规则。
06
结果回收设置
创建一个多个结果回收规则，与过程监控类似，可从参数或文件回收结果，也可通过Python代码定义更加灵活的结果回收规则。
07
封装打包
保存当前集成工程，将上述集成过程定义的规则封装打包，输出一个适配器（egg文件），适配我们的科学计算中间件Mirror，即可运行求解。
如果您对MCLink感兴趣，请不吝赐教！
