Building Elements within Cells

We have a highly repetitive series of residential units across a large project including bathrooms, internal partitions, furniture etc. In plain old Microstation we would have used cells to group together these elements and place them throughout the design, enabling them to be quickly updated altogether when needed.

However in ABD if we use cells to group together building elements, such as walls, furniture, doors etc then they cannot be seen by the datagroup explorer without first being dropped. An alternative would to be to put the room elements within a dgn and use references instead of cells but it quickly leads to an unwieldy sets of attachments.

Any suggestions as to how to best to handle repetitive groups of objects rather than just repetitive individual objects?

Thanks,
Thomas

ABD SS4 08.11.09.593
GB Dataset

Parents
  • Use a compound Cell

    Ustn since 1988
    SS4 - i7-3.45Ghz-16 Gb-250/1Tb/1Tb-Win8.1-64b

    Eric D. Milberger
    Architect + Master Planner + BIM

    Senior  Master Planner NASA - Marshall Space Flight Center

    The Milberger Architectural Group, llc

  • Sounds like a CR....?

    Amazing that this hasn't come up as an issue before... or has it?

    AecoSim can't very BIM-oriented if a simple Ctrl-G screws up the whole 'Single Source of Truth' thing.

  • I would say that grouping elements is bad practice, simple as. Grouping should only ever be a temporary fix.

    If you are grouping items(such as room/apartment layouts) then these should really be done as references, which then allows you to assign logical names etc to each reference, which then produces very detailed and nicely broken down schedules through the datagroup.

    references also are the best for updating on a large scale. with cells or graphic groups you will have to update manually.

  • Nah...  Bentley should fix the problem. After they do you'll be singing a different tune : -)

  • Dominic, there is no "problem" to fix per se since DataGroup catalog types were designed to define what a thing is.  So when grouping disparate elements into a single cell what you have is now a "new" element using whatever Catalog type was applied.   For example, I could group together five doors into a cell and assign it the DataGroup catalog type Toilet Fixture.  Despite containing five Doors, it's now a (very special) Toilet Fixture.   :)    The closest thing to something like this would be an assembly such as a Bar Joist, but as Thomas pointed out that's really not what he's looking for.

    Thomas, using references is the most common way to approach what you're doing.  A Duncan pointed out you can use Logical Name to indentify what's what while still maintaining the unique component instances contained within each file.  And whenever any of the components within those references is changed in some fashion, all instances update.  Plus it accomplishes the "move everything at once" nature of a graphic group.



  • Steve, there is a problem, plain and hopefully simple to solve.

    In the BIM-world, we have to do a lot of assembly:part-type modeling. For example you work on a Washroom: Yes, you would group the entire space as a WC block... comprising of sub-groups of mens, womens cubicles, wheelchair-accessible cubicles, handwash basin units etc etc as assemblies. Each assembly would be built up using either sub-assemblies and/or 'elemental' parts. Cladding panels would be another example.

    It is pretty similar to a MCAD modeler modelling a pickup truck. The overall truck model would consists of sub-assemblies for the body, doors, transmission, axles, wheels etc. At any point in time, they will need to be able to do a BOM or attach / modify tag information to the parts or assemblies.

    Do you honestly think that they would be happy if all they could see is the top level 'elements'?  

    Using Refs will bog down very quickly. That's not what Refs are used for... especially the way they are set up at the moment. Ref Dialog gets pretty unweildy pretty quickly.

    As mentioned above, GG's do not support updates as they do not store insertion point, transform info. Modern 'parametric' BIM-style working relies heavily on being to link and update components and assemblies. Check out the AIA's Model Progression Schedule concept.

    I think it would be best for everyone if the DGS could improve the way it scans the dgn + attachments when reporting. The info is available. Don't seem to have this limitation with Items / EC Schema info. Maybe DGS should scan the new fangled SS5 cache... on the side?

