Add NFP for SpaceLoadDefinitions#11614
Conversation
|
Group discussion at the EnergyPlus technicalities meeting was favorable, but one discussion point was (and is) the split between what goes in the instance object versus what goes in the definition object. Please comment with your thoughts in case we need to make any revisions to the design. |
|
There was discussion about the Multiplier field too : in OpenStudio each SpaceLoadInstnace has a "Multiplier" field, which was omitted to limit the scope of the NFP, but it is actually quite valuable. The only small issue is that the ElectricEquipment:ITE:AirCooled kinda has it already, but just for the case when Design Power Input Calculation Method = EquipmentLevel
|
|
Overall, I can see the value in pursuing this. Saving the repetition of certain fields in numerous places in the input would be a good thing. While there was discussion or perhaps this setting a precedent, I think several precedents have already been set. Recent work done to the radiant systems split the input into two objects in a somewhat similar fashion. The key is to fully determine what is rationally most likely to stay the same from object to object and include that in the "design" or "definition" object. It seemed like during the call discussion that there was a multiplier that was part of the base object--that would be an excellent idea since it would allow a lot more flexibility. The multiplier would potentially make it possible for everything to use a single definition object within a file (like who is going to change fraction radiant for people between different spaces?). Overall, this seems like a reasonable concept and the solution being proposed is good though it's possible that others might have arguments for some inputs being switched from the base to the definition or vice versa? |
JasonGlazer
left a comment
JasonGlazer
left a comment
There was a problem hiding this comment.
Of the three NFPs related to OpenStudio, I think this one probably deserves some more due diligence. It will impact almost all users and I believe for many, perhaps most, it will be adding to a burden rather than reducing one. When modeling an actual building design, the modeler often counts the lighting and plug load power for each zone. In this workflow, adding a separate definition object simply adds complexity of a second object and another object name to remember. I think it deserves some user outreach to current modelers that use EnergyPlus directly to see if it is viewed as more of a benefit or more of a hassle. While I am not opposed to this, I typically create prototypical models which would benefit from this approach. I would hate to see a lot of push back from the user community seeing this for the first time at a future release.
| - Heat gain fraction fields | ||
| - Type-specific fields (fuel type, CO₂ generation, thermal comfort model choices, ITE parameters, etc.) | ||
|
|
||
| For example, `ElectricEquipment` goes from a single object with fields for zone name, schedule, design level method, fractions, and end-use subcategory, to: |
There was a problem hiding this comment.
Please revise the NPF to explicitly show how each of the eight current input objects will be revised into two objects. It is especially difficult to understand what will be happening to the People and Lights input objects since they are more complicated.
| Zone1 Workstation, !- Name | ||
| Workstation Def, !- Electric Equipment Definition Name | ||
| Zone 1, !- Zone or ZoneList or Space or SpaceList Name | ||
| Office Schedule, !- Schedule Name |
There was a problem hiding this comment.
It seems like the operation of an end-use is tightly coupled with the end use itself so perhaps the schedule should be part of the obj:Definition.
There was a problem hiding this comment.
The Schedule is installation specific, not physical, it is more logical in the Instance rather than the Definition.
A definition could be used for a lighting level, and used in two spaces with different schedules because they are used on a different schedule.
| Workstation Def, !- Electric Equipment Definition Name | ||
| Zone 1, !- Zone or ZoneList or Space or SpaceList Name | ||
| Office Schedule, !- Schedule Name | ||
| Workstations; !- End-Use Subcategory |
There was a problem hiding this comment.
The end-use subcategory seems like it is closely associated with the equipment also so maybe it belongs in the obj:Definition input object.
There was a problem hiding this comment.
Having it on the Instance gives you more flexibility. You can have a definition for 10W/m2 equipment, but use unique End Use Subcategory ("Space 1 Equipment" and "Space 2 Equipment" for eg) and you'll get info in the tabular reports.
| ElectricEquipment:Definition, | ||
| Workstation Def, !- Name | ||
| Watts/Area, !- Design Level Calculation Method | ||
| , , !- (Equipment Level, Watts/Area, Watts/Person) |
There was a problem hiding this comment.
The Watts/area and Watts/person make sense to have in the obj:Defintion input objects since they can be applied to different sized zones but the Total power level expressed in Watts seems unlikely to be in needed in the obj:Definition. Maybe it should stay in the original object.
There was a problem hiding this comment.
An absolute value could be used in a single definition, and several instances would use a different schedule.
Also, it should be clearer soon after we push a revision to the NFP to include the multiplier field: you could define a definition with absolute value (a 100W workstation, a 60 W Light bulb) and use it in several instances with a different multiplier (and schedule if you wanted).
|
|
||
| 1. **Alignment of EnergyPlus and OpenStudio** — the EnergyPlus IDD and the OpenStudio Model API now share the same conceptual shape, reducing the translation surface and the associated maintenance burden. Allowing usage of OpenStudio directly on an IDF will provide ability to work on **any** IDF, including fully unsupported objects (objects not wrapped in OpenStudio model/ namespace) and objects which don't have ReverseTranslator rules (the ReverseTranslator IDF -> OSM is lacking in terms of HVAC especially). | ||
| 2. **DRY input data** — a single `ElectricEquipment:Definition` describing, say, a standard office workstation can be referenced by any number of `ElectricEquipment` instances across the building, each with its own zone/space assignment and schedule, without repeating the physical characteristics. | ||
| 3. **Cleaner IDD semantics** — the split makes explicit which properties are intrinsic to the load type (the definition) and which are extrinsic, installation-specific concerns (the instance). |
There was a problem hiding this comment.
The question of better semantics seems 25 years to late. At this point users are used to the current approach and should see a specific benefit for the change.
| By introducing the same Instance/Definition pattern in EnergyPlus, we achieve three concrete benefits: | ||
|
|
||
| 1. **Alignment of EnergyPlus and OpenStudio** — the EnergyPlus IDD and the OpenStudio Model API now share the same conceptual shape, reducing the translation surface and the associated maintenance burden. Allowing usage of OpenStudio directly on an IDF will provide ability to work on **any** IDF, including fully unsupported objects (objects not wrapped in OpenStudio model/ namespace) and objects which don't have ReverseTranslator rules (the ReverseTranslator IDF -> OSM is lacking in terms of HVAC especially). | ||
| 2. **DRY input data** — a single `ElectricEquipment:Definition` describing, say, a standard office workstation can be referenced by any number of `ElectricEquipment` instances across the building, each with its own zone/space assignment and schedule, without repeating the physical characteristics. |
There was a problem hiding this comment.
I like the idea of reducing redundancy but for many models in which the lighting and plug loads are determined by specific take offs, this is actually increasing the effort for the modeler, they now have two objects to manage instead of one and another name. Personally, I think the excessive number of named input objects is what makes IDF files so complicated to follow and increases the learning curve for new users. This would be adding to that burden.
- Fix typo and grammar issues in the expanded NFP text. - Add Multiplier rows to the field-location tables. - Make proposed Multiplier fields real values with minimum 0 and default 1. - Keep operation and loading schedules on instance objects, including the ITE CPU loading schedule. - Use Multiplier consistently for ITE instead of Number of Units. - Document transition handling for mapping existing ITE Number of Units to Multiplier.
|
As discussed at the 6/10 Technicalities meeting, we would like to adjust this PR so that it is backwards compatible. The existing space loads shall remain the same and the NFP will add new instance and definition objects. For example, People will remain exactly as is. We will add People:Instance and People:Definition. There will be no transition rules. |
|
[TRANE] No major comments here. We are not sure about whether we'd pull this in to our version of the engine, so if it makes sense for EnergyPlus to adopt this, then seems like a good approach. [Myoldmopar] I am glad you resolved to make this backwards compatible. No need to break everyone's files and add transition rules for this when it can be a new optional object. The use of definitions/templates/instances/whatevers can be a nice improvement when building apps, so having this would be useful for some stakeholders I suspect. |
7 participants
Pull request overview
Adds the NFP design document for splitting internal gains objects into instance and definition objects, aligning EnergyPlus with OpenStudio’s reusable space load definition pattern.