4. 脚本录制与代码生成入门

在COMSOL中手工编写Java或Method脚本时，最困难的部分往往不是语法，而是不知道某个操作对应哪个API方法、参数该填什么。宏录制功能正是解决这一问题的入口：它把图形界面中的鼠标操作翻译成可执行的Java代码，让初学者先“看到”代码长什么样，再逐步理解并改造它。本节围绕录制宏的完整过程展开，从开启录制、执行典型建模操作，到阅读生成代码、识别其局限，最后完成一次手动优化。

录制宏的开启与操作范围

在COMSOL Desktop中，宏录制通过“开发工具”选项卡下的“录制方法”按钮启动。点击后，软件开始把后续的模型操作记录为Java方法调用。需要特别注意的是，录制只捕获通过图形界面触发的操作，例如在模型开发器中添加物理场接口、在几何节点中创建矩形、在材料节点中设定参数、在研究中点击“计算”。而通过命令行、外部脚本或某些后台自动完成的行为不会被记录。

一个实用的录制策略是：先想清楚要录制的“最小完整动作”，再开始录制。例如要录制“创建一个二维稳态传热模型并求解”的宏，操作顺序可以设计为：新建模型 → 选择空间维度为二维 → 添加“传热传质”中的“固体传热”接口 → 在几何中创建一个矩形 → 为矩形指定材料 → 设置温度边界条件 → 添加稳态研究 → 点击计算。每一步都通过界面完成，录制结束后停止，即可得到一段覆盖完整建模链路的代码。

录制代码的结构解析

停止录制后，COMSOL会生成一个以model为入口的Java方法。其典型结构如下：

public void recordMethod() throws Exception {
    // 新建模型
    Model model = ModelUtil.create("Model");
    model.modelNode().create("comp1");
    model.geom().create("geom1", 2);
    model.mesh().create("mesh1", "geom1");

    // 添加物理场
    model.physics().create("ht", "HeatTransfer", "geom1");

    // 创建几何
    model.geom("geom1").create("r1", "Rectangle");
    model.geom("geom1").feature("r1").set("size", new double[]{0.1, 0.1});
    model.geom("geom1").run();

    // 设置材料
    model.material().create("mat1", "Common", "geom1");
    model.material("mat1").propertyGroup("def")
        .set("thermalconductivity", new String[]{"400", "0", "0", "0", "0", "0", "0", "0", "0"});

    // 设置边界条件
    model.physics("ht").feature("temp1").set("T0", 293.15);

    // 创建研究并求解
    model.study().create("std1");
    model.study("std1").create("stat", "Stationary");
    model.sol("sol1").runAll();
}

从结构上看，录制代码遵循“创建对象 → 设置属性 → 执行动作”的三段式模式。每一类节点（几何、物理场、材料、研究）都通过create方法建立，再通过set方法写入参数，最后用run或runAll触发计算。理解这个模式后，即使面对陌生的物理场接口，也能大致推断出代码的调用顺序。

录制代码的典型局限性

录制得到的代码可以直接运行，但直接用于批量仿真往往不够。常见局限有以下几类。

硬编码参数。录制时输入的具体数值会以字面量形式写入代码，例如set("size", new double[]{0.1, 0.1})。如果后续要扫描不同尺寸，就必须手动把这些数值替换为变量或循环变量。

冗余与顺序依赖。录制会忠实记录每一次界面点击，包括中间态的无效操作。例如反复调整视图、重复打开同一节点，都会产生多余代码。此外，录制代码严格按操作顺序排列，若手动调整了某几行的先后，可能因对象尚未创建而报错。

缺少流程控制。录制只能生成线性代码，无法自动产生for循环、条件判断或异常捕获。批量仿真恰恰需要这些结构来遍历参数组合。

对象命名固定。录制生成的标签如"r1"、"ht"、"mat1"是固定字符串。如果在一个脚本中多次创建同类对象，需要手动保证名称不冲突，或改用动态命名。

手动优化的四个方向

拿到录制代码后，可以按以下方向改造，使其适合批量仿真。

1. 参数提取。把需要扫描的数值从代码中抽出，集中定义为变量。例如将矩形尺寸0.1改为double L = 0.1;，后续在循环中修改L并重新执行几何与网格。
2. 封装为方法。把“创建模型 → 设置参数 → 求解 → 提取结果”封装成一个带参数的Java方法，主循环只负责传入不同参数组合。
3. 加入循环与结果收集。用for循环遍历参数数组，每次求解后通过model.result().numerical()读取关注量（如最高温度、热通量），存入列表或写入文件。
4. 清理冗余。删除录制产生的重复set调用、未使用的中间变量和多余的视图操作，保留最小可执行链路。

下面给出一个优化后的片段示例，展示如何把录制代码改造成参数扫描结构：

double[] lengths = {0.08, 0.10, 0.12, 0.15};
for (double L : lengths) {
    Model model = ModelUtil.create("Model");
    // ... 创建几何时使用 L ...
    model.geom("geom1").feature("r1").set("size", new double[]{L, L});
    model.geom("geom1").run();
    // ... 求解 ...
    model.sol("sol1").runAll();
    // 提取最高温度
    double Tmax = model.result().numerical("eval1").getReal()[0];
    System.out.println("L=" + L + ", Tmax=" + Tmax);
}

这段代码保留了录制代码的核心调用，但去掉了固定尺寸，加入了循环和结果输出。运行后可以在控制台看到不同边长对应的最高温度，为后续批量分析提供数据基础。

录制与手写的配合策略

实际工作中，推荐“录制打底、手写改造”的混合方式。对于不熟悉的物理场接口或复杂边界条件，先用录制得到可运行的基础代码，确认调用路径正确；再在此基础上提取参数、加入循环和结果处理。这样既避免了从零查API的低效，也弥补了录制代码缺乏灵活性的短板。

判断录制代码是否已经“可用”的标准很简单：把它粘贴到方法编辑器中运行，若能完整走完建模与求解流程且无报错，说明录制链路是通的；接下来再检查其中哪些数值需要参数化、哪些步骤需要重复，就可以有针对性地进行优化。录制是起点，不是终点，真正的批量仿真能力来自对生成代码的理解与重构。