Biggest model size in Open Studio

asked 2016-06-11 14:42:53 -0600

Dinosaver's avatar

updated 2016-10-18 14:22:01 -0600

I'm trying to work on a model with 450 spaces and 4500 surfaces. Looks like OS cannot process this... The performance is almost unacceptably low. Last August I worked with the model with 150 spaces and it was ok. Is it Open Studio feature or smthg is wrong?

edit retag flag offensive close merge delete

Comments

The EnergyPlus run is slow? Or viewing and editing the model is slow? If the latter, then this same question was asked very recently here.

__AmirRoth__'s avatar __AmirRoth__  ( 2016-06-11 16:26:02 -0600 )edit

The more questions, the harder to find answers... Yes, the problem is in OS GUI, Sketch Up works slowly but surely. I like tables, they allow (in theory) to manage massive data easily. Spaces, surfaces, zones - we asked for them, pity they don't work when they are really needed... I remember, 2 years ago OS could work with models with 400 spaces (not zones)... E+ runs the model within half an hour for a year simulation, that's appropriate, but to prepare the model it took a whole day. Ok, let's agree, that big models are out of OS scope.

Dinosaver's avatar Dinosaver  ( 2016-06-11 18:31:12 -0600 )edit

It may be the grid view that makes things slow. That would make sense because it has to look at large portions of the model at once. We can take a look at it, but there may be a basic trade-off here. There more things you have active and selectable/editable in the GUI, the slower each action will be.

__AmirRoth__'s avatar __AmirRoth__  ( 2016-06-12 10:46:39 -0600 )edit

I agree that the OS GUI gets very slow with a large model. I´m talking about a model of 490 spaces and 5,200 surfaces. Sketchup gets slower but is still manageable. But the OS application gets impractically slow within the spaces tab.

Carlos Vazquez's avatar Carlos Vazquez  ( 2016-06-13 08:43:09 -0600 )edit

Amir is correct - this performance hit was a side effect of introducing the grid view feature that was requested by many practitioners using the Application. OS App was built using Qt, which is an older software technology that doesn't handle cacheing of large amounts of data very well. We'd like to migrate the App to Angular, which does a much better job of that sort of thing (the team is shifting PAT to Angular as I write this), but it's not currently in our plans. In the interim, it's always prudent to look at floor multipliers as a means of reducing (potentially unnecessary) complexity.

ljbrackney's avatar ljbrackney  ( 2016-06-13 09:34:25 -0600 )edit