Solid Element Operator Errors

Solid Element Operations and other trimming functions are helpful and even critical in generating the correct geometries and drawings in ARCHICAD. That being said, they should be avoided wherever possible! Overuse and misuse of SEO’s is one of the biggest contributing factors to a slow or glitchy file and can often be the cause of “beach balling”, freeze ups, and crashed files.

What Not to Do!

  • First, avoid dissociative trimming operations. That is, do not trim a wall, beam, column, to a roof, slab or wall that it is not actually associated with. The program beach balls when this is done excessively since it is looking for associations between elements that do not exist.
  • Second, do not repeat SEO’s. If elements do not trim to each other, do not simply “try again”. This will rack up the number of operators and targets and cause all kinds of file slow down. If elements do not trim to each other with an SEO, there may be a momentary glitch or something about the elements that are preventing them from trimming properly. I often see this error when walls are trimmed to roof in a group, then selected again and re-trimmed to another roof + the original roof (just for good measure).
  • Third, avoid creating a dedicated trimming element if a model element can be used in its place. For example, you do not need to carve out a site for the building if a basement slab is already in place. Redundant elements can cause elements to disappear in elevation/section/3d views.
  • Fourth, do not use an SEO if a simple geometry can create the same shape. I see this error most often for stair openings in slabs or clerestory openings in roofs. You do not need to trim these openings, you can simply generate them with a hole in the slab/roof (use the pet palette “-” button).

The File Failure Threshold Test

For this article I ran a quick test to assess the tolerance for the first (and most destructive) example of SEO misuse listed above. I took a simple collection of 4 walls, 1 roof, and 1 slab. I arrayed this collection into a 10×10 grid (14,800 polygons), 15×15 grid (30,600 polygons), and a 20×20 grid (54,400 polygons). None of these configurations should cause a slow and glitchy file based on complexity of model elements, since even the largest test is less than 2% of our average files polygon count.

Screen Shot 2016-03-22 at 1.49.17 PM

Test 1:

For each array size I then trimmed walls to their associated slab with downward with upward extrusion and their roof with upward extrusion, at a 1:1 ration. No wall was trimmed to a roof or slab it did not touch. The result was a smooth running and efficient file, even at the largest array of 400 roofs and slabs and 1600 walls. In the image below, notice the SEO fly out on the selected roof, only 4 associated targets to each roof/slab.

Screen Shot 2016-03-22 at 1.51.37 PM

Test 2:

Next I removed all operators and targets for each of the three tests. Then selected all walls and trimmed to all roofs with upward extrusion, and another SEO with all walls trimmed downward on all slabs. So the worst case is 1600 targets on 400 operators, performed twice.

Screen Shot 2016-03-22 at 2.01.57 PM

The results on the 10×10 array were acceptable, with minor, but noticeable performance and navigation slow down.

The 15×15 array had up to 10 second “beach ball” delays during basic navigation and editing, which is annoying but not inoperable.

The 20×20 array took over 15 minutes just to perform each solid element operation. After they were performed there were over 30 second delays to simply orbit or switch between plan and 3d views. The file crashed twice while performing basic navigation.

Final Thoughs

These tests were done in a file with no view map or layout book and no source markers of any type. This slow down will be noticeably pronounced in files with more total polygons, views in the view map that read these trimming/trimmed elements, and layouts with these views placed on them.

Again, I want to reemphasize, this test was done on a file with no complex content and only 54,400 polygons and only 2,400 total elements max. So be careful of how you use SEO’s! If your file is running slowly, this is the first place to look on regaining some speed and efficiency; even at the sacrifice of redoing most or all of the trimming elements, it could pay off in the file speed and efficiency of work. (Please speak with me before blowing out all your SEO’s though, it only makes sense if your file is inoperably bad or at an extremely early phase)

4 thoughts on “Solid Element Operator Errors

  1. Bradley

    Great read and good directions on what not to do. To many times I look at an element that has 20 SOE’s and only 1 of them is accurately linked. I would check with HQ to see if the slowness you see is caused by the SOE or a bug in AC19. We found many bugs that they are working on that caused AC19 to run slow in processing repetitive 3D elements.

    Like

    Reply
    1. wwabim Post author

      Brad, it is definitely not a bug, since many projects have thousands of individual operations. Its when SEO’s become disassociated in mass quantities that they cause problems. My first exposure to this was when all walls had been trimmed to all roofs. A clear modeling error that caused the file to freeze so bad it took 1/2 a day just to remove all operations (due to freeze up).

      Like

      Reply
  2. Pingback: Smarter Modeling & Top Link Settings | WWA BIM

  3. Pingback: File Performance – Self Audits | WWA BIM

Leave a reply to wwabim Cancel reply