8.1 Application Builder：把模型封装成仿真 App

8.1 Application Builder：把模型封装成仿真 App

本节摘要：App 开发器提供开发器与 App 双视图：表单编辑器把参数绑成输入框、把研究绑成按钮，方法编辑器给输入加校验，最终交付为 Server 页面或独立编译的可执行程序。本节把散热器模型封装成一个十分钟即可上手的散热评估 App。

双视图工作模式

功能区切换"App 开发器"，界面变成左右两栏：左边是开发器视图（表单、方法、模型互相独立地编辑），右边实时预览 App 视图（用户最终看到的界面）。这个布局本身就是工作模式的宣言：你在左边定义"能做什么"，用户在右边只看到"该做什么"。点"新 App 表单"，先创建主表单，拖一个"输入字段"进预览区——绑定的第一步就从这里开始。

把 Q_chip 绑给第一个输入框：选中输入字段，设置窗口里"源"选参数、指定 Q_chip；同样方式把 h_air、T_inf 各绑一个框。再拖一个"按钮"，其"命令"选"运行"并指定研究 1；拖一个"图形"窗口块，数据源选温度面图。三分钟，最小可用产品成型：右上角点"运行"进入测试，改功耗数字、点计算、看云图——你的模型第一次拥有了"用户界面"。

方法：给 App 立规矩

裸表单的危险在于没有边界：h_air 填成零会让温度发散，Q_chip 填负数物理上莫名其妙。方法编辑器负责立规矩。它使用类 Java 的脚本语言，新手最快的路径是"录制"：点击录制备录下你的手动操作序列，生成代码后再手工改造。给散热 App 加一段输入校验：

// 输入校验：换热系数与功耗必须在合理区间
if (h_air < 5 || h_air > 500) {
    alert("换热系数须在 5 到 500 W/(m2·K) 之间，当前值越界");
    return;
}
if (Q_chip <= 0 || Q_chip > 200) {
    alert("功耗须为 0 到 200 W 之间的正数");
    return;
}
model.study("std1").run();
​

把这段方法绑到按钮上替代裸的"运行"，App 就有了防呆能力：越界输入被拦截并给出人话提示，模型树在 App 视图里完全不可见——用户既改不坏几何与网格，也偷不走你的建模思路，知识产权与使用安全是同一枚的两面。更进一步可以把"判读"也写进方法：计算完成后自动比对结温与 45 ℃ 目标，直接在结果区给出"裕量 1.8 K"或"超温 2.3 K"的字样，把专家的判读逻辑固化进工具。

图：仿真 App 的分层架构与交付形态

交付形态的成本账

App 做好之后有三种交付路径，成本与适用面各不同。文件共享最轻：把 .mph 文件发给装了同版本许可的同事，双击即用，适合团队内部小范围。COMSOL Server 是中量级：App 发布到服务器，用户浏览器里打开，无需安装桌面版，IT 部门喜欢它的集中管控，适合推广到跨部门。Compiler 编译是重量级：把 App 打包成独立可执行文件，最终用户机器上既不需要 COMSOL 也不需要许可，适合交付给客户或产线现场——代价是编译流程与许可要求，且模型更新后要重新编译。选择的判据就两条：用户有没有 COMSOL 环境、更新频率有多高；团队内部高频迭代选 Server，交付外部低频使用选编译。

本节要点回顾

• 双视图即权限观：开发器视图定义能力，App 视图只暴露该暴露的，模型树天然不可见。
• 最小 App 三件：参数输入框、绑定研究的按钮、绑定绘图组的图形窗口，十分钟的活。
• 方法层立规矩：录制起步、类 Java 改造，输入校验与自动判读把专家逻辑固化进工具。
• 交付三形态按用户与频率选：文件共享、Server 浏览器、Compiler 独立编译，成本递增。
• App 化的副产品是把隐性使用规则写成显式契约，这一步的价值常大于工具本身。

仿真 App 的设计原则是"给非专家一个安全的仿真工具"——它的核心挑战不是功能实现而是用户体验设计。一个好的仿真 App 需要在三个层面做好设计。输入设计：只暴露用户需要调整的参数（比如散热器的翅片数量和材料），把求解器设置、网格参数、物理场常数全部隐藏——用户面对的输入项越少越好，理想情况是三个到五个参数。输出设计：用户关心的不是温度云图的彩色细节，而是"达标了吗"的二元判断——所以输出应该是大字号的关键数字（如芯片最高温度 47.2 ℃，低于限值 85 ℃ 绿色通过）加一个趋势图。错误处理：参数超出合理范围时给出友好的提示（"翅片间距建议在 2-10 mm 之间，当前值 0.5 mm 过小"）而不是 COMSOL 的技术性报错。做一个仿真 App 的时间大约是一到两周（包含界面设计和测试），但它的回报是把仿真从"专家的专利"变成"团队的工具"——当设计工程师可以自助使用仿真时，仿真专家的效率也会成倍释放。

补一个仿真 App 开发的用户测试方法。App 做好了不代表用户会用——用户测试是发现可用性问题的唯一可靠手段。测试方法：找一个从未接触过这个 App 的同事，给他一个任务（比如"用这个 App 评估如果散热器翅片从 7 片增加到 9 片，芯片温度会怎么变"），观察他从打开 App 到得到答案的全过程。测试时记录四个指标：完成时间、是否需要帮助、输入的参数值是否合理、对结果的解读是否正确。四个指标中任何一个出问题都指向一个设计缺陷——完成时间长说明界面不够直观、需要帮助说明说明文档不够清楚、参数不合理说明缺少输入校验、解读错误说明结果展示不够友好。用户测试的样本量不需要很大——三到五个用户就能发现 80% 的可用性问题。测试之后修复发现的问题，再换一批人测试——两轮测试后 App 的可用性就能达到可交付水平。

仿真 App 的一个完整开发案例值得详细展开。案例：散热器快速评估 App。用户输入：芯片功耗（W）、环境温度（℃）、翅片数量、翅片高度（mm）、风速。输出：芯片最高温度（℃）、是否达标（低于 85 ℃ 判定绿色通过、否则红色超限）、推荐改进（如果超限，提示加翅片或加风速）。开发步骤：第一步在 COMSOL 中完成散热器参数化模型并验证（用第 2-3 章的方法），确认参数化扫描在合理范围内结果正确。第二步在 Application Builder 中设计界面——输入区放五个参数输入框（带合理范围的验证提示）、输出区放温度大字显示和达标指示灯。第三步添加计算按钮的事件处理——点击后调用底层模型求解并提取结果更新显示。第四步测试——用已知解析解的简单工况验证 App 输出的正确性。整个 App 开发约两到三天，产出一个可以让没有任何仿真背景的设计工程师自助使用的工具。这个案例的教学价值在于它把 COMSOL 从"仿真专家的桌面软件"变成了"设计团队的自助服务工具"——这个角色的转变是仿真价值最大化的关键一步。