DataGroup Explorer and Cells

I am modeling a building with prefabricated concrete facade elements. One element consists of a wall and one ore more windows. In my mind the most natural approach is to collect these parts in a cell. As the design evolves I can edit the facade elements cell by cell. And update the whole building, where the facade is modeled in a series of floor plan models, by updating cells as needed. Then I have to count and annotate both windows and concrete walls.

But DataGroup Explorer can not reveal the contents of cells! I have to drop the cells. But after that it is really cumbersome to edit the facade elements...

How am I supposed to design this kind of facade using ABD?

Parents
  • Correct - once nested within a cell, the sub-component DataGroup info is not accessible to DataGroup Explorer (or any other fashion). This has always been the case, though.

    *Edit: Ignore the below - I see Travis has replied with an alternative method using reference attachments instead.


    Aside from grouping as a cell, placing as a single unit, and then dropping for reporting/modification purposes, I'm not sure there are many other options for the scenario you've described. But I am curious to know how others might approach this type of thing.



  • Or Bentley should just overhaul the Datagroup system. Seems like a huge oversight in the spec in this BIM-crazy world that we live in, where assembly:component modeling is pretty upfront and in-your-face every day.

    Using Ref's is not a long term or sustainable solution. The Ref Dialog already slows to a crawl when we have more than 50+ Refs.De-cell-ing will mean thousands of Refs. Also don't forget that the assembly:component way of modeling means that there will be a lot of nesting. Something else that will slow the Ref Dailog down.

    We also have to publish to Navisworks weekly for coordination. Having everything as separate files will be a problem. Yes, you could probably merge all of the Refs that would normally be Cells before converting, but better to just fix the problem.

    Harry, I would be interested to know:

    1. if the cell info is available if you publish the model as an i-model. This might be the better workaround.
    2. if the Annotation Tools can access the nested cell's DGS info. Say you have a door handle Cell that is nested in a Door Cell, will ABD's Annotation Tool be able to extract and label info tagged onto the door handle?

  • An overhaul of the Data Group System is really needed. Why is everything in ABD so complicated? Especially for someone like me who work far from US standards. I have to dig into an overwhelming amount of xml files to adjust the system to deliver what I want and need. Why can't Bentley provide a simple building component editor. An extension of a cell manager able to add instance data to basic geometry created by plain Microstation. And finally get rid of antiques as Frame Builder and PC Studio. Who needs parametric components? These just make reporting more complicated. A cell library with a reliable sync with the projekt models is easier, faster and far more flexible.

    hopefully
    / Harry
  • Overhaul: yea... if you do a search in this forum, you will find many complaints about DGS and the original Family + Parts data set stuff.

    F+P (and DGS?) was based on an externally developed vertical called Triforma. It's interesting to see that Bricsys have at least looked at the 'database' and come up with a much easier to use UI for it.

    http://communities.bentley.com/products/building/building_analysis___design/f/5917/p/89683/255385#255385

    I always get the feeing that DGS and the F+P system never really gets improved because it is essentially in maintenance mode since the original Triforma authors are no longer on the team, and/or perpetually waiting for platforms to lay the ground work for something more up-to-date and more easily improvable.

    There seems to a lot cooking at platform level which could help. You may want to join the Microstation Connect EAP forum.


    Unknown said:
    Who needs parametric components? These just make reporting more complicated. A cell library with a reliable sync with the projekt models is easier, faster and far more flexible.

    Errr.. lots of people have been waiting for better parametrics in Mstn and its extensions like ABD.... at many levels. I think that the more BIM and info-centric we get the more we will need to rely on 'parametric' tools to manage the information. Extracting quantities and attributes needs a system that will handle 'typing' information, so that changes can be propagated automatically. Manual updating is for the birds...

    Garbage In <> Garbage Out... which is pretty much guaranteed if something like Bricsys' 'cascading' Object Styles isn't built into the UI... IMO.

Reply
  • Overhaul: yea... if you do a search in this forum, you will find many complaints about DGS and the original Family + Parts data set stuff.

    F+P (and DGS?) was based on an externally developed vertical called Triforma. It's interesting to see that Bricsys have at least looked at the 'database' and come up with a much easier to use UI for it.

    http://communities.bentley.com/products/building/building_analysis___design/f/5917/p/89683/255385#255385

    I always get the feeing that DGS and the F+P system never really gets improved because it is essentially in maintenance mode since the original Triforma authors are no longer on the team, and/or perpetually waiting for platforms to lay the ground work for something more up-to-date and more easily improvable.

    There seems to a lot cooking at platform level which could help. You may want to join the Microstation Connect EAP forum.


    Unknown said:
    Who needs parametric components? These just make reporting more complicated. A cell library with a reliable sync with the projekt models is easier, faster and far more flexible.

    Errr.. lots of people have been waiting for better parametrics in Mstn and its extensions like ABD.... at many levels. I think that the more BIM and info-centric we get the more we will need to rely on 'parametric' tools to manage the information. Extracting quantities and attributes needs a system that will handle 'typing' information, so that changes can be propagated automatically. Manual updating is for the birds...

    Garbage In <> Garbage Out... which is pretty much guaranteed if something like Bricsys' 'cascading' Object Styles isn't built into the UI... IMO.