Reply
  • Steve, there is a problem, plain and hopefully simple to solve.

    In the BIM-world, we have to do a lot of assembly:part-type modeling. For example you work on a Washroom: Yes, you would group the entire space as a WC block... comprising of sub-groups of mens, womens cubicles, wheelchair-accessible cubicles, handwash basin units etc etc as assemblies. Each assembly would be built up using either sub-assemblies and/or 'elemental' parts. Cladding panels would be another example.

    It is pretty similar to a MCAD modeler modelling a pickup truck. The overall truck model would consists of sub-assemblies for the body, doors, transmission, axles, wheels etc. At any point in time, they will need to be able to do a BOM or attach / modify tag information to the parts or assemblies.

    Do you honestly think that they would be happy if all they could see is the top level 'elements'?  

    Using Refs will bog down very quickly. That's not what Refs are used for... especially the way they are set up at the moment. Ref Dialog gets pretty unweildy pretty quickly.

    As mentioned above, GG's do not support updates as they do not store insertion point, transform info. Modern 'parametric' BIM-style working relies heavily on being to link and update components and assemblies. Check out the AIA's Model Progression Schedule concept.

    I think it would be best for everyone if the DGS could improve the way it scans the dgn + attachments when reporting. The info is available. Don't seem to have this limitation with Items / EC Schema info. Maybe DGS should scan the new fangled SS5 cache... on the side?

Children
  • Isn't references smarter and more economic than cells? And with cells you loose the control of each instance.

    Thomas problem is not references per se, but how to view and control them in the UI. There are things like 'hidden' refs (I understand it as the name is hidden in the ref dialog). Perhaps the UI for refs can be enhanced with filters, groups etc.

    regards / Thomas Voghera

  • "However in ABD if we use cells to group together building elements, such as walls, furniture, doors etc then they cannot be seen by the datagroup explorer without first being dropped."

    As I understand it, its not about view or 'graphic' control, but 'data' control from DGE.

    "Isn't references smarter and more economic than cells?"

    Sure, they are... but at a cost. I think a lot of things should not be Refs and should be cells. Do you really want your Ref Dialog clogged up with thousands of bolts or rebar or door handles? Never mind the explosion in the Level Display dialog that would entail.

  • Blimey Bentley, get a grip, prune the overgrown tree, down to the ground if necessary, provide something that does as much, but without arcane undocumented tweakery and incompatibility between branches -

    by new means, routines and nomenclature as and if necessary.

    The time has come, at last, to face up to abandoning the fixation on legacy compatibility, unless it can still be preserved by clever behind-the-scenes translation. I do trust that the presumably new quantum-leap v9 dgn format will accommodate this, at least by v9i time.

    Otherwise, surely, eyes will be turning to whatever 'new-broom' Dassault and Belmont have in preparation. Because AFAIK all the others, incl Revit aren't much better - the 'truly modern BIM' prize is still there for the taking, meaning at least as capable as the best features cherry-picked from the Mcads.

  • I agree with the sentiments of all of these points. The general discussion is one of workarounds, where what we are talking about is basic information management of nested components - this is core functionality of any serious BIM application.

    I also find it frustrating that these discussions are often polarised between two groups, those who are principally managing geometry albeit using basic BIM functions to produce drawings (most of this is achievable reasonably easily), and those who are concerned with managing information (BIM) - AECOSIM is a BIM application, or so the marketing material tells us. The default assumption on this group should be that when managing components and assemblies the user is going to be interested in the data as well as the way the geometry display.

    Clients value data above geometry.

  • There are some good points here and agree with much of what has been said.

    My original question was primarily motivated by the desire to access the data as Robert describes and not be restricted to either having assemblies of elements treated as either:

    1. a compound cell or PCS type element with just one set of overall attached data but easily moved around and replicated; or

    2. as separate elements all with their own relevant data but without the ease of manipulation in terms of copying and then updating.

    I agree with Duncan that references provide a more robust way of dealing with repeated elements (logical names for analysing the data, doesn't require the updating that shared cells do) but as ckeischar rightly points out I think there could be problems in the long run with potentially hundreds of attachments. I currently have a hotel with approximately fifty rooms per floor so each floor model requires fifty references just to deal with the rooms alone, and if different types have the same bathroom then there's an issue about whether to nest the references so it's modelled once or model it in each type and update in turn.

    I think this issue occurs at a range of scales: in the past I have had situations such as a window assembly with deep reveals that require a plasterboard return which is easily modelled within a compound cell but then isn't included in quantity takeoffs leading to either those elements having to be modelled outside the cell and therefore managed separately from it, or incorporating them within the cell and writing the desired information into the metadata for use in schedules which is then carries risks of not being updated, not deriving from the model itself etc.