Revision history [back]

There would be more than one of doing this IMO, the details of which would depend on whether the EnergyPlus model is being developed by hand (GUI), rather than automated/scripted (e.g. OpenStudio Ruby API). Here's an option that would be fairly straightforward to automate:

1. First run Case 2 with daylighting controls.
2. Retrieve and store (from EnergyPlus results) the annual Zone 2 lighting requirements (kW, kWh). Optionally, you could output/post-process the annual time series data for Zone 2 lighting, or for each independently controlled bank of lights in Zone 2.
3. Run Case 1 without exterior lighting.
4. Add stored Zone 2 lighting requirements from Case 2 (kW, kWh) to the building's energy requirements (a post-simulation results summation).

More in line with your question, you could instead process the annual Zone 2 lighting time series data (from Case 2) to generate a Schedule:File, as an exterior lighting schedule. This would allow Zone 2 lighting power to be synchronized with the building power draw at each time step, as well as stay within EnergyPlus' post-simulation results processing.

There are drawbacks to using Case 2 and "virtual" fenestration. I don't believe EnergyPlus will allow VT (SimpleGlazing), or otherwise material visible transmittance, to be set to "1.0", which entails some drop in daylighting levels due to solar incidence angles away from normal (i.e. most of the day). So the approximation would be on the conservative side, but maybe "noise" whether you're modelling (or not) the surrounding landscape and urban environment.

There would be more than one of doing this IMO, the details of which would depend on whether the EnergyPlus model is being developed by hand (GUI), rather than automated/scripted (e.g. OpenStudio Ruby API). Here's an option that would be fairly straightforward to automate:automate (very similar to what you describe):

1. First run Case 2 with daylighting controls.
2. Retrieve and store (from EnergyPlus results) the annual Zone 2 lighting requirements (kW, kWh). Optionally, you could output/post-process the annual time series data for Zone 2 lighting, or for each independently controlled bank of lights in Zone 2.
3. Run Case 1 without exterior lighting.
4. Add stored Zone 2 lighting requirements from Case 2 (kW, kWh) to the building's energy requirements in Case 1 (a post-simulation results summation).summation, as you suggest).

More in line with your question, you could instead process the annual Zone 2 lighting time series data (from Case 2) to generate a Schedule:File, as an exterior lighting schedule. This would allow Zone 2 lighting power to be synchronized with the building power draw at each time step, as well as stay within EnergyPlus' post-simulation results processing.

There are drawbacks to using Case 2 and "virtual" fenestration. I don't believe EnergyPlus will allow VT (SimpleGlazing), or otherwise material visible transmittance, to be set to "1.0", which entails some drop in daylighting levels due to solar incidence angles away from normal (i.e. most of the day). So the approximation would be on the conservative side, but maybe "noise" whether you're modelling (or not) the surrounding landscape and urban environment.

There would be more than one of doing this IMO, the details of which would depend on whether the EnergyPlus model is being developed by hand (GUI), rather than automated/scripted (e.g. OpenStudio Ruby API). Here's an option that would be fairly straightforward to automate (very similar to what you describe):

1. First run Case 2 with daylighting controls.
2. Retrieve and store (from EnergyPlus results) the annual Zone 2 lighting requirements (kW, kWh). Optionally, you could output/post-process the annual time series data for Zone 2 lighting, or for each independently controlled bank of lights in Zone 2.
3. Run Case 1 without exterior lighting.
4. Add stored Zone 2 lighting requirements from Case 2 (kW, kWh) to the building's energy requirements in Case 1 (a post-simulation results summation, as you suggest).

More in line with your question, you could instead process the annual Zone 2 lighting time series data (from Case 2, step 2) to generate a Schedule:File, used as an exterior lighting schedule. This would allow Zone 2 lighting power to be synchronized with the Case 1 building power draw at each time step, as well as stay within EnergyPlus' post-simulation results processing.

There are drawbacks to using Case 2 and "virtual" fenestration. I don't believe EnergyPlus will allow VT (SimpleGlazing), or otherwise material visible transmittance, to be set to "1.0", which entails some drop in daylighting levels due to solar incidence angles away from normal (i.e. most of the day). So the approximation would be on the conservative side, but maybe "noise" whether you're modelling (or not) the surrounding landscape and urban environment.