3.1.11 Managing User Input

This section addresses the processes of data entry and the validation of user input data that can be performed prior to and independent of the energy simulation.

Building Descriptor Inputs and Restrictions

Building descriptors are discussed in Chapter 6 and listed in tabular form in Appendix A. Building descriptors are classified in one of several ways:

• Reference. Information that does not affect the energy rating results, such as the name of the architect, the address of the building, or rating authority applications numbers.
• Trigger. A building descriptor that turns on or turns off the applicability of other building descriptors. An example is the daylight modeling method.
• Asset. Information about the rated building that does affect the results such as insulation levels, window construction or equipment efficiency.
• Special Asset. Information about the rated building that is considered an asset, but requires special documentation of performance. Examples include reduced infiltration or credit for natural ventilation.
• Neutral Dependent. Information that is the same for both the rated building and the baseline building. The baseline building assumes the same conditions specified for the rated buildings. Examples are schedules of operation, temperature settings, etc. For purposes that do not use a modeled baseline building, such as Design to Earn ENERGY STAR, the designation of “neutral dependent” means that the rating process attempts to neutralize for this variable.
• Use-or-Lose. This is a special case of a neutral dependent classification except that baseline value has a floor or ceiling. An example is retail display lighting whereby the baseline building is equal to the rated building up to a maximum power limit. When the rated building value is within an acceptable range, the use-or-lose” variable is neutral dependent. When the value for the rated building is outside the acceptable range, the building descriptor is an asset.
• Neutral Independent. Information that is the same for both the rated building and the baseline building, but is prescribed. Examples are schedules of operation when the purpose is federal tax credits.
• Defaults are provided for many building descriptors. A common default is provided for convenience and may be overridden by the user with no special documentation. However, when a default is provided for a special asset, the value must be used unless special documentation is provided.  

Building descriptors may also be classified by the level of software support that is required: compulsory, required, optional, and unsanctioned. Compulsory inputs must always be supported by the software and specified by the user. Required inputs shall be supported by the rating software but they may not be applicable for all ratings. Optional inputs are addressed in this anual and restrictions may apply, but it is up to the software vendor as to whether the inputs are supported. Unsanctioned inputs are inputs that are not addressed in this manual; these are not listed in Appendix A or discussed in Chapter 6.

Restrictions may apply to all compulsory and required inputs. Appendix A specifies the compulsory building descriptors. Examples of compulsory inputs are climate zone, floor area, and space-by-space classification. If the software provides a means for the user to input building descriptors listed as optional in Appendix A, all input conditions and restrictions shall apply.

The software user interface shall: 1) clearly indicate when a building descriptor has an associated default, 2) indicate what the default value is, and 3) provide a convenient means for the user to over-ride the default. When default values for special assets are overridden, the software interface shall notify the user that documentation is required. 

For neutral independent building descriptors, the software is not required to provide a means for users to enter data since the software will automatically assign the prescribed value. However, if the user is permitted to input values for prescribed inputs, the software must inform the user that a prescribed value and not the value input by the user will be used in calculating the rating.

No restrictions are specified for unsanctioned inputs. If the software uses unsanctioned inputs, the software documentation or help system shall specify the applicability of the building descriptors, its definition, the units in which it is expressed, restrictions on input for the proposed design, and, if applicable, how the building descriptor is defined for the baseline building.

The software may assist the user in describing the proposed design by displaying typical values for building descriptors, provided deliberate action by the user is necessary before a displayed value is used.

Data Validation

Compulsory Input Checks

The software shall check to ensure that valid entries have been made for all compulsory building descriptors before the user is permitted to proceed with the next step in the rating process.

Handling of Missing Inputs

If a required input is missing or invalid, the software shall: 1) notify the user that the input is missing or invalid, 2) identify the input field(s) with missing or invalid data, and 3) prevent the user from moving to the next step of the rating process. The software may provide additional information designed to help the user correct the deficiency.

Validity Checks

The software shall check all user inputs to ensure that the following conditions are met:

• Simulation Tool Limits. Inputs do not exceed the minimums or maximums for the parameters permitted by the simulation engine.
• Rating Rule Limits. Inputs do not exceed minimums or maximums for the descriptors specified in Chapter 6 of this document.
• Simulation Tool Discrete Options. Inputs correspond with valid discrete or list options for parameters available in the simulation engine.
• Rating Rule Discrete Options. Inputs correspond with valid discrete options provided for in Chapter 6.

Handling Invalid Input

When invalid data is entered, the software shall: 1) notify the user of the invalid input, 2) identify the nonconforming input field, and 3) prevent execution of the next step of the rating process; i.e., generating the input description for the proposed design. The software may provide additional information designed to help the user correct the deficiency.

Consistency Checks

The consistency checks described above are intended to identify errors and oversights in user input and thereby help ensure that the building description is complete and interpretable by the energy analysis program. Examples of consistency checks include making sure that total window area does not exceed the wall area in which they are contained and that the necessary plant equipment has actually been connected to the secondary HVAC systems. The software may include additional consistency checks provided these are clearly documented in the user documentation or on-line help system.

Handling Inconsistent Input

If the proposed design fails a consistency check, the software shall: 1) notify the user that an inconsistency exists, 2) identify the specific consistency check that has been failed, 3) identify the inconsistent input fields, if feasible, and 4) prevent execution of the next step of the rating process; i.e., generating the input description for the proposed design. The software may provide additional information designed to help the user correct the deficiency.