Revision history [back]

I have never done it but I think one solution would be to create as many constructions as you want your u-value to vary and write an EMS program that changes the construction assigned to a particular surfaces using the Construction State Actuator based on for instance a schedule.

I have never done it but I think one solution would be to create as many constructions as you want your u-value to vary and write an EMS program that changes the construction assigned to a particular surfaces using the Construction State Actuator based on for instance a schedule.

I have never done it but I think one solution would be to create as many constructions as you want your u-value to vary and write an EMS program that changes the construction assigned to a particular surfaces using the Construction State Actuator based on for instance a schedule.

EDIT: Here is more infor info from the EMS Application Guide

An actuator is available for controlling the construction assigned to a surface that can be useful for modeling dynamic technologies for thermal envelopes. These actuators are called “Surface” and have a control type “Construction State.” This actuator is used in conjunction with the input object called EnergyManagementSystem:ConstructionIndexVariable. Each Construction object defined in an input file has an index that points to where the data for that construction are stored in the program’s internal data structures. The EnergyManagementSystem:ConstructionIndexVariable input object is used to create and fill a global Erl variable with the value that points to the specific construction named in the object. The Erl variable is what you assign to the construction state actuator’s variable to override the construction assigned to a particular surface. When the actuator is set to Null, the surface reverts to the Construction originally referenced by the surface in the input file. Using the surface construction state actuator brings with it a high degree of risk when it comes to modeling thermal heat capacity and transient heat transfer in opaque surfaces. If this actuator is used inappropriately, for example to assign different constructions, to a single surface, that have radically different heat storage capacities, then the heat transfer modeling results may not be physically accurate. When a construction state is overridden using this actuator, the thermal history data that evolved while using the previous construction are reused for the new construction. When this actuator is used, the program attempts to detect if incompatible constructions are being assigned. In some cases it issues a warning and allows the assignments to proceed, in others it warns and doesn’t allow the assignment to proceed. If the original construction assigned to a surface has internal source/sink (defined using Construction:InternalSource) then any assignments to the surface must also be internal source constructions. If using the heat transfer algorithm called ConductionFiniteDifference, then the constructions must have the same number of finite difference nodes or the assignment is not allowed. The construction state actuator cannot be used in conjunction with the heat transfer algorithms called ConductionFiniteDifferenceSimplified or CombinedHeatAndMoistureFiniteElement

I have never done it but I think one solution would be to create as many constructions as you want your u-value to vary and write an EMS program that changes the construction assigned to a particular surfaces using the Construction State Actuator based on for instance on, for instance, a schedule.

EDIT: Here is more info from the EMS Application Guide

An actuator is available for controlling the construction assigned to a surface that can be useful for modeling dynamic technologies for thermal envelopes. These actuators are called “Surface” and have a control type “Construction State.” This actuator is used in conjunction with the input object called EnergyManagementSystem:ConstructionIndexVariable. Each Construction object defined in an input file has an index that points to where the data for that construction are stored in the program’s internal data structures. The EnergyManagementSystem:ConstructionIndexVariable input object is used to create and fill a global Erl variable with the value that points to the specific construction named in the object. The Erl variable is what you assign to the construction state actuator’s variable to override the construction assigned to a particular surface. When the actuator is set to Null, the surface reverts to the Construction originally referenced by the surface in the input file. Using the surface construction state actuator brings with it a high degree of risk when it comes to modeling thermal heat capacity and transient heat transfer in opaque surfaces. If this actuator is used inappropriately, for example to assign different constructions, to a single surface, that have radically different heat storage capacities, then the heat transfer modeling results may not be physically accurate. When a construction state is overridden using this actuator, the thermal history data that evolved while using the previous construction are reused for the new construction. When this actuator is used, the program attempts to detect if incompatible constructions are being assigned. In some cases it issues a warning and allows the assignments to proceed, in others it warns and doesn’t allow the assignment to proceed. If the original construction assigned to a surface has internal source/sink (defined using Construction:InternalSource) then any assignments to the surface must also be internal source constructions. If using the heat transfer algorithm called ConductionFiniteDifference, then the constructions must have the same number of finite difference nodes or the assignment is not allowed. The construction state actuator cannot be used in conjunction with the heat transfer algorithms called ConductionFiniteDifferenceSimplified or CombinedHeatAndMoistureFiniteElement