"out of virtual memory"

bmatthews · Posts: 30

Dear DB
My simulation returns an error message after running for 6 hours saying it is out of virtual memory. My computer is a 2.8 gigahertz, 2gig ram machine with 3gig virtual ram. The message is true, my meter of my available ram shows 99% at the end of the simulation right when it reports its results. After I click ok on the message, I get a bugged error box with a yellow caution sign but no text in the error box. Clicking ok to that crashing DB with the data. I have tried different settings on my computer and conclude it a DB problem.
Thank you Very much

Andy Tindale · Posts: 2432 Location: Stroud

The usual reason for virtual memory crashes is making a request for lots of hourly output data in a large building for an annual simulation.

If this does not explain it, please upload the dsb file so we can take a look.

Andy

bmatthews · Posts: 30

Attached is the file that dies and early death, please feel free to tell me if I am doing anything wrong.
Thanks for the help.

File attachment used and removed

bmatthews · Posts: 30

Two errors on my part:
I had natural ventilation modeled for little reason than to model stack effect from elevator shafts,
and I was simulating hourly results despite the fact that the program computes hourly results regardless of whether you choose hourly, daily, monthly/yearly in the simulation pop-up window. I had thought that hourly schedules were neglected in daily or above simulation result reporting.
Thanks DB, and Mahabir

Andy Tindale · Posts: 2432 Location: Stroud

I have found when this crash has happened to me that it is often possible to re-open the dsb file, go back to the simulation tab and read in the eplusout.eso output file without error (using File > Load results file menu option).

The probable reason for the crash is DB loading and processing large amounts of hourly data before E+ has been unloaded from memory following the simulation (it can take some time following a large building being simulated). We will look into improving this process and also DB's ability to warn the user when large amounts of data have been requested.

As you have discovered, the easiest way to avoid the problem is to only request hourly and sub-hourly results for short simulations (i.e. when there are > 10-20 zones). You may also find running the simulation using the EXE E+ option helps.

bmatthews · Posts: 30

Hmm...
Here I run into a problem. Energy calculation requirements state that there be many zones. ASHRAE 2004 90.1 Appendix G Table G3.1 #8 lists how a building must be broken up into zones. A simple common sized block building following these requirements has at least 21 zones starting, then those areas break up further into areas of differing schedules, and LPD. For my building, 81 zones is the minimum I can go. I will take your suggestion and only report on a daily basis, but that runs into problems with troubleshooting results due to the lack of detail.

Andy Tindale · Posts: 2432 Location: Stroud

The usual way round this problem is to run short winter and summer simulations requesting hourly data for diagnostic checks, then once you are happy that the model is behaving correctly, run annual simulations requesting monthly results only.

Shortcuts

Login