Revision history [back]

I understand your question is specifically geared toward using EnergyPlus in the standard way and therefore about pure hardware. The other answers cover that well already, no need to expand.

I still it's still somewhat relevant to mention that you could try the following things, especially during the development/debugging stage: - Diagnostic runs: Start by first having two run periods: one in the winter, one in the summer. Either a single design day, or a week of time. You'll be able to catch most runtime errors and warnings, and you will be able to analyze the output to see if your model is behaving like you expect it to. And it'll be much faster than a full year - Then you might want to do some preliminary runs and look into job splitting, such as running 12 parallel 1-month simulation, or even just running one week of each month. - Once satisfied, to reduce any bias and errors introduced, you can run it once in full on a single thread.

Some (re)sources:

• Reduce E+ runtime on E+ helpdesk
• Accelerating EnergyPlus by job splitting
• Development and performance evaluation of a methodology, based on distributed computing, for speeding EnergyPlus simulation, Garg et Al, Journal of Building Performance Simulation, 2011
• EPparallel (from the authors above)

I understand your question is specifically geared toward using EnergyPlus in the standard way and therefore about pure hardware. The other answers cover that well already, no need to expand.

I still it's still somewhat relevant to mention that you could try the following things, especially during the development/debugging stage: - stage:

• Diagnostic runs: Start by first having two run periods: one in the winter, one in the summer. Either a single design day, or a week of time. You'll be able to catch most runtime errors and warnings, and you will be able to analyze the output to see if your model is behaving like you expect it to. And it'll be much faster than a full year - year
• Then you might want to do some preliminary runs runs and look into job splitting, such as running 12 parallel 1-month simulation, or even just running one week of each month. - month. Gains of 3 to 6 times in runtime have been found while deviation was only a couple of percent (Garg et al, 2011). This is accurate enough to play with your design to improve the building.
• Once satisfied, to reduce any bias and errors introduced, introduced during preliminary runs, you can run it do a final run once in full on a single thread.

Some (re)sources:

• Reduce E+ runtime on E+ helpdesk
• Accelerating EnergyPlus by job splitting
• Development and performance evaluation of a methodology, based on distributed computing, for speeding EnergyPlus simulation, Garg et Al, Journal of Building Performance Simulation, 2011
• EPparallel (from the authors above)

I understand your question is specifically geared toward using EnergyPlus in the standard way and therefore about pure hardware. The other answers cover that well already, no need to expand.

I still it's still somewhat relevant to mention that you could try the following things, especially during the development/debugging stage:

• Diagnostic runs: Start by first having two run periods: one in the winter, one in the summer. Either a single design day, or a week of time. You'll be able to catch most runtime errors and warnings, and you will be able to analyze the output to see if your model is behaving like you expect it to. And it'll be much faster than a full year
• Then you might want to do some preliminary runs and look into job splitting, such as running 12 parallel 1-month simulation, or even just running one week of each month. Gains of 3 to 6 times in runtime - for 12 1-month simulations - have been found while deviation was only a couple of percent (Garg et al, 2011). This is accurate enough to play with your design to improve the building.
• Once satisfied, to reduce any bias and errors introduced during preliminary runs, you can do a final run once in full on a single thread.

Some (re)sources:

• Reduce E+ runtime on E+ helpdesk
• Accelerating EnergyPlus by job splitting
• Development and performance evaluation of a methodology, based on distributed computing, for speeding EnergyPlus simulation, Garg et Al, Journal of Building Performance Simulation, 2011
• EPparallel (from the authors above)

I understand your question is specifically geared toward using EnergyPlus in the standard way and therefore about pure hardware. The other answers cover that well already, no need to expand.

I still think it's still somewhat relevant to mention that you could try the following things, to break up your workflow in three distinct phases, and gains would be especially important during the development/debugging stage:

• Diagnostic runs: Start by first having two run periods: one in the winter, one in the summer. Either a single design day, for sizing periods only, or a week of time. You'll be able to catch most runtime errors and warnings, and you will be able to analyze the output to see if your model is behaving like you expect it to. And it'll be much faster than a full year
• Then year.
• After fixing it, then you might want to do some preliminary runs and look into job splitting, such as running 12 parallel 1-month simulation, or even just running one week of each month. Gains of 3 to 6 times in runtime - for 12 1-month simulations - have been found while deviation was only a couple of percent (Garg et al, 2011). This is more than accurate enough to play with your design to improve the building.building and see where you stand.
• Once satisfied, to reduce any bias and errors introduced during preliminary runs, you can do a final run once in full on a single thread.

Some (re)sources:

• Reduce E+ runtime on E+ helpdesk
• Accelerating EnergyPlus by job splitting
• Development and performance evaluation of a methodology, based on distributed computing, for speeding EnergyPlus simulation, Garg et Al, Journal of Building Performance Simulation, 2011
• EPparallel (from the authors above)