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 Reply
  • 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.



Children
  • 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?

  • 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.