Revision history [back]

To answer your first question only about fictive v real day, the I/O ref guide for SizingPeriod:DesignDay is pretty clear:

Using the values in these fields, EnergyPlus “creates” a complete days’ worth of weather data (air temperatures, solar radiation, etc.)

More information is in the I/O ref and if that doesn't satisfy your curiosity, the Engineering reference has a section titled EnergyPlus Design Day Temperature Calculations that goes in a bit more detail (it basically just adds the equation). The bottom line is:

$$T_{current} = T_{Max} - T_{range} \cdot T_{Multiplier}$$

where

• $T_{current}$ = Air temperature of current Hour of Day
• $T_{Max}$ = User supplied Max Dry-bulb Temperature
• $T_{range}$ = User supplied Daily Temperature Range
• $T_{Multiplier}$ = Range multiplier as shown on the below graph

You can always choose to not use this default range multiplier and provide your own schedule instead using the Dry-Bulb Temperature Range Modifier Day Schedule Name

To answer your first question only about fictive v real day, the I/O ref guide for SizingPeriod:DesignDay is pretty clear:

Using the values in these fields, EnergyPlus “creates” a complete days’ worth of weather data (air temperatures, solar radiation, etc.)

More information is in the I/O ref and if that doesn't satisfy your curiosity, the Engineering reference has a section titled EnergyPlus Design Day Temperature Calculations that goes in a bit more detail (it basically just adds the equation). The bottom line is:

$$T_{current} = T_{Max} - T_{range} \cdot T_{Multiplier}$$

where

• $T_{current}$ = Air temperature of current Hour of Day
• $T_{Max}$ = User supplied Max Dry-bulb Temperature
• $T_{range}$ = User supplied Daily Temperature Range
• $T_{Multiplier}$ = Range multiplier as shown on the below graph

You can always choose to not use this default range multiplier and provide your own schedule instead using the Dry-Bulb Temperature Range Modifier Day Schedule Name

To answer your first question only about fictive v real day, day, the I/O ref guide for SizingPeriod:DesignDay is pretty clear:

Using the values in these fields, EnergyPlus “creates” a complete days’ worth of weather data (air temperatures, solar radiation, etc.)

More information is in the I/O ref and if that doesn't satisfy your curiosity, the Engineering reference has a section titled EnergyPlus Design Day Temperature Calculations that goes in a bit more detail (it basically just adds the equation). The bottom line is:

$$T_{current} = T_{Max} - T_{range} \cdot T_{Multiplier}$$

where

• $T_{current}$ = Air temperature of current Hour of Day
• $T_{Max}$ = User supplied Max Dry-bulb Temperature
• $T_{range}$ = User supplied Daily Temperature Range
• $T_{Multiplier}$ = Range multiplier as shown on the below graph

You can always choose to not use this default range multiplier and provide your own schedule instead using the Dry-Bulb Temperature Range Modifier Day Schedule Name, as well as defining your own Wetbulb temps using the Daily Wet-Bulb Temperature Range field, but some weird processing will be required.

My two cents is that - bottom line - the SizingPeriod:DesignDay object is meant to facilitate your life by asking only for a few key parameters, but if you want to use your own data to fully define the design day, then it's making your life much harder.

Potential workaround

I think there's something you could try, which is to use the SizingPeriod:WeatherFileDays instead. You could define a 367 days weather file, where you'd create two fictious next-year days that would represent your design day conditions so you can select them in SizingPeriod:WeatherFileDayswhile setting the RunPeriod object to run only on your actual 365 days.

I have never had to try this, so I gave no guarantee that it'll work.

To answer your first question only about fictive v real day, the I/O ref guide for SizingPeriod:DesignDay is pretty clear:

Using the values in these fields, EnergyPlus “creates” a complete days’ worth of weather data (air temperatures, solar radiation, etc.)

More information is in the I/O ref and if that doesn't satisfy your curiosity, the Engineering reference has a section titled EnergyPlus Design Day Temperature Calculations that goes in a bit more detail (it basically just adds the equation). The bottom line is:

$$T_{current} = T_{Max} - T_{range} \cdot T_{Multiplier}$$

where

• $T_{current}$ = Air temperature of current Hour of Day
• $T_{Max}$ = User supplied Max Dry-bulb Temperature
• $T_{range}$ = User supplied Daily Temperature Range
• $T_{Multiplier}$ = Range multiplier as shown on the below graph

You can always choose to not use this default range multiplier and provide your own schedule instead using the Dry-Bulb Temperature Range Modifier Day Schedule Name, as well as defining your own Wetbulb temps using the Daily Wet-Bulb Temperature Range field, but some weird processing will be required.

My two cents is that - bottom line - the SizingPeriod:DesignDay object is meant to facilitate your life by asking only for a few key parameters, but if you want to use your own data to fully define the design day, then it's making your life much harder.

Potential workaround

I think there's something you could try, which is to use the SizingPeriod:WeatherFileDays instead. You could define a 367 days weather file, where you'd create two fictious next-year days that would represent your design day conditions so you can select them in SizingPeriod:WeatherFileDayswhile setting the RunPeriod object to run only on your actual 365 days.

I have never had to try this, so I gave give no guarantee that it'll work.

To answer your first question only about fictive v real day, the I/O ref guide for SizingPeriod:DesignDay is pretty clear:

Using the values in these fields, EnergyPlus “creates” a complete days’ worth of weather data (air temperatures, solar radiation, etc.)

More information is in the I/O ref and if that doesn't satisfy your curiosity, the Engineering reference has a section titled EnergyPlus Design Day Temperature Calculations that goes in a bit more detail (it basically just adds the equation). The bottom line is:

$$T_{current} = T_{Max} - T_{range} \cdot T_{Multiplier}$$

where

• $T_{current}$ = Air temperature of current Hour of Day
• $T_{Max}$ = User supplied Max Dry-bulb Temperature
• $T_{range}$ = User supplied Daily Temperature Range
• $T_{Multiplier}$ = Range multiplier as shown on the below graph

You can always choose to not use this default range multiplier and provide your own schedule instead using the Dry-Bulb Temperature Range Modifier Day Schedule Name, as well as defining your own Wetbulb temps using the Daily Wet-Bulb Temperature Range field, but some weird processing will be required.

My two cents is that - bottom line - the SizingPeriod:DesignDay object is meant to facilitate your life by asking only for a few key parameters, but if you want to use your own data to fully define the design day, then it's making your life much harder.

Potential workaround

I think there's something you could try, which is to use the SizingPeriod:WeatherFileDays instead. You could define a 367 days weather file, where you'd create two fictious next-year days that would represent your design day conditions so you can select them in SizingPeriod:WeatherFileDays while setting the RunPeriod object to run only on your actual 365 days.

I have never had to try this, so I give no guarantee that it'll work.