Clarify object input design rules

[mjwitte]

The "Input Concepts" section of the Module Developers Guide discusses rules for object input design. This section needs some updating and clarification.

References to other objects

This issue was initially prompted regarding the convention that references to another object type should always be a pair of fields, e.g. Cooling Coil Object Type, and Cooling Coil Name. This is stated in the guide, but it gets lost in the midst of a larger discussion and is scattered in multiple locations.

"When object names/types are included as part of the input, then the field name should contain “Object Type”: Example: Zone Equipment 1 Object Type"

"When field choices list object references, the field choices shall list the class/object type name the same as its class definition in the IDD."

"The “standard” for describing such fields would be to list the “coil type” and then the “coil name” fields, such as in the UNITARYSYSTEM:HEATPUMP:AIRTOAIR object."

Redundant child object node names in parent objects

Another convention which I do not find in the module developers guide is the move towards eliminating child object node names in parent object inputs. Initially, the design concept was that everything a component needs to know should be include in it's input. Thus early versions of parent objects, such as ZoneHVAC:FourPipeFanCoil included references to child components node names for use in controlling the overall fan coil system: A3 , \field Air Inlet Node Name \required-field A4 , \field Air Outlet Node Name \required-field A5 , \field Outdoor Air Node Name \required-field A6 , \field Air Relief Node Name \required-field A7 , \field Cold Water Inlet Node Name \required-field A8 , \field Hot Water Inlet Node Name \required-field

A few years back ( @rraustad would remember when) there was a move towards mining these node names from the child object in order to simplify input and avoid errors and avoid the need for verifying that these node names matched the node names in the child object (see SetUpCompSets/TestCompSet whose sole purpose it to catch such node name errors). The fan coil object has now been reduced to only two node names, which are the overall inlet and outlet of the fan coil unit: A5 , \field Air Inlet Node Name \required-field \type node A6 , \field Air Outlet Node Name \required-field \type node

All zonehvac:* objects were updated to eliminate these redundant node names, but there was not a push to purge these from all parts of the code (e.g. Branch and WaterHeater:HeatPump objects). And all new objects are supposed to avoid this type of redundant input, but I do not see any mention of this in the Module Developers Guide.

The intent of this issue is to get these (and other?) rules clearly listed. Beyond that, we should discuss whether it is time to push towards eliminating these redundant node names everywhere which would invoke a significant amount of transition requirements but may be welcomed by interface developers and users alike. The most significant of these would be the Branch object where the node names (and the branch control type which is not used, at least in plant, maybe still used in air loops?) could be eliminated. This would reduce the fields per object on the branch from 5 to 2 (just type and name).

[nmerket]

Definitely interested in where this ends up.