How many times a day does AECOsim crash for you?

Well it comes and goes.  Honestly.

Usually I find the culprits that cause the crash or things just get fixed as I work.

Refs off should help but I would say that my models are quite large and that is probably more of the issue.

Try little tricks like running as an administrator.  Make sure things are broken down into chunks of data.  don't break them down just to break them down but there are logical ways that need to be broken down like.  Stairs, first floor, 2nd floor, roof, exterior walls, etc.

If you find a file that repeatedly crashes then copy it and start deleting things until you find the culprit.  Or create a blank ad add stuff until it crashes.  Last project I had it was quick made trusses that the structural stuff wont make.

When I made solids, clipped stuff and merged into one it started having problems in pdf and dwg creation

So I remade the truss differently and everything is now better.

remember that you are using someone else's file and they may not be made as well as yours.

Thanks for the tips Eric,

I have some fairly large files 1.2GB in total. I also have (what I thought) plenty of system resource.

32GB RAM
6GB Graphics Card
New i7 Hexcore processor....

I will try running as admin to see if that has an impact.

I am unable to trim bits out of half of the files I'm recieving as they are i.dgn and locked down... I get a pop up often, something about 'Large Level Dictionaries', and have compressed to no avail. I assume that the i.dgn won't allow the removal of unused levels...

anywho.... Back to the grindstone...

@Eric,

That is bizarre that you would be experiencing more crashes on an SSD than HDD. I will try moving my page file.

Requiring 50GB to print is, um, well pretty crazy IMO...

I think the SSD is to fast for the process of what is going on and like the fishing like it gets in  a knot

OK, thanks Tim.   If you're often sitting in that 3.2GB range then yes, a spike at that point certainly could be a factor.

Just from a pure testing perspective...  have you signed up for the MicroStation x64 Early Access Preview?   I'm just wondering how those same operations would fare in the native 64bit version.  Granted, the building data will not be loaded so it's not quite a fair comparison, but if you're curious you could also try ABD's MicroStation mode first as a bridge of sorts between the two.  

You know, we were having all sorts of speed issues and crashes. We couldn’t figure out what it was. Network speed? Memory? We were going crazy. The fellow who started the project went about referencing files like the old days. He referenced files to other files when he needed them. He set the nesting level so he got what he wanted. It was a real mess. I suspected that circular references were a part of the problem. Think about it. If there were 20 references files that through nesting were attached on the average of 3 times, then statistics tell us the combinations would be 1140 nested references! So we started there.

So I had another individual go through and create a single master file, not only for architectural, but also for each discipline. There are often multiple models per discipline for as many as eight to ten disciplines. The references in each of the master files was set to no nesting. All of the references to each of our reference files were deleted and the master files were attached. My hunch proved much more on line than I though. Files opened more quickly by a factor of ten and the crashes stopped. We didn’t have to do any other “fixes.”

Not only did this master file philosophy make thing much, much faster, it also made things better organized. Now if HVAC creates an additional model, then we only need to attach it to the single HVAC master to have it referenced to all of the other files.

Actually we could have attached the discipline files to the architectural master and set the nesting level to one and accomplished the same thing. This makes things even more organized. When you create a new file, all you need to do is attach the architectural master and you have all of the project models at your service. This could also be done in a “modeling” seed file, but we haven’t done that yet.

For those who don’t know, you can use the Level Display dialog, drill down through the nesting to the reference you want to turn on/off and left click and check/uncheck Display in the pop-up.

Hey Tom,

What you are suggesting seems to resonate with what I am experiencing.

We have 2 main consultants providing files. one we set no nesting, the other have instructed us to set nesting at 99...

The 'no nesting' files are .dgn and seem to be structured well.

The 99 nested files are .i.dgn so I cannot modify, and have to live with the issues.

I am often getting 'Large Level Name Dictionaries' warnings also, which I attribute to the same files.

So short of asking the consultant to clean up thier files, It looks like I have to like with 5-10 crashes per hour of each day...

Hey Tom,

What you are suggesting seems to resonate with what I am experiencing.

We have 2 main consultants providing files. one we set no nesting, the other have instructed us to set nesting at 99...

The 'no nesting' files are .dgn and seem to be structured well.

The 99 nested files are .i.dgn so I cannot modify, and have to live with the issues.

I am often getting 'Large Level Name Dictionaries' warnings also, which I attribute to the same files.

So short of asking the consultant to clean up thier files, It looks like I have to like with 5-10 crashes per hour of each day...

We do the Master File with nesting never going above 3 or 4.

The "Mass Mode" for us is nothing but a collection of reference files of all our 3d models that create the project

If I need to manipulate it more specifically I can alway break that master down into all the sub models.

Every model have may reference all the other models but you make make sure each is always set to ONE or don't nest.

No more nesting.

Very good point, Tom!   Circular referencing can add up very quickly, taking what could ne 50MB worth of data and loading it as 500MB instead just by pure redundancy.  That's a good amount of overhead to add to the application itself, as well as processes actually being performed within that 32bit address space.  

So it's very good to see that you've seen such a difference after cleaning up those attachments.    :)

Tim

Have you tested to put all the i.dgns in one folder and reference them, without nesting, to one single consultantX.dgn.

If that works, reference consultantX.dgn, with nesting set to 1, to your 'master'. If that works you might check with X why s/he needs nesting.

hey Thomas, as mentioned above, the main problem files are i.dgn that have multiple nested references inside, so I cannot do as you suggest...

After talking with our .i.dgn consultant, I was welcomed to 'the club' with respect to crash frequency, and that there was absolutely no chance of current policy changes, i.e. 'suck it up'. I was also told that identical hardware and identical configurations return different error frequency and form....

I am assuming that Tom knight is correct, yet cannot effect any change.

I guess I have to enjoy my frustration until;

• Bentley update their software to 64-bit
• We change consultants
• The consultants have a revelation that this is not an acceptable commercial reality and address their modelling policy/process or change software.

It is a pity that my introduction to AECOsim has made me feel like the software is inherently broken...

Unfortunately this is a reality when running 32bit applications.   While 64bit land isn't a panacea for everything, it certainly can help when dealing with pure PC resource requirements...  requirements that can be greatly improved as mentioned above, albeit with a little virtual elbow grease.