This group of objects describe concepts applied to heat
transfer surfaces that are of an advanced nature. Careful
consideration must be given before using these.
This object, and three other related objects, can be used
to control which surface heat transfer model is used on
specific surfaces. The separate object called HeatBalanceAlgorithm
is used to control the heat transfer model in an overall way
while this object can be used to revise the algorithm
selections for specific surfaces. This object allows
selectively overriding the global setting in HeatBalanceAlgorithm
to choose one of the following models for a particular
surface:
CTF (Conduction Transfer Functions),
EMPD (Effective Moisture Penetration Depth with
Conduction Transfer Functions).
This is the name of the surface that will be assigned to
use the heat transfer algorithm selected in the next field.
This should be a name of a surface defined elsewhere.
This field is used to determine the heat transfer algorithm
that is to be applied to the surface named in the previous
field. The allowable choices are:
This object can be used to control the surface heat
transfer model used for specific types of surfaces. The
separate object called HeatBalanceAlgorithm
is used to control the heat transfer model in an overall way
while this object can be used to revise the algorithm
selections for specific types of surfaces. This object allows
selectively overriding the global setting in HeatBalanceAlgorithm
to choose one of the following models for all surfaces of a
particular type:
CTF (Conduction Transfer Functions),
EMPD (Effective Moisture Penetration Depth with
Conduction Transfer Functions).
This field is selects the type of surfaces that are all
assigned to use the heat transfer algorithm selected in the
next field. This field is used with one of the following
allowable keywords:
AllExteriorSurfaces—all surfaces that have “Outdoors”
outside boundary condition
AllExteriorWalls—all walls that have “Outdoors” outside
boundary condition
AllExteriorRoofs—all roofs that have “Outdoors” outside
boundary condition
AllExteriorFloors—all floors that have “Outdoors”
outside boundary condition
AllGroundContactSurfaces—all surfaces that have
“Ground” outside boundary condition
AllInteriorSurfaces—all surfaces that are internal
partition-type surfaces
AllInteriorWalls—all walls that are internal
surfaces
AllInteriorCeilings—all ceilings that are internal
surfaces
AllInteriorFloors—all floors that are internal
surfaces
This field is used to determine the heat transfer algorithm
that is to be applied to the surface types in the previous
field. The allowable choices are:
This object can be used to control the surface heat
transfer model used for a list of surfaces. The separate
object called HeatBalanceAlgorithm
is used to control the heat transfer model in an overall way
while this object can be used to revise the algorithm
selections for a list of specific surfaces. This object allows
selectively overriding the global setting in HeatBalanceAlgorithm
to choose one of the following models for listed:
CTF (Conduction Transfer Functions),
EMPD (Effective Moisture Penetration Depth with
Conduction Transfer Functions).
This field is used to determine the heat transfer algorithm
that is to be applied to the surface listed in the remaining
fields. The allowable choices are:
This is the name of the “Nth” surface that will be assigned
to use the heat transfer algorithm selected in this object.
These should be the names of surfaces defined elsewhere. This
object is extensible. Additional surfaces can be added to
extend the object.
An example IDF object follows.
SurfaceProperty:HeatTransferAlgorithm:SurfaceList,
my wall construct override, !- Name
ConductionFiniteDifference, !- Algorithm
Zn001:Wall001, !- Surface Name 1
Zn001:Wall002, !- Surface Name 2
Zn001:Wall003, !- Surface Name 3
Zn001:Wall004; !- Surface Name 4
This object can be used to control the surface heat
transfer model used for surfaces that have a specific type of
construction. The separate object called HeatBalanceAlgorithm
is used to control the heat transfer model in an overall way
while this object can be used to revise the algorithm
selections for specific constructions. This object allows
selectively overriding the global setting in HeatBalanceAlgorithm
to choose one of the following models for all surfaces with
particular type of construction:
CTF (Conduction Transfer Functions),
EMPD (Effective Moisture Penetration Depth with
Conduction Transfer Functions).
This field is used to determine the heat transfer algorithm
that is to be applied to the surfaces with the type of of
construction listed in the next field. The allowable choices
are:
This field is the name of a Construction
object defined elsewhere. All the surfaces in the model that
are assigned this type of construction will be assigned to use
the heat transfer algorithm selected in the previous
field.
An example IDF object follows.
SurfaceProperty:HeatTransferAlgorithm:Construction,
my wall construct override, !- Name
ConductionFiniteDifference, !- Algorithm
R13WALL; !- Construction Name
Movable insulation can be used/scheduled on any surface
regular surface (such as a wall, floor, roof, etc.) but not on
a subsurface (such as a window, use WindowShadingControl
instead). With movable insulation, no reference is made in the
surface that is using the insulation – rather the movable
insulation statement references the surface to which it is
applied.
Exterior and interior movable insulation have undergone
some testing and appears to producing expected results. The
underlying principle has been implemented in EnergyPlus for
both interior and exterior movable insulation with the
possibility for exterior movable insulation to be transparent
(transparent insulation material or TIM).
TIM exterior layers can be used with the
ConductionFiniteDifference (CondFD) solution algorithm. With
this addition, TIM layers can be used in conjunction with wall
layers that have phase change materials (PCM) included, or any
other advanced capability of the CondFD algorithm such as
variable conductivity. The input requirements are exactly the
same as when used with the CTF algorithm. The Solution
Algorithm needs to be changed to CondFD, and as with CTF, the
“SurfaceControl:MovableInsulation”
object must be completed to specify the insulated surface and
the “WindowMaterial:Glazing”
or “WindowMaterial:Glazing:EquivalentLayer”
object is needed to provide the TIM layer properties.
Basically, the addition of movable insulation allows the
user to schedule an extra amount of insulation on either the
inside or outside surface of a wall (or both). The insulation
must be a simple, homogenous material layer (linked to a
material definition within the input data file). Note that
EnergyPlus allows the exterior movable insulation layer to be
transparent to short wavelength radiation (solar). In this
case, incident solar is split between the plane between the
movable insulation and the surface and the plane between the
movable insulation and the surrounding air. This calculation
is fairly basic and based on the solar transmittance of the
insulation layer (material properties). Using transparent
layers for exterior movable insulation allows solar energy to
penetrate deeper into a construction where it can be stored
for later use in the building (similar in concept to a Trombe
Wall).
This field determines whether the movable insulation is
applied to the inside or the outside of the surface by
entering either “Inside” or “Outside”, respectively.
This field refers the movable insulation back to a
particular surface (ref: Building
Surfaces) via its user assigned name so that EnergyPlus knows
where to apply this extra layer of insulation. This will
affect either the inside or outside surface heat balance of
this surface depending on the value in the insulation type
field (see previous field).
This field refers to a material layer (e.g., Material,Material:NoMass,WindowMaterial:Glazing,
or WindowMaterial:Glazing:EquivalentLayer;
transparent layers are only valid for outside movable
insulation) via its user assigned name. This provides the
program with a full complement of material properties so that
the effect of the insulation (R-value and solar transmittance)
can be correctly taken into account by EnergyPlus. Note that
for non-glazing materials the solar absorptivity of the layer
will be used directly in the calculations. For glazing
material layers, the solar absorptivity will be calculated by
subtracting both the transmissivity and the front side
reflectivity from unity for the material.
This field is a schedule that theoretically can be any
positive real number but was originally intended to be a
parameter between 0.0 and 1.0. Its purpose is to act as a
fractional modifier on the resistance of the material layer.
The actual thermal resistance of the movable insulation is
equal to the resistance of the material layer times the
current value in the movable insulation schedule. A value of
0.0 simply means that the movable insulation is not
present.
An example of this syntax implemented in an input file
is:
SurfaceControl:MoveableInsulation,
Exterior, ! Insulation Type
Zone001:Wall001, ! Surface Name
TransparentInsulationMaterial, ! Material Name
PresentInWinterSchedule; ! Schedule Name
By referencing the Other Side Coefficients statement in the
surface statements (i.e. Outside Boundary Condition), the
temperature of the outer plane of a surface (see Figure 1)
can be directly controlled. Other side coefficients can also
be used to control the exterior convective heat transfer
coefficient of a surface and the corresponding exterior air
temperature. It should be noted that solar effects are not
accounted for when other side coefficients are used. In
addition, if other side coefficients are specified for a
surface, they also hold for subsurfaces of that surface
(though subsurfaces can have their own coefficient set).
other side coefficients have the same effect on all types
of heat transfer surfaces. In other words, an interior surface
with other side coefficients specified and an exterior wall
with identical other side coefficients specified are simulated
exactly the same. A surface that uses other side coefficients
should be thought of as a new or separate type of surface. All
heat transfer surfaces are simulated in the same manner
through conduction transfer functions. The only difference
between the various types of heat transfer surfaces is the
environment on the other side of the surface. For example, the
other side environment of an exterior surface is the outdoor
environment. For an interior surface, the temperature of the
outer plane of the surface is set equal to the temperature of
the inner plane of the surface. Similarly, a surface with
other side coefficients specified will allow the user to
control the other side environment.
Heat transfer through a surface is an extremely important
component in the calculation of zone loads. The information to
calculate this heat transfer is readily available if the
surface is exposed to the outdoor environment or to another
zone that is being simulated. Occasionally, a user will want
to model the heat transfer through a surface that is adjacent
to an area that is not included in the EnergyPlus model. For
example, an office area is attached to a warehouse and the
user is only interested in simulating the office area. An
interior surface with other side coefficients specified could
be used to control the environment on the other side of the
surface, thereby accounting for the heat transfer through the
adjoining surface.
Other Side Coefficients affects the “other side” of a
surface as described below. Each coefficient has a special
meaning. You may enter a 0 or blank if you are not using a
particular coefficient. Note that there are two potential ways
to use other side coefficients. Either they are used to set
the temperature of the exterior side surface directly (if the
combined convective/radiative coefficient below is less than
or equal to zero) or to set both the film coefficient
(positive value for the combined convective/radiative
coefficient below) and the outside air temperature.
This, of course, is the string referenced in the Surface
statement that is using OtherSideCoefficients as the Outside
Boundary Condition.
Field:
Combined Convective/Radiative Film Coefficient[LINK]
This is a trigger value. If the value is greater than zero,
then it is taken to be the combined convective/radiative film
coefficient. In this case (value > 0), the remaining fields
are used first to calculate the outside air temperature for
the surface and then to calculate the outside surface
temperature based on the outside air temperature and the film
coefficient. If this field is less than or equal to zero, then
the remaining fields are used to calculate the surface
temperature (not the outside air temperature). The units for
this field are the same as for a convective heat transfer
coefficient: W/(m\(^{2}\)*K).
This is referred to as “C1” in the reference below.
This field defines a temperature term that is a constant
part of the calculation either of the surface or outside air
temperature. This parameter is shown as “C2” in the equation
below. The units for this parameter are degrees C. If a
schedule name is included as the second parameter, the value
of this parameter will be overridden by the value from the
schedule. The default for this field is 0.0.
This field defines a constant coefficient that is applied
to the constant temperature (see previous field). This
parameter is shown as “C3” in the equation below. This
parameter is dimensionless. The value of this parameter is
usually 1.0 if a schedule is used to set C2. This field is
ignored if Sinusoidal Variation of Constant Temperature
Coefficient = Yes. The default for this field is 1.0.
Field:
External Dry-Bulb Temperature Coefficient[LINK]
This field defines a constant coefficient that is applied
to the outside air dry-bulb temperature. This parameter is
shown as “C4” in the equation below. This parameter is
dimensionless. The default for this field is 0.0.
This field defines a constant coefficient that is applied
to the ground temperature (ref.
Site:GroundTemperature:BuildingSurface). This parameter is
shown as “C5” in the equation below. This parameter is
dimensionless.
This field defines a constant coefficient that is applied
to the product of the outside air dry-bulb temperature and the
wind speed. This parameter is shown as “C6” in the equation
below. This parameter has dimensions of inverse velocity or
s/m. The default for this field is 0.0.
This field defines a constant coefficient that is applied
to the temperature of the zone to which this surface belongs.
This parameter is shown as “C7” in the equation below. This
parameter is dimensionless. The default for this field is
0.0.
This field is used to supply a schedule name. That schedule
will supply the “constant” temperature value C2. Note that the
value of the C3 field should normally be 1.0 if a schedule is
used for C2. If not blank, this field must be a valid schedule
name.
Field:
Sinusoidal Variation of Constant Temperature Coefficient[LINK]
This field is optional and can be used to define an
alternate method of prescribing the coefficient that is
applied to the constant temperature (see the fields Constant
Temperature and Constant Temperature Coefficient). This
parameter is shown as “C2” in the equation below. If this
field is omitted, left blank, or set to “No,” then C2 is a
constant (defined in the field Constant Temperature
Coefficient). However, if this is set to “Yes,” then the value
of C2 varies with a unitary sine wave in the following
way:
The value for “period” is controlled in the following
field. The value for “time of day” is based on the zone
timestep and is in units of hours. The sine function here uses
input as radians. When using this option, the value for C2
will vary between -1.0 and 1.0 and the value put in the field
Constant Temperature Coefficient is not used. This option
cannot be used at the same time as scheduling a constant
temperature with the previous field.
This field is used to define the period of the sine wave
when using the Sinusoidal Variation of Constant Temperature
Coefficient capability selected in the previous field. This
field is the time period of the sine wave in units of hours.
The default is 24 hours and provides a diurnal sine wave. The
value entered here is “period” in the equation in the previous
field.
Field:
Previous Other Side Temperature Coefficient[LINK]
This field defines a constant coefficient that is applied
to the other side temperature computed by this object from the
previous zone time step. This parameter is shown as “C8” in
the equation below. This parameter is dimensionless. The
default for this field is 0.0.
Tpast = Other side temperature from previous zone timestep
(°C)
Illustration for Other Side
Coefficients
! Example input using temperature schedule
SurfaceProperty:OtherSideCoefficients,
OSCCoef:Zn005:Wall003, !- Name
0, !- Combined Convective/Radiative Film Coefficient {W/m2-K}
0.000000, !- Constant Temperature {C}
1.000000, !- Constant Temperature Coefficient
0.000000, !- External Dry-Bulb Temperature Coefficient
0.000000, !- Ground Temperature Coefficient
0.000000, !- Wind Speed Coefficient
0.000000, !- Zone Air Temperature Coefficient
Zn005Wall003OtherSideTempSched; !- Constant Temperature Schedule Name
! Example input for outside heat transfer coefficient of 1.23, using Toadb
SurfaceProperty:OtherSideCoefficients,
OSCCoef:Zn005:Wall004, !- Name
1.230000, !- Combined Convective/Radiative Film Coefficient {W/m2-K}
0.000000, !- Constant Temperature {C}
0.000000, !- Constant Temperature Coefficient
1.000000, !- External Dry-Bulb Temperature Coefficient
0.000000, !- Ground Temperature Coefficient
0.000000, !- Wind Speed Coefficient
0.000000, !- Zone Air Temperature Coefficient
, !- Constant Temperature Schedule Name
No, !- Sinusoidal Variation of Constant Temperature Coefficient
24, !- Period of Sinusoidal Variation {hr}
0., !- Previous Other Side Temperature Coefficient
, !- Minimum Other Side Temperature Limit {C}
; !- Maximum Other Side Temperature Limit {C}
By referencing the Other Side Conditions Model statement in
the surface statements (i.e. Outside Boundary Condition), the
boundary conditions for the outer plane of the mass wall can
be connected to the appropriate model for various multi-skin
components. The types of multi-skin components that use this
object include systems that are mounted to the outside surface
using standoffs that create a small air gap – see Figure 2.
This type of modeling allows using the usual heat transfer
calculations for the underlying surface with other types of
multi-skin component models that are available including:
unglazed transpired solar collectors, ventilated photovoltaic
panels, and naturally ventilated facades.
The boundary condition values are determined dynamically by
the program using internal component models. If you want to
define other side surface temperatures or convection
conditions, then use SurfaceProperty:OtherSideCoefficients
instead of this object.
It should be noted that when other side conditions models
are used, solar effects are removed from the surface’s outside
face heat balance but are used in modeling the component
adjacent to that surface.
The other side conditions model also includes underground
piping system interaction. The PipingSystem:Underground:Domain
object represents a mass of ground which may include
interaction with, for example, basement surfaces. In this
case, the ground model will internally use the other side
condition model hook to update boundary conditions for those
surfaces which use that other side condition model name
reference.
The other side conditions model also includes an underwater
boundary condition connection. By specifying
“ConvectiveUnderwater” as the boundary type, and including any
number of “SurfaceProperty:Underwater”
objects in the input, the user can connect surfaces to water
such as for a moving vessel.
This is a string key selection used to identify the type of
model that will be used to determine boundary conditions. The
only available choices are “GapConvectionRadiation,”
“UndergroundPipingSystemSurface,” “GroundCoupledSurface,” and
“ConvectiveUnderwater.”
Illustration for Other Side
Conditions Model
An example specification is:
SurfaceProperty:OtherSideConditionsModel,
UTSC OSCM ZN11, ! OtherSideConditionsModel Name
GapConvectionRadiation; ! Type of Modeling used to determine Boundary Conditions
This object captures the inputs required to model a
water-connected boundary condition for a surface. This model
is useful for either statically positioned buildings with
natural convection to the water boundary condition, or a
moving building (vessel).
This is the string referenced in the Surface statement that
is using this OtherSideModel as the Exterior Environment.
Field:
Distance from Surface Centroid to Leading Edge of Boundary
Layer[LINK]
This distance represents the distance from the centroid of
this particular surface to leading edge of the boundary layer.
For a surface with zero velocity, this field will be
irrelevant, because there is no forced boundary layer, and
convection will be buoyantly driven. For a moving vessel, this
distance should be the nominal distance from the leading edge
of the vessel, assuming a nearly flat surface along that
path.
Field:
Free Stream Water Temperature Schedule[LINK]
This schedule defines the temperature of the free stream
water used in the convection calculations.
This schedule defines the average velocity of the free
stream water used in the convection calculations. This
schedule could be the water velocity as it moves past
stationary surface, the surface velocity as it moves past
stationary water, or an effective velocity as a result of the
combination.
An example specification is:
SurfaceProperty:Underwater,
Underwater, !- Name
140, !- Distance from Surface Centroid to Leading Edge of Boundary Layer
WaterTempSchedule, !- Free Stream Water Temperature Schedule
VelocitySchedule; !- Free Stream Water Velocity Schedule
Schedule:Constant,
WaterTempSchedule,
Any Number,
23;
Schedule:Constant,
VelocitySchedule,
Any Number,
10.2;
Foundation:Kiva
objects describe boundary conditions for ground-coupled
foundation surfaces. Surfaces with the “Outside Boundary
Condition” defined as “Foundation”, may also refer to a Foundation:Kiva
object in the “Outside Boundary Condition Object” field (if
unspecified, a default Foundation:Kiva
object will be created and applied).
Only floors and walls may use Foundation:Kiva
objects as Outside Boundary Conditions.
For a given zone, each floor surface must reference a
different Foundation:Kiva
object. In other words, multiple foundation floor surfaces may
exist in the same thermal zone so long as they reference
separate Foundation:Kiva
objects. The same Foundation:Kiva
object may be referenced by multiple floors so long as they
are in different zones.
Any number of wall surfaces may reference a single Foundation:Kiva
object so long as that object is referenced by exactly one
floor surface in the same thermal zone.
Foundation wall surfaces that are not triangular or
quadrilateral may not translate well into the two-dimensional
finite difference context.
For each floor surface with “Foundation” set as the
“Outside Boundary Condition” there must also be a
corresponding “SurfaceProperty:ExposedFoundationPerimeter”
object to define how much of the floor perimeter is below
exterior walls.
The inputs from Foundation:Kiva
objects are translated into Kiva’s foundation heat transfer
model. KivaTM generates a two-dimensional heat
transfer calculation to represent heat flow between a zone and
the adjacent ground. Foundation:Kiva
surfaces do not use the same HeatBalanceAlgorithm
(e.g., Conduction Transfer Functions) as the rest of the
model.
Foundation:Kiva
objects are used to describe the two-dimensional features that
cannot be captured by the typical one-dimensional
constructions used in EnergyPlus. Figure 3 illustrates Kiva’s
two-dimensional context for a basement where the basement slab
and wall both refer to “Foundation” as the Outside Boundary
Condition, the ceiling of the basement and the exterior wall
of the zone above the basement refer to “Surface” (or “Zone”)
and “Outdoors”, respectively. Note: Not all of the foundation
wall surface needs to be below grade (see the “Wall Height
Above Grade” field for this object). Any part of the
foundation wall above grade is modeled in Kiva’s
two-dimensional heat transfer calculations. The non-foundation
surfaces are shown in Figure 3
for context, but are not part of the Kiva model.
Outside Boundary Conditions for
surfaces within Kiva’s Two-dimensional context. Only surfaces
referencing “Foundation” are simulated in Kiva
This context allows for a finer description of the
structural and insulation components of a foundation that
impact heat transfer (Figure 4).
Structural and insulation
components of Foundation:Kiva objects
Foundation:Kiva
objects define only the aspects of the foundation that are not
already defined by the one-dimensional constructions of the
respective surfaces. That is, the footing wall and slab
constructions and their relative dimensions are inferred from
the respective Surface objects (see Figure 5).
Two-dimensional interpretation
of foundation surface data
The depth of the foundation is defined by the height of the
wall surfaces that reference the Foundation:Kiva
boundary condition object. For slab-on-grade foundations, a
depth of zero is implied by having no associated wall
surfaces. Figure 6 shows a slab-on-grade foundation
with whole slab insulation. Notice there are no walls
referencing the “Foundation” Outside Boundary Condition. In
this case, the under-slab insulation is modeled as part of the
slab construction, while the edge/gap insulation is modeled
using the interior vertical insulation fields of a Foundation:Kiva
object. Note: Since there are no wall surfaces for slab
foundations, the footing wall construction is defined within
the Foundation:Kiva
object (or defaulted to a 0.3m wide cast concrete wall).
Two-dimensional interpretation
of foundation surface data
A walkout basement (with a variable grade along the sides;
see Figure 7) is best modeled using
discrete quadrilateral surfaces of stepped height for the
walls as shown in Figure 8.
Example walkout
basementWalkout basement wall and floor
surfaces (in gray) all reference the same Foundation:Kiva
object
The width of the floor surface in the two-dimensional
context is defined by the area and the exposed perimeter (see
SurfaceProperty:ExposedFoundationPerimeter) of the floor
surface object. Details on this calculation can be found in
the Engineering Reference document.
Other components of the two-dimensional context are defined
by the Foundation:Kiva:Settings
object and applied uniformly for all instances of Foundation:Kiva
objects. These components include:
Indoor air temperature used for Kiva initialization (prior
to warmup period). If left blank, indoor air temperature
during initialization will be estimated based on zone
setpoints.
Field:
Interior Horizontal Insulation Material Name[LINK]
A reference to a material object associated with the
interior horizontal insulation. If left blank, no interior
horizontal insulation will be used. Default: blank.
The following two fields define the placement of this
material within Kiva’s two-dimensional context and are
illustrated in Figure 9.
Distance from the bottom of the slab to the top of interior
horizontal insulation, in m. Generally, interior horizontal
insulation is placed directly below the slab, and therefore,
this value will generally be set to zero (as indicated in
Figure 9). Required if Interior
Horizontal Insulation Material
Name is defined.
Extent of insulation as measured from the wall interior to
the edge of interior horizontal insulation, in m. Required if
Interior Horizontal Insulation Material
Name is defined.
Field:
Interior Vertical Insulation Material Name[LINK]
A reference to a material object associated with the
interior vertical insulation. If left blank, no interior
vertical insulation will be used. Default: blank.
The following field defines the placement of this material
within Kiva’s two-dimensional context and are illustrated in
Figure 10.
Extent of insulation as measured from the wall top to the
bottom edge of the interior vertical insulation, in m.
Required if Interior Vertical Insulation Material
Name is defined.
Field:
Exterior Horizontal Insulation Material Name[LINK]
A reference to a material object associated with the
exterior horizontal insulation. If left blank, no exterior
horizontal insulation will be used. Default: blank.
The following two fields define the placement of this
material within Kiva’s two-dimensional context and are
illustrated in Figure 11.
Distance from the exterior grade to the top of exterior
horizontal insulation, in m. Required if Exterior Horizontal
Insulation Material
Name is defined.
Extent of insulation as measured from the wall exterior to
the edge of exterior horizontal insulation, in m. Required if
Exterior Horizontal Insulation Material
Name is defined.
Field:
Exterior Vertical Insulation Material Name[LINK]
A reference to a material object associated with the
exterior vertical insulation. If left blank, no exterior
vertical insulation will be used. Default: blank
The following field defines the placement of this material
within Kiva’s two-dimensional context and are illustrated in
Figure 12.
Extent of insulation as measured from the wall top to the
bottom edge of the exterior vertical insulation, in m.
Required if Exterior Vertical Insulation Material
Name is defined.
Distance from the exterior grade to the wall top, in m.
Default: 0.2 m
Figures 13 and 14 illustrate the
definition of both the “Wall Height Above Grade” and the
following field, “Wall Depth Below Slab”. If the top of
foundation wall is flush with the ground then the “Wall Height
Above Grade” is zero.
Definition of exterior grade
and footing wall depth relative to the wall surface (for a
basement foundation context)Definition of exterior grade
and footing wall depth relative to the wall surface (for a
slab foundation context)
Distance from the slab bottom to the bottom of the
foundation wall, in m. Default: 0.0 m
Extending the wall below the slab provides a coarse
approximation of the foundation footing. Alternatively, one
may use the fields “Footing Material
Name” and “Footing Depth” to explicitly model the footing.
Note, that explicit modeling of the footing requires a higher
spatial discretization and, therefore, longer computation
times.
Defines the construction of the foundation footing wall for
slab foundations where the foundation wall is not exposed to
the zone (and has no zone surface to explicitly assign a
construction).
By default, this is the same construction as any associated
below-grade wall surfaces, or a 0.3 m wide poured concrete
wall (conductivity = 1.95 W/m-K, density = 2240 kg/m3,
specific heat = 900 J/kg-K).
A reference to a material object associated with the
foundation footing (typically some form of concrete). The
thickness of this material is used to determine the width of
the footing. If left blank, no footing will be used. Default:
blank
The following field defines the placement of this material
within Kiva’s two-dimensional context and are illustrated in
Figure 15.
Top-to-bottom dimension of the footing (not to be confused
with its depth in the ground). The width of the footing is
defined by the material’s thickness. Default: 0.3 m.
A reference to a material object associated with a custom
block in the two-dimensional foundation context. The thickness
of this material determines the width of the block.
Custom blocks can be used to represent solid materials in
the two-dimensional context that are not otherwise covered by
the fields above. Examples of this might include interior
finishings and insulation (Figure 16) or
backfill soil with different thermal properties (Figure 17).
If two or more custom blocks overlap, the final properties
are determined by the higher block number (e.g., Custom Block
4 in the input object supersedes properties defined by Custom
Block 2). All custom blocks properties are superseded by the
elements shown in Figure 4.
The following fields defines the placement of this material
within Kiva’s two-dimensional context and are illustrated in
Figure 18.
Top-to-bottom dimension of the block downward. The default
is the depth from the wall top to the top of the slab to
facilitate interior constructions. Default: Slab depth
This object defines settings applied across all Kiva
foundation calculations. This object is not required. If it is
not defined, all defaults will be applied.
The distance from the wall interior to the zero horizontal
heat flux (i.e., adiabatic) far-field boundary, in m. This
distance represents either the distance halfway between this
foundation and a similar foundation of a neighboring building,
or a distance adequately far from the foundation such that it
is isolated from the effects of the boundary (typically >=
40 m). Default: 40 m.
Defines the type of boundary condition to apply at the
Deep-Ground Depth. Options are:
ZeroFlux
GroundWater
Autoselect
ZeroFlux applies a zero vertical heat flux (i.e. adiabatic)
boundary condition. GroundWater applies a constant temperature
boundary condition, with a temperature equal to the average
outdoor air dry-bulb temperature from the environment(s).
Autoselect applies either boundary condition depending on the
elevation of the building site (Williams and Williamson,
1989):
\[d_{wt}=0.1022\cdot
d_{elev}\]
If \(d_{wt} \le\) 40 m.,
the GroundWater boundary is applied at this depth, otherwise a
ZeroFlux boundary is applied at 40 m. If the calculated ground
water depth is shallower than any element of a foundation
construction, then the GroundWater is applied at 1 m below the
lowest element for that foundation.
The distance from the exterior grade to the deep ground
boundary, in m. This distance represents either the distance
to the ground water level, or a distance adequately far from
the foundation such that it is isolated from the effects of
the boundary (typically >= 40 m). Default 40 m, or the
distance determined by the “Autoselect” Deep-Ground Boundary
Condition. If the Deep-Ground Boundary Condition is set to
“Autoselect”, this field should be set to “Autocalculate”. If
the Deep-Ground Boundary Condition is not set to “Autoselect”,
but this field is set to “Autocalculate” (or allowed to
default), an error will be issued.
This field allows the user to choose whether to calculate
foundation loads on the zone timestep or at hourly intervals.
Hourly intervals will allow for less overall computation time,
but with less accuracy. Choices are “Hourly” and “Timestep”.
Default: Hourly
This object (currently only used in conjunction with Foundation:Kiva
boundary conditions) defines the perimeter of a foundation
floor that is exposed to the exterior environment through the
floor. The user may either define the total exposed perimeter,
the fraction of the total perimeter that is exposed, or
individually define which segments of the floor surface
perimeter are exposed. This object is required for any floor
surface with a Foundation:Kiva
boundary condition.
Figure 19 illustrates how the exposed
perimeter is determined from a floor plan of the foundation
level.
Some buildings may have neighboring zones with different
foundation types. For example, a crawlspace next to a garage
with a slab (Figure 20).
The foundation wall in this case is NOT considered part of
either floor’s exposed perimeter, and should not reference a
Foundation boundary condition. Kiva does not calculate heat
flow between two zones through ground. In this case, it is
best to approximate interior foundation wall using an
Adiabatic Outside Boundary Condition.
Exposed foundation
perimeterInterior foundation
wall
Required key/choice field that tells which method to use to
calculate the exposed foundation perimeter. Choices are:
TotalExposedPerimeter: Exposed perimeter is defined as
an absolute distance in m. (The Total Exposed Perimeter field
should be filled.)
ExposedPerimeterFraction: Exposed perimeter is defined
as a fraction of the total floor perimeter. (The Exposed
Perimeter Fraction field should be filled.) Note: This option
works best when you are confident that the floor surface is
completely exposed.
BySegment: Each segment of the floor polygon
(corresponding to distance between each set of vertices) is
defined as exposed (“Yes”) or not exposed (“No”) in an
extensible list corresponding to the number of vertices in the
floor polygon. Exposed perimeter is defined as the sum of all
exposed segment lengths. (The Surface Segment <x>
Exposed fields should be filled.) Note: The number of segments
identified in this object must match the number of vertices in
the corresponding surface object.
This object provides options to change the individual
convection model equations for dynamic selection when using
AdaptiveConvectionAlgorithm. This object is only needed to
make changes to the default model selections for any or all of
the surface categories. This object is for the inside face,
the side of the surface facing a thermal zone.
Applies to zone with no HVAC or when HVAC is off. This is
for vertical walls. The key choice options include:
FohannoPolidoriVerticalWall, ASHRAEVerticalWall,
AlamdariHammondVerticalWall, KhalifaEq3WallAwayFromHeat,
KhalifaEq6NonHeatedWalls FohannoPolidoriVerticalWall,
ISO15099Windows, or UserCurve
Field:
Simple Buoyancy Vertical Wall User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this
field is used when the previous field is set to UserCurve
Applies to zone with no HVAC or when HVAC is off. This is
for horizontal surfaces with heat flow directed for stable
thermal stratification. The key choice options include:
WaltonStableHorizontalOrTilt, AlamdariHammondStableHorizontal,
or UserCurve
Field:
Simple Buoyancy Stable Horizontal Equation User Curve
Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this
field is used when the previous field is set to UserCurve
Applies to zone with no HVAC or when HVAC is off. This is
for passive horizontal surfaces with heat flow for unstable
thermal stratification. The key choice options include:
WaltonUnstableHorizontalOrTilt,
AlamdariHammondUnstableHorizontal, or UserCurve.
Field:
Simple Buoyancy Unstable Horizontal Equation User Curve
Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this
field is used when the previous field is set to UserCurve.
Applies to zone with no HVAC or when HVAC is off. This is
for tilted surfaces with heat flow for stable thermal
stratification. The key choice options include:
WaltonStableHorizontalOrTilt, AlamdariHammondStableHorizontal,
or UserCurve
Field:
Simple Buoyancy Stable Tilted Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this
field is used when the previous field is set to UserCurve.
Applies to zone with no HVAC or when HVAC is off. This is
for tilted surfaces with heat flow for unstable thermal
stratification. The key choices include:
WaltonUnstableHorizontalOrTilt,
AlamdariHammondUnstableHorizontal, or UserCurve.
Field:
Simple Buoyancy Unstable Tilted Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this
field is used when the previous field is set to UserCurve.
Field:
Simple Buoyancy Windows Equation Source[LINK]
Applies to zone with no HVAC or when HVAC is off. This is
for all window surfaces. The key choice options include:
ASHRAEVerticalWall, AlamdariHammondVerticalWall,
FohannoPolidoriVerticalWall, KaradagChilledCeiling,
ISO15099Windows, or UserCurve.
Field:
Simple Buoyancy Windows Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this
field is used when the previous field is set to UserCurve.
Applies to zone with in-floor heating and/or in-ceiling
cooling. This is for vertical walls. The key choice options
include: ASHRAEVerticalWall, AlamdariHammondVerticalWall,
KhalifaEq3WallAwayFromHeat, FohannoPolidoriVerticalWall,
ISO15099Windows, or UserCurve.
Applies to zone with in-floor heating and/or in-ceiling
cooling. This is for passive horizontal surfaces with heat
flow for stable thermal stratification. The key choice options
include: WaltonStableHorizontalOrTilt,
AlamdariHammondStableHorizontal, or UserCurve.
Applies to zone with in-floor heating and/or in-ceiling
cooling. This is for passive horizontal surfaces with heat
flow for unstable thermal stratification. The key choice
options include: WaltonUnstableHorizontalOrTilt,
AlamdariHammondUnstableHorizontal,
KhalifaEq4CeilingAwayFromHeat, or UserCurve.
Applies to zone with in-floor heating and/or in-ceiling
cooling. This is for a floor with active heating elements. The
key choice options include: WaltonUnstableHorizontalOrTilt,
AlamdariHammondUnstableHorizontal, AwbiHattonHeatedFloor, or
UserCurve
Applies to zone with in-floor heating and/or in-ceiling
cooling. This is for a ceiling with active cooling elements.
The key choice options include:
WaltonUnstableHorizontalOrTilt,
AlamdariHammondUnstableHorizontal, KaradagChilledCeiling, or
UserCurve.
Applies to zone with in-floor heating and/or in-ceiling
cooling. This is for tilted surfaces with heat flow for stable
thermal stratification. The key choice options include:
WaltonStableHorizontalOrTilt, AlamdariHammondStableHorizontal,
ISO15099Windows, or UserCurve.
Applies to zone with in-floor heating and/or in-ceiling
cooling. This is for tilted surfaces with heat flow for
unstable thermal stratification. The key choice options
include: WaltonUnstableHorizontalOrTilt,
AlamdariHammondUnstableHorizontal, ISO15099Windows, or
UserCurve.
Applies to zone with in-floor heating and/or in-ceiling
cooling. This is for all window surfaces. The key choice
options include: ASHRAEVerticalWall,
AlamdariHammondVerticalWall, ISO15099Windows, or
UserCurve.
Field:
Floor Heat Ceiling Cool Window Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this
field is used when the previous field is set to UserCurve.
Applies to zone with in-wall panel heating. This is for
vertical walls that are not actively heated. The key choice
options include: ASHRAEVerticalWall,
AlamdariHammondVerticalWall, KhalifaEq6NonHeatedWalls,
FohannoPolidoriVerticalWall, AlamdariHammondVerticalWall,
ISO15099Windows, or UserCurve.
Field:
Wall Panel Heating Vertical Wall Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this
field is used when the previous field is set to UserCurve.
Applies to zone with in-wall panel heating. This is for
vertical walls that are being actively heated. The key choice
options include: ASHRAEVerticalWall,
AlamdariHammondVerticalWall, KhalifaEq5WallNearHeat,
AwbiHattonHeatedWall, FohannoPolidoriVerticalWall,
AlamdariHammondVerticalWall, or UserCurve.
Field:
Wall Panel Heating Heated Wall Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this
field is used when the previous field is set to UserCurve.
Applies to zone with in-wall panel heating. This is for
horizontal surfaces with heat flow directed for stable thermal
stratification. The key choice options include:
WaltonStableHorizontalOrTilt, AlamdariHammondStableHorizontal,
or UserCurve.
Field:
Wall Panel Heating Stable Horizontal Equation User Curve
Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this
field is used when the previous field is set to UserCurve.
Applies to zone with in-wall panel heating. This is for
horizontal surfaces with heat flow directed for unstable
thermal stratification. The key choice options include:
ASHRAEVerticalWall, WaltonUnstableHorizontalOrTilt,
AlamdariHammondUnstableHorizontal, KhalifaEq7Ceiling, or
UserCurve
Field:
Wall Panel Heating Unstable Horizontal Equation User Curve
Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this
field is used when the previous field is set to UserCurve.
Applies to zone with in-wall panel heating. This is for
tilted surfaces with heat flow for stable thermal
stratification. The key choice options include:
WaltonStableHorizontalOrTilt, AlamdariHammondStableHorizontal,
ISO15099Windows, or UserCurve.
Field:
Wall Panel Heating Stable Tilted Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this
field is used when the previous field is set to UserCurve
Applies to zone with in-wall panel heating. This is for
tilted surfaces with heat flow for unstable thermal
stratification. The key choice options include:
WaltonUnstableHorizontalOrTilt,
AlamdariHammondUnstableHorizontal, ISO15099Windows, or
UserCurve.
Field:
Wall Panel Heating Unstable Tilted Equation User Curve
Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this
field is used when the previous field is set to UserCurve.
Applies to zone with in-wall panel heating. This is for all
window surfaces. The key choice options include:
ASHRAEVerticalWall, AlamdariHammondVerticalWall,
FohannoPolidoriVerticalWall, ISO15099Windows, or
UserCurve.
Field:
Wall Panel Heating Window Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this
field is used when the previous field is set to UserCurve.
Field:
Convective Zone Heater Vertical Wall Equation Source[LINK]
Applies to zone with convective heater. This is for
vertical walls not directly affected by heater. The key choice
options include: ASHRAEVerticalWall,
AlamdariHammondVerticalWall, KhalifaEq3WallAwayFromHeat,
KhalifaEq6NonHeatedWalls, FohannoPolidoriVerticalWall,
ISO15099Windows, or UserCurve
Field:
Convective Zone Heater Vertical Wall Equation User Curve
Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this
field is used when the previous field is set to UserCurve.
Field:
Convective Zone Heater Vertical Walls Near Heater Equation
Source[LINK]
Applies to zone with convective heater. This is for
vertical walls that are directly affected by heater. Walls are
considered “near” when listed in field set for Fraction of
Radiant Energy to Surface. The key choice options include:
ASHRAEVerticalWall, AlamdariHammondVerticalWall,
KhalifaEq5WallNearHeat, AwbiHattonHeatedWall,
FohannoPolidoriVerticalWall, ISO15099Windows, or
UserCurve.
Field:
Convective Zone Heater Vertical Walls Near Heater Equation
User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this
field is used when the previous field is set to UserCurve.
Field:
Convective Zone Heater Stable Horizontal Equation Source[LINK]
Applies to zone with convective heater. This is for
horizontal surfaces with heat flow directed for stable thermal
stratification. The key choice options include:
WaltonStableHorizontalOrTilt, AlamdariHammondStableHorizontal,
or UserCurve.
Field:
Convective Zone Heater Stable Horizontal Equation User Curve
Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this
field is used when the previous field is set to UserCurve
Field:
Convective Zone Heater Unstable Horizontal Equation
Source[LINK]
Applies to zone with convective heater. This is for
horizontal surfaces with heat flow directed for unstable
thermal stratification. The key choice options include:
WaltonUnstableHorizontalOrTilt,
AlamdariHammondUnstableHorizontal,
KhalifaEq4CeilingAwayFromHeat, KhalifaEq7Ceiling, or
UserCurve.
Field:
Convective Zone Heater Unstable Horizontal Equation User Curve
Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this
field is used when the previous field is set to UserCurve.
Field:
Convective Zone Heater Stable Tilted Equation Source[LINK]
Applies to zone with convective heater. This is for tilted
surfaces with heat flow for stable thermal stratification. The
key choice options include: WaltonStableHorizontalOrTilt,
AlamdariHammondStableHorizontal, or UserCurve.
Field:
Convective Zone Heater Stable Tilted Equation User Curve
Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this
field is used when the previous field is set to UserCurve.
Field:
Convective Zone Heater Unstable Tilted Equation Source[LINK]
Applies to zone with convective heater. This is for tilted
surfaces with heat flow for unstable thermal stratification.
The key choice options include:
WaltonUnstableHorizontalOrTilt,
AlamdariHammondUnstableHorizontal, or UserCurve.
Field:
Convective Zone Heater Unstable Tilted Equation User Curve
Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this
field is used when the previous field is set to UserCurve.
Field:
Convective Zone Heater Windows Equation Source[LINK]
Applies to zone with convective heater. This is for all
window surfaces. The key choice options include:
ASHRAEVerticalWall, AlamdariHammondVerticalWall,
KhalifaEq3WallAwayFromHeat, FohannoPolidoriVerticalWall,
ISO15099Windows, or UserCurve.
Field:
Convective Zone Heater Windows Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this
field is used when the previous field is set to UserCurve.
Field:
Central Air Diffuser Wall Equation Source[LINK]
Applies to zone with mechanical forced central air with
diffusers. This is for all wall surfaces. The key choice
options include: ASHRAEVerticalWall,
FisherPedersenCeilingDiffuserWalls,
AlamdariHammondVerticalWall,
BeausoleilMorrisonMixedAssistedWall,
BeausoleilMorrisonMixedOpposingWall,
FohannoPolidoriVerticalWall, ISO15099Windows,
GoldsteinNovoselacCeilingDiffuserWalls, or UserCurve
Field:
Central Air Diffuser Wall Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this
field is used when the previous field is set to UserCurve.
Field:
Central Air Diffuser Ceiling Equation Source[LINK]
Applies to zone with mechanical forced central air with
diffusers. This is for all ceiling surfaces. The key choice
options include: FisherPedersenCeilingDiffuserCeiling,
BeausoleilMorrisonMixedStableCeiling,
BeausoleilMorrisonMixedUnstableCeiling, or UserCurve.
Field:
Central Air Diffuser Ceiling Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this
field is used when the previous field is set to UserCurve.
Field:
Central Air Diffuser Floor Equation Source[LINK]
Applies to zone with mechanical forced central air with
diffusers. This is for all floor surfaces. The key choice
options include: FisherPedersenCeilingDiffuserFloor,
BeausoleilMorrisonMixedStableFloor,
BeausoleilMorrisonMixedUnstableFloor,
GoldsteinNovoselacCeilingDiffuserFloor, or UserCurve.
Field:
Central Air Diffuser Floor Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this
field is used when the previous field is set to UserCurve.
Field:
Central Air Diffuser Window Equation Source[LINK]
Applies to zone with mechanical forced central air with
diffusers. This is for all window surfaces. The key choice
options include: ASHRAEVerticalWall,
FisherPedersenCeilingDiffuserWalls,
BeausoleilMorrisonMixedAssistedWall,
BeausoleilMorrisonMixedOpposingWall,
FohannoPolidoriVerticalWall, AlamdariHammondVerticalWall,
ISO15099Windows, GoldsteinNovoselacCeilingDiffuserWindow, or
UserCurve.
Field:
Central Air Diffuser Window Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this
field is used when the previous field is set to UserCurve
Field:
Mechanical Zone Fan Circulation Vertical Wall Equation
Source[LINK]
The key choice options include: KhalifaEq3WallAwayFromHeat,
ASHRAEVerticalWall, FisherPedersenCeilingDiffuserWalls,
AlamdariHammondVerticalWall,
BeausoleilMorrisonMixedAssistedWall,
BeausoleilMorrisonMixedOpposingWall,
FohannoPolidoriVerticalWall, ISO15099Windows,
GoldsteinNovoselacCeilingDiffuserWalls, or UserCurve.
Field:
Mechanical Zone Fan Circulation Vertical Wall Equation User
Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this
field is used when the previous field is set to UserCurve
Field:
Mechanical Zone Fan Circulation Stable Horizontal Equation
Source[LINK]
The key choice options include:
WaltonStableHorizontalOrTilt, AlamdariHammondStableHorizontal,
or UserCurve.
Field:
Mechanical Zone Fan Circulation Stable Horizontal Equation
User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this
field is used when the previous field is set to UserCurve.
Field:
Mechanical Zone Fan Circulation Unstable Horizontal Equation
Source[LINK]
The key choice options include:
KhalifaEq4CeilingAwayFromHeat, WaltonUnstableHorizontalOrTilt,
AlamdariHammondUnstableHorizontal, or UserCurve.
Field:
Mechanical Zone Fan Circulation Unstable Horizontal Equation
User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this
field is used when the previous field is set to UserCurve.
Field:
Mechanical Zone Fan Circulation Stable Tilted Equation
Source[LINK]
The key choice options include:
WaltonStableHorizontalOrTilt or UserCurve
Field
Mechanical Zone Fan Circulation Stable Tilted Equation User
Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this
field is used when the previous field is set to UserCurve.
Field:
Mechanical Zone Fan Circulation Unstable Tilted Equation
Source[LINK]
The key choice options include:
WaltonUnstableHorizontalOrTilt,
AlamdariHammondUnstableHorizontal, or UserCurve.
Field:
Mechanical Zone Fan Circulation Unstable Tilted Equation User
Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this
field is used when the previous field is set to UserCurve.
Field:
Mechanical Zone Fan Circulation Window Equation Source[LINK]
The key choice options include: ASHRAEVerticalWall,
AlamdariHammondVerticalWall, FohannoPolidoriVerticalWall,
ISO15099Windows, GoldsteinNovoselacCeilingDiffuserWindow, or
UserCurve.
Field:
Mechanical Zone Fan Circulation Unstable Tilted Equation User
Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this
field is used when the previous field is set to UserCurve
Field:
Mixed Regime Buoyancy Assisting Flow on Walls Equation
Source[LINK]
The key choice options include:
BeausoleilMorrisonMixedAssistedWall,
AlamdariHammondVerticalWall, FohannoPolidoriVerticalWall,
ASHRAEVerticalWall, FisherPedersenCeilingDiffuserWalls,
GoldsteinNovoselacCeilingDiffuserWalls, or UserCurve.
Field:
Mixed Regime Buoyancy Assisting Flow on Walls Equation User
Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this
field is used when the previous field is set to UserCurve.
Field:
Mixed Regime Buoyancy Opposing Flow on Walls Equation
Source[LINK]
The key choice options include:
BeausoleilMorrisonMixedOpposingWall,
AlamdariHammondVerticalWall, FohannoPolidoriVerticalWall,
ASHRAEVerticalWall, FisherPedersenCeilingDiffuserWalls,
GoldsteinNovoselacCeilingDiffuserWalls, or UserCurve
Field:
Mixed Regime Buoyancy Opposing Flow on Walls Equation User
Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this
field is used when the previous field is set to UserCurve
The key choice options include:
BeausoleilMorrisonMixedUnstableCeiling,
WaltonUnstableHorizontalOrTilt,
AlamdariHammondUnstableHorizontal, or UserCurve.
Field:
Mixed Regime Unstable Ceiling Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this
field is used when the previous field is set to UserCurve.
Options to change the individual convection model equations
for dynamic selection when using AdaptiveConvectionAlgorithm.
This object is only needed to make changes to the default
model selections for any or all of the surface categories.
This object is for the outside face, the side of the surface
facing away from the thermal zone.
This is for just the wind-driven component of the total
convection coefficient. The key choice options include:
SimpleCombined, TARPWindward, MoWiTTWindward, DOE2Windward,
NusseltJurges, McAdams, Mitchell, Blocken, Emmel, or
UserCurve.
Field:
Wind Convection Windward Equation Vertical Wall User Curve
Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this
field is used when the previous field is set to UserCurve.
This is for just the wind-driven component of the total
convection coefficient. The key choice options include:
SimpleCombined, TARPLeeward, MoWiTTLeeward, DOE2Leeward,
Emmel, NusseltJurges, McAdams, Mitchell, or UserCurve.
Field:
Wind Convection Leeward Vertical Wall Equation User Curve
Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this
field is used when the previous field is set to UserCurve.
This is for just the wind-driven component of the total
convection coefficient. The key choice options include:
SimpleCombined, TARPWindward, MoWiTTWindward, DOE2Windward,
NusseltJurges, McAdams, Mitchell, Blocken, Emmel, ClearRoof,
or UserCurve.
Field:
Wind Convection Horizontal Roof User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this
field is used when the previous field is set to UserCurve.
This is for just the natural convection portion of the
total film coefficient. This is for vertical walls. The key
choice options include: ASHRAEVerticalWall,
AlamdariHammondVerticalWall, FohannoPolidoriVerticalWall,
ISO15099Windows, UserCurve, or None.
Field:
Natural Convection Vertical Wall Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this
field is used when the previous field is set to UserCurve.
This is for just the natural convection portion of the
total film coefficient. This is for horizontal surfaces with
heat flow directed for stable thermal stratification. The key
choice options include: WaltonStableHorizontalOrTilt,
AlamdariHammondStableHorizontal, UserCurve, or None.
Field:
Natural Convection Stable Horizontal Equation User Curve
Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this
field is used when the previous field is set to UserCurve.
This is for just the natural convection portion of the
total film coefficient. This is for horizontal surfaces with
heat flow directed for unstable thermal stratification. The
key choice options include: WaltonUnstableHorizontalOrTilt,
AlamdariHammondUnstableHorizontal, UserCurve, or None
Field:
Natural Convection Unstable Horizontal Equation User Curve
Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this
field is used when the previous field is set to UserCurve.
This object is used to describe a custom model equation for
surface convection heat transfer coefficients. If more than
one curve is referenced, or non-blank, then they are all used,
and the result is the simple addition of all the curve
results.
Field:
Reference Temperature for Convection Heat Transfer[LINK]
This field controls the nature of the reference temperature
used with convection coefficient when calculating the heat
flow at the surface. Select one of the three choices:
MeanAirTemperature, AdjacentAirTemperature,
SupplyAirTemperature. MeanAirTemperature is the typical
application for the classic convection model used with the
complete mixing of room air. AdjacentAirTemperature applies
when used with Roomair models that account for temperature
variations within the zone air and directs the model to use
the temperature near the surface rather than the average for
the entire zone. SupplyAirTemperature directs the model to use
the supply air conditions for the heat transfer
conditions.
Field:
Hc Function of Temperature Difference Curve Name[LINK]
This field contains the name of separate performance curve
or table object that describes h\(_{c}\), the convection
coefficient, as a function of temperature difference. The
curve’s “x” is absolute value of delta-T (Surface temperature
minus air temperature, (C))
Field:
Hc Function of Temperature Difference Divided by Height Curve
Name[LINK]
This field contains the name of separate performance curve
or table object that describes h\(_{c}\), the convection
coefficient, as a function of temperature difference divided
by height. The curve’s “x” is absolute value of delta-T/Height
(Surface temp minus Air temp)/(vertical length scale), (C/m).
For an inside face, the vertical length scale is the zone’s
interior height.
Field: Hc
Function of Air Change Rate Curve Name[LINK]
This field contains the name of separate performance curve
or table object that describes h\(_{c}\), the convection
coefficient, as a function of air change rate. The curve’s “x”
is mechanical ACH (Air Changes per hour from mechanical air
system), (1/hr)
Field:
Hc Function of Air System Volume Flow Rate Divided by Zone
Perimeter Length Curve Name[LINK]
This field contains the name of separate performance curve
or table object that describes h\(_{c}\), the convection
coefficient, as a function of air change rate divided
perimeter scale. Curve’s “x” is mechanical system air flow
rate (m\(^{3}\)/s) divided by
zone’s length along exterior walls (m).
This object is used to describe a custom model equation for
surface convection heat transfer coefficients. If more than
one curve is referenced, or non-blank, then they are all used
and the result is the simple addition of all the curve
results.
This field specifies what sort of wind velocity data should
be used in when evaluating the curve in the following field.
There are for key choice options. “WeatherFile” directs using
the unmodified value from the epw file or design weather data.
“HeightAdjust” uses the value from the epw file modified for
height above ground, as determined by the z coordinate, using
the site terrain and weather station information.
“ParallelComponent” uses the value from the epw file modified
to take just the velocity component that is parallel to the
surface. “ParallelComponentHeightAdjust” uses the height
adjusted wind velocity and then computes the parallel
component.
This field contains the name of separate performance curve
or table object that describes h\(_{f}\), the forced
convection coefficient, as a function of wind speed. The
curve’s “x” is wind speed as defined by the method chosen in
the previous field.
Field:
Hn Function of Temperature Difference Curve Name[LINK]
This field contains the name of separate performance curve
or table object that describes h\(_{n}\), the natural
convection coefficient, as a function of temperature
difference. Curve’s “x” is absolute value of delta-T (Surface
temperature minus air temperature, (C))
Field:
Hc Function of Temperature Difference Divided by Height Curve
Name[LINK]
This field contains the name of separate performance curve
or table object that describes h\(_{n}\), the natural
convection coefficient, as a function of temperature
difference divided by height. Curve’s “x” is absolute value of
delta-T/Height (Surface temp minus Air temp)/(vertical length
scale), (C/m). For an outside face the vertical length scale
is the exterior facade’s overall height.
The convection coefficients of each surface, both exterior
and interior, are automatically calculated during EnergyPlus
execution. These calculations are “governed” by other objects
such as the SurfaceConvectionAlgorithm:Inside
(overall default), the Zone
object’s field called Zone
Inside Convection Algorithm (Zone Default), the and the SurfaceConvectionAlgorithm:Outside
(overall default), and/or the Zone
object’s field called Zone
Outside Convection Algorithm (Zone Default). Usually, that
will be enough flexibility for most users. However, if you
need to match pre-existing convection coefficients (from
another program) or are trying to match a test suite of
results, you may wish to use the “override” convection
coefficients in the following object. This object allows for a
single surface to be given specific convection
coefficients.
Note that using these in conjunction, in particular, the
“Simple” option on either the Outside Convection Algorithm or
the Zone
Outside Convection Algorithm field will result in a combined
coefficient regardless of choice chosen here.
Note that surfaces with “SurfaceProperty:OtherSideCoefficients”
cannot use this object with the “outside” coefficient –
attempting to do so will cause a severe error; SurfaceProperty:OtherSideCoefficients
surfaces can apply an “inside” coefficient. And, surfaces with
“Ground” exposure do not use the “outside” coefficient that
might be supplied here. Note, too, that some lower boundaries
are used regardless by certain surface types (i.e. Window) or
certain algorithm types.
For simplicity, the descriptions of these field occur
together – however, the fields are used sequentially when put
into the IDF file (reference the IDF examples following the
descriptions).
If the Convection type was “Schedule”, then this field
contains the name of a schedule describing the value to be
used during the time intervals for the schedule.
Field:
Convection Coefficient 1 User Curve Name[LINK]
Field:
Convection Coefficient 2 User Curve Name[LINK]
If the Convection type was “UserCurve”, then this field
contains the name of a SurfaceConvectionAlgorithm:UserCurve
input object describing the model equations to be used during
the time intervals for the schedule.
In IDF usage:
SurfaceProperty:ConvectionCoefficients,
Zn001:Wall001, ! Surface Name
Outside, ! Convection Coefficient 1 Location
Value, ! Convection Coefficient 1 Type
9.8, ! Convection Coefficient 1
, ! Convection Coefficient 1 Schedule Name
, ! Convection Coefficient 1 User Curve Name
Inside, ! Convection Coefficient 2 Location
Schedule, ! Convection Coefficient 2 Type
, ! Convection Coefficient 2 {blank because using schedule}
MyInteriorCC, ! Convection Coefficient 2 Schedule Name
; ! Convection Coefficient 2 User Curve Name
SurfaceProperty:ConvectionCoefficients,
Zn001:Wall002, ! Surface Name
Inside, ! Convection Coefficient 1 Location
Value, ! Convection Coefficient 1 Type
.8, ! Convection Coefficient 1
, ! Convection Coefficient 1 Schedule Name
, ! Convection Coefficient 1 User Curve Name
Outside, ! Convection Coefficient 2 Location
Value, ! Convection Coefficient 2 Type
5.5, ! Convection Coefficient 2
; ! Convection Coefficient 2 User Curve Name
SurfaceProperty:ConvectionCoefficients,
Zn001:Wall003, ! Surface Name
Outside, ! Convection Coefficient 1 Location
Value, ! Convection Coefficient 1 Type
9.8; ! Convection Coefficient 1
The convection coefficients of each surface, both outside
and inside, are automatically calculated during EnergyPlus
execution. These calculations are “governed” by other objects
such as the Inside Convection Algorithm (overall default) and
the Zone
Inside Convection Algorithm (Zone Default) and the Outside
Convection Algorithm (overall default) and/or the Zone
Outside Convection Algorithm (Zone Default). Usually, that
will be enough flexibility for most users. However, if you
need to match pre-existing convection coefficients (from
another program) or are trying to match a test suite of
results, you may wish to use the “override” convection
coefficients in the following object. This object is similar
to the preceding “ConvectionCoefficients” object but allows
multiple surfaces to be assigned a type with one object
entry.
Note that using these in conjunction, in particular, the
“Simple” option on either the Outside Convection Algorithm or
the Zone
Outside Convection Algorithm field will result in a combined
coefficient regardless of choice chosen here.
Note that surfaces with “SurfaceProperty:OtherSideCoefficients”
cannot use this object with the “outside” coefficient –
attempting to do so will ignore OSC surfaces during a multiple
surface “apply”; SurfaceProperty:OtherSideCoefficients
surfaces can apply an “inside” coefficient. And, surfaces with
“Ground” exposure do not use the “outside” coefficient that
might be supplied here. Note, too, that some lower boundaries
are used regardless by certain surface types (i.e. Window) or
certain algorithm types.
For simplicity, the descriptions of these field occur
together – however, the fields are used sequentially when put
into the IDF file (reference the IDF examples following the
descriptions).
If the Convection type was “Schedule”, then this field
contains the name of a schedule describing the value to be
used during the time intervals for the schedule.
Field:
Convection Coefficient 1 User Curve Name[LINK]
Field:
Convection Coefficient 2 User Curve Name[LINK]
If the Convection type was “UserCurve”, then this field
contains the name of a SurfaceConvectionAlgorithm:UserCurve
input object describing the model equations to be used during
the time intervals for the schedule.
Ultimate flexibility and possibly ultimate user confusion
can result from the convection coefficient possibilities in
EnergyPlus. The objects that control how convection models are
assigned to individual surfaces are:
Outputs for the User Supplied Convection Coefficients
appear as values in the Surface Output Variables (Surface
Inside Face Convection Heat Transfer Coefficient and
Surface Outside Face Convection Heat Transfer
Coefficient). What the program expects to use is shown in
the Surface Details report (Output:Surfaces:List,
Details;)
When EnergyPlus is set to Display Advanced Variables
(Output:Diagnostics, DisplayAdvancedVariables;), then
additional output variables are available that indicate the
status of convection modeling by identifying which models are
in effect at a given time. The adaptive convection algorithms
may switch between models over time and the following output
variables provide a way to monitor this behavior. These
outputs are integer codes and the integer values are explained
in tables.
Surface
Inside Face Convection Classification Index[LINK]
This variable reports how the surface was classified as
part of the adaptive convection algorithm for the inside
face. The algorithm examines probable flow regimes, heat flow
directions, orientations, HVAC equipment connections, and
current operating status to assign each surface a category.
The numbers in this report are integer codes that correspond
to surface categories as described in the following table.
Code
Zone Airflow Regime
Type of surface
Heat Flow
-1
Invalid
N/A
N/A
1
A1 Radiant Heated Floor or
Chilled Ceiling
Vertical Wall
Any
2
A1 Radiant Heated Floor or
Chilled Ceiling
Horizontal
Stable
3
A1 Radiant Heated Floor or
Chilled Ceiling
Horizontal
Unstable
4
A1 Radiant Heated Floor or
Chilled Ceiling
Heated Floor
Unstable
5
A1 Radiant Heated Floor or
Chilled Ceiling
Chilled Ceiling
Unstable
6
A1 Radiant Heated Floor or
Chilled Ceiling
Tilted
Stable
7
A1 Radiant Heated Floor or
Chilled Ceiling
Tilted
Unstable
8
A1 Radiant Heated Floor or
Chilled Ceiling
Window
Any
9
A2 Radiant Wall Heat
Non-heated Vertical Wall
Any
10
A2 Radiant Wall Heat
Heated wall
Any
11
A2 Radiant Wall Heat
Horizontal
Stable
12
A2 Radiant Wall Heat
Horizontal
Unstable
13
A2 Radiant Wall Heat
Tilted
Stable
14
A2 Radiant Wall Heat
Tilted
Unstable
15
A2 Radiant Wall Heat
Windows
Any
16
A3 Simple Buoyancy
Vertical Walls
Any
17
A3 Simple Buoyancy
Horizontal
Stable
18
A3 Simple Buoyancy
Horizontal
Unstable
19
A3 Simple Buoyancy
Tilted
Stable
20
A3 Simple Buoyancy
Tilted
Unstable
21
A3 Simple Buoyancy
Windows
Any
22
B Convective Zone Heat
Vertical Walls
Any
23
B Convective Zone Heat
Vertical Walls near heater
Any
24
B Convective Zone Heat
Horizontal
Stable
25
B Convective Zone Heat
Horizontal
Unstable
26
B Convective Zone Heat
Tilted
Stable
27
B Convective Zone Heat
Tilted
Unstable
28
B Convective Zone Heat
Windows
Any
29
C Central Air Diffuser
Walls
Any
30
C Central Air Diffuser
Ceiling
Any
31
C Central Air Diffuser
Floor
Any
32
C Central Air Diffuser
Windows
Any
33
D Zone Fan Unit
Walls
Any
34
D Zone Fan Unit
Horizontal
Stable
35
D Zone Fan Unit
Horizontal
Unstable
36
D Zone Fan Unit
Tilted
Stable
37
D Zone Fan Unit
Tilted
Unstable
38
D Zone Fan Unit
Windows
Any
39
E Mixed Forced and Buoyancy
Walls
Assisting
40
E Mixed Forced and Buoyancy
Walls
Opposing
41
E Mixed Forced and Buoyancy
Floor
Stable
42
E Mixed Forced and Buoyancy
Floor
Unstable
43
E Mixed Forced and Buoyancy
Ceiling
Stable
44
E Mixed Forced and Buoyancy
Ceiling
Unstable
45
E Mixed Forced and Buoyancy
Windows
Any
Surface
Inside Face Convection Model Equation Index[LINK]
This variable reports the specific model equation used to
calculate the inside face convection coefficient. This can
vary when using the adaptive convection algorithm and so the
result of that selection algorithm is reported here. The
following table lists the models associated with specific
interger codes reported here. The models correspond to key
words used in input objects.
Report Code
Related key and model
200
UserValue
201
UserSchedule
202
UserCurve
203
ASHRAEVerticalWall
204
WaltonUnstableHorizontalOrTilt
205
WaltonStableHorizontalOrTilt
206
FisherPedersenCeilDiffuserFloor
207
FisherPedersenCeilDiffuserCeiling
208
FisherPedersenCeilDiffuserWalls
209
AlamdariHammondStableHorizontal
210
AlamdariHammondVerticalWall
211
AlamdariHammondUnstableHorizontal
212
KhalifaEq3WallAwayFromHeat
213
KhalifaEq4CeilingAwayFromHeat
214
KhalifaEq5WallNearHeat
215
KhalifaEq6NonHeatedWalls
216
KhalifaEq7Ceiling
217
AwbiHattonHeatedFloor
218
AwbiHattonHeatedWall
219
BeausoleilMorrisonMixedAssistingWall
220
BeausoleilMorrisonMixedOppossingWall
221
BeausoleilMorrisonMixedStableCeiling
222
BeausoleilMorrisonMixedUnstableCeiling
223
BeausoleilMorrisonMixedStableFloor
224
BeausoleilMorrisonMixedUnstableFloor
225
FohannoPolidoriVerticalWall
226
KaradagChilledCeiling
227
ISO15099Windows
228
GoldsteinNovoselacCeilingDiffuserWindow
229
GoldsteinNovoselacCeilingDiffuserWalls
230
GoldsteinNovoselacCeilingDiffuserFloor
Surface
Inside Face Convection Reference Air Index[LINK]
The inside face convection heat transfer calculations can
be based on different reference air temperatures. This
reference air temperature can vary during the simulation when
the adaptive algorithm selects models that use different
references. The following table lists the meaning of the
integer codes.
Report Code
Reference Air Temperature
Method
1
Zone mean air temperature
2
Surface adjacent air
temperature
3
Supply air temperature
Surface
Outside Face Convection Classification Index[LINK]
This variable reports how the surface was classified as
part of the adaptive convection algorithm for the outside
face. The algorithm examines the wind direction, heat flow
directions and orientations to assign each surface a
category. The numbers in this report are integer codes that
correspond to surface categories as described in the following
table.
Report Code
Surface Classification
-1
Invalid
101
Vertical Wall, Windward
102
Vertical Wall, Leeward
103
Roof, stable heat flow
direction
104
Roof, unstable heat flow
direction
Surface
Outside Face Forced Convection Model Equation Index[LINK]
Surface
Outside Face Natural Convection Model Equation Index[LINK]
These variables report the specific model equation used to
calculate the outside face’s convection coefficient. They can
vary when using the adaptive convection algorithm and so the
results of that selection algorithm are reported in these
variables. The following table lists the models associated
with specific integer codes that might be reported here. The
models correspond to key words used in input objects.
Advanced/Research Usage: The internal and external vapor
transfer coefficients that are used by the
CombinedHeatAndMoistureFiniteElement model are automatically
calculated during EnergyPlus execution using information on
the convection coefficients. However it is sometimes useful to
be able to “override” the calculation and set fixed values of
vapor transfer coefficient for a single surface. These
coefficients are only used by the
CombinedHeatAndMoistureFiniteElement model and will be ignored
by other solution algorithms.
The CombinedHeatAndMoistureFiniteElement algorithm will use
this value to calculate the vapor transfer into and out of the
internal surface of this surface. Units are kg/Pa.s.m2.
Below is an example input of vapor transfer coefficients
for a surface.
SurfaceProperties:VaporCoefficients,
South wall, !- Surface Name
Yes, !- Constant External Vapor Transfer Coefficient
0.0000000625, !- External Vapor Coefficient Value
Yes, !- Constant Internal vapor Transfer Coefficient
0.00000002; !- Internal Vapor Coefficient Value
This object is used to model a multi-skin exterior heat
transfer surface. This is a special case where the outside
face is a slightly detached layer forming a naturally
ventilated cavity. The actual outer surface is referred to as
the baffle. The modeling here assumes that the heat capacity
in the outer baffle can be neglected since it is much lower
than the underlying mass surface. This object is used with the
BuildingSurface:Detailed
object where the Heat Transfer surfaces are referred to as the
underlying surfaces. The constructions and materials for the
BuildingSurface:Detailed
object should reflect the construction of just the underlying
surface. The SurfaceProperty:ExteriorNaturalVentedCavity
object is used to describe the decoupled layer, or baffle, and
the characteristics of the cavity and openings for natural
ventilation. This object is also used in conjunction with the
OtherSideConditionsModel.
The area and orientation are obtained from BuildingSurface:Detailed
objects, which are referenced by name. This object can be used
to model certain types of photovoltaic mounting configurations
such as interlocking roof pavers. If the baffle covers only
part of a surface, then that surface should be split into
separate BuildingSurface:Detailed
objects where one matches the size of the baffle. A single
baffle can be associated with as many BuildingSurface:Detailed
objects as desired. The base heat transfer surfaces need not
be contiguous nor have the same orientation, but the program
will issue warnings if surfaces have widely ranging tilts and
azimuths.
Note that the model involves predicting the rates that
ambient air moves in and out of the cavity. Accurate modeling
of these air flows would be extremely challenging and so the
models provided through this object are simplistic engineering
models based on discharge coefficients that are sensitive to
wind and buoyancy effects. The accuracy depends on the values
for, and applicability of, the discharge coefficients and
unfortunately little research is available to help
characterize these. The models should be considered
rudimentary and the user is encouraged to explore different
values for the coefficients in attempts to bound the
importance of natural ventilation for the cavities. See the
Engineering Reference for more details.
This field contains the name of an SurfaceProperty:OtherSideConditionsModel
object declared elsewhere in the input file. This will connect
the baffle and ventilated cavity to the exterior boundary
conditions for the underlying heat transfer surface.
This field is used to enter an area fraction for what part
of the baffle consists of openings. The area of the openings
will set to the product of this field and the sum of the area
of the underlying surfaces.
Field:
Thermal Emissivity of Exterior Baffle Material[LINK]
This field is used to enter the thermal emissivity of the
baffler. This surface property is for longwave infrared
radiation. The property is used for both sides of collector.
Most painted materials have an emissivity of 0.9.
Field:
Solar Absorptivity of Exterior Baffle[LINK]
This field is used to enter the solar absorptivity of the
baffle. This surface property is for shortwave, solar
radiation. The property is used for the front side of the
baffle that faces the environment. Darker colors have a higher
absorptivity. While black is the highest performance, other
colors might be used to match the color scheme of the rest of
the façade.
Field:
Height Scale for Buoyancy-Driven Ventilation[LINK]
This field is used to enter a nominal height scale (m) for
prediction of ventilation induced by buoyancy. This value
(\(\Delta {H_{NPL}}\) ) is
defined as the height from the midpoint of the lower opening
to the neutral pressure level. Increasing the value will
increase the ventilation rate due to buoyancy.
Field:
Effective Thickness of Cavity Behind Exterior Baffle[LINK]
This field is used to enter a nominal gap thickness (m) for
the collector. If the baffle is corrugated, use the average
depth. This distance value is only used when the collector is
near horizontal to determine a length scale in the vertical
direction for buoyancy calculations. For example, if the
collector is mounted on a flat roof, its tilt-adjusted height
is zero and the program will use this gap thickness as a
length scale rather than the height from the previous
field.
Field:
Ratio of Actual Surface Area to Projected Surface Area[LINK]
This field is used to enter a factor that accounts for the
extra surface area resulting from and uneven baffle surface.
Corrugations may be present to help stiffen the baffle or
ventilated roofing tiles may have more surface are for
convection heat transfer than the underlying surface. The
projected surface area is obtained by the program from the
(flat) underlying surfaces. If the baffle is flat then this
ratio is 1.0. If the baffle is corrugated, then this ratio
will be greater than one with a typical value might be
1.165.
This field is used to describe the relative roughness of
the baffle material. This field is similar to one in the
Material
object. This parameter only influences the convection
coefficients, more specifically the exterior convection
coefficient. A special keyword is expected in this field with
the options being “VeryRough”, “Rough”, “MediumRough”,
“MediumSmooth”, “Smooth”, and “VerySmooth” in order of
roughest to smoothest options.
Field:
Effectiveness for Perforations with Respect to Wind[LINK]
This field is used to enter a value for the coefficient
used to determine natural air exchanges from wind. Wind will
cause exterior air to move in and out of the cavity. Cv is an
arbitrary coefficient used to model the effectiveness of
openings and depends on opening geometry and the orientation
with respect to the wind. Cv should probably be in the range
0.05 to 0.65. Increasing Cv will increase the amount of
natural ventilation. The following equation shows how Cv is
used in the program to predict the volumetric flow rate due to
wind:
Field:
Discharge Coefficient for Openings with Respect to Buoyancy
Driven Flow[LINK]
This field is used to enter a value for the coefficient
used to determine natural air exchanges from buoyancy. Stack
or buoyancy effects will cause exterior air to move in and out
of the cavity. Cd is an arbitrary discharge coefficient that
depends on the geometry of the opening. Cd should probably be
in the range 0.1 to 1.0. Increasing Cd will increase the
amount of natural ventilation. The following equations show
how Cd is used in the program to predict the volume flow rate
due to buoyancy:
The remaining fields are used to name the BuildingSurface:Detailed
objects that are associated with the exterior naturally vented
cavity. These are the underlying heat transfer surfaces and
are defined elsewhere in the input file. These surfaces should
all specify OtherSideConditionsModel as their exterior
environment. This object is extensible, so additional fields
of this type can be added to the end of this object.
An example IDF entry is
SurfaceProperty:ExteriorNaturalVentedCavity,
PVRoofPaverExtVentCav1 , ! Name
PVRoofPaverSystem1, ! OtherSideConditionsModel Object Name
0.02, ! Area Fraction of Openings
0.9, ! Thermal Emissivity of Exterior Baffle Material
0.92, ! Solar Absorbtivity of Exterior Baffle
0.05, ! Height scale for buoyancy-driven ventilation
0.05, ! Effective Thickness of Cavity Behind Exterior Baffle
0.97, ! Ratio of Actual surface area to projected surface area
Smooth , ! Roughness of collector
0.1 , ! Cv, Effectiveness for perforations with respect to Wind
0.5 , ! Cd, Discharge Coefficient for Openings with respect to buoyancy-driven flow
Zn001:Roof001 ; ! Surface Name
In addition to related output that can be obtained for all
surfaces, these outputs are available for exterior naturally
vented cavity configurations:
HVAC,Average, Surface Exterior Cavity Air Drybulb
Temperature [C]
HVAC,Average, Surface Exterior Cavity Baffle Surface
Temperature [C]
HVAC,Average, Surface Exterior Cavity Total Natural
Ventilation Air Change Rate [ACH]
HVAC,Average, Surface Exterior Cavity Total Natural
Ventilation Mass Flow Rate [kg/s]
HVAC,Average, Surface Exterior Cavity Natural
Ventilation from Wind Mass Flow Rate [kg/s]
HVAC,Average, Surface Exterior Cavity Natural
Ventilation from Buoyancy Mass Flow Rate [kg/s]
Surface
Exterior Cavity Air Drybulb Temperature [C][LINK]
The temperature of air inside the cavity behind the
baffle.
Surface
Exterior Cavity Baffle Surface Temperature [C][LINK]
The surface temperature of the exterior baffle material
itself.
Surface
Exterior Cavity Total Natural Ventilation Air Change Rate
[ACH][LINK]
The rate of natural ventilation air exchange between the
plenum and ambient when the collector is inactive in Air
Changes per Hour.
Surface
Exterior Cavity Total Natural Ventilation Mass Flow Rate
[kg/s][LINK]
The mass flow rate of natural ventilation air exchange
between the plenum and ambient when the collector is
inactive.
Surface
Exterior Cavity Natural Ventilation from Wind Mass Flow Rate
[kg/s][LINK]
The part of mass flow rate of natural ventilation air
exchange between the plenum and ambient when the collector is
inactive due to wind-driven forces.
Surface
Exterior Cavity Natural Ventilation from Buoyancy Mass Flow
Rate [kg/s][LINK]
The part of mass flow rate of natural ventilation air
exchange between the plenum and ambient when the collector is
inactive due to buoyancy-driven forces.
This object can be used as an alternative to the standard
(automatic) EnergyPlus calculation of the solar radiation
incident on interior surfaces of the building. Using this
method, the normal EnergyPlus calculation is replaced with a
schedule of solar incidence values that are calculated outside
the program.
The building surface associated with this object (ref
BuildingSurface:Detailed). Solar absorptance values in the
schedule file will be applied to the inside of this
surface.
The building construction associated with this object (ref
Construction). It is possible that the Energy Management
System will change the construction associated with the
surface; if the construction is changed, a new set of data may
need to be applied to the current surface.
Field:
Inside Surface Incident Sun Solar Radiation Schedule Name[LINK]
This field specifies the name of a schedule that contains
the values for incident solar radiation. Values from the
schedule data will be used to replace the absorbed solar
radiation that would normally be calculated by EnergyPlus.
Units in the external schedule file must be W/m\(^{2}\).
Schedule:Compact,
North Wall SSG, !- Name
Positive Number, !- Schedule Type Limits Name
Through: 12/31, !- Field 1
For: AllDays, !- Field 2
Until: 07:00,10, !- Field 3
Until: 17:00,20, !- Field 5
Until: 24:00,15; !- Field 7
SurfaceProperty:SolarIncidentInside,
North Wall Solar Incident, !- Name
Room102 North Wall, !- Surface Name
Room Wall - North, !- Construction Name
North Wall SSG; !- Schedule Name
This object enables a simplified way to specify the
properties of a shading device that directly discount the
incident solar radiation. The multiplier can be a single fixed
value or a schedule of values. An idd object SurfaceProperty:IncidentSolarMultiplier
will be added to enable users to specify the multiplier. This
multiplier resembles the SHADING-SCHEDULE in DOE-2, which can
adjust the solar heat gain through windows with a multiplier
schedule.
This field is specifies the name of the exterior window
outside surface where the incident solar multiplier is applied
to. If the surface is not an exterior window surface, the
following error message will be shown:
“IncidentSolarMultiplier should be defined for exterior
windows”.
A constant multiplier for the incident solar radiation. The
value should be between 0 and 1 (both inclussive). If not
specified, the default 1.0 will be used. If the Incident Solar
Multiplier Schedule Name is defined, the product of these two
will be the final Incident Solar Multiplier. Otherwise, this
constant multiplier will be applied throughout the
simulation.
Field:
Incident Solar Multiplier Schedule Name[LINK]
The name of the schedule of the incident solar multiplier.
If this field is not defined, the value of the Incident Solar
Multiplier will be used. Otherwise, the product of the two
will be used. The Schedule value needs to be no less than 0
and no greater than 1.
This object can be used as an alternative to the standard
(automatic) EnergyPlus calculation of the solar radiation
absorbed by fenestration systems in the building. Using this
method, the normal EnergyPlus calculation is replaced with a
schedule of solar absorptance values that are calculated
outside the program.
The fenestration surface associated with this object (ref
FenestrationSurface:Detailed). Values from the schedule data
will be used to replace the absorbed solar radiation in the
fenestration layers that would normally be calculated by
EnergyPlus. Value units in the schedule must be W/m\(^{2}\).
The building construction associated with this object (ref
Construction). It is possible that the Energy Management
System will change the construction associated with the
surface; if the construction is changed, a new set of data may
need to be applied to the current surface.
Field:
Layer 1 Solar Radiation Absorbed Schedule Name[LINK]
Specifies the name of a schedule that contains the absorbed
solar radiation values in units of W/m\(^{2}\). Values from the schedule
are used for the absorbed solar radiation of the first
(outside) layer.
Field:
Layer 2 Solar Radiation Absorbed Schedule Name[LINK]
Specifies the name of a schedule that contains absorbed
solar radiation values in units of W/m\(^{2}\). Values from the schedule
are used for the absorbed solar radiation of the second
layer.
Field:
Layer 3 Solar Radiation Absorbed Schedule Name[LINK]
Specifies the name of a schedule that contains absorbed
solar radiation values in units of W/m\(^{2}\). Values from the schedule
are used for the absorbed solar radiation for the third
layer.
Field:
Layer 4 Solar Radiation Absorbed Schedule Name[LINK]
Specifies the name of a schedule that contains absorbed
solar radiation values in units of W/m\(^{2}\). Values from the schedule
are used for the absorbed solar radiation of the fourth
layer.
Field:
Layer 5 Solar Radiation Absorbed Schedule Name[LINK]
Specifies the name of a schedule that contains absorbed
solar radiation values in units of W/m\(^{2}\). Values from the schedule
are used for the absorbed solar radiation of the fifth
layer.
Schedule:Compact,
Layer 1, !- Name
Positive Number, !- Schedule Type Limits Name
Through: 12/31, !- Field 1
For: AllDays, !- Field 2
Until: 07:00,1, !- Field 3
Until: 17:00,2, !- Field 5
Until: 24:00,1.5; !- Field 7
Schedule:Compact,
Layer 2, !- Name
Positive Number, !- Schedule Type Limits Name
Through: 12/31, !- Field 1
For: AllDays, !- Field 2
Until: 07:00,0.8, !- Field 3
Until: 17:00,1.2, !- Field 5
Until: 24:00,1.0; !- Field 7
Schedule:Compact,
Layer 3, !- Name
Positive Number, !- Schedule Type Limits Name
Through: 12/31, !- Field 1
For: AllDays, !- Field 2
Until: 07:00,1, !- Field 3
Until: 17:00,2.1, !- Field 5
Until: 24:00,1.7; !- Field 7
ComplexFenestrationProperty:SolarAbsorbedLayers,
South Window Solar Absorbed Layers, !- Name
Room 102 South Window, !- Fenestration surface name
CFS_Glz_2, !- Construction Surface name
Layer 1, !- Absorbed solar energy in layer 1
Layer 2, !- Absorbed solar energy in layer 2
Layer 3; !- Absorbed solar energy in layer 3
This object provides a simple method of altering the
footprint geometry of a model. The intent is to provide a
single parameter that can be used to reshape the building
description contained in the rest of the input file. This
object was implemented for use in parametric massing studies
and with the optimization program GenOpt. Although building
footprint is often constrained in practice, analysts may find
this object useful for investigating how building form impacts
daylighting and solar gains on the east and west facades
without having to change all of the surface geometry
input.
Aspect Ratio is defined as the overall length in the
East-West direction divided by the overall length in the
North-South direction.
This object should be used with considerable care since it
will completely alter the geometry modeled by EnergyPlus and
may have unintended side effects. The surface areas of all
horizontal surfaces may change radically with corresponding
changes in Zone
floor areas. The total floor area will not change but
individual horizontal surfaces will gain and loose area.
Vertical surfaces will have the same height but will gain and
lose length. Lighting and electrical equipment design levels
for individual zones will likely have a different energy per
unit area in the transformed geometry.
The surface geometry must be set to
Relative, see GlobalGeometryRules.
Of course, the coordinates must be entered in relative
coordinates as well.
Since windows in EnergyPlus need to be rectangular, it is
possible to define a horizontal window (skylight) that once
transformed is no longer rectangular and will cause EnergyPlus
to halt. To avoid this problem, horizontal windows should be
defined orthogonal to the Cardinal directions and building
rotation (see Building)
used to orient the final form with respect to North.
The object doesn’t create any specific output, but the
results of using it can be understood by viewing DXF output
files. Figure 21
shows an example of a building that has been morphed using the
Aspect Ratio Transform object. Using this object allowed the
same geometry input to generate both of the models represented
in by their DXF output files.
This field specifies the plane that the geometry transform
should act on. It is currently restricted to altering the
horizontal footprint of a building and must be set to
“XY.”
This field specifies the aspect ratio of the building
geometry described in the rest of the input file. It is used
to scale the new aspect ratio. If this field is set to 1.0,
then the altered building will not necessarily have the new
aspect ratio defined in the next field.
The object is used to calculate long wave radiation to an
external surface from its surrounding surfaces, defining the
properties of the surrounding surfaces. The property object
declares a list of single surrounding surfaces which has a
name, a field of view factor, and another field Temperature
Schedule Name referencing a schedule containing the
temperature of the surrounding surface, which can be
overwritten at each time step in EnergyPlus run time through
co-simulation. View factors are assumed to be constant values.
At least one surrounding surface should be defined in this
object.
The object also defines the sky and ground temperature and
view factors to the external surface. The sum of all defined
view factors should not exceed 1.0. If only sky view is
defined in this object, the ground view factor to this surface
will be 1.0 subtracted with the ground view factor and all
other defined surface view factors. If only ground view is
defined in this object, the sky view factor to this surface
will be 1.0 subtracted with the sky view factor and all other
defined surface view factors. If neither of the sky and ground
view factors are explicitly declared here, the sum of the sky
and ground view factor would be 1.0 subtracted with all other
defined surface view factors and the proportion will be set as
the same with the global setting.
This field defines the constant sky view factor to an
external surface. The sky view factor used in solar radiation
calculation of the surface would be overwritten with the value
of the fraction if defined here. If the field is left blank,
the sky view factor of this surface will be calculated with
the rules demonstrated above.
This field is used to supply a schedule name of the sky
temperature. The sky temperature used in solar radiation
calculation of the surface would be overwritten with the value
of the scheduled temperature if defined here. If the field is
left blank, the global sky temperature would be used.
This field defines the constant ground view factor to an
external surface. The ground view factor used in solar
radiation calculation of the surface would be overwritten with
the value of the fraction if defined here. If the field is
left blank, the ground view factor of this surface will be
calculated with the rules demonstrated above. Ground surface
view factor defined in SurfaceProperty:GroundSurfaces
object overrides the value specified in this field.
This field is used to supply a schedule name of the ground
temperature. The ground temperature used in long wave
radiation exchange calculation of the surface would be
overwritten with the value of the scheduled temperature if
defined here. If the field is left blank, the global ground
temperature would be used. Ground surface temperature defined
in SurfaceProperty:GroundSurfaces
object overrides the value specified in this field.
This object is used for calculating building exterior
surfaces long-wave radation exchange with the ground and the
calculation of solar radiation reflection from ground surfaces
to a building exterior surface. A given exterior surface can
view multiple ground surfaces with different surface
properties and view factors. Thus, this object allows
specifying multiple ground view factors, ground surfaces
temperature, and ground surfaces refelectance properties
viewed by a given exterior surface. View factors are assumed
to be constant values. The ground surface temperature and
ground surface reflectance are specified using schedule
object. Ground surface view factors and ground surface
temperature defined in this object overrides the ground
surface view factor and ground temperature specified in SurfaceProperty:SurroundingSurfaces
object.
The sum of all defined view factors that include the sky
virew factor, the ground surfaces view factors and surrounding
surfaces view factors seen by a given building exterior
surface should be 1.0, or the sum of the ground view factors
for a given exterior surface should not exceed 1 subtracted
the sky view factor and the sum of view factors of all
surrounding surfaces defined in SurfaceProperty:SurroundingSurfaces
object. If the ground view factor input field is blank in
SurfaceProperty:GroundSurfaces
object, the ground view factor to this surface will be 1.0
subtracted the sky view factor and all other defined
surrounding surface view factors defined in SurfaceProperty:SurroundingSurfaces
object. If neither SurfaceProperty:GroundSurfaces
object nor the SurfaceProperty:SurroundingSurfaces
object is specified for an exterior surface, the default view
factor specified in BuildingSurface:Detailed
or FenestrationSurface:Detailed
object is used.
This field defines the constant ground view factor of a
building exterior surface to ground surface 1. The ground
surface view factor is used in long-wave radiation exchange
and ground surface solar reflectance calculations. If this
field is left blank, the ground view factor of this surface
will be calculated with the rules demonstrated above.
Field:
Ground Surface 1 Temperature Schedule Name[LINK]
This field is used to provide a schedule name of the ground
surface 1 temperature. The ground surface temperature used in
long-wave radiation exchange calculation of a building
exterior surface with the ground surface. If the field is left
blank, the default method will be used.
This field is used to provide a schedule name of a ground
surface reflectance. The ground surface reflectance is used to
calculate ground surface reflected solar radition to a
building exterior surface. If the field is left blank, the
global reflectance object defined else where or default values
will be used.
This object is extensible, so the last four fields can be
repeated to define ground surface name, ground surface view
factor, ground surface temperature, and ground surface
reflectace sets.
Ground surfaces solar reflectance values derived from
satelite data for common ground surfaces obtained from Ground
Albedo Measurements and Modeling (Bill Marion, 2018) are
summerized in table below.
Item
Ground Surface Type
Ground Surface Reflectance
[]
1
Grass
0.15 - 0.26
2
Black Earth
0.08 - 0.13
3
White Sand, New Mexico
0.60
4
Snow
0.55 - 0.98
5
Asphalt Pavement
0.09 - 0.18
6
Concrete Pavement
0.20 - 0.40
An example IDF objects.
SurfaceProperty:GroundSurfaces,
GndSurfs:South, !- Name
GndSurfSouth_Parking, !- Ground Surface 1 Name
0.2, !- Ground Surface 1 View Factor
GndSurfsSouth_Parking_Sch, !- Ground Surface 1 Temperature Schedule Name
GndSurfsSouth_Parking_Sch, !- Ground Surface 1 Reflectance Schedule Name
GndSurfSouth_Grass, !- Ground Surface 2 Name
0.2, !- Ground Surface 2 View Factor
GndSurfsSouth_Grass_Sch, !- Ground Surface 2 Temperature Schedule Name
GndSurfsSouth_Grass_Sch, !- Ground Surface 2 Reflectance Schedule Name
GndSurfSouth_Water, !- Ground Surface 3 Name
0.1, !- Ground Surface 3 View Factor
GndSurfsSouth_Water_Sch, !- Ground Surface 3 Temperature Schedule Name
GndSurfsSouth_Water_Sch; !- Ground Surface 3 Reflectance Schedule Name
SurfaceProperty:LocalEnvironment,
LocEnv:Zn001:Wall001, !- Name
Zn001:Wall001, !- Exterior Surface Name
, !- External Shading Fraction Schedule Name
, !- Surrounding Surfaces Object Name
OutdoorAirNode:0001, !- Outdoor Air Node Name
GndSurfs:South; !- Ground Surfaces Object Name
Zone,Average,Surfaces Property Ground Surfaces Average
Temperature [C]
Zone,Average,Surfaces Property Ground Surfaces Average
Reflectance []
Surfaces
Property Ground Surfaces Average Temperature [C][LINK]
This is an average surface temperature of multiple ground
surfaces in deg C viewed by an exterior surface for each time
step. If there is only one ground surface specified in a given
SurfaceProperty:GroundSurfaces
object, then the average surface temperature will be the same
as the specified ground surface temperature. This output
variable is not generated when all ground surface temperature
schedule name fields are blank.
Surfaces
Property Ground Surfaces Average Reflectance [][LINK]
This is an average surface reflectance of multiple ground
surfaces viewed by an exterior surface for each time step. If
there is only one ground surface specified in a given SurfaceProperty:GroundSurfaces
object, then the average surface reflectance will be the same
as the specified ground surface reflectance. This output
variable is not generated when all ground surface reflectance
schedule name fields are blank.
The object links to an exterior surface object BuildingSurface:Detailed
or an exterior fenestration object FenestrationSurface:Detailed
and is used when there is a need to calculate surface level
environmental data externally and import them into the
simulation to override existing environmental data, including
external solar shading fractions, local air velocity,
temperature and humidity, and surrounding surface
temperatures, sky view factor, ground surfaces view factors,
ground surfaces temperature and ground surfaces refelectance.
The object links to four optional objects including a schedule
object declared by Field: External Shading Fraction
Schedule Name, a SurfaceProperty:SurroundingSurfaces
object declared by Field: Surrounding Surfaces Object
Name, an OutdoorAir:Node
object declared by Field: Outdoor Air Node
Name, and a SurfaceProperty:GroundSurfaces
object declared by Field: Ground Surfaces Object
Name. The object provides inputs to calculate
shading, solar radiation, zone air balance, and surface
exterior heat balance.
This is the name of the surface that will be assigned to
use the local environmental data defined in the next three
fields. This should be a name of a surface defined
elsewhere.
This field is used to import surrounding surfaces
properties (temperature and view factors to the external
surface) from external calculation. This should be a name of a
SurfaceProperty:SurroundingSurfaces
object.
This field is used to import local environmental data from
local outdoor air nodes, including dry and wet bulb
temperature, wind speed and wind direction. This should be a
name of a OutdoorAir:Node
object.
This field is used to specify ground surfaces properties
(ground surface temperature, solar reflectance and view
factors to the external surface) determined from external
calculation. This should be a name of a SurfaceProperty:GroundSurfaces
object.
An example IDF object follows.
SurfaceProperty:LocalEnvironment,
LocEnv:Zn001:Wall001, !- Name
Zn001:Wall001, !- Exterior Surface Name
ExtShadingSch:Zn001:Wall001, !- External Shading Fraction Schedule Name
SrdSurf:Zn001:Wall001, !- Surrounding Surfaces Object Name
OutdoorAirNode:0001, !- Outdoor Air Node Name
GndSurfs:South; !- Ground Surfaces Object Name
The object links to a Zone
object and is used when there is a need to calculate zone
level environmental data externally and import them into the
simulation to override existing environmental data, including
local air temperature and humidity, wind velocity and
direction. links to an OutdoorAir:Node
object declared by Field: Outdoor Air Node
Name. The reference local outdoor air node provides
ambient conditions for the calculation of infiltration and
ventilation at the zone level.
This is the name of the zone that will be assigned to use
the local environmental data defined in the next field. This
should be a name of a zone defined elsewhere.
This field is used to import local environmental data from
local outdoor air nodes, including dry and wet bulb
temperature, wind speed and wind direction. This should be a
name of a OutdoorAir:Node
object.
An example IDF object follows.
ZoneProperty:LocalEnvironment,
LocEnv:Zn001, !- Name
Zn001, !- Exterior Surface Name
OutdoorAirNode:0001; !- Outdoor Air Node Name
The object allows additional heat source term of the
surface boundary condition in the surface heat balance
calculation. The object specifies a surface with the
additional heat source term described by a schedule of heat
rates (can be positive or negative values) in W/m\(^2\). A heat source can be added
to either or both the inside and outside of the same surface.
The heat rates are pre-calculated outside EnergyPlus.
This is the name of the surface that will be assigned to
use the additional heat source term in heat balance
calculation
Field:
Inside Face Heat Source Term Schedule Name[LINK]
The value of this schedule is the source term value for the
inside face of this surface. If this field is left blank, no
inside surface source term will be applied. The schedule
values are heat rate per surface area (W/m2), when positive
schedule values indicate heat gain and negative values
indicates loss.
Field:
Outside Face Heat Source Term Schedule Name[LINK]
The value of this schedule is the source term value for the
outside face of this surface. If this field is left blank, no
outside surface source term will be applied. The schedule
values are heat rate per surface area (W/m2), when positive
schedule values indicate heat gain and negative values
indicates loss.
SurfaceProperty:HeatBalanceSourceTerm,
Zn001:Wall001, !- Surface Name
, !- Inside Face Heat Source Term Schedule Name
HeatSourceSch:001; !- Outside Face Heat Source Term Schedule Name
EnergyPlus has two options for specifying the thermal
radiation exchange view factors between surfaces in a zone:
the approximate option and the user input option. Because the
actual geometric arrangement within a zone is very complex,
the approximate method of including thermal mass and other
forced exchanges is more realistic than trying to come up with
“exact” view factors. However, in some research situations it
might be desirable to have control of the view factors used.
For this reason, a user input mode has been included in
EnergyPlus. The two modes are described in the next
sections.
The first option produces approximate results and uses an
area weighted scheme to calculate “view factors” between
surfaces within a thermal zone. Each surface uses the total
area that it can “see” among the other surfaces. The
approximate view factor from this surface to each other
surface is then the area of the receiving surface over the sum
of areas that are visible to the sending surface.
In order to account in some limited way for the fact that
certain surfaces will not see each other, several assumptions
have been built into this view factor approximation. First, a
surface cannot see itself. Second, surfaces with approximately
the same azimuth (facing direction) and tilt (“same” being
within a built in limit) will not see each other. This means
that a window will not see the wall that it is placed on, for
example. Third, floors cannot see each other. Fourth, if the
surface is a floor, ceiling, roof, or internal mass, the rule
for the same azimuth and tilt eliminating radiant exchange
between surfaces is waived when the receiving surface is
floor, roof, ceiling, or internal mass as long as both
surfaces are not floors.
Note that this does not take into account that surfaces may
be “around the corner” from each other and in reality not see
each other at all. Rooms are assumed to be convex rather than
concave in this method.
To summarize, using the Surface “Class”, the approximate
view factors have:
No surface sees itself.
No Floor sees another floor.
All other surface types see Internal Mass.
All other surface types see floors.
Floors always see ceilings.
Floors always see roofs.
All other surfaces whose tilt or facing angle
differences are greater than 10 degrees see each
other.
If geometry is correct, conditions 1, 3, and 7 should take
care of all surfaces, but the other conditions supply common
sense when the geometry is incorrect. More information about
the EnergyPlus view factor calculation is contained in the
Engineering Reference document.
The second option for specifying view factors requires user
input values. These should be used with care in research or
special situations. The object available for this is ZoneProperty:UserViewFactors:BySurfaceName.
The method of entering user view factors is to enter each
surface name and its view factor value to other surfaces in a
radiant/solar enclosure which may consist of one space, one
zone or a group of spaces or zones.
Field:
Zone or ZoneList or Space or SpaceList Name[LINK]
An enclosure for radiant exchange may be a single space or
zone, or a group of spaces or zones connected by one or more
air boundaries (see Construction:AirBoundary). An enclosure
may also be a group of spaces in the same zone with implied
air boundaries because the spaces are defined only by floor
surfaces (see Space.
If a ZoneList
name is specified, the referenced “ZoneList”)
must match a group of zones connected with Construction:AirBoundary.
Enter the applicable surface pairs with non-zero view
factors. Any omitted surface pair is assumed to have a zero
view factor.
Group – Advanced Surface Concepts[LINK]
This group of objects describe concepts applied to heat transfer surfaces that are of an advanced nature. Careful consideration must be given before using these.
SurfaceProperty:HeatTransferAlgorithm[LINK]
This object, and three other related objects, can be used to control which surface heat transfer model is used on specific surfaces. The separate object called HeatBalanceAlgorithm is used to control the heat transfer model in an overall way while this object can be used to revise the algorithm selections for specific surfaces. This object allows selectively overriding the global setting in HeatBalanceAlgorithm to choose one of the following models for a particular surface:
CTF (Conduction Transfer Functions),
EMPD (Effective Moisture Penetration Depth with Conduction Transfer Functions).
CondFD (Conduction Finite Difference)
HAMT (Combined Heat And Moisture Finite Element)
Inputs[LINK]
Field: Surface Name[LINK]
This is the name of the surface that will be assigned to use the heat transfer algorithm selected in the next field. This should be a name of a surface defined elsewhere.
Field: Algorithm[LINK]
This field is used to determine the heat transfer algorithm that is to be applied to the surface named in the previous field. The allowable choices are:
ConductionTransferFunction
MoisturePenetrationDepthConductionTransferFunction
ConductionFiniteDifference
CombinedHeatAndMoistureFiniteElement
SurfaceProperty:HeatTransferAlgorithm:MultipleSurface[LINK]
This object can be used to control the surface heat transfer model used for specific types of surfaces. The separate object called HeatBalanceAlgorithm is used to control the heat transfer model in an overall way while this object can be used to revise the algorithm selections for specific types of surfaces. This object allows selectively overriding the global setting in HeatBalanceAlgorithm to choose one of the following models for all surfaces of a particular type:
CTF (Conduction Transfer Functions),
EMPD (Effective Moisture Penetration Depth with Conduction Transfer Functions).
CondFD (Conduction Finite Difference)
HAMT (Combined Heat And Moisture Finite Element)
Inputs[LINK]
Field: Name[LINK]
This is a unique, user-defined name for the object.
Field: Surface Type[LINK]
This field is selects the type of surfaces that are all assigned to use the heat transfer algorithm selected in the next field. This field is used with one of the following allowable keywords:
AllExteriorSurfaces—all surfaces that have “Outdoors” outside boundary condition
AllExteriorWalls—all walls that have “Outdoors” outside boundary condition
AllExteriorRoofs—all roofs that have “Outdoors” outside boundary condition
AllExteriorFloors—all floors that have “Outdoors” outside boundary condition
AllGroundContactSurfaces—all surfaces that have “Ground” outside boundary condition
AllInteriorSurfaces—all surfaces that are internal partition-type surfaces
AllInteriorWalls—all walls that are internal surfaces
AllInteriorCeilings—all ceilings that are internal surfaces
AllInteriorFloors—all floors that are internal surfaces
Field: Algorithm[LINK]
This field is used to determine the heat transfer algorithm that is to be applied to the surface types in the previous field. The allowable choices are:
ConductionTransferFunction
MoisturePenetrationDepthConductionTransferFunction
ConductionFiniteDifference
CombinedHeatAndMoistureFiniteElement
SurfaceProperty:HeatTransferAlgorithm:SurfaceList[LINK]
This object can be used to control the surface heat transfer model used for a list of surfaces. The separate object called HeatBalanceAlgorithm is used to control the heat transfer model in an overall way while this object can be used to revise the algorithm selections for a list of specific surfaces. This object allows selectively overriding the global setting in HeatBalanceAlgorithm to choose one of the following models for listed:
CTF (Conduction Transfer Functions),
EMPD (Effective Moisture Penetration Depth with Conduction Transfer Functions).
CondFD (Conduction Finite Difference)
HAMT (Combined Heat And Moisture Finite Element)
Inputs[LINK]
Field: Name[LINK]
This is a unique, user-defined name for the object.
Field: Algorithm[LINK]
This field is used to determine the heat transfer algorithm that is to be applied to the surface listed in the remaining fields. The allowable choices are:
ConductionTransferFunction
MoisturePenetrationDepthConductionTransferFunction
ConductionFiniteDifference
CombinedHeatAndMoistureFiniteElement
Field: Surface Name N[LINK]
This is the name of the “Nth” surface that will be assigned to use the heat transfer algorithm selected in this object. These should be the names of surfaces defined elsewhere. This object is extensible. Additional surfaces can be added to extend the object.
An example IDF object follows.
SurfaceProperty:HeatTransferAlgorithm:Construction[LINK]
This object can be used to control the surface heat transfer model used for surfaces that have a specific type of construction. The separate object called HeatBalanceAlgorithm is used to control the heat transfer model in an overall way while this object can be used to revise the algorithm selections for specific constructions. This object allows selectively overriding the global setting in HeatBalanceAlgorithm to choose one of the following models for all surfaces with particular type of construction:
CTF (Conduction Transfer Functions),
EMPD (Effective Moisture Penetration Depth with Conduction Transfer Functions).
CondFD (Conduction Finite Difference)
HAMT (Combined Heat And Moisture Finite Element)
Inputs[LINK]
Field: Name[LINK]
This is a unique, user-defined name for the object.
Field: Algorithm[LINK]
This field is used to determine the heat transfer algorithm that is to be applied to the surfaces with the type of of construction listed in the next field. The allowable choices are:
ConductionTransferFunction
MoisturePenetrationDepthConductionTransferFunction
ConductionFiniteDifference
CombinedHeatAndMoistureFiniteElement
Field: Construction Name[LINK]
This field is the name of a Construction object defined elsewhere. All the surfaces in the model that are assigned this type of construction will be assigned to use the heat transfer algorithm selected in the previous field.
An example IDF object follows.
SurfaceControl:MovableInsulation[LINK]
Movable insulation can be used/scheduled on any surface regular surface (such as a wall, floor, roof, etc.) but not on a subsurface (such as a window, use WindowShadingControl instead). With movable insulation, no reference is made in the surface that is using the insulation – rather the movable insulation statement references the surface to which it is applied.
Exterior and interior movable insulation have undergone some testing and appears to producing expected results. The underlying principle has been implemented in EnergyPlus for both interior and exterior movable insulation with the possibility for exterior movable insulation to be transparent (transparent insulation material or TIM).
TIM exterior layers can be used with the ConductionFiniteDifference (CondFD) solution algorithm. With this addition, TIM layers can be used in conjunction with wall layers that have phase change materials (PCM) included, or any other advanced capability of the CondFD algorithm such as variable conductivity. The input requirements are exactly the same as when used with the CTF algorithm. The Solution Algorithm needs to be changed to CondFD, and as with CTF, the “SurfaceControl:MovableInsulation” object must be completed to specify the insulated surface and the “WindowMaterial:Glazing” or “WindowMaterial:Glazing:EquivalentLayer” object is needed to provide the TIM layer properties.
Basically, the addition of movable insulation allows the user to schedule an extra amount of insulation on either the inside or outside surface of a wall (or both). The insulation must be a simple, homogenous material layer (linked to a material definition within the input data file). Note that EnergyPlus allows the exterior movable insulation layer to be transparent to short wavelength radiation (solar). In this case, incident solar is split between the plane between the movable insulation and the surface and the plane between the movable insulation and the surrounding air. This calculation is fairly basic and based on the solar transmittance of the insulation layer (material properties). Using transparent layers for exterior movable insulation allows solar energy to penetrate deeper into a construction where it can be stored for later use in the building (similar in concept to a Trombe Wall).
Field: Insulation Type[LINK]
This field determines whether the movable insulation is applied to the inside or the outside of the surface by entering either “Inside” or “Outside”, respectively.
Field: Surface Name[LINK]
This field refers the movable insulation back to a particular surface (ref: Building Surfaces) via its user assigned name so that EnergyPlus knows where to apply this extra layer of insulation. This will affect either the inside or outside surface heat balance of this surface depending on the value in the insulation type field (see previous field).
Field: Material Name[LINK]
This field refers to a material layer (e.g., Material, Material:NoMass, WindowMaterial:Glazing, or WindowMaterial:Glazing:EquivalentLayer; transparent layers are only valid for outside movable insulation) via its user assigned name. This provides the program with a full complement of material properties so that the effect of the insulation (R-value and solar transmittance) can be correctly taken into account by EnergyPlus. Note that for non-glazing materials the solar absorptivity of the layer will be used directly in the calculations. For glazing material layers, the solar absorptivity will be calculated by subtracting both the transmissivity and the front side reflectivity from unity for the material.
Field: Schedule Name[LINK]
This field is a schedule that theoretically can be any positive real number but was originally intended to be a parameter between 0.0 and 1.0. Its purpose is to act as a fractional modifier on the resistance of the material layer. The actual thermal resistance of the movable insulation is equal to the resistance of the material layer times the current value in the movable insulation schedule. A value of 0.0 simply means that the movable insulation is not present.
An example of this syntax implemented in an input file is:
SurfaceProperty:OtherSideCoefficients[LINK]
By referencing the Other Side Coefficients statement in the surface statements (i.e. Outside Boundary Condition), the temperature of the outer plane of a surface (see Figure 1) can be directly controlled. Other side coefficients can also be used to control the exterior convective heat transfer coefficient of a surface and the corresponding exterior air temperature. It should be noted that solar effects are not accounted for when other side coefficients are used. In addition, if other side coefficients are specified for a surface, they also hold for subsurfaces of that surface (though subsurfaces can have their own coefficient set).
other side coefficients have the same effect on all types of heat transfer surfaces. In other words, an interior surface with other side coefficients specified and an exterior wall with identical other side coefficients specified are simulated exactly the same. A surface that uses other side coefficients should be thought of as a new or separate type of surface. All heat transfer surfaces are simulated in the same manner through conduction transfer functions. The only difference between the various types of heat transfer surfaces is the environment on the other side of the surface. For example, the other side environment of an exterior surface is the outdoor environment. For an interior surface, the temperature of the outer plane of the surface is set equal to the temperature of the inner plane of the surface. Similarly, a surface with other side coefficients specified will allow the user to control the other side environment.
Heat transfer through a surface is an extremely important component in the calculation of zone loads. The information to calculate this heat transfer is readily available if the surface is exposed to the outdoor environment or to another zone that is being simulated. Occasionally, a user will want to model the heat transfer through a surface that is adjacent to an area that is not included in the EnergyPlus model. For example, an office area is attached to a warehouse and the user is only interested in simulating the office area. An interior surface with other side coefficients specified could be used to control the environment on the other side of the surface, thereby accounting for the heat transfer through the adjoining surface.
Other Side Coefficients affects the “other side” of a surface as described below. Each coefficient has a special meaning. You may enter a 0 or blank if you are not using a particular coefficient. Note that there are two potential ways to use other side coefficients. Either they are used to set the temperature of the exterior side surface directly (if the combined convective/radiative coefficient below is less than or equal to zero) or to set both the film coefficient (positive value for the combined convective/radiative coefficient below) and the outside air temperature.
Inputs[LINK]
Field: Name[LINK]
This, of course, is the string referenced in the Surface statement that is using OtherSideCoefficients as the Outside Boundary Condition.
Field: Combined Convective/Radiative Film Coefficient[LINK]
This is a trigger value. If the value is greater than zero, then it is taken to be the combined convective/radiative film coefficient. In this case (value > 0), the remaining fields are used first to calculate the outside air temperature for the surface and then to calculate the outside surface temperature based on the outside air temperature and the film coefficient. If this field is less than or equal to zero, then the remaining fields are used to calculate the surface temperature (not the outside air temperature). The units for this field are the same as for a convective heat transfer coefficient: W/(m\(^{2}\)*K). This is referred to as “C1” in the reference below.
Field: Constant Temperature[LINK]
This field defines a temperature term that is a constant part of the calculation either of the surface or outside air temperature. This parameter is shown as “C2” in the equation below. The units for this parameter are degrees C. If a schedule name is included as the second parameter, the value of this parameter will be overridden by the value from the schedule. The default for this field is 0.0.
Field: Constant Temperature Coefficient[LINK]
This field defines a constant coefficient that is applied to the constant temperature (see previous field). This parameter is shown as “C3” in the equation below. This parameter is dimensionless. The value of this parameter is usually 1.0 if a schedule is used to set C2. This field is ignored if Sinusoidal Variation of Constant Temperature Coefficient = Yes. The default for this field is 1.0.
Field: External Dry-Bulb Temperature Coefficient[LINK]
This field defines a constant coefficient that is applied to the outside air dry-bulb temperature. This parameter is shown as “C4” in the equation below. This parameter is dimensionless. The default for this field is 0.0.
Field: Ground Temperature Coefficient[LINK]
This field defines a constant coefficient that is applied to the ground temperature (ref. Site:GroundTemperature:BuildingSurface). This parameter is shown as “C5” in the equation below. This parameter is dimensionless.
Field: Wind Speed Coefficient[LINK]
This field defines a constant coefficient that is applied to the product of the outside air dry-bulb temperature and the wind speed. This parameter is shown as “C6” in the equation below. This parameter has dimensions of inverse velocity or s/m. The default for this field is 0.0.
Field: Zone Air Temperature Coefficient[LINK]
This field defines a constant coefficient that is applied to the temperature of the zone to which this surface belongs. This parameter is shown as “C7” in the equation below. This parameter is dimensionless. The default for this field is 0.0.
Field: Constant Temperature Schedule Name[LINK]
This field is used to supply a schedule name. That schedule will supply the “constant” temperature value C2. Note that the value of the C3 field should normally be 1.0 if a schedule is used for C2. If not blank, this field must be a valid schedule name.
Field: Sinusoidal Variation of Constant Temperature Coefficient[LINK]
This field is optional and can be used to define an alternate method of prescribing the coefficient that is applied to the constant temperature (see the fields Constant Temperature and Constant Temperature Coefficient). This parameter is shown as “C2” in the equation below. If this field is omitted, left blank, or set to “No,” then C2 is a constant (defined in the field Constant Temperature Coefficient). However, if this is set to “Yes,” then the value of C2 varies with a unitary sine wave in the following way:
\[C2 = Sin\left( {2\pi \frac{{\left( {time\,of\,day} \right)}}{{\left( {period} \right)}}} \right)\]
The value for “period” is controlled in the following field. The value for “time of day” is based on the zone timestep and is in units of hours. The sine function here uses input as radians. When using this option, the value for C2 will vary between -1.0 and 1.0 and the value put in the field Constant Temperature Coefficient is not used. This option cannot be used at the same time as scheduling a constant temperature with the previous field.
Field: Period of Sinusoidal Variation[LINK]
This field is used to define the period of the sine wave when using the Sinusoidal Variation of Constant Temperature Coefficient capability selected in the previous field. This field is the time period of the sine wave in units of hours. The default is 24 hours and provides a diurnal sine wave. The value entered here is “period” in the equation in the previous field.
Field: Previous Other Side Temperature Coefficient[LINK]
This field defines a constant coefficient that is applied to the other side temperature computed by this object from the previous zone time step. This parameter is shown as “C8” in the equation below. This parameter is dimensionless. The default for this field is 0.0.
Field: Minimum Other Side Temperature Limit[LINK]
This field specifies a lower limit for the other side temperature result in degrees C. If blank, there is no lower limit.
Field: Maximum Other Side Temperature Limit[LINK]
This field specifies an upper limit for the other side temperature result in degrees C. If blank, there is no upper limit.
The coefficients listed above are used in the following equation:
\[T = C2*C3 + C4*Toadb + C5*Tgrnd + C6*Wspd*Toadb + C7*Tzone + C8*Tpast\]
where:
T = Outside Air Temperature when C1 (Combined convective/radiative film Coeff) > 0
T = Exterior Surface Temperature when C1 (Combined convective/radiative film Coeff) < = 0
Tzone = Temperature of the zone being simulated (°C)
Toadb = Dry-bulb temperature of the outdoor air (°C)
Tgrnd = Temperature of the ground (°C) from Site:GroundTemperature:BuildingSurface
Wspd = Outdoor wind speed (m/sec)
Tpast = Other side temperature from previous zone timestep (°C)
Outputs[LINK]
Surface Other Side Coefficients Exterior Air Drybulb Temperature [C][LINK]
This is the air temperature applied to the other side of the surface.
SurfaceProperty:OtherSideConditionsModel[LINK]
By referencing the Other Side Conditions Model statement in the surface statements (i.e. Outside Boundary Condition), the boundary conditions for the outer plane of the mass wall can be connected to the appropriate model for various multi-skin components. The types of multi-skin components that use this object include systems that are mounted to the outside surface using standoffs that create a small air gap – see Figure 2. This type of modeling allows using the usual heat transfer calculations for the underlying surface with other types of multi-skin component models that are available including: unglazed transpired solar collectors, ventilated photovoltaic panels, and naturally ventilated facades.
The boundary condition values are determined dynamically by the program using internal component models. If you want to define other side surface temperatures or convection conditions, then use SurfaceProperty:OtherSideCoefficients instead of this object.
It should be noted that when other side conditions models are used, solar effects are removed from the surface’s outside face heat balance but are used in modeling the component adjacent to that surface.
The other side conditions model also includes underground piping system interaction. The PipingSystem:Underground:Domain object represents a mass of ground which may include interaction with, for example, basement surfaces. In this case, the ground model will internally use the other side condition model hook to update boundary conditions for those surfaces which use that other side condition model name reference.
The other side conditions model also includes an underwater boundary condition connection. By specifying “ConvectiveUnderwater” as the boundary type, and including any number of “SurfaceProperty:Underwater” objects in the input, the user can connect surfaces to water such as for a moving vessel.
Inputs[LINK]
Field: Name[LINK]
This is the string referenced in the Surface statement that is using OtherSideModel as the Exterior Environment.
Field: Type of Modeling[LINK]
This is a string key selection used to identify the type of model that will be used to determine boundary conditions. The only available choices are “GapConvectionRadiation,” “UndergroundPipingSystemSurface,” “GroundCoupledSurface,” and “ConvectiveUnderwater.”
An example specification is:
Outputs[LINK]
Zone,Average,Surface Other Side Conditions Modeled Convection Air Temperature [C]
Zone,Average,Surface Other Side Conditions Modeled Convection Heat Transfer Coefficient [W/m2-K]
Zone,Average,Surface Other Side Conditions Modeled Radiation Temperature [C]
Zone,Average,Surface Other Side Conditions Modeled Radiation Heat Transfer Coefficient [W/m2-K]
Surface Other Side Conditions Modeled Convection Air Temperature [C][LINK]
This is the air temperature exposed to the other side of the surface by the model and used in convection heat transfer calculations.
Surface Other Side Conditions Modeled Convection Heat Transfer Coefficient [W/m2-K][LINK]
This is the surface convection heat transfer coefficient applied to the other side of the surface by the model.
Surface Other Side Conditions Modeled Radiation Temperature [C][LINK]
This is the effective temperature exposed to the other side of the surface for thermal radiation heat transfer calculations.
Surface Other Side Conditions Modeled Radiation Heat Transfer Coefficient [W/m2-K][LINK]
This is the effective (Linearized) radiation heat transfer coefficient applied to the other side of the surface by the model.
SurfaceProperty:Underwater[LINK]
This object captures the inputs required to model a water-connected boundary condition for a surface. This model is useful for either statically positioned buildings with natural convection to the water boundary condition, or a moving building (vessel).
Inputs[LINK]
Field: Name[LINK]
This is the string referenced in the Surface statement that is using this OtherSideModel as the Exterior Environment.
Field: Distance from Surface Centroid to Leading Edge of Boundary Layer[LINK]
This distance represents the distance from the centroid of this particular surface to leading edge of the boundary layer. For a surface with zero velocity, this field will be irrelevant, because there is no forced boundary layer, and convection will be buoyantly driven. For a moving vessel, this distance should be the nominal distance from the leading edge of the vessel, assuming a nearly flat surface along that path.
Field: Free Stream Water Temperature Schedule[LINK]
This schedule defines the temperature of the free stream water used in the convection calculations.
Field: Free Stream Water Velocity Schedule[LINK]
This schedule defines the average velocity of the free stream water used in the convection calculations. This schedule could be the water velocity as it moves past stationary surface, the surface velocity as it moves past stationary water, or an effective velocity as a result of the combination.
An example specification is:
Foundation:Kiva[LINK]
Foundation:Kiva objects describe boundary conditions for ground-coupled foundation surfaces. Surfaces with the “Outside Boundary Condition” defined as “Foundation”, may also refer to a Foundation:Kiva object in the “Outside Boundary Condition Object” field (if unspecified, a default Foundation:Kiva object will be created and applied).
Limitations when using Foundation:Kiva objects include:
Only floors and walls may use Foundation:Kiva objects as Outside Boundary Conditions.
For a given zone, each floor surface must reference a different Foundation:Kiva object. In other words, multiple foundation floor surfaces may exist in the same thermal zone so long as they reference separate Foundation:Kiva objects. The same Foundation:Kiva object may be referenced by multiple floors so long as they are in different zones.
Any number of wall surfaces may reference a single Foundation:Kiva object so long as that object is referenced by exactly one floor surface in the same thermal zone.
Foundation wall surfaces that are not triangular or quadrilateral may not translate well into the two-dimensional finite difference context.
For each floor surface with “Foundation” set as the “Outside Boundary Condition” there must also be a corresponding “SurfaceProperty:ExposedFoundationPerimeter” object to define how much of the floor perimeter is below exterior walls.
The inputs from Foundation:Kiva objects are translated into Kiva’s foundation heat transfer model. KivaTM generates a two-dimensional heat transfer calculation to represent heat flow between a zone and the adjacent ground. Foundation:Kiva surfaces do not use the same HeatBalanceAlgorithm (e.g., Conduction Transfer Functions) as the rest of the model.
Foundation:Kiva objects are used to describe the two-dimensional features that cannot be captured by the typical one-dimensional constructions used in EnergyPlus. Figure 3 illustrates Kiva’s two-dimensional context for a basement where the basement slab and wall both refer to “Foundation” as the Outside Boundary Condition, the ceiling of the basement and the exterior wall of the zone above the basement refer to “Surface” (or “Zone”) and “Outdoors”, respectively. Note: Not all of the foundation wall surface needs to be below grade (see the “Wall Height Above Grade” field for this object). Any part of the foundation wall above grade is modeled in Kiva’s two-dimensional heat transfer calculations. The non-foundation surfaces are shown in Figure 3 for context, but are not part of the Kiva model.
This context allows for a finer description of the structural and insulation components of a foundation that impact heat transfer (Figure 4).
Foundation:Kiva objects define only the aspects of the foundation that are not already defined by the one-dimensional constructions of the respective surfaces. That is, the footing wall and slab constructions and their relative dimensions are inferred from the respective Surface objects (see Figure 5).
The depth of the foundation is defined by the height of the wall surfaces that reference the Foundation:Kiva boundary condition object. For slab-on-grade foundations, a depth of zero is implied by having no associated wall surfaces. Figure 6 shows a slab-on-grade foundation with whole slab insulation. Notice there are no walls referencing the “Foundation” Outside Boundary Condition. In this case, the under-slab insulation is modeled as part of the slab construction, while the edge/gap insulation is modeled using the interior vertical insulation fields of a Foundation:Kiva object. Note: Since there are no wall surfaces for slab foundations, the footing wall construction is defined within the Foundation:Kiva object (or defaulted to a 0.3m wide cast concrete wall).
A walkout basement (with a variable grade along the sides; see Figure 7) is best modeled using discrete quadrilateral surfaces of stepped height for the walls as shown in Figure 8.
The width of the floor surface in the two-dimensional context is defined by the area and the exposed perimeter (see SurfaceProperty:ExposedFoundationPerimeter) of the floor surface object. Details on this calculation can be found in the Engineering Reference document.
Other components of the two-dimensional context are defined by the Foundation:Kiva:Settings object and applied uniformly for all instances of Foundation:Kiva objects. These components include:
Far-Field width
Deep Ground depth (and boundary type)
Soil and ground surface thermal properties
Example IDF[LINK]
Inputs[LINK]
Field: Name[LINK]
The unique identifier of the Foundation:Kiva object. Referenced by a the “Outside Boundary Condition Object” field in a surface object.
Field: Initial Indoor Air Temperature[LINK]
Indoor air temperature used for Kiva initialization (prior to warmup period). If left blank, indoor air temperature during initialization will be estimated based on zone setpoints.
Field: Interior Horizontal Insulation Material Name[LINK]
A reference to a material object associated with the interior horizontal insulation. If left blank, no interior horizontal insulation will be used. Default: blank.
The following two fields define the placement of this material within Kiva’s two-dimensional context and are illustrated in Figure 9.
Field: Interior Horizontal Insulation Depth[LINK]
Distance from the bottom of the slab to the top of interior horizontal insulation, in m. Generally, interior horizontal insulation is placed directly below the slab, and therefore, this value will generally be set to zero (as indicated in Figure 9). Required if Interior Horizontal Insulation Material Name is defined.
Field: Interior Horizontal Insulation Width[LINK]
Extent of insulation as measured from the wall interior to the edge of interior horizontal insulation, in m. Required if Interior Horizontal Insulation Material Name is defined.
Field: Interior Vertical Insulation Material Name[LINK]
A reference to a material object associated with the interior vertical insulation. If left blank, no interior vertical insulation will be used. Default: blank.
The following field defines the placement of this material within Kiva’s two-dimensional context and are illustrated in Figure 10.
Field: Interior Vertical Insulation Depth[LINK]
Extent of insulation as measured from the wall top to the bottom edge of the interior vertical insulation, in m. Required if Interior Vertical Insulation Material Name is defined.
Field: Exterior Horizontal Insulation Material Name[LINK]
A reference to a material object associated with the exterior horizontal insulation. If left blank, no exterior horizontal insulation will be used. Default: blank.
The following two fields define the placement of this material within Kiva’s two-dimensional context and are illustrated in Figure 11.
Field: Exterior Horizontal Insulation Depth[LINK]
Distance from the exterior grade to the top of exterior horizontal insulation, in m. Required if Exterior Horizontal Insulation Material Name is defined.
Field: Exterior Horizontal Insulation Width[LINK]
Extent of insulation as measured from the wall exterior to the edge of exterior horizontal insulation, in m. Required if Exterior Horizontal Insulation Material Name is defined.
Field: Exterior Vertical Insulation Material Name[LINK]
A reference to a material object associated with the exterior vertical insulation. If left blank, no exterior vertical insulation will be used. Default: blank
The following field defines the placement of this material within Kiva’s two-dimensional context and are illustrated in Figure 12.
Field: Exterior Vertical Insulation Depth[LINK]
Extent of insulation as measured from the wall top to the bottom edge of the exterior vertical insulation, in m. Required if Exterior Vertical Insulation Material Name is defined.
Field: Wall Height Above Grade[LINK]
Distance from the exterior grade to the wall top, in m. Default: 0.2 m
Figures 13 and 14 illustrate the definition of both the “Wall Height Above Grade” and the following field, “Wall Depth Below Slab”. If the top of foundation wall is flush with the ground then the “Wall Height Above Grade” is zero.
Field: Wall Depth Below Slab[LINK]
Distance from the slab bottom to the bottom of the foundation wall, in m. Default: 0.0 m
Extending the wall below the slab provides a coarse approximation of the foundation footing. Alternatively, one may use the fields “Footing Material Name” and “Footing Depth” to explicitly model the footing. Note, that explicit modeling of the footing requires a higher spatial discretization and, therefore, longer computation times.
Field: Footing Wall Construction Name[LINK]
Defines the construction of the foundation footing wall for slab foundations where the foundation wall is not exposed to the zone (and has no zone surface to explicitly assign a construction).
By default, this is the same construction as any associated below-grade wall surfaces, or a 0.3 m wide poured concrete wall (conductivity = 1.95 W/m-K, density = 2240 kg/m3, specific heat = 900 J/kg-K).
Field: Footing Material Name[LINK]
A reference to a material object associated with the foundation footing (typically some form of concrete). The thickness of this material is used to determine the width of the footing. If left blank, no footing will be used. Default: blank
The following field defines the placement of this material within Kiva’s two-dimensional context and are illustrated in Figure 15.
Field: Footing Depth[LINK]
Top-to-bottom dimension of the footing (not to be confused with its depth in the ground). The width of the footing is defined by the material’s thickness. Default: 0.3 m.
Field: Custom Block <x> Material Name[LINK]
A reference to a material object associated with a custom block in the two-dimensional foundation context. The thickness of this material determines the width of the block.
Custom blocks can be used to represent solid materials in the two-dimensional context that are not otherwise covered by the fields above. Examples of this might include interior finishings and insulation (Figure 16) or backfill soil with different thermal properties (Figure 17).
If two or more custom blocks overlap, the final properties are determined by the higher block number (e.g., Custom Block 4 in the input object supersedes properties defined by Custom Block 2). All custom blocks properties are superseded by the elements shown in Figure 4.
The following fields defines the placement of this material within Kiva’s two-dimensional context and are illustrated in Figure 18.
Field: Custom Block <x> Depth[LINK]
Top-to-bottom dimension of the block downward. The default is the depth from the wall top to the top of the slab to facilitate interior constructions. Default: Slab depth
Field: Custom Block <x> X Position[LINK]
Position outward (+) or inward (-) relative to the foundation wall.
Field: Custom Block <x> Z Position[LINK]
Position downward (+) relative to the foundation wall top. Default: Wall top
Outputs[LINK]
Output for surfaces with a Foundation boundary condition type will include all opaque surface output variables except:
Surface Outside Face variables (since there is no “Outside Face”)
Surface Heat Storage variables (since this definition depends on an “Outside Face”)
Surface Internal Source Location Temperature (Kiva doesn’t handle internal sources yet, but this is a possible future enhancement)
Foundation:Kiva:Settings[LINK]
This object defines settings applied across all Kiva foundation calculations. This object is not required. If it is not defined, all defaults will be applied.
Inputs[LINK]
Field: Soil Conductivity[LINK]
The thermal conductivity of the soil, in W/m-K. Default: 1.73 W/m-K.
Field: Soil Density[LINK]
The bulk density of the soil, in kg/m3. Default: 1842 kg/m3.
Field: Soil Specific Heat[LINK]
The specific heat of the soil, in J/kg-K. Default: 419 J/kg-K
Field: Ground Solar Absorptivity[LINK]
Solar absorptivity of the exterior grade surface. Default: 0.9.
Field: Ground Thermal Absorptivity[LINK]
Long-wave absorptivity (emissivity) of the exterior grade surface. Default: 0.9.
Field: Ground Surface Roughness[LINK]
The relief roughness of the exterior ground surface in m. Default: 0.03 m.
Estimates of surface roughnesses in m are shown in Table 1.
Field: Far-Field Width[LINK]
The distance from the wall interior to the zero horizontal heat flux (i.e., adiabatic) far-field boundary, in m. This distance represents either the distance halfway between this foundation and a similar foundation of a neighboring building, or a distance adequately far from the foundation such that it is isolated from the effects of the boundary (typically >= 40 m). Default: 40 m.
Field: Deep-Ground Boundary Condition[LINK]
Defines the type of boundary condition to apply at the Deep-Ground Depth. Options are:
ZeroFlux
GroundWater
Autoselect
ZeroFlux applies a zero vertical heat flux (i.e. adiabatic) boundary condition. GroundWater applies a constant temperature boundary condition, with a temperature equal to the average outdoor air dry-bulb temperature from the environment(s). Autoselect applies either boundary condition depending on the elevation of the building site (Williams and Williamson, 1989):
\[d_{wt}=0.1022\cdot d_{elev}\]
If \(d_{wt} \le\) 40 m., the GroundWater boundary is applied at this depth, otherwise a ZeroFlux boundary is applied at 40 m. If the calculated ground water depth is shallower than any element of a foundation construction, then the GroundWater is applied at 1 m below the lowest element for that foundation.
Default: Autoselect.
Field: Deep-Ground Depth[LINK]
The distance from the exterior grade to the deep ground boundary, in m. This distance represents either the distance to the ground water level, or a distance adequately far from the foundation such that it is isolated from the effects of the boundary (typically >= 40 m). Default 40 m, or the distance determined by the “Autoselect” Deep-Ground Boundary Condition. If the Deep-Ground Boundary Condition is set to “Autoselect”, this field should be set to “Autocalculate”. If the Deep-Ground Boundary Condition is not set to “Autoselect”, but this field is set to “Autocalculate” (or allowed to default), an error will be issued.
Default: Autocalculate.
Field: Minimum Cell Dimension[LINK]
The minimum cell dimension, in m, used in the Kiva discretization. Default: 0.02 m.
Field: Maximum Cell Growth Coefficient[LINK]
The maximum ratio of growth between neighboring cells in the direction away from the near-field area of interest. Default: 1.50.
Field: Simulation Timestep[LINK]
This field allows the user to choose whether to calculate foundation loads on the zone timestep or at hourly intervals. Hourly intervals will allow for less overall computation time, but with less accuracy. Choices are “Hourly” and “Timestep”. Default: Hourly
SurfaceProperty:ExposedFoundationPerimeter[LINK]
This object (currently only used in conjunction with Foundation:Kiva boundary conditions) defines the perimeter of a foundation floor that is exposed to the exterior environment through the floor. The user may either define the total exposed perimeter, the fraction of the total perimeter that is exposed, or individually define which segments of the floor surface perimeter are exposed. This object is required for any floor surface with a Foundation:Kiva boundary condition.
Figure 19 illustrates how the exposed perimeter is determined from a floor plan of the foundation level.
Some buildings may have neighboring zones with different foundation types. For example, a crawlspace next to a garage with a slab (Figure 20). The foundation wall in this case is NOT considered part of either floor’s exposed perimeter, and should not reference a Foundation boundary condition. Kiva does not calculate heat flow between two zones through ground. In this case, it is best to approximate interior foundation wall using an Adiabatic Outside Boundary Condition.
Inputs[LINK]
Field: Surface Name[LINK]
Name of foundation floor surface object.
Field: Exposed Perimeter Calculation Method[LINK]
Required key/choice field that tells which method to use to calculate the exposed foundation perimeter. Choices are:
TotalExposedPerimeter: Exposed perimeter is defined as an absolute distance in m. (The Total Exposed Perimeter field should be filled.)
ExposedPerimeterFraction: Exposed perimeter is defined as a fraction of the total floor perimeter. (The Exposed Perimeter Fraction field should be filled.) Note: This option works best when you are confident that the floor surface is completely exposed.
BySegment: Each segment of the floor polygon (corresponding to distance between each set of vertices) is defined as exposed (“Yes”) or not exposed (“No”) in an extensible list corresponding to the number of vertices in the floor polygon. Exposed perimeter is defined as the sum of all exposed segment lengths. (The Surface Segment <x> Exposed fields should be filled.) Note: The number of segments identified in this object must match the number of vertices in the corresponding surface object.
Field: Total Exposed Perimeter[LINK]
Total perimeter that is exposed in m.
Field: Exposed Perimeter Fraction[LINK]
Fraction of the total perimeter that is exposed. Default 1.0
Field: Surface Segment <x> Exposed[LINK]
Surface Segment <x> is the perimeter between the <x>th and (<x>+1)th vertices.
SurfaceConvectionAlgorithm:Inside:AdaptiveModelSelections[LINK]
This object provides options to change the individual convection model equations for dynamic selection when using AdaptiveConvectionAlgorithm. This object is only needed to make changes to the default model selections for any or all of the surface categories. This object is for the inside face, the side of the surface facing a thermal zone.
Inputs[LINK]
Field: Name[LINK]
A unique name for the object.
Field: Simple Buoyancy Vertical Wall Equation Source[LINK]
Applies to zone with no HVAC or when HVAC is off. This is for vertical walls. The key choice options include: FohannoPolidoriVerticalWall, ASHRAEVerticalWall, AlamdariHammondVerticalWall, KhalifaEq3WallAwayFromHeat, KhalifaEq6NonHeatedWalls FohannoPolidoriVerticalWall, ISO15099Windows, or UserCurve
Field: Simple Buoyancy Vertical Wall User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this field is used when the previous field is set to UserCurve
Field: Simple Buoyancy Stable Horizontal Equation Source[LINK]
Applies to zone with no HVAC or when HVAC is off. This is for horizontal surfaces with heat flow directed for stable thermal stratification. The key choice options include: WaltonStableHorizontalOrTilt, AlamdariHammondStableHorizontal, or UserCurve
Field: Simple Buoyancy Stable Horizontal Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this field is used when the previous field is set to UserCurve
Field: Simple Buoyancy Unstable Horizontal Equation Source[LINK]
Applies to zone with no HVAC or when HVAC is off. This is for passive horizontal surfaces with heat flow for unstable thermal stratification. The key choice options include: WaltonUnstableHorizontalOrTilt, AlamdariHammondUnstableHorizontal, or UserCurve.
Field: Simple Buoyancy Unstable Horizontal Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this field is used when the previous field is set to UserCurve.
Field: Simple Buoyancy Stable Tilted Equation Source[LINK]
Applies to zone with no HVAC or when HVAC is off. This is for tilted surfaces with heat flow for stable thermal stratification. The key choice options include: WaltonStableHorizontalOrTilt, AlamdariHammondStableHorizontal, or UserCurve
Field: Simple Buoyancy Stable Tilted Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this field is used when the previous field is set to UserCurve.
Field: Simple Buoyancy Unstable Tilted Equation Source[LINK]
Applies to zone with no HVAC or when HVAC is off. This is for tilted surfaces with heat flow for unstable thermal stratification. The key choices include: WaltonUnstableHorizontalOrTilt, AlamdariHammondUnstableHorizontal, or UserCurve.
Field: Simple Buoyancy Unstable Tilted Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this field is used when the previous field is set to UserCurve.
Field: Simple Buoyancy Windows Equation Source[LINK]
Applies to zone with no HVAC or when HVAC is off. This is for all window surfaces. The key choice options include: ASHRAEVerticalWall, AlamdariHammondVerticalWall, FohannoPolidoriVerticalWall, KaradagChilledCeiling, ISO15099Windows, or UserCurve.
Field: Simple Buoyancy Windows Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this field is used when the previous field is set to UserCurve.
Field: Floor Heat Ceiling Cool Vertical Wall Equation Source[LINK]
Applies to zone with in-floor heating and/or in-ceiling cooling. This is for vertical walls. The key choice options include: ASHRAEVerticalWall, AlamdariHammondVerticalWall, KhalifaEq3WallAwayFromHeat, FohannoPolidoriVerticalWall, ISO15099Windows, or UserCurve.
Field: Floor Heat Ceiling Cool Vertical Wall Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this field is used when the previous field is set to UserCurve.
Field: Floor Heat Ceiling Cool Stable Horizontal Equation Source[LINK]
Applies to zone with in-floor heating and/or in-ceiling cooling. This is for passive horizontal surfaces with heat flow for stable thermal stratification. The key choice options include: WaltonStableHorizontalOrTilt, AlamdariHammondStableHorizontal, or UserCurve.
Field: Floor Heat Ceiling Cool Stable Horizontal Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this field is used when the previous field is set to UserCurve.
Field: Floor Heat Ceiling Cool Unstable Horizontal Equation Source[LINK]
Applies to zone with in-floor heating and/or in-ceiling cooling. This is for passive horizontal surfaces with heat flow for unstable thermal stratification. The key choice options include: WaltonUnstableHorizontalOrTilt, AlamdariHammondUnstableHorizontal, KhalifaEq4CeilingAwayFromHeat, or UserCurve.
Field: Floor Heat Ceiling Cool Unstable Horizontal Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this field is used when the previous field is set to UserCurve.
Field: Floor Heat Ceiling Cool Heated Floor Equation Source[LINK]
Applies to zone with in-floor heating and/or in-ceiling cooling. This is for a floor with active heating elements. The key choice options include: WaltonUnstableHorizontalOrTilt, AlamdariHammondUnstableHorizontal, AwbiHattonHeatedFloor, or UserCurve
Field: Floor Heat Ceiling Cool Heated Floor Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this field is used when the previous field is set to UserCurve.
Field: Floor Heat Ceiling Cool Chilled Ceiling Equation Source[LINK]
Applies to zone with in-floor heating and/or in-ceiling cooling. This is for a ceiling with active cooling elements. The key choice options include: WaltonUnstableHorizontalOrTilt, AlamdariHammondUnstableHorizontal, KaradagChilledCeiling, or UserCurve.
Field: Floor Heat Ceiling Cool Chilled Ceiling Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this field is used when the previous field is set to UserCurve
Field: Floor Heat Ceiling Cool Stable Tilted Equation Source[LINK]
Applies to zone with in-floor heating and/or in-ceiling cooling. This is for tilted surfaces with heat flow for stable thermal stratification. The key choice options include: WaltonStableHorizontalOrTilt, AlamdariHammondStableHorizontal, ISO15099Windows, or UserCurve.
Field: Floor Heat Ceiling Cool Stable Tilted Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this field is used when the previous field is set to UserCurve.
Field: Floor Heat Ceiling Cool Unstable Tilted Equation Source[LINK]
Applies to zone with in-floor heating and/or in-ceiling cooling. This is for tilted surfaces with heat flow for unstable thermal stratification. The key choice options include: WaltonUnstableHorizontalOrTilt, AlamdariHammondUnstableHorizontal, ISO15099Windows, or UserCurve.
Field: Floor Heat Ceiling Cool Unstable Tilted Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this field is used when the previous field is set to UserCurve.
Field: Floor Heat Ceiling Cool Window Equation Source[LINK]
Applies to zone with in-floor heating and/or in-ceiling cooling. This is for all window surfaces. The key choice options include: ASHRAEVerticalWall, AlamdariHammondVerticalWall, ISO15099Windows, or UserCurve.
Field: Floor Heat Ceiling Cool Window Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this field is used when the previous field is set to UserCurve.
Field: Wall Panel Heating Vertical Wall Equation Source[LINK]
Applies to zone with in-wall panel heating. This is for vertical walls that are not actively heated. The key choice options include: ASHRAEVerticalWall, AlamdariHammondVerticalWall, KhalifaEq6NonHeatedWalls, FohannoPolidoriVerticalWall, AlamdariHammondVerticalWall, ISO15099Windows, or UserCurve.
Field: Wall Panel Heating Vertical Wall Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this field is used when the previous field is set to UserCurve.
Field: Wall Panel Heating Heated Wall Equation Source[LINK]
Applies to zone with in-wall panel heating. This is for vertical walls that are being actively heated. The key choice options include: ASHRAEVerticalWall, AlamdariHammondVerticalWall, KhalifaEq5WallNearHeat, AwbiHattonHeatedWall, FohannoPolidoriVerticalWall, AlamdariHammondVerticalWall, or UserCurve.
Field: Wall Panel Heating Heated Wall Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this field is used when the previous field is set to UserCurve.
Field: Wall Panel Heating Stable Horizontal Equation Source[LINK]
Applies to zone with in-wall panel heating. This is for horizontal surfaces with heat flow directed for stable thermal stratification. The key choice options include: WaltonStableHorizontalOrTilt, AlamdariHammondStableHorizontal, or UserCurve.
Field: Wall Panel Heating Stable Horizontal Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this field is used when the previous field is set to UserCurve.
Field: Wall Panel Heating Unstable Horizontal Equation Source[LINK]
Applies to zone with in-wall panel heating. This is for horizontal surfaces with heat flow directed for unstable thermal stratification. The key choice options include: ASHRAEVerticalWall, WaltonUnstableHorizontalOrTilt, AlamdariHammondUnstableHorizontal, KhalifaEq7Ceiling, or UserCurve
Field: Wall Panel Heating Unstable Horizontal Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this field is used when the previous field is set to UserCurve.
Field: Wall Panel Heating Stable Tilted Equation Source[LINK]
Applies to zone with in-wall panel heating. This is for tilted surfaces with heat flow for stable thermal stratification. The key choice options include: WaltonStableHorizontalOrTilt, AlamdariHammondStableHorizontal, ISO15099Windows, or UserCurve.
Field: Wall Panel Heating Stable Tilted Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this field is used when the previous field is set to UserCurve
Field: Wall Panel Heating Unstable Tilted Equation Source[LINK]
Applies to zone with in-wall panel heating. This is for tilted surfaces with heat flow for unstable thermal stratification. The key choice options include: WaltonUnstableHorizontalOrTilt, AlamdariHammondUnstableHorizontal, ISO15099Windows, or UserCurve.
Field: Wall Panel Heating Unstable Tilted Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this field is used when the previous field is set to UserCurve.
Field: Wall Panel Heating Window Equation Source[LINK]
Applies to zone with in-wall panel heating. This is for all window surfaces. The key choice options include: ASHRAEVerticalWall, AlamdariHammondVerticalWall, FohannoPolidoriVerticalWall, ISO15099Windows, or UserCurve.
Field: Wall Panel Heating Window Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this field is used when the previous field is set to UserCurve.
Field: Convective Zone Heater Vertical Wall Equation Source[LINK]
Applies to zone with convective heater. This is for vertical walls not directly affected by heater. The key choice options include: ASHRAEVerticalWall, AlamdariHammondVerticalWall, KhalifaEq3WallAwayFromHeat, KhalifaEq6NonHeatedWalls, FohannoPolidoriVerticalWall, ISO15099Windows, or UserCurve
Field: Convective Zone Heater Vertical Wall Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this field is used when the previous field is set to UserCurve.
Field: Convective Zone Heater Vertical Walls Near Heater Equation Source[LINK]
Applies to zone with convective heater. This is for vertical walls that are directly affected by heater. Walls are considered “near” when listed in field set for Fraction of Radiant Energy to Surface. The key choice options include: ASHRAEVerticalWall, AlamdariHammondVerticalWall, KhalifaEq5WallNearHeat, AwbiHattonHeatedWall, FohannoPolidoriVerticalWall, ISO15099Windows, or UserCurve.
Field: Convective Zone Heater Vertical Walls Near Heater Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this field is used when the previous field is set to UserCurve.
Field: Convective Zone Heater Stable Horizontal Equation Source[LINK]
Applies to zone with convective heater. This is for horizontal surfaces with heat flow directed for stable thermal stratification. The key choice options include: WaltonStableHorizontalOrTilt, AlamdariHammondStableHorizontal, or UserCurve.
Field: Convective Zone Heater Stable Horizontal Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this field is used when the previous field is set to UserCurve
Field: Convective Zone Heater Unstable Horizontal Equation Source[LINK]
Applies to zone with convective heater. This is for horizontal surfaces with heat flow directed for unstable thermal stratification. The key choice options include: WaltonUnstableHorizontalOrTilt, AlamdariHammondUnstableHorizontal, KhalifaEq4CeilingAwayFromHeat, KhalifaEq7Ceiling, or UserCurve.
Field: Convective Zone Heater Unstable Horizontal Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this field is used when the previous field is set to UserCurve.
Field: Convective Zone Heater Stable Tilted Equation Source[LINK]
Applies to zone with convective heater. This is for tilted surfaces with heat flow for stable thermal stratification. The key choice options include: WaltonStableHorizontalOrTilt, AlamdariHammondStableHorizontal, or UserCurve.
Field: Convective Zone Heater Stable Tilted Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this field is used when the previous field is set to UserCurve.
Field: Convective Zone Heater Unstable Tilted Equation Source[LINK]
Applies to zone with convective heater. This is for tilted surfaces with heat flow for unstable thermal stratification. The key choice options include: WaltonUnstableHorizontalOrTilt, AlamdariHammondUnstableHorizontal, or UserCurve.
Field: Convective Zone Heater Unstable Tilted Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this field is used when the previous field is set to UserCurve.
Field: Convective Zone Heater Windows Equation Source[LINK]
Applies to zone with convective heater. This is for all window surfaces. The key choice options include: ASHRAEVerticalWall, AlamdariHammondVerticalWall, KhalifaEq3WallAwayFromHeat, FohannoPolidoriVerticalWall, ISO15099Windows, or UserCurve.
Field: Convective Zone Heater Windows Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this field is used when the previous field is set to UserCurve.
Field: Central Air Diffuser Wall Equation Source[LINK]
Applies to zone with mechanical forced central air with diffusers. This is for all wall surfaces. The key choice options include: ASHRAEVerticalWall, FisherPedersenCeilingDiffuserWalls, AlamdariHammondVerticalWall, BeausoleilMorrisonMixedAssistedWall, BeausoleilMorrisonMixedOpposingWall, FohannoPolidoriVerticalWall, ISO15099Windows, GoldsteinNovoselacCeilingDiffuserWalls, or UserCurve
Field: Central Air Diffuser Wall Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this field is used when the previous field is set to UserCurve.
Field: Central Air Diffuser Ceiling Equation Source[LINK]
Applies to zone with mechanical forced central air with diffusers. This is for all ceiling surfaces. The key choice options include: FisherPedersenCeilingDiffuserCeiling, BeausoleilMorrisonMixedStableCeiling, BeausoleilMorrisonMixedUnstableCeiling, or UserCurve.
Field: Central Air Diffuser Ceiling Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this field is used when the previous field is set to UserCurve.
Field: Central Air Diffuser Floor Equation Source[LINK]
Applies to zone with mechanical forced central air with diffusers. This is for all floor surfaces. The key choice options include: FisherPedersenCeilingDiffuserFloor, BeausoleilMorrisonMixedStableFloor, BeausoleilMorrisonMixedUnstableFloor, GoldsteinNovoselacCeilingDiffuserFloor, or UserCurve.
Field: Central Air Diffuser Floor Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this field is used when the previous field is set to UserCurve.
Field: Central Air Diffuser Window Equation Source[LINK]
Applies to zone with mechanical forced central air with diffusers. This is for all window surfaces. The key choice options include: ASHRAEVerticalWall, FisherPedersenCeilingDiffuserWalls, BeausoleilMorrisonMixedAssistedWall, BeausoleilMorrisonMixedOpposingWall, FohannoPolidoriVerticalWall, AlamdariHammondVerticalWall, ISO15099Windows, GoldsteinNovoselacCeilingDiffuserWindow, or UserCurve.
Field: Central Air Diffuser Window Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this field is used when the previous field is set to UserCurve
Field: Mechanical Zone Fan Circulation Vertical Wall Equation Source[LINK]
The key choice options include: KhalifaEq3WallAwayFromHeat, ASHRAEVerticalWall, FisherPedersenCeilingDiffuserWalls, AlamdariHammondVerticalWall, BeausoleilMorrisonMixedAssistedWall, BeausoleilMorrisonMixedOpposingWall, FohannoPolidoriVerticalWall, ISO15099Windows, GoldsteinNovoselacCeilingDiffuserWalls, or UserCurve.
Field: Mechanical Zone Fan Circulation Vertical Wall Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this field is used when the previous field is set to UserCurve
Field: Mechanical Zone Fan Circulation Stable Horizontal Equation Source[LINK]
The key choice options include: WaltonStableHorizontalOrTilt, AlamdariHammondStableHorizontal, or UserCurve.
Field: Mechanical Zone Fan Circulation Stable Horizontal Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this field is used when the previous field is set to UserCurve.
Field: Mechanical Zone Fan Circulation Unstable Horizontal Equation Source[LINK]
The key choice options include: KhalifaEq4CeilingAwayFromHeat, WaltonUnstableHorizontalOrTilt, AlamdariHammondUnstableHorizontal, or UserCurve.
Field: Mechanical Zone Fan Circulation Unstable Horizontal Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this field is used when the previous field is set to UserCurve.
Field: Mechanical Zone Fan Circulation Stable Tilted Equation Source[LINK]
The key choice options include: WaltonStableHorizontalOrTilt or UserCurve
Field Mechanical Zone Fan Circulation Stable Tilted Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this field is used when the previous field is set to UserCurve.
Field: Mechanical Zone Fan Circulation Unstable Tilted Equation Source[LINK]
The key choice options include: WaltonUnstableHorizontalOrTilt, AlamdariHammondUnstableHorizontal, or UserCurve.
Field: Mechanical Zone Fan Circulation Unstable Tilted Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this field is used when the previous field is set to UserCurve.
Field: Mechanical Zone Fan Circulation Window Equation Source[LINK]
The key choice options include: ASHRAEVerticalWall, AlamdariHammondVerticalWall, FohannoPolidoriVerticalWall, ISO15099Windows, GoldsteinNovoselacCeilingDiffuserWindow, or UserCurve.
Field: Mechanical Zone Fan Circulation Unstable Tilted Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this field is used when the previous field is set to UserCurve
Field: Mixed Regime Buoyancy Assisting Flow on Walls Equation Source[LINK]
The key choice options include: BeausoleilMorrisonMixedAssistedWall, AlamdariHammondVerticalWall, FohannoPolidoriVerticalWall, ASHRAEVerticalWall, FisherPedersenCeilingDiffuserWalls, GoldsteinNovoselacCeilingDiffuserWalls, or UserCurve.
Field: Mixed Regime Buoyancy Assisting Flow on Walls Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this field is used when the previous field is set to UserCurve.
Field: Mixed Regime Buoyancy Opposing Flow on Walls Equation Source[LINK]
The key choice options include: BeausoleilMorrisonMixedOpposingWall, AlamdariHammondVerticalWall, FohannoPolidoriVerticalWall, ASHRAEVerticalWall, FisherPedersenCeilingDiffuserWalls, GoldsteinNovoselacCeilingDiffuserWalls, or UserCurve
Field: Mixed Regime Buoyancy Opposing Flow on Walls Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this field is used when the previous field is set to UserCurve
Field: Mixed Regime Stable Floor Equation Source[LINK]
The key choice options include: BeausoleilMorrisonMixedStableFloor, WaltonStableHorizontalOrTilt, AlamdariHammondStableHorizontal, or UserCurve
Field: Mixed Regime Stable Floor Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this field is used when the previous field is set to UserCurve.
Field: Mixed Regime Unstable Floor Equation Source[LINK]
The key choice options include: BeausoleilMorrisonMixedUnstableFloor, WaltonUnstableHorizontalOrTilt, AlamdariHammondUnstableHorizontal, or UserCurve.
Field: Mixed Regime Unstable Floor Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this field is used when the previous field is set to UserCurve.
Field: Mixed Regime Stable Ceiling Equation Source[LINK]
The key choice options include: BeausoleilMorrisonMixedStableCeiling, WaltonStableHorizontalOrTilt, AlamdariHammondStableHorizontal, or UserCurve.
Field: Mixed Regime Stable Ceiling Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this field is used when the previous field is set to UserCurve.
Field: Mixed Regime Unstable Ceiling Equation Source[LINK]
The key choice options include: BeausoleilMorrisonMixedUnstableCeiling, WaltonUnstableHorizontalOrTilt, AlamdariHammondUnstableHorizontal, or UserCurve.
Field: Mixed Regime Unstable Ceiling Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this field is used when the previous field is set to UserCurve.
Field: Mixed Regime Window Equation Source[LINK]
The key choice options include: GoldsteinNovoselacCeilingDiffuserWindow, ISO15099Windows, or UserCurve.
Field: Mixed Regime Window Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this field is used when the previous field is set to UserCurve.
SurfaceConvectionAlgorithm:Outside:AdaptiveModelSelections[LINK]
Options to change the individual convection model equations for dynamic selection when using AdaptiveConvectionAlgorithm. This object is only needed to make changes to the default model selections for any or all of the surface categories. This object is for the outside face, the side of the surface facing away from the thermal zone.
Inputs[LINK]
Field: Name[LINK]
A unique name for the object
Field: Wind Convection Windward Vertical Wall Equation Source[LINK]
This is for just the wind-driven component of the total convection coefficient. The key choice options include: SimpleCombined, TARPWindward, MoWiTTWindward, DOE2Windward, NusseltJurges, McAdams, Mitchell, Blocken, Emmel, or UserCurve.
Field: Wind Convection Windward Equation Vertical Wall User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this field is used when the previous field is set to UserCurve.
Field: Wind Convection Leeward Vertical Wall Equation Source[LINK]
This is for just the wind-driven component of the total convection coefficient. The key choice options include: SimpleCombined, TARPLeeward, MoWiTTLeeward, DOE2Leeward, Emmel, NusseltJurges, McAdams, Mitchell, or UserCurve.
Field: Wind Convection Leeward Vertical Wall Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this field is used when the previous field is set to UserCurve.
Field: Wind Convection Horizontal Roof Equation Source[LINK]
This is for just the wind-driven component of the total convection coefficient. The key choice options include: SimpleCombined, TARPWindward, MoWiTTWindward, DOE2Windward, NusseltJurges, McAdams, Mitchell, Blocken, Emmel, ClearRoof, or UserCurve.
Field: Wind Convection Horizontal Roof User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this field is used when the previous field is set to UserCurve.
Field: Natural Convection Vertical Wall Equation Source[LINK]
This is for just the natural convection portion of the total film coefficient. This is for vertical walls. The key choice options include: ASHRAEVerticalWall, AlamdariHammondVerticalWall, FohannoPolidoriVerticalWall, ISO15099Windows, UserCurve, or None.
Field: Natural Convection Vertical Wall Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this field is used when the previous field is set to UserCurve.
Field: Natural Convection Stable Horizontal Equation Source[LINK]
This is for just the natural convection portion of the total film coefficient. This is for horizontal surfaces with heat flow directed for stable thermal stratification. The key choice options include: WaltonStableHorizontalOrTilt, AlamdariHammondStableHorizontal, UserCurve, or None.
Field: Natural Convection Stable Horizontal Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this field is used when the previous field is set to UserCurve.
Field: Natural Convection Unstable Horizontal Equation Source[LINK]
This is for just the natural convection portion of the total film coefficient. This is for horizontal surfaces with heat flow directed for unstable thermal stratification. The key choice options include: WaltonUnstableHorizontalOrTilt, AlamdariHammondUnstableHorizontal, UserCurve, or None
Field: Natural Convection Unstable Horizontal Equation User Curve Name[LINK]
The SurfaceConvectionAlgorithm:UserCurve named in this field is used when the previous field is set to UserCurve.
SurfaceConvectionAlgorithm:Inside:UserCurve[LINK]
This object is used to describe a custom model equation for surface convection heat transfer coefficients. If more than one curve is referenced, or non-blank, then they are all used, and the result is the simple addition of all the curve results.
Inputs[LINK]
Field: Name[LINK]
Unique name of input object.
Field: Reference Temperature for Convection Heat Transfer[LINK]
This field controls the nature of the reference temperature used with convection coefficient when calculating the heat flow at the surface. Select one of the three choices: MeanAirTemperature, AdjacentAirTemperature, SupplyAirTemperature. MeanAirTemperature is the typical application for the classic convection model used with the complete mixing of room air. AdjacentAirTemperature applies when used with Roomair models that account for temperature variations within the zone air and directs the model to use the temperature near the surface rather than the average for the entire zone. SupplyAirTemperature directs the model to use the supply air conditions for the heat transfer conditions.
Field: Hc Function of Temperature Difference Curve Name[LINK]
This field contains the name of separate performance curve or table object that describes h\(_{c}\), the convection coefficient, as a function of temperature difference. The curve’s “x” is absolute value of delta-T (Surface temperature minus air temperature, (C))
Field: Hc Function of Temperature Difference Divided by Height Curve Name[LINK]
This field contains the name of separate performance curve or table object that describes h\(_{c}\), the convection coefficient, as a function of temperature difference divided by height. The curve’s “x” is absolute value of delta-T/Height (Surface temp minus Air temp)/(vertical length scale), (C/m). For an inside face, the vertical length scale is the zone’s interior height.
Field: Hc Function of Air Change Rate Curve Name[LINK]
This field contains the name of separate performance curve or table object that describes h\(_{c}\), the convection coefficient, as a function of air change rate. The curve’s “x” is mechanical ACH (Air Changes per hour from mechanical air system), (1/hr)
Field: Hc Function of Air System Volume Flow Rate Divided by Zone Perimeter Length Curve Name[LINK]
This field contains the name of separate performance curve or table object that describes h\(_{c}\), the convection coefficient, as a function of air change rate divided perimeter scale. Curve’s “x” is mechanical system air flow rate (m\(^{3}\)/s) divided by zone’s length along exterior walls (m).
SurfaceConvectionAlgorithm:Outside:UserCurve[LINK]
This object is used to describe a custom model equation for surface convection heat transfer coefficients. If more than one curve is referenced, or non-blank, then they are all used and the result is the simple addition of all the curve results.
Inputs[LINK]
Field: Name[LINK]
Unique name of input object.
Field: Wind Speed Type for Curve[LINK]
This field specifies what sort of wind velocity data should be used in when evaluating the curve in the following field. There are for key choice options. “WeatherFile” directs using the unmodified value from the epw file or design weather data. “HeightAdjust” uses the value from the epw file modified for height above ground, as determined by the z coordinate, using the site terrain and weather station information. “ParallelComponent” uses the value from the epw file modified to take just the velocity component that is parallel to the surface. “ParallelComponentHeightAdjust” uses the height adjusted wind velocity and then computes the parallel component.
Field: Hf Function of Wind Speed Curve Name[LINK]
This field contains the name of separate performance curve or table object that describes h\(_{f}\), the forced convection coefficient, as a function of wind speed. The curve’s “x” is wind speed as defined by the method chosen in the previous field.
Field: Hn Function of Temperature Difference Curve Name[LINK]
This field contains the name of separate performance curve or table object that describes h\(_{n}\), the natural convection coefficient, as a function of temperature difference. Curve’s “x” is absolute value of delta-T (Surface temperature minus air temperature, (C))
Field: Hc Function of Temperature Difference Divided by Height Curve Name[LINK]
This field contains the name of separate performance curve or table object that describes h\(_{n}\), the natural convection coefficient, as a function of temperature difference divided by height. Curve’s “x” is absolute value of delta-T/Height (Surface temp minus Air temp)/(vertical length scale), (C/m). For an outside face the vertical length scale is the exterior facade’s overall height.
SurfaceProperty:ConvectionCoefficients[LINK]
The convection coefficients of each surface, both exterior and interior, are automatically calculated during EnergyPlus execution. These calculations are “governed” by other objects such as the SurfaceConvectionAlgorithm:Inside (overall default), the Zone object’s field called Zone Inside Convection Algorithm (Zone Default), the and the SurfaceConvectionAlgorithm:Outside (overall default), and/or the Zone object’s field called Zone Outside Convection Algorithm (Zone Default). Usually, that will be enough flexibility for most users. However, if you need to match pre-existing convection coefficients (from another program) or are trying to match a test suite of results, you may wish to use the “override” convection coefficients in the following object. This object allows for a single surface to be given specific convection coefficients.
Note that using these in conjunction, in particular, the “Simple” option on either the Outside Convection Algorithm or the Zone Outside Convection Algorithm field will result in a combined coefficient regardless of choice chosen here.
Note that surfaces with “SurfaceProperty:OtherSideCoefficients” cannot use this object with the “outside” coefficient – attempting to do so will cause a severe error; SurfaceProperty:OtherSideCoefficients surfaces can apply an “inside” coefficient. And, surfaces with “Ground” exposure do not use the “outside” coefficient that might be supplied here. Note, too, that some lower boundaries are used regardless by certain surface types (i.e. Window) or certain algorithm types.
Inputs[LINK]
Field: Surface Name[LINK]
This field is the applicable surface name for the user supplied convection coefficient.
Fields (Convection Location, Type, Coefficient & Schedule Name)[LINK]
For simplicity, the descriptions of these field occur together – however, the fields are used sequentially when put into the IDF file (reference the IDF examples following the descriptions).
Field: Convection Coefficient 1 Location[LINK]
Field: Convection Coefficient 2 Location[LINK]
This field contains the word “Outside” or “Inside” depending on which location is being described.
Field: Convection Coefficient 1 Type[LINK]
Field: Convection Coefficient 2 Type[LINK]
The entries can be of several types: Value (simple numeric value), Schedule (name of schedule with the values), the usual key choices for overall models for Outside or Inside (Simple, SimpleCombined, TARP, AdaptiveConvectionAlgorithm etc.), the key choices for individual convection equations used for customizing the adaptive algorithm, or a custom user defined correlation. The field should contain one of the keys listed in the table below along with face they can be applied. The definitions of the models and key choices are discussed under SurfaceConvectionAlgorithm:Inside, SurfaceConvectionAlgorithm:Outside, SurfaceConvectionAlgorithm:Inside:AdaptiveModelSelections, and SurfaceConvectionAlgorithm:Outside:AdaptiveModelSelections.
Field: Convection Coefficient 1[LINK]
Field: Convection Coefficient 2[LINK]
If the Convection type was “Value”, then this field is filled and contains the simple value to be used. Otherwise, this can be blank.
Field: Convection Coefficient 1 Schedule Name[LINK]
Field: Convection Coefficient 2 Schedule Name[LINK]
If the Convection type was “Schedule”, then this field contains the name of a schedule describing the value to be used during the time intervals for the schedule.
Field: Convection Coefficient 1 User Curve Name[LINK]
Field: Convection Coefficient 2 User Curve Name[LINK]
If the Convection type was “UserCurve”, then this field contains the name of a SurfaceConvectionAlgorithm:UserCurve input object describing the model equations to be used during the time intervals for the schedule.
In IDF usage:
SurfaceProperty:ConvectionCoefficients:MultipleSurface[LINK]
The convection coefficients of each surface, both outside and inside, are automatically calculated during EnergyPlus execution. These calculations are “governed” by other objects such as the Inside Convection Algorithm (overall default) and the Zone Inside Convection Algorithm (Zone Default) and the Outside Convection Algorithm (overall default) and/or the Zone Outside Convection Algorithm (Zone Default). Usually, that will be enough flexibility for most users. However, if you need to match pre-existing convection coefficients (from another program) or are trying to match a test suite of results, you may wish to use the “override” convection coefficients in the following object. This object is similar to the preceding “ConvectionCoefficients” object but allows multiple surfaces to be assigned a type with one object entry.
Note that using these in conjunction, in particular, the “Simple” option on either the Outside Convection Algorithm or the Zone Outside Convection Algorithm field will result in a combined coefficient regardless of choice chosen here.
Note that surfaces with “SurfaceProperty:OtherSideCoefficients” cannot use this object with the “outside” coefficient – attempting to do so will ignore OSC surfaces during a multiple surface “apply”; SurfaceProperty:OtherSideCoefficients surfaces can apply an “inside” coefficient. And, surfaces with “Ground” exposure do not use the “outside” coefficient that might be supplied here. Note, too, that some lower boundaries are used regardless by certain surface types (i.e. Window) or certain algorithm types.
Inputs[LINK]
Field: Surface Type[LINK]
This field is the applicable surface name for the user supplied convection coefficient. The allowable surface types are:
AllExteriorSurfaces (all surfaces that are “external environment” surfaces)
AllExteriorWindows (all windows that are “external environment” surfaces)
AllExteriorWalls
AllExteriorRoofs
AllExteriorFloors
AllInteriorSurface (all surfaces that are “internal” surfaces)
AllInteriorWindows
AllInteriorCeilings
AllInteriorFloors
Fields (Convection Location, Type, Coefficient & Schedule Name)[LINK]
For simplicity, the descriptions of these field occur together – however, the fields are used sequentially when put into the IDF file (reference the IDF examples following the descriptions).
Field: Convection Coefficient 1 Location[LINK]
Field: Convection Coefficient 2 Location[LINK]
This field contains the word “Outside” or “Inside” depending on which location is being described.
Field: Convection Coefficient 1 Type[LINK]
Field: Convection Coefficient 2 Type[LINK]
The entries can be of several types: Value (simple numeric value), Schedule (name of schedule with the values), the usual key choices for overall models for Outside or Inside (Simple, SimpleCombined, TARP, AdaptiveConvectionAlgorithm etc.), the key choices for individual convection equations used for customizing the adaptive algorithm, or a custom user defined correlation. The field should contain one of the keys listed in the table below along with face they can be applied. The definitions of the models and key choices are discussed under SurfaceConvectionAlgorithm:Inside , SurfaceConvectionAlgorithm:Outside, SurfaceConvectionAlgorithm:Inside:AdaptiveModelSelections, and SurfaceConvectionAlgorithm:Outside:AdaptiveModelSelections.
Field: Convection Coefficient 1[LINK]
Field: Convection Coefficient 2[LINK]
If the Convection type was “Value”, then this field is filled and contains the simple value to be used. Otherwise, this can be blank.
Field: Convection Coefficient 1 Schedule Name[LINK]
Field: Convection Coefficient 2 Schedule Name[LINK]
If the Convection type was “Schedule”, then this field contains the name of a schedule describing the value to be used during the time intervals for the schedule.
Field: Convection Coefficient 1 User Curve Name[LINK]
Field: Convection Coefficient 2 User Curve Name[LINK]
If the Convection type was “UserCurve”, then this field contains the name of a SurfaceConvectionAlgorithm:UserCurve input object describing the model equations to be used during the time intervals for the schedule.
In IDF usage:
Convection Coefficient Application Hierarchy[LINK]
Ultimate flexibility and possibly ultimate user confusion can result from the convection coefficient possibilities in EnergyPlus. The objects that control how convection models are assigned to individual surfaces are:
SurfaceConvectionAlgorithm:Inside
SurfaceConvectionAlgorithm:Outside
Zone, Field: Zone Inside Convection Algorithm
Zone, Field: Zone Outside Convection Algorithm
SurfaceProperty:ConvectionCoefficients
SurfaceProperty:ConvectionCoefficients:MultipleSurface
General to Specific, they are assigned in this order:
There are additional objects that provide fine control over the models that get assigned.
SurfaceConvectionAlgorithm:Inside:AdaptiveModelSelections
SurfaceConvectionAlgorithm:Outside:AdaptiveModelSelections
SurfaceConvectionAlgorithm:Inside:UserCurve
SurfaceConvectionAlgorithm:Outside:UserCurve
Convection Coefficients Outputs[LINK]
Outputs for the User Supplied Convection Coefficients appear as values in the Surface Output Variables (Surface Inside Face Convection Heat Transfer Coefficient and Surface Outside Face Convection Heat Transfer Coefficient). What the program expects to use is shown in the Surface Details report (Output:Surfaces:List, Details;)
When EnergyPlus is set to Display Advanced Variables (Output:Diagnostics, DisplayAdvancedVariables;), then additional output variables are available that indicate the status of convection modeling by identifying which models are in effect at a given time. The adaptive convection algorithms may switch between models over time and the following output variables provide a way to monitor this behavior. These outputs are integer codes and the integer values are explained in tables.
Surface Inside Face Convection Classification Index[LINK]
This variable reports how the surface was classified as part of the adaptive convection algorithm for the inside face. The algorithm examines probable flow regimes, heat flow directions, orientations, HVAC equipment connections, and current operating status to assign each surface a category. The numbers in this report are integer codes that correspond to surface categories as described in the following table.
Surface Inside Face Convection Model Equation Index[LINK]
This variable reports the specific model equation used to calculate the inside face convection coefficient. This can vary when using the adaptive convection algorithm and so the result of that selection algorithm is reported here. The following table lists the models associated with specific interger codes reported here. The models correspond to key words used in input objects.
Surface Inside Face Convection Reference Air Index[LINK]
The inside face convection heat transfer calculations can be based on different reference air temperatures. This reference air temperature can vary during the simulation when the adaptive algorithm selects models that use different references. The following table lists the meaning of the integer codes.
Surface Outside Face Convection Classification Index[LINK]
This variable reports how the surface was classified as part of the adaptive convection algorithm for the outside face. The algorithm examines the wind direction, heat flow directions and orientations to assign each surface a category. The numbers in this report are integer codes that correspond to surface categories as described in the following table.
Surface Outside Face Forced Convection Model Equation Index[LINK]
Surface Outside Face Natural Convection Model Equation Index[LINK]
These variables report the specific model equation used to calculate the outside face’s convection coefficient. They can vary when using the adaptive convection algorithm and so the results of that selection algorithm are reported in these variables. The following table lists the models associated with specific integer codes that might be reported here. The models correspond to key words used in input objects.
SurfaceProperties:VaporCoefficients[LINK]
Advanced/Research Usage: The internal and external vapor transfer coefficients that are used by the CombinedHeatAndMoistureFiniteElement model are automatically calculated during EnergyPlus execution using information on the convection coefficients. However it is sometimes useful to be able to “override” the calculation and set fixed values of vapor transfer coefficient for a single surface. These coefficients are only used by the CombinedHeatAndMoistureFiniteElement model and will be ignored by other solution algorithms.
Inputs[LINK]
Field: Surface Name[LINK]
This field is the applicable surface name for the user supplied vapor transfer coefficient.
Field: Constant External Vapor Transfer Coefficient[LINK]
Select ‘yes’ to use the value supplied as the external vapor transfer coefficient
Field: External Vapor Coefficient Value[LINK]
HAMT will use this value to calculate the vapor transfer into and out off the external surface of this surface. Units are kg/Pa.s.m2.
Field: Constant Internal vapor Transfer Coefficient[LINK]
Select ‘yes’ to use the value supplied as the internal vapor transfer coefficient
Field: Internal Vapor Coefficient Value[LINK]
The CombinedHeatAndMoistureFiniteElement algorithm will use this value to calculate the vapor transfer into and out of the internal surface of this surface. Units are kg/Pa.s.m2.
Below is an example input of vapor transfer coefficients for a surface.
SurfaceProperty:ExteriorNaturalVentedCavity[LINK]
This object is used to model a multi-skin exterior heat transfer surface. This is a special case where the outside face is a slightly detached layer forming a naturally ventilated cavity. The actual outer surface is referred to as the baffle. The modeling here assumes that the heat capacity in the outer baffle can be neglected since it is much lower than the underlying mass surface. This object is used with the BuildingSurface:Detailed object where the Heat Transfer surfaces are referred to as the underlying surfaces. The constructions and materials for the BuildingSurface:Detailed object should reflect the construction of just the underlying surface. The SurfaceProperty:ExteriorNaturalVentedCavity object is used to describe the decoupled layer, or baffle, and the characteristics of the cavity and openings for natural ventilation. This object is also used in conjunction with the OtherSideConditionsModel.
The area and orientation are obtained from BuildingSurface:Detailed objects, which are referenced by name. This object can be used to model certain types of photovoltaic mounting configurations such as interlocking roof pavers. If the baffle covers only part of a surface, then that surface should be split into separate BuildingSurface:Detailed objects where one matches the size of the baffle. A single baffle can be associated with as many BuildingSurface:Detailed objects as desired. The base heat transfer surfaces need not be contiguous nor have the same orientation, but the program will issue warnings if surfaces have widely ranging tilts and azimuths.
Note that the model involves predicting the rates that ambient air moves in and out of the cavity. Accurate modeling of these air flows would be extremely challenging and so the models provided through this object are simplistic engineering models based on discharge coefficients that are sensitive to wind and buoyancy effects. The accuracy depends on the values for, and applicability of, the discharge coefficients and unfortunately little research is available to help characterize these. The models should be considered rudimentary and the user is encouraged to explore different values for the coefficients in attempts to bound the importance of natural ventilation for the cavities. See the Engineering Reference for more details.
Inputs[LINK]
Field: Name[LINK]
This field contains a unique name for the ventilated cavity.
Field: Boundary Conditions Model Name[LINK]
This field contains the name of an SurfaceProperty:OtherSideConditionsModel object declared elsewhere in the input file. This will connect the baffle and ventilated cavity to the exterior boundary conditions for the underlying heat transfer surface.
Field: Area Fraction of Openings[LINK]
This field is used to enter an area fraction for what part of the baffle consists of openings. The area of the openings will set to the product of this field and the sum of the area of the underlying surfaces.
Field: Thermal Emissivity of Exterior Baffle Material[LINK]
This field is used to enter the thermal emissivity of the baffler. This surface property is for longwave infrared radiation. The property is used for both sides of collector. Most painted materials have an emissivity of 0.9.
Field: Solar Absorptivity of Exterior Baffle[LINK]
This field is used to enter the solar absorptivity of the baffle. This surface property is for shortwave, solar radiation. The property is used for the front side of the baffle that faces the environment. Darker colors have a higher absorptivity. While black is the highest performance, other colors might be used to match the color scheme of the rest of the façade.
Field: Height Scale for Buoyancy-Driven Ventilation[LINK]
This field is used to enter a nominal height scale (m) for prediction of ventilation induced by buoyancy. This value (\(\Delta {H_{NPL}}\) ) is defined as the height from the midpoint of the lower opening to the neutral pressure level. Increasing the value will increase the ventilation rate due to buoyancy.
Field: Effective Thickness of Cavity Behind Exterior Baffle[LINK]
This field is used to enter a nominal gap thickness (m) for the collector. If the baffle is corrugated, use the average depth. This distance value is only used when the collector is near horizontal to determine a length scale in the vertical direction for buoyancy calculations. For example, if the collector is mounted on a flat roof, its tilt-adjusted height is zero and the program will use this gap thickness as a length scale rather than the height from the previous field.
Field: Ratio of Actual Surface Area to Projected Surface Area[LINK]
This field is used to enter a factor that accounts for the extra surface area resulting from and uneven baffle surface. Corrugations may be present to help stiffen the baffle or ventilated roofing tiles may have more surface are for convection heat transfer than the underlying surface. The projected surface area is obtained by the program from the (flat) underlying surfaces. If the baffle is flat then this ratio is 1.0. If the baffle is corrugated, then this ratio will be greater than one with a typical value might be 1.165.
Field: Roughness of Exterior Surface[LINK]
This field is used to describe the relative roughness of the baffle material. This field is similar to one in the Material object. This parameter only influences the convection coefficients, more specifically the exterior convection coefficient. A special keyword is expected in this field with the options being “VeryRough”, “Rough”, “MediumRough”, “MediumSmooth”, “Smooth”, and “VerySmooth” in order of roughest to smoothest options.
Field: Effectiveness for Perforations with Respect to Wind[LINK]
This field is used to enter a value for the coefficient used to determine natural air exchanges from wind. Wind will cause exterior air to move in and out of the cavity. Cv is an arbitrary coefficient used to model the effectiveness of openings and depends on opening geometry and the orientation with respect to the wind. Cv should probably be in the range 0.05 to 0.65. Increasing Cv will increase the amount of natural ventilation. The following equation shows how Cv is used in the program to predict the volumetric flow rate due to wind:
\[\dot{V}_{\rm{wind}} = C_v A_{\rm{in}} U_{\infty}\]
Field: Discharge Coefficient for Openings with Respect to Buoyancy Driven Flow[LINK]
This field is used to enter a value for the coefficient used to determine natural air exchanges from buoyancy. Stack or buoyancy effects will cause exterior air to move in and out of the cavity. Cd is an arbitrary discharge coefficient that depends on the geometry of the opening. Cd should probably be in the range 0.1 to 1.0. Increasing Cd will increase the amount of natural ventilation. The following equations show how Cd is used in the program to predict the volume flow rate due to buoyancy:
\(\dot{V}_{thermal} = C_D A_{in} \sqrt 2 g \Delta H_{NPL} \left( T_{a,cav} - T_{amb} \right) / T_{a,cav}\) (if \(T_{a,cav} > T_{amb}\) )
\(\dot{V}_{\text{thermal}} = C_D A_{in} \sqrt 2 g \Delta H_{NPL} \left( T_{amb} - T_{a,cav} \right) / T_{amb}\) (if \(T_{amb} > T_{a,cav}\) and baffle is vertical)
where \(\Delta {H_{NPL}}\) is the value input into the field above for the height scale for buoyancy-driven ventilation.
Field(s): Surface <1 thru x> Name[LINK]
The remaining fields are used to name the BuildingSurface:Detailed objects that are associated with the exterior naturally vented cavity. These are the underlying heat transfer surfaces and are defined elsewhere in the input file. These surfaces should all specify OtherSideConditionsModel as their exterior environment. This object is extensible, so additional fields of this type can be added to the end of this object.
An example IDF entry is
Outputs[LINK]
In addition to related output that can be obtained for all surfaces, these outputs are available for exterior naturally vented cavity configurations:
HVAC,Average, Surface Exterior Cavity Air Drybulb Temperature [C]
HVAC,Average, Surface Exterior Cavity Baffle Surface Temperature [C]
HVAC,Average, Surface Exterior Cavity Total Natural Ventilation Air Change Rate [ACH]
HVAC,Average, Surface Exterior Cavity Total Natural Ventilation Mass Flow Rate [kg/s]
HVAC,Average, Surface Exterior Cavity Natural Ventilation from Wind Mass Flow Rate [kg/s]
HVAC,Average, Surface Exterior Cavity Natural Ventilation from Buoyancy Mass Flow Rate [kg/s]
Surface Exterior Cavity Air Drybulb Temperature [C][LINK]
The temperature of air inside the cavity behind the baffle.
Surface Exterior Cavity Baffle Surface Temperature [C][LINK]
The surface temperature of the exterior baffle material itself.
Surface Exterior Cavity Total Natural Ventilation Air Change Rate [ACH][LINK]
The rate of natural ventilation air exchange between the plenum and ambient when the collector is inactive in Air Changes per Hour.
Surface Exterior Cavity Total Natural Ventilation Mass Flow Rate [kg/s][LINK]
The mass flow rate of natural ventilation air exchange between the plenum and ambient when the collector is inactive.
Surface Exterior Cavity Natural Ventilation from Wind Mass Flow Rate [kg/s][LINK]
The part of mass flow rate of natural ventilation air exchange between the plenum and ambient when the collector is inactive due to wind-driven forces.
Surface Exterior Cavity Natural Ventilation from Buoyancy Mass Flow Rate [kg/s][LINK]
The part of mass flow rate of natural ventilation air exchange between the plenum and ambient when the collector is inactive due to buoyancy-driven forces.
SurfaceProperty:SolarIncidentInside[LINK]
This object can be used as an alternative to the standard (automatic) EnergyPlus calculation of the solar radiation incident on interior surfaces of the building. Using this method, the normal EnergyPlus calculation is replaced with a schedule of solar incidence values that are calculated outside the program.
Inputs[LINK]
Field: Name[LINK]
The name of the SurfaceProperty:SolarIncidentInside object Must be unique between all SurfaceProperty:SolarIncidentInside objects.
Field: Surface Name[LINK]
The building surface associated with this object (ref BuildingSurface:Detailed). Solar absorptance values in the schedule file will be applied to the inside of this surface.
Field: Construction Name[LINK]
The building construction associated with this object (ref Construction). It is possible that the Energy Management System will change the construction associated with the surface; if the construction is changed, a new set of data may need to be applied to the current surface.
Field: Inside Surface Incident Sun Solar Radiation Schedule Name[LINK]
This field specifies the name of a schedule that contains the values for incident solar radiation. Values from the schedule data will be used to replace the absorbed solar radiation that would normally be calculated by EnergyPlus. Units in the external schedule file must be W/m\(^{2}\).
Example for SurfaceProperty:SolarIncidentInside using a compact schedule:
SurfaceProperty:IncidentSolarMultiplier[LINK]
This object enables a simplified way to specify the properties of a shading device that directly discount the incident solar radiation. The multiplier can be a single fixed value or a schedule of values. An idd object SurfaceProperty:IncidentSolarMultiplier will be added to enable users to specify the multiplier. This multiplier resembles the SHADING-SCHEDULE in DOE-2, which can adjust the solar heat gain through windows with a multiplier schedule.
This adjustment is compatible with building shading structures like overhangs, but not with the following regular shading objects in EnergyPlus: WindowMaterial:Shade, WindowMaterial:Blind, WindowMaterial:Screen, WindowShadingControl, or WindowMaterial:*:EquivalentLayer objects. If any of them are defined for a window in addition to the SurfaceProperty:IncidentSolarMultiplier, an error message will be shown: “Non-compatible shades defined alongside SurfaceProperty:IncidentSolarMultiplier for the same window.”
Field: Surface Name[LINK]
This field is specifies the name of the exterior window outside surface where the incident solar multiplier is applied to. If the surface is not an exterior window surface, the following error message will be shown: “IncidentSolarMultiplier should be defined for exterior windows”.
Field: Incident Solar Multiplier[LINK]
A constant multiplier for the incident solar radiation. The value should be between 0 and 1 (both inclussive). If not specified, the default 1.0 will be used. If the Incident Solar Multiplier Schedule Name is defined, the product of these two will be the final Incident Solar Multiplier. Otherwise, this constant multiplier will be applied throughout the simulation.
Field: Incident Solar Multiplier Schedule Name[LINK]
The name of the schedule of the incident solar multiplier. If this field is not defined, the value of the Incident Solar Multiplier will be used. Otherwise, the product of the two will be used. The Schedule value needs to be no less than 0 and no greater than 1.
ComplexFenestrationProperty:SolarAbsorbedLayers[LINK]
This object can be used as an alternative to the standard (automatic) EnergyPlus calculation of the solar radiation absorbed by fenestration systems in the building. Using this method, the normal EnergyPlus calculation is replaced with a schedule of solar absorptance values that are calculated outside the program.
Inputs[LINK]
Field: Name[LINK]
The name of the ComplexFenestrationProperty:SolarAbsorbedLayers object Must be unique between all ComplexFenestrationProperty:SolarAbsorbedLayers objects.
Field: Fenestration Surface[LINK]
The fenestration surface associated with this object (ref FenestrationSurface:Detailed). Values from the schedule data will be used to replace the absorbed solar radiation in the fenestration layers that would normally be calculated by EnergyPlus. Value units in the schedule must be W/m\(^{2}\).
Field: Construction Name[LINK]
The building construction associated with this object (ref Construction). It is possible that the Energy Management System will change the construction associated with the surface; if the construction is changed, a new set of data may need to be applied to the current surface.
Field: Layer 1 Solar Radiation Absorbed Schedule Name[LINK]
Specifies the name of a schedule that contains the absorbed solar radiation values in units of W/m\(^{2}\). Values from the schedule are used for the absorbed solar radiation of the first (outside) layer.
Field: Layer 2 Solar Radiation Absorbed Schedule Name[LINK]
Specifies the name of a schedule that contains absorbed solar radiation values in units of W/m\(^{2}\). Values from the schedule are used for the absorbed solar radiation of the second layer.
Field: Layer 3 Solar Radiation Absorbed Schedule Name[LINK]
Specifies the name of a schedule that contains absorbed solar radiation values in units of W/m\(^{2}\). Values from the schedule are used for the absorbed solar radiation for the third layer.
Field: Layer 4 Solar Radiation Absorbed Schedule Name[LINK]
Specifies the name of a schedule that contains absorbed solar radiation values in units of W/m\(^{2}\). Values from the schedule are used for the absorbed solar radiation of the fourth layer.
Field: Layer 5 Solar Radiation Absorbed Schedule Name[LINK]
Specifies the name of a schedule that contains absorbed solar radiation values in units of W/m\(^{2}\). Values from the schedule are used for the absorbed solar radiation of the fifth layer.
Example for ComplexFenestrationProperty:SolarAbsorbedLayers with compact schedules:
GeometryTransform[LINK]
This object provides a simple method of altering the footprint geometry of a model. The intent is to provide a single parameter that can be used to reshape the building description contained in the rest of the input file. This object was implemented for use in parametric massing studies and with the optimization program GenOpt. Although building footprint is often constrained in practice, analysts may find this object useful for investigating how building form impacts daylighting and solar gains on the east and west facades without having to change all of the surface geometry input.
Aspect Ratio is defined as the overall length in the East-West direction divided by the overall length in the North-South direction.
This object should be used with considerable care since it will completely alter the geometry modeled by EnergyPlus and may have unintended side effects. The surface areas of all horizontal surfaces may change radically with corresponding changes in Zone floor areas. The total floor area will not change but individual horizontal surfaces will gain and loose area. Vertical surfaces will have the same height but will gain and lose length. Lighting and electrical equipment design levels for individual zones will likely have a different energy per unit area in the transformed geometry.
The surface geometry must be set to Relative, see GlobalGeometryRules. Of course, the coordinates must be entered in relative coordinates as well.
Since windows in EnergyPlus need to be rectangular, it is possible to define a horizontal window (skylight) that once transformed is no longer rectangular and will cause EnergyPlus to halt. To avoid this problem, horizontal windows should be defined orthogonal to the Cardinal directions and building rotation (see Building) used to orient the final form with respect to North.
The object doesn’t create any specific output, but the results of using it can be understood by viewing DXF output files. Figure 21 shows an example of a building that has been morphed using the Aspect Ratio Transform object. Using this object allowed the same geometry input to generate both of the models represented in by their DXF output files.
Inputs[LINK]
Field: Plane of Transform[LINK]
This field specifies the plane that the geometry transform should act on. It is currently restricted to altering the horizontal footprint of a building and must be set to “XY.”
Field: Current Aspect Ratio[LINK]
This field specifies the aspect ratio of the building geometry described in the rest of the input file. It is used to scale the new aspect ratio. If this field is set to 1.0, then the altered building will not necessarily have the new aspect ratio defined in the next field.
Field: New Aspect Ratio[LINK]
This field specifies the aspect ratio that the building described in the rest of the input file will be changed to.
SurfaceProperty:SurroundingSurfaces[LINK]
The object is used to calculate long wave radiation to an external surface from its surrounding surfaces, defining the properties of the surrounding surfaces. The property object declares a list of single surrounding surfaces which has a name, a field of view factor, and another field Temperature Schedule Name referencing a schedule containing the temperature of the surrounding surface, which can be overwritten at each time step in EnergyPlus run time through co-simulation. View factors are assumed to be constant values. At least one surrounding surface should be defined in this object.
The object also defines the sky and ground temperature and view factors to the external surface. The sum of all defined view factors should not exceed 1.0. If only sky view is defined in this object, the ground view factor to this surface will be 1.0 subtracted with the ground view factor and all other defined surface view factors. If only ground view is defined in this object, the sky view factor to this surface will be 1.0 subtracted with the sky view factor and all other defined surface view factors. If neither of the sky and ground view factors are explicitly declared here, the sum of the sky and ground view factor would be 1.0 subtracted with all other defined surface view factors and the proportion will be set as the same with the global setting.
If ground surfaces view factors are defined in SurfaceProperty:GroundSurfaces object, then this ground view factors overrides the gorund view factors specified in SurfaceProperty:SurroundingSurfaces object. The sum of the sky view factors and the surrounding surfaces view factors defined in SurfaceProperty:SurroundingSurfaces and the ground surfaces view factors defined in SurfaceProperty:GroundSurfaces object should not exceed 1.0. The SurfaceProperty:GroundSurfaces object allows specifying multiple ground surfaces viewed by an exterior surfaces.
Field: Name[LINK]
This is the unique name of the surface property.
Field: Sky View Factor[LINK]
This field defines the constant sky view factor to an external surface. The sky view factor used in solar radiation calculation of the surface would be overwritten with the value of the fraction if defined here. If the field is left blank, the sky view factor of this surface will be calculated with the rules demonstrated above.
Field: Sky Temperature Schedule Name[LINK]
This field is used to supply a schedule name of the sky temperature. The sky temperature used in solar radiation calculation of the surface would be overwritten with the value of the scheduled temperature if defined here. If the field is left blank, the global sky temperature would be used.
Field: Ground View Factor[LINK]
This field defines the constant ground view factor to an external surface. The ground view factor used in solar radiation calculation of the surface would be overwritten with the value of the fraction if defined here. If the field is left blank, the ground view factor of this surface will be calculated with the rules demonstrated above. Ground surface view factor defined in SurfaceProperty:GroundSurfaces object overrides the value specified in this field.
Field: Ground Temperature Schedule Name[LINK]
This field is used to supply a schedule name of the ground temperature. The ground temperature used in long wave radiation exchange calculation of the surface would be overwritten with the value of the scheduled temperature if defined here. If the field is left blank, the global ground temperature would be used. Ground surface temperature defined in SurfaceProperty:GroundSurfaces object overrides the value specified in this field.
Field: Surrounding Surface 1 Name[LINK]
This field defines the name of a surrounding surface to the external surface.
Field: Surrounding Surface 1 View Factor[LINK]
This field defines the constant view factor of a surrounding surface to an external surface.
Field: Surrounding Surface 1 Temperature Schedule Name[LINK]
This field is used to supply a schedule name of the of a surrounding surface temperature.
The object is extensible so the last three fields can be repeated to define multiple surrounding surface name, temperature and view factor sets.
An example IDF object follows.
SurfaceProperty:GroundSurfaces[LINK]
This object is used for calculating building exterior surfaces long-wave radation exchange with the ground and the calculation of solar radiation reflection from ground surfaces to a building exterior surface. A given exterior surface can view multiple ground surfaces with different surface properties and view factors. Thus, this object allows specifying multiple ground view factors, ground surfaces temperature, and ground surfaces refelectance properties viewed by a given exterior surface. View factors are assumed to be constant values. The ground surface temperature and ground surface reflectance are specified using schedule object. Ground surface view factors and ground surface temperature defined in this object overrides the ground surface view factor and ground temperature specified in SurfaceProperty:SurroundingSurfaces object.
The sum of all defined view factors that include the sky virew factor, the ground surfaces view factors and surrounding surfaces view factors seen by a given building exterior surface should be 1.0, or the sum of the ground view factors for a given exterior surface should not exceed 1 subtracted the sky view factor and the sum of view factors of all surrounding surfaces defined in SurfaceProperty:SurroundingSurfaces object. If the ground view factor input field is blank in SurfaceProperty:GroundSurfaces object, the ground view factor to this surface will be 1.0 subtracted the sky view factor and all other defined surrounding surface view factors defined in SurfaceProperty:SurroundingSurfaces object. If neither SurfaceProperty:GroundSurfaces object nor the SurfaceProperty:SurroundingSurfaces object is specified for an exterior surface, the default view factor specified in BuildingSurface:Detailed or FenestrationSurface:Detailed object is used.
Field: Name[LINK]
This is a unique name of the surface property ground surfaces object.
Field: Ground Surface 1 Name[LINK]
This is a unique name for ground surface 1.
Field: Ground Surface 1 View Factor[LINK]
This field defines the constant ground view factor of a building exterior surface to ground surface 1. The ground surface view factor is used in long-wave radiation exchange and ground surface solar reflectance calculations. If this field is left blank, the ground view factor of this surface will be calculated with the rules demonstrated above.
Field: Ground Surface 1 Temperature Schedule Name[LINK]
This field is used to provide a schedule name of the ground surface 1 temperature. The ground surface temperature used in long-wave radiation exchange calculation of a building exterior surface with the ground surface. If the field is left blank, the default method will be used.
Field: Ground Surface 1 Reflectance Schedule Name[LINK]
This field is used to provide a schedule name of a ground surface reflectance. The ground surface reflectance is used to calculate ground surface reflected solar radition to a building exterior surface. If the field is left blank, the global reflectance object defined else where or default values will be used.
This object is extensible, so the last four fields can be repeated to define ground surface name, ground surface view factor, ground surface temperature, and ground surface reflectace sets.
Ground surfaces solar reflectance values derived from satelite data for common ground surfaces obtained from Ground Albedo Measurements and Modeling (Bill Marion, 2018) are summerized in table below.
An example IDF objects.
Outputs[LINK]
Zone,Average,Surfaces Property Ground Surfaces Average Temperature [C]
Zone,Average,Surfaces Property Ground Surfaces Average Reflectance []
Surfaces Property Ground Surfaces Average Temperature [C][LINK]
This is an average surface temperature of multiple ground surfaces in deg C viewed by an exterior surface for each time step. If there is only one ground surface specified in a given SurfaceProperty:GroundSurfaces object, then the average surface temperature will be the same as the specified ground surface temperature. This output variable is not generated when all ground surface temperature schedule name fields are blank.
Surfaces Property Ground Surfaces Average Reflectance [][LINK]
This is an average surface reflectance of multiple ground surfaces viewed by an exterior surface for each time step. If there is only one ground surface specified in a given SurfaceProperty:GroundSurfaces object, then the average surface reflectance will be the same as the specified ground surface reflectance. This output variable is not generated when all ground surface reflectance schedule name fields are blank.
References[LINK]
Bill Marion. 2018. Ground Albedo Measurements and Modeling. Bifacial PV Workshop Lakewood, Colorado. September 11, 2018. NREL/PR-5K00-72589. https://www.nrel.gov/docs/fy20osti/72589.pdf
SurfaceProperty:LocalEnvironment[LINK]
The object links to an exterior surface object BuildingSurface:Detailed or an exterior fenestration object FenestrationSurface:Detailed and is used when there is a need to calculate surface level environmental data externally and import them into the simulation to override existing environmental data, including external solar shading fractions, local air velocity, temperature and humidity, and surrounding surface temperatures, sky view factor, ground surfaces view factors, ground surfaces temperature and ground surfaces refelectance. The object links to four optional objects including a schedule object declared by Field: External Shading Fraction Schedule Name, a SurfaceProperty:SurroundingSurfaces object declared by Field: Surrounding Surfaces Object Name, an OutdoorAir:Node object declared by Field: Outdoor Air Node Name, and a SurfaceProperty:GroundSurfaces object declared by Field: Ground Surfaces Object Name. The object provides inputs to calculate shading, solar radiation, zone air balance, and surface exterior heat balance.
Field: Name[LINK]
This is the unique name of the surface property.
Field: Surface Name[LINK]
This is the name of the surface that will be assigned to use the local environmental data defined in the next three fields. This should be a name of a surface defined elsewhere.
Field: External Shading Fraction Schedule Name[LINK]
This field is used to import external shading fraction data from external calculation. This should be a name of a schedule object with fraction input.
Field: Surrounding Surfaces Object Name[LINK]
This field is used to import surrounding surfaces properties (temperature and view factors to the external surface) from external calculation. This should be a name of a SurfaceProperty:SurroundingSurfaces object.
Field: Outdoor Air Node Name[LINK]
This field is used to import local environmental data from local outdoor air nodes, including dry and wet bulb temperature, wind speed and wind direction. This should be a name of a OutdoorAir:Node object.
Field: Ground Surfaces Object Name[LINK]
This field is used to specify ground surfaces properties (ground surface temperature, solar reflectance and view factors to the external surface) determined from external calculation. This should be a name of a SurfaceProperty:GroundSurfaces object.
An example IDF object follows.
ZoneProperty:LocalEnvironment[LINK]
The object links to a Zone object and is used when there is a need to calculate zone level environmental data externally and import them into the simulation to override existing environmental data, including local air temperature and humidity, wind velocity and direction. links to an OutdoorAir:Node object declared by Field: Outdoor Air Node Name. The reference local outdoor air node provides ambient conditions for the calculation of infiltration and ventilation at the zone level.
Field: Name[LINK]
This is the unique name of the zone property.
Field: Zone Name[LINK]
This is the name of the zone that will be assigned to use the local environmental data defined in the next field. This should be a name of a zone defined elsewhere.
Field: Outdoor Air Node Name[LINK]
This field is used to import local environmental data from local outdoor air nodes, including dry and wet bulb temperature, wind speed and wind direction. This should be a name of a OutdoorAir:Node object.
An example IDF object follows.
SurfaceProperty:HeatBalanceSourceTerm[LINK]
The object allows additional heat source term of the surface boundary condition in the surface heat balance calculation. The object specifies a surface with the additional heat source term described by a schedule of heat rates (can be positive or negative values) in W/m\(^2\). A heat source can be added to either or both the inside and outside of the same surface. The heat rates are pre-calculated outside EnergyPlus.
Field: Surface Name[LINK]
This is the name of the surface that will be assigned to use the additional heat source term in heat balance calculation
Field: Inside Face Heat Source Term Schedule Name[LINK]
The value of this schedule is the source term value for the inside face of this surface. If this field is left blank, no inside surface source term will be applied. The schedule values are heat rate per surface area (W/m2), when positive schedule values indicate heat gain and negative values indicates loss.
Field: Outside Face Heat Source Term Schedule Name[LINK]
The value of this schedule is the source term value for the outside face of this surface. If this field is left blank, no outside surface source term will be applied. The schedule values are heat rate per surface area (W/m2), when positive schedule values indicate heat gain and negative values indicates loss.
Zone Property View Factors[LINK]
EnergyPlus has two options for specifying the thermal radiation exchange view factors between surfaces in a zone: the approximate option and the user input option. Because the actual geometric arrangement within a zone is very complex, the approximate method of including thermal mass and other forced exchanges is more realistic than trying to come up with “exact” view factors. However, in some research situations it might be desirable to have control of the view factors used. For this reason, a user input mode has been included in EnergyPlus. The two modes are described in the next sections.
Approximate Option[LINK]
The first option produces approximate results and uses an area weighted scheme to calculate “view factors” between surfaces within a thermal zone. Each surface uses the total area that it can “see” among the other surfaces. The approximate view factor from this surface to each other surface is then the area of the receiving surface over the sum of areas that are visible to the sending surface.
In order to account in some limited way for the fact that certain surfaces will not see each other, several assumptions have been built into this view factor approximation. First, a surface cannot see itself. Second, surfaces with approximately the same azimuth (facing direction) and tilt (“same” being within a built in limit) will not see each other. This means that a window will not see the wall that it is placed on, for example. Third, floors cannot see each other. Fourth, if the surface is a floor, ceiling, roof, or internal mass, the rule for the same azimuth and tilt eliminating radiant exchange between surfaces is waived when the receiving surface is floor, roof, ceiling, or internal mass as long as both surfaces are not floors.
Note that this does not take into account that surfaces may be “around the corner” from each other and in reality not see each other at all. Rooms are assumed to be convex rather than concave in this method.
To summarize, using the Surface “Class”, the approximate view factors have:
No surface sees itself.
No Floor sees another floor.
All other surface types see Internal Mass.
All other surface types see floors.
Floors always see ceilings.
Floors always see roofs.
All other surfaces whose tilt or facing angle differences are greater than 10 degrees see each other.
If geometry is correct, conditions 1, 3, and 7 should take care of all surfaces, but the other conditions supply common sense when the geometry is incorrect. More information about the EnergyPlus view factor calculation is contained in the Engineering Reference document.
User Input View Factors[LINK]
The second option for specifying view factors requires user input values. These should be used with care in research or special situations. The object available for this is ZoneProperty:UserViewFactors:BySurfaceName.
ZoneProperty:UserViewFactors:BySurfaceName[LINK]
The method of entering user view factors is to enter each surface name and its view factor value to other surfaces in a radiant/solar enclosure which may consist of one space, one zone or a group of spaces or zones.
Inputs[LINK]
Field: Zone or ZoneList or Space or SpaceList Name[LINK]
An enclosure for radiant exchange may be a single space or zone, or a group of spaces or zones connected by one or more air boundaries (see Construction:AirBoundary). An enclosure may also be a group of spaces in the same zone with implied air boundaries because the spaces are defined only by floor surfaces (see Space. If a ZoneList name is specified, the referenced “ZoneList”) must match a group of zones connected with Construction:AirBoundary.
Enter the applicable surface pairs with non-zero view factors. Any omitted surface pair is assumed to have a zero view factor.
Field: From Surface 1[LINK]
This field specifies the name of the “from surface”.
Field: To Surface 1[LINK]
This field specifies the name of the “to surface”.
Field: Factor 1[LINK]
This value is the view factor for “from Surface” to “to Surface”.
An IDF Example:
Documentation content copyright © 1996-2026 The Board of Trustees of the University of Illinois and the Regents of the University of California through the Ernest Orlando Lawrence Berkeley National Laboratory. All rights reserved. EnergyPlus is a trademark of the US Department of Energy.
This documentation is made available under the EnergyPlus Open Source License v1.0.