Part Ⅰ 把 Class List 里的骨架类都过了一遍Site、Building、Material、Construction 这些建完之后模型已经是一栋看得见的房子。但用 IDF Editor 的人都清楚左侧列表过了 C 和 M 之后真正磨人的部分才刚刚开始——时间表、热区、内扰、输出这些类单个看字段不多组合起来却直接决定你的模型是能跑还是跑得对。这一篇接着往下讲顺序就按我在实际项目里的处理习惯来先讲控制整个模拟过程的三个类再拆 Schedule 家族的完整写法然后是 Zone 和三类内扰对象的字段陷阱最后给出输出体系的配置思路。内容偏实战适合已经从示例文件跑通过一遍、准备认真做自己模型的读者。1. 模拟控制三件套SimulationControl、Timestep 与 RunPeriod 的协作逻辑IDF Editor 左侧的类列表是按字母序排列的所以你会先看到 Output、PlantLoop 这些然后才轮到 RunPeriod、Schedule、SimulationControl。这个顺序和建模的依赖顺序完全是反着的我第一次用就在这里吃过亏先建了一堆 Zone 和 Materials最后才想起来补 SimulationControl结果第一次运行直接报 no simulation control object。这三个类在列表里挨得不算远但各自负责的事完全不同必须放在一起理解。1.1 SimulationControl 的六个布尔开关先搞清楚这一趟在算什么SimulationControl 是我见过的最一票否决的类——六个字段全是 Yes/No没有中间态但只要有一项没想清楚后面的模拟结果要么是空的要么数值错得离谱。我第一次独立建模时就漏了第三个字段自以为建好了负荷模型结果 Plant Sizing 根本没执行冷机容量全是默认值整个能耗报告等于白做。六个字段里前三个控制要不要做容量核算Do Zone Sizing Calculation、Do System Sizing Calculation、Do Plant Sizing Calculation。名字已经很直白但注意它们是递进关系——System Sizing 依赖 Zone Sizing 的输出Plant Sizing 又依赖 System Sizing 的输出所以实际项目里基本都是三个一起 Yes很少有人单独只开其中一个。后面三个控制到底跑哪些工况Run Simulation for Sizing Periods 决定要不要跑设计日Run Simulation for Weather File Run Periods 决定要不要跑全年逐时模拟最后一个 Do HVAC Sizing Calculation for Sizing Periods 决定是否在核算过程中顺带完成空调系统的选型计算。最常见的全年模拟配置长这样SimulationControl, Yes, !- Do Zone Sizing Calculation Yes, !- Do System Sizing Calculation Yes, !- Do Plant Sizing Calculation No, !- Run Simulation for Sizing Periods Yes, !- Run Simulation for Weather File Run Periods Yes; !- Do HVAC Sizing Calculation for Sizing Periods如果你只想快速看设计日工况、不想跑全年就把第 4 个改成 Yes、第 5 个改成 No运行时间会快一个量级。三种典型组合对比如下场景Zone/System/Plant SizingRun Sizing PeriodsRun Weather RunPeriods适用情况全年逐时模拟三个 YesNoYes常规能耗分析只看设计日三个 YesYesNo校核容量、快速排错参数已定纯复核三个 NoNoYes后期敏感性分析这里有个特别容易迷惑的点即使在全年模式里把 Run Simulation for Sizing Periods 设为 NoEnergyPlus 依然会在设计日对象上执行容量核算只是不输出设计日的逐时结果。所以这个开关控制的其实是要不要输出设计日的模拟结果而不是要不要做核算两者千万别搞混。我见过有人为了省时间把三个 Sizing 全部关掉结果容量字段统统按默认值处理后面的系统能耗曲线全都失真了。1.2 Timestep 与 RunPeriod时间粒度和模拟窗口怎么配合Timestep 类里真正要填的字段只有一个Number of Timesteps per Hour默认值是 4。做过气象数据比对的人应该能理解模拟引擎内部所有计算都是按这个步长推进的4 意味着每 15 分钟一个计算点。默认 4 完全能跑但我做办公类项目习惯设 6也就是 10 分钟一步。设置方式非常直接Timestep, 6; !- Number of Timesteps per Hour为什么不是越大越好因为时间表插值、风机盘管开关、温度到达判定这些逻辑都会跟着步长一起变化。步长越细瞬态响应越逼真但模型规模一大比如几千个 zone运行时间会成倍上涨。我的一般原则是初步迭代用 4收敛阶段的精细校核用 6除非要做瞬态控制策略研究否则不建议直接上 12。按 12 步长跑一个带完整 HVAC 系统的中型商业模型单次运行可能要多出好几个小时而结果精度的提升往往并不明显。RunPeriod 则是定义全年模拟时间窗口的类最核心的字段是起止月份和起止日期。这里有个小坑Begin Day 和 End Day 填的是具体的日期而不是天数偏移有人从旧版示例文件里抄了个 1, 31 就以为是一月三十一天实际上那是 1 月 31 日。Day of Week for Start Day 如果留空EnergyPlus 会采用气象文件里实际对应的星期几如果填了则强制覆盖成你指定的星期。一般建议留空让模拟自然对齐日历。RunPeriod, Annual Run, !- Name 1, !- Begin Month 1, !- Begin Day 12, !- End Month 31, !- End Day , !- Day of Week for Start Day Yes, !- Use Weather File Holidays and Daylight Saving No, !- Apply Weekend Holiday Rule Yes, !- Use Weather File Rain Indicators Yes; !- Use Weather File Snow Indicators关于节假日要特别多说一句。旧版本里有个字段叫 Use Weather File Holidays and Daylight Saving很多教程直接抄 Yes结果美国标准的节假日被套用到了中国项目里。EnergyPlus 对节假日和夏令时的处理依赖气象文件附带的定义如果你的项目所在地没有夏令时制度建议把这个字段改成 No否则某些周一会莫名其妙地多出一轮错误的负荷偏移。不同 EnergyPlus 版本的 RunPeriod 字段数量略有差异新版本还拆出了夏令时独立开关填写时留意一下编辑器里的字段提示即可。1.3 SizingPeriod:DesignDay 是隐藏前提没有它容量核算无从谈起SimulationControl 里的 Sizing 开关只管要不要算真正提供计算工况的是 SizingPeriod:DesignDay 这个类。如果你没定义任何设计日、同时又把 Sizing 开成 Yes新版本会给出警告然后尝试自动补救老版本直接报错终止。设计日的核心字段包括设计日类型SummerDesignDay 或 WinterDesignDay、月份日期、最高干球温度、日较差、湿度类型与数值、风速风向、气压等。一个实际项目最稳妥的做法是定义四组设计日夏季极端、夏季典型、冬季极端、冬季典型。夏季极端的干球温度和湿球温度可以从气象文件或者当地设计规范里查冬季极端主要看干球温度和风速。这套数据是空调容量核算的基准随便填一个夏天 35 度、相对湿度 60%也许能跑通但算出来的主机容量可能偏差非常大。我在一个教育建筑项目里就吃过亏设计日温度填低了 2 度结果冷机选小了一档后来施工图阶段被迫调整设备选型非常被动。2. Schedule 全家桶从边界定义到逐时剧本的完整写法在 Class List 里S 开头的类是最拥挤的区域Schedule:Day:Interval、Schedule:Day:Hourly、Schedule:Week:Compact、Schedule:Compact 四个挨在一起再往上是 ScheduleTypeLimits。很多新手会跳过 ScheduleTypeLimits 直接写 Schedule:Compact结果运行时报一串 Schedule Type Limits not found然后不知所云地反复检查语法。2.1 ScheduleTypeLimits先给数据立规矩再谈写数值时间表本质上就是一张时间-数值对照表但 EnergyPlus 要求每张表必须先声明数值的类型边界否则它不知道你这张表是湿度、温度、分数还是开关量。ScheduleTypeLimits 就是干这个的四个字段分别定义名称、下限、上限、数值类型Continuous 或 Discrete和单位类型。最常见的两类是 Fraction 和 TemperatureScheduleTypeLimits, Fraction, !- Name 0.0, !- Lower Limit 1.0, !- Upper Limit Continuous, !- Numeric Type Dimensionless; !- Unit TypeTemperature 类型的上限可以开到 50 甚至 60因为空调设定温度再极端也就 26~28 度留足余量不会报错。如果一个字段要求的是温度型数据你给它挂了一张 Fraction 型时间表EnergyPlus 要么直接报类型不匹配要么在结果里给你一个完全没法解释的中间量。我的习惯是任何项目开始写时间表之前先把需要的 ScheduleTypeLimits 统一建好至少要有 Fraction、Temperature、On/Off、Number 四个。模板里一次性配齐后面建任何时间表都直接引用再也没有因为类型问题返工过。2.2 Day 类型与 Week 轮换常规时间表的标准战法Schedule:Day:Interval 是最常用的逐日时间表结构很清晰先指定引用哪个 ScheduleTypeLimits然后是一串时间-数值对最后以 24:00 收尾。关键字段是 Interpolate to Timestep——默认 No意思是这个数值在下一个时间点到来之前保持不变画出来是台阶改成 Yes 之后相邻两个数值之间会按 Timestep 做线性插值。Schedule:Day:Interval, OfficeWeekday_People, !- Name Fraction, !- Schedule Type Limits Name No, !- Interpolate to Timestep 06:00, 0.0, 08:00, 0.8, 12:00, 0.5, 13:00, 0.8, 18:00, 0.1, 24:00, 0.0;室内人员这种离散变化的变量用 No 是对的阶梯状最符合实际但温度设定值这种连续控制目标插值开成 Yes 会更平滑避免每个整点边界出现阶跃式的负荷跳变。Schedule:Day:Hourly 则更简单直接给 24 个整点数值适合从 Excel 或者其他能耗模型导出的数据粘贴进来最快。有了天级时间表还得告诉软件哪些天用哪张表这就是 Schedule:Week:Compact 的职责。它的写法是把日期类型和时间表名成对写在一起Schedule:Week:Compact, OfficeWeek_People, !- Name Fraction, !- Schedule Type Limits Name Monday..Friday, OfficeWeekday_People, Saturday, OfficeWeekend_People, Sunday, OfficeWeekend_People, SummerDesignDay, OfficeSummer_People, WinterDesignDay, OfficeWinter_People;日期类型里最容易被忽略的是 SummerDesignDay 和 WinterDesignDay。如果工作日配了表、休息日也配了表却唯独没给设计日单独配表那么设计日核算时会把平时的工作日作息硬套在 40 度的酷暑工况上设计负荷和实际运行负荷完全对不上。我在一个商业综合体项目里就栽过这个跟头后来养成了硬性习惯任何 Week 表都强制写全工作日、休息日、夏季设计日、冬季设计日这四类缺一不可。2.3 Schedule:Compact规则引擎式写法适合复杂工况Schedule:Compact 是另一种完全不同的表达方式用 Through、For、Until 三个关键字层层嵌套把全年的时间规则压成一行行指令。语法上它有点像一套简化版的规则引擎Schedule:Compact, Office_People, !- Name Fraction, !- Schedule Type Limits Name Through: 12/31, For: SummerDesignDay, Until: 08:00, 0.0, Until: 18:00, 1.0, Until: 24:00, 0.0, For: Monday..Friday, Until: 08:00, 0.1, Until: 12:00, 0.9, Until: 13:00, 0.5, Until: 18:00, 0.9, Until: 24:00, 0.0, For: Saturday, Until: 24:00, 0.0, For: Sunday, Until: 24:00, 0.0;理解这套语法的关键在 Until 的语义直到某个时间前面的值都保持不变。所以 Until: 08:00, 0.1 表示 0:00~8:00 都是 0.1而不是 8:00 之后变成 0.1。我刚接触时把方向理解反了结果整张表的作息整体往后错了一个小时负荷曲线看起来毫无规律查了好几个小时才发现是语义问题。这个坑几乎每个人都会踩一次建议第一次用 Compact 时先写一小段、再输出一个变量验证一下时段边界确认没问题了再铺开写。Compact 的优势在于能把工作日、周末、节假日、设计日的差异全部压缩在同一个对象里不用像 Week 方案那样额外维护五六张独立的 Day 表。缺点也很明显可读性差时间一长连你自己都可能忘了某条 For 的作用域边界。我的建议是项目里少于 5 个时间表时优先用 DayWeek 组合时间表数量多且规则复杂时再上 Compact并且给每一段加注释行方便三个月后回来看得懂。3. 热区与内扰Zone、People、Lights、Equipment 的建模次序与字段陷阱模型从骨架阶段进入运转阶段标志就是开始往 Zone 里填人和设备。在 IDF Editor 左侧列表中Zone 类在靠后的位置People、Lights、ElectricEquipment、OtherEquipment 紧跟在后面它们在逻辑上是一个整体——先有热区才谈得上热区内部的热扰动项。3.1 Zone几何字段里藏着三个常见默认值误区Zone 对象在必填名称之外前几个字段都是几何相关Direction of Relative North、X/Y/Z Origin、Multiplier、Ceiling Height、Volume、Floor Area。其中 Multiplier 是个非常实用的字段表示这个区域代表 N 个完全相同的区。比如一层有 12 间布局一样的办公室写 1 个 Zone 然后 Multiplier12比复制 12 个 Zone 再贴 12 遍内表面高效得多运行速度和文件体积都有明显改善。Volume 和 Floor Area 两个字段有一个设计得比较隐蔽的默认逻辑留空的话EnergyPlus 会根据外表面几何自动计算但前提是你的表面模型必须构成封闭空间。如果你的模型是从建模软件体块直接转换来的很可能存在微小的缝隙或重叠面这时候软件算出来的体积和设计值能差出 5%~10%直接影响热容和负荷曲线的形状。所以我在建模时一定手动填这两个值并且让它们和建筑专业提供的面积表对得上。Ceiling Height 同理如果填了体积却没填面积软件会用体积除以层高反推面积层高一旦填错后面所有按面积算的负荷人员密度、照明功率密度全部跟着错。Zone, OfficeZone, !- Name 0, !- Direction of Relative North 0, !- X Origin 0, !- Y Origin 0, !- Z Origin 1, !- Multiplier 3.0, !- Ceiling Height 180.0, !- Volume 60.0, !- Floor Area , !- Zone Inside Convection Algorithm , !- Zone Outside Convection Algorithm Yes; !- Part of Total Floor Area另一个容易踩的是 Part of Total Floor Area 字段默认 Yes。如果模型里有设备夹层、管廊这类不计入建筑面积的空间记得改成 No否则建筑总面积统计会虚高照明功率密度和人员密度的控制指标反而被稀释了对后续绿建评估和能耗对标都会产生误导。3.2 People/Lights/ElectricEquipment设计值、时间表与散热分成这三类内扰对象的字段结构高度相似对象名、所属 Zone、时间表、设计值计算方式、设计值、以及一串散热比例系数。设计值计算方式一般有按总设计值、按单位面积、按每人三种我建议统一用按单位面积People/Zone Floor Area、Watts/Area这样和设计提资表的单位一致复核起来最省事。People 对象里容易被忽略的是 Fraction Radiant 和 Sensible Heat Fraction。前者表示人员散热量里以辐射形式释放的比例默认 0.3 左右后者如果留空软件会根据活动强度自动计算显热和潜热的分配。如果你在 Activity Level Schedule Name 里填了办公室静态活动这类代谢率约 117 W/人的时间表软件会自动拆分显热与潜热否则默认值可能偏离实际。我见过不少模型只填人数、不填活动水平结果夏季潜热负荷明显偏小空调除湿量算出来几乎为零和实测完全对不上。People, OfficeZone_People, !- Name OfficeZone, !- Zone or ZoneList Name Office_People_Sched, !- Number of People Schedule Name People/Zone Floor Area, !- Number of People Calculation Method , !- Number of People 0.1, !- People per Zone Floor Area , !- Zone Floor Area per Person 0.3, !- Fraction Radiant , !- Sensible Heat Fraction ActivityLevel_Sched; !- Activity Level Schedule NameLights 对象里的 Return Air Fraction 是回风带走的照明热量比例这个字段直接影响风机能耗和空调冷量分配。如果房间是吊顶回风照明热量大部分会进入回风而不是房间Return Air Fraction 可以设到 0.5 甚至 0.7普通顶棚散热就保持 0。很多人在这步偷懒不填默认 0 的情况下照明散热全算进房间显热夏季冷负荷偏保守精细化校核时这个偏差并不小。Lights, OfficeZone_Lights, !- Name OfficeZone, !- Zone or ZoneList Name Office_Lights_Sched, !- Schedule Name Watts/Area, !- Design Level Calculation Method , !- Lighting Level 11.0, !- Watts per Zone Floor Area , !- Watts per Person 0.0, !- Return Air Fraction 0.6, !- Fraction Radiant 0.2, !- Fraction Visible 0.7; !- Fraction ReplaceableElectricEquipment 的字段里Fraction Latent、Fraction Radiant、Fraction Lost 三个比例加起来通常不需要等于 1剩余部分才是进入室内空气的对流显热。很多新手会纠结三个比例相加不是 1 是不是写错了其实 EnergyPlus 的设计就是让 Lost 单独拿出来模拟散热到室外或非空调空间的部分。ElectricEquipment, OfficeZone_Equip, !- Name OfficeZone, !- Zone or ZoneList Name Office_Equip_Sched, !- Schedule Name Watts/Area, !- Design Level Calculation Method , !- Design Level 12.0, !- Watts per Zone Floor Area , !- Watts per Person 0.0, !- Fraction Latent 0.3, !- Fraction Radiant 0.0; !- Fraction Lost设备时间表也别直接抄人员时间表。办公电脑有大量待机功耗白天人员午休时设备并不会归零好的做法是单独建一张带待机基线的设备时间表比如9:00~18:00 为 1.0其余时段 0.2。这样全年电耗里既算出了工作时段的主负荷也算出了夜间的待机损耗和实际电费账单做对比时更容易对得上。4. 输出体系让模拟结果可读、可查、可汇报跑完模拟后的第一件事是打开 eplusout.err 看警告第二件事就是导出结果。输出这块的类在 IDF Editor 里是 O 开头的一堆Output:Variable、Output:Meter、Output:Table:SummaryReports、Output:Table:Monthly 等。它们不参与计算但配得不好等于白跑一趟。4.1 Output:Variable选点、频次与文件体积的平衡Output:Variable 的结构非常简洁核心字段就三个Key Value、Variable Name、Reporting Frequency。Key Value 填 * 代表所有对象都输出也可以填某个具体对象名来限定范围。Variable Name 强烈建议通过 IDF Editor 的下拉列表去选而不是手敲因为 EnergyPlus 的变量名非常严格比如 Zone Air Temperature 和 Zone Mean Air Temperature 是两个不同的变量手敲很容易踩拼写坑。Output:Variable, *, !- Key Value Zone Air Temperature, !- Variable Name Hourly; !- Reporting FrequencyReporting Frequency 的选项从 Timestep 到 RunPeriod 都有一般建议调试阶段用 Hourly 看逐时曲线月度或年度汇总用 Monthly/RunPeriod只有排查瞬态控制问题时才用 Timestep。拿一个大中型办公楼的模型举例在全项目范围输出 20 个变量、频率设为 Timestep生成的 CSV 能到几百 MB打开和处理都很难受同样 20 个变量改成 Hourly文件体积能缩小一个数量级信息量对绝大多数分析完全够用。我自己的习惯是分两批配置第一批是固定模板全年 Hourly 输出各 Zone 的空气温度、含湿量、总冷热负荷以及各空调系统的供冷供热量第二批是临时调试按需添加 Timestep 频率的瞬态量调试完就删掉绝不留在最终版 IDF 里。这样既保证了正式分析有完整数据又不会让结果文件变得不可收拾。4.2 Meter 与 SummaryReports不写自定义变量也能拿到结论Output:Variable 是按单个变量输出的原始数据Output:Meter 给出的则是系统级的汇总计量比如 Electricity:Facility、NaturalGas:Facility 这种整栋楼的口径。Meter 的好处是单位已经统一成 kWh、GJ 等不用自己再做积分求和。EnergyPlus 的 Meter 名称体系是分层的Facility 是最顶层下面按 InteriorLights、SpaceHeating、Cooling 等继续细分。哪怕你一个 Output:Variable 都不写只要在 Output:Meter 里写上 Electricity:Facility 和 NaturalGas:Facility全年能耗总量就有了。Output:Meter, Electricity:Facility, !- Key Name Hourly; !- Reporting FrequencyOutput:Table:SummaryReports 则是更省事的方案它直接生成排好版的表格。AllSummary 会包含建筑总面积、单位面积能耗、峰值负荷等一整套汇总用来做初步报告几乎不用再加工。对一个常规项目我的最小配置是Output:Meter电、气各一个、Output:Table:SummaryReportsAllSummary再加上少数几个核心 Output:Variable。表格用来汇报逐时变量用来深入分析两套数据互相印证基本不会遗漏关键结论。Output:Table:SummaryReports, AllSummary, BuildingSummary, ZoneTemperatureSummary;5. 实操习惯把 Class List 从字典变成工作台到这里Part Ⅱ 的核心类基本都过完了。最后分享几个我在实际项目中反复用到的组织习惯它们不是某个类的字段功能却能帮你少走很多弯路尤其是当你手头同时维护三四个模型的时候。5.1 引用顺序与命名规范排错成本最低的组织方式IDF Editor 左侧的类列表按字母序排列但模型的依赖关系却是网状的Material 被 Construction 引用Construction 被 Surface 引用Schedule 被 People、Lights 引用Zone 被内扰和 HVAC 引用。虽然 EnergyPlus 在读取时会做引用完整性检查但一个大型模型如果对象顺序混乱排查未定义引用的成本会非常高。我习惯把新建对象的顺序固定为环境与模拟控制、材料与构造、ScheduleTypeLimits、各类时间表、Zone 与内扰、HVAC 与输出。这样在文本编辑器里翻文件时依赖链条一眼就能顺着看下来。命名规范这件事年轻的时候觉得无所谓直到有次一个模型里同时出现 Office_Zone_People_1 和 Office_People_Zone_1排查了两天才发现是同一个对象被引用了两次。现在我的规则很简单对象名前缀标识类型后缀标识所在区域例如 SCH_Frac_Office_People、ZN_Office_Main、MAT_Concrete_200、EQ_Office_PlugLoad。在 IDF Editor 的下拉列表里这种前缀命名能让同类对象聚在一起选引用时一眼就能定位不会眼花缭乱。5.2 一套最小可跑通的类组合我的默认模板给第一次从零开始建模的朋友一份兜底清单。一个能正常完成全年能耗分析的模型最少需要下面这些类缺一个就会在报错阶段被卡住Version指定 EnergyPlus 版本IDF Editor 会自动生成SimulationControl 与 TimestepSizingPeriod:DesignDay至少一组夏季、一组冬季RunPeriod全年模拟窗口Site:Location 与天气文件路径围护结构Material、Material:NoMass、Construction几何Zone、Surface外墙、内墙、屋顶、楼板、Window如果要开窗时间表ScheduleTypeLimits、Schedule:Day:Interval或 Hourly、Schedule:Week:Compact内扰People、Lights、ElectricEquipment输出Output:Variable、Output:Meter、Output:Table:SummaryReports每次新建项目我就把这套模板从老模型里复制过来只改场地、气候和几何数据然后逐步添加复杂系统。模板的好处除了省时间更重要的是默认配置已经经过验证不会出现忘了填 Volume或ScheduleTypeLimits 类型不匹配这种低级错误。模板里我还固定放了一个 Timestep 频率的 Zone Air Temperature 输出任何模型出问题时第一件事就是打开这条曲线快速判断收敛是否正常。另外一个小技巧跑完第一步永远先开 eplusout.err从上往下按 Fatal Error、Severe、Warning 分级处理。Warning 不一定会让结果报废但像 Schedule limits exceeded 这类警告说明时间表数值越界了数值本身会被钳制到上下限你不看警告根本不知道。这个习惯我坚持了几年省下的排错时间远远超过多输出几个变量带来的那点开销。对我来说把这几类理顺之后IDF Editor 左侧那一列就不再是让人犯晕的字母清单了。每次打开一个新模型我都是顺着这个顺序从上到下扫一遍心里直接有数哪块还没建、哪个引用有风险、哪个字段走了默认值。把这些类吃透你的模型就能从能跑真正进入跑得对的状态。
