I exported idf file from DesignBuilder and further process using IDF editor.
However, when I try to open idf file by IDF editor, I get following error.
Are there any way to open idf file by idf editor without getting this error?
My idf file had a similar "Out of memory" error and I could not open it with IDFEditor.
My idf file is irrelevant to DesignBuilder. The data size is simply large: 52MB, 2600 Zones, 33000 Surfaces.
Originally, the idf file was created in V8-9-0. Then, it was updated to V9-6-0 and V22-2-0.
I did not get the error above in V8-9-0 and V9-6-0, but I got it in V22-2-0.
The error suggests to edit Energy+.idd file and reduce the number of input lines of Schedule:Compact, but for my idf file, Schedule:Compact was not the cause of the error. My idf file had only 14 Schedule:Compact objects.
In conclusion, I fixed the error by editing the Energy.idd file and reducing the input lines of BuildingSurface:Detailed. We can input up to Vertex 120 (N362) by default. I reduced it to Vertex 100 (N302) considering the surface with the maximum number of vertices, and I could open the idf file with IDFEditor.
It seems that reducing unused lines (unused input fields) in Energy+.idd file helps fix the error. Schedule:Compact is not the only class which has many lines by default. BuildingSurface:Detailed, AirLoopHVAC:ZoneSplitter, AirLoopHVAC:ZoneMixer, BranchList, Connector:Splitter, Connector:Mixer, NodeList, OutdoorAirNodeList and EnergyManagementSystem:Program also have so many lines.
@JasonGlazer it sounds like making a similar pull request for IDF Editor to also mention these other object types at the bottom of this post with many input fields defined in the IDD would improve the critical memory error message by giving more possible object types to consider (not just Schedule:Compact).
Thats sounds like a very extreme model! How of curiosity, how long does an annual run of that beast take in E+? (You must be getting a ton of Convexity warnings too if you have surfaces with 100 vertices)
@Julien Marrec I'm still modelling. For testing, it took 5 hours for sizing run wih Timestep of only "1". Most of vertices are 4, but only a few BOH corridors are long and with a complicated shape, which result in nearly 100 vertices.
I agree, we should probably make a more general comment in that dialog box about reducing memory usage. @Keigo can you send me the file as an example?
Comments
@MJWitte or @JasonGlazer any ideas?
There is also a related post about needing to split a large IDF into two separate "sub-IDFs" to avoid errors in IDF-Editor
Please send me a link to your file and I will see if I can figure out the problem in the debugger. jglazer at gard dot com