Children
  • Unknown said:
    F+P (and DGS?) was based on an externally developed vertical called Triforma. It's interesting to see that Bricsys have at least looked at the 'database' and come up with a much easier to use UI for it.

    Can I rewrite that to be even more interesting? ...

    'F+P  is completely unchanged in 20yrs, from an externally developed vertical called Briscwork running on PD95, which Bentley bought and re named Triforma 1 running on MS95 (but not DGS - that's all-Bentley and came much later). It's interesting to see that Bricsys (which still exists as an independent) have at least looked at the 'database' and come up with a much easier to use UI for it, in their older-and-wiser BIM add-on to BricsCad, which is possibly the best of the Autocad clones (because they've dared to go much rurther with it than a mere Acad replica)'.

    Unknown said:
    There seems to a lot cooking at platform level which could help

    and at BD level, temporarily on hold while the team get SS6 launched. I'm pretty confident that BD Connect, hopefully within the year, will be an even larger overhaul of BD's fundamentals. that MS Connect is. It has to be.

  • Cascading...

    https://communities.bentley.com/products/building/building_analysis___design/f/5917/p/89615/255533#255533

    https://communities.bentley.com/products/building/building_analysis___design/f/5917/p/70554/185377#185377

    Connect: yea... some of the new functionality is looking like a re-boot of a lot of what F+P and DGS are doing. I suppose that this has been happening already since V8i introduced Element Templates and especially DV's which kind of follwoed in the footsteps of F+P which had to deal with different symbologies for cut/forward etc views.

    On the parametric / datagroup front, I suppose a lot of this has also been creeping in over the years with things like Items... and as now that a 'common modeling environment' based on Functional Components that are fed off a revamped DDD/Feature Solids Variables Table and a bit of ECFramework stuff thrown in. I can't really see much use for a separate code stream for DGS. Again, I suppose you could argue some of this has already snuck in via Spaceplanner which can also use ECFrameworks to store its nested room data.

    SS6 is a bit of a 'sayonara' release before jumping on to the overdue 64bit band wagon. Hopefully, the ABD team will make the jump and not just port old code like F+P, DGS and DEM over. But, even Connect is interim as it seems that there is something called Graphite

    "In its first incarnation, Graphite was used to create the new Bentley Navigator CONNECT application. The platform has a new SQLite-based file format that enables file streaming and is more suited to distributed server-based access. The SQLite format makes design information more granular and provides relational links, enabling multiple data schemas (e.g. COBie) to be included. It also provides powerful and fast search/filter capabilities."

  • RUMOUR CONTROL!

    Unknown said:

    SS6 is a bit of a 'sayonara' release before jumping on to the overdue 64bit band wagon. Hopefully, the ABD team will make the jump and not just port old code like F+P, DGS and DEM over. But, even Connect is interim as it seems that there is something called Graphite

    Simply to pre-empt misinterpretation or tangential extrapolation, CONNECT and the DGN V8 format will not be superseded by 'Graphite', they are complementary. CONNECT is not interim! I'll leave it for others to discuss further in appropriate detail elsewhere.

    Regards

    Marc

  • Unknown said:
    they are complementary. CONNECT is not interim! I'll leave it for others to discuss further in appropriate detail elsewhere.

    Errr... of course they are !

    Do tell...

    "What else

    I also think we need to focus more on the business problem that needs solving than the independent pieces of geometry or graphics. Our software is pretty graphics centric and the model is premised on the fact that we understand the physical location of things and that works for designing roads bridges and buildings. But the bigger concern is what does this model mean, what problem is it trying to solve. There is going to be an inverting. Today it is geometry first but in future I think we will defines things in term of “I want a building that has these qualifications and inside has these systems to help do this”. I don’t mean to imply that we won’t have all of the same tools for creating geometry and there are reasons why you must know the physical properties of things so that you can design better. But it is business first then physical."

    In the mean time, I would hope that Mstn will be able to reference attach those new .imodel files, the way it can currently attach i-model files.

  • From KB interview

    Unknown said:
    ... we need to focus more on the business problem that needs solving than the independent pieces of geometry or graphics ... I don’t mean to imply that we won’t have all of the same tools for creating geometry ... But it is business first then physical.

    Well, there's much long-awaited fundamental work to be done in BD before anyone can say 'job done' as far as geometry creation and modification - "same tools" won't do at all. This won't be 'gilding the lily', but getting to the starting blocks! Signs are, it's going to happen (tho prob not in SS6, downloading as In write).