Possible to outline an 'MVD exchange requirement' to address the concept of #groups?

[theoryshaw]

For the next Coordination View 3.0 Certification (presumably for IFC 2x4), would it be possible to support and outline an 'MVD exchange requirement' for Groups/Blocks/Cells/Objects/Families/Components/Assemblies/Modules/etc. (exact name is software dependent) between BIM software? (For the sake of consolidation and discussion here, i'll call them #Groups)

Would like to support a workflow similar to the following...

• A BIM file, from Vendor X, contains 10 instances of #Group Z. →
• This BIM file is exported, via IFC, and in turn imported into Vendor Y's BIM file. →
• Within vendor Y's program, a user changes/modifies the definition of #group Z. This change is, in turn, propagated throughout the 10 instances of #Group Z , within vendor Y's file.

Not necessarily looking to save the parametric values of these #Groups yet, just static definitions at this point, would suffice. Want to keep it as simple as possible.

In an ideal world, it would be great to outline this proposed exchange schema as a new type of MVD, call it a #RoundTripMVD or #Bi-DirectionalMVD. I have a sense, however, that it would be easier incorporating this proposed exchange requirement in an existing MVD--Coordination View 3.0, for example...but would defer to others on this.

Related conversation, if interested. http://sourceforge.net/p/ifcexporter/discussion/general/thread/fad5b2f8/

From my understanding, would one use the following IFC entities to accomplish this? --IfcMappedItem http://www.buildingsmart-tech.org/ifc/IFC2x4/rc4/html/schema/ifcgeometryresource/lexical/ifcmappeditem.htm --IfcGroup http://www.buildingsmart-tech.org/ifc/IFC2x4/rc4/html/schema/ifckernel/lexical/ifcgroup.htm

Thanks Much, Ryan

I'm sure i'm missing a few, but provided the following for Reference...

• Revit (Families, Groups, Assembles)
• Microstations (Cells)
• Archicad (Objects, Modules)
• Vectorworks (Symbols)
• Tekla (Components)
• Sketchup (Components)

[jwouellette]

Ryan, There are so many issues wrapped up in this it may take a bit to unravel.

FIRST: Round-tripping? Everyone talks about this being "ideal", but I still don't see it, at least I don't see the NEED for it. I know, I know, I've heard the arguments, but below the surface, these arguments are very superficial and don't really address the REAL problems of changes needed to workflows and processes.

We could argue about this until you're blue in the face, but I think it is not worth it. Instead of focusing on round-tripping/bi-directionality using IFC, or any other "file format", I think it is better to explore the untapped power already available, if people just stop and see how they can work with it and not against it.

[jwouellette]

SECOND: It appears that you are confusing the concepts of software conveniences with a data model to represent a building. At the same time, you are failing to recognize the concept of "types" in IFC, which already directly addresses the notion of a single definition with multiple instances, much like vendor software does in their numerous nomenclature permutations.

In the IFC spec, you'll notice that there are object concepts - IfcColumn, IfcWallStandardCase, IfcDoor, etc. But yo should also notice the object type concepts (there in 2x3, but more robust and consistent in IFC4) - IfcColumnType, IfcWallStandardCaseType, IfcDoorType, etc. A object type creates a definition of common geometry and attributes that can be directly referenced by multiple instances throughout the model. The definitions vary by object type, due to the fact that the similarities of objects may differ, e.g. a wall type defines the "assembly" of the wall construction and its attributes, but not the extents of the wall itself, defined by the instance, where as a column type will define the geometry as well as the attributes for all instances.

Accordingly, the geometric RepresentationMap occurs within the type definition.

[jwouellette]

THIRD: IfcGroup, by specification, is an arbitrary assignment of a "logical collection of objects". An IfcGroup could define a collection of furniture or casework for a housing unit, or a housing unit itself, all of the structural columns of a building, or all the components of an HVAC ducted system on the floor of a building.

The group definition is NOT one-to-many like an object type. It is merely an arbitrary collection based on some arbitrary logical association. This can be used to help further identify, and explicitly "mark" a particular relationship between objects that may initially seem unrelated (like walls and furniture), but have some other logical relationship (the walls and furniture of a housing unit - #303, for example - in a multi-family complex).

The group does NOT contain its own shape representation or position by specification.

[jwouellette]

FINALLY: The software vendors have come a LONG way in the last year to support IFC-based workflows through the buildingSMART International Certification 2.0 process. These results have been worked out by the vendors through the buildingSMART International Implementation Support Group, with support from the IFC experts on the Model Support Group. Granted, end users aren't directly part of this effort, but through the budding IUG (International User Group) and better feedback on a user-by-user, vendor-by-vendor basis, results improve.

For each vendor, there are nuances in setting up and using objects and models to get the best interoperable results. This is because they all come from such unique starting points, developments, technologies, and workflows. If we had all used IFC as a starting point, a reference for the building data model and all the data logical structures, I believe that there would be far less differences between them. As such, I think it is encouraging that we have made such effort and progress to use IFC as a means of sharing information possible today, across the board.

Some things are automated quite well, many things are not. Ideally, it all would be automated to the point that non-technical end users wouldn't have to worry about any of it. We're not there yet, across the board, but I am encouraged by the progress as more user implement what is possible and give feedback to their vendors.

Using IFC, right now, is an ongoing learning experience for all. Not everyone needs to be an expert, like Tim Chipman or Thomas Liebich, but some basic knowledge goes a long way in understanding how to best utilize the opportunities of IFC-based workflows. Ultimately, every user also has to understand that THEY may need to change the way they do things in order to make it work best, too.

[MatthiasWeise]

A mix of interesting topics!

A first step would be to agree on how to deal with your requirements in IFC. As mentioned by Jeff, it is related to the occurrence-type modeling paradigm of IFC (IfcElementAssembly/IfcElementAssemblyType would be an option). This is to be discussed in the Implementer Support Group of IFC.

Next step would be to specify required parts of IFC (and maybe additional rules) using mvdXML. A lot of examples are already included in the IFC4 documentation, e.g. how to define decomposition of elements (http://www.buildingsmart-tech.org/ifc/IFC4/final/html/schema/templates/element-decomposition.htm) or object typing (http://www.buildingsmart-tech.org/ifc/IFC4/final/html/schema/templates/object-typing.htm). IFC4 CV is currently prepared by buildingSMART, which not only shall be used for documentation purposes but also to support software certification.

Final step would be to use an MVD for software certification. buildingSMART is currently checking export and import, but no roundtrip (as you probably know). mvdXML enables to differentiate between import, export and both (but I am not really sure if this differentiation is really necessary in mvdXML).

[theoryshaw]

Apropos to this discussion: https://www.researchgate.net/publication/305770614_Modeling_of_repetitive_IFC_Building_Elements_using_the_Flyweight_Design_Pattern_Approach Thought I'd share.

[jwouellette]

I'm not sure I understand the reasons all this work was done by the researchers. The problem is solved with the proper implementation of IfcTypeObject. As mentioned before, this was NOT mandatory for IFC2x3 CV2.0, but will be for most aspects IFC4 certification.

[timchipman]

I'm not sure I understand what the author of that research paper is trying to achieve. There are several levels of "optimization", each of which may or may not be desirable depending on the scenario: (a) optimizing for storage or transmission -- IFC and ifcXML files of identical content typically compress to around 20% of the original size (though depends on content and other optimizations below) -- such compression happens automatically in web servers and clients supporting HTTP compression, which is pretty much all major software. While compressing IFC files on a local disk could also be done at the time of authoring, that would come at the expense of time storing or retrieving. (b) optimizing data encoding -- many programs export IFC or ifcXML in an optimized way such that there is only one record of data having the same value, e.g. IfcCartesianPoint(0.,0.,0.). And various programs are able to compress any existing IFC or ifcXML file in that same way. However, such optimization may also come at the expense of time editing or exporting (software maintaining hash tables to lookup and intern references), and optimizations of (a) also solve this. Such optimization may also come at the expense of scalability for software designed to work with huge models (i.e. terabytes) with only subsets of information loaded into memory and the rest indexed within a database. (c) optimizing data content -- if multiple objects within a building refer to the same product type, then they can use type objects to hold this common information. However, regardless of whether this is done, optimizations of (b) already solve duplicate information that can be interned when serialized. This approach may be favorable for software that compresses and indexes records on a per-object level such as Revit. (d) optimizing identifiable objects -- if repetitive objects such as tunnel segments that the author describes are represented a single identifiable object having placement arrays, that can also shrink the size, however it does so at the expense of making objects no longer capable of being referenced individually. For elements like rebar, combining multiple bars into a single IfcReinforcingBar with mapped geometry is common practice, as nobody typically needs to later reference an individual bar. Though doing that in general such as for walls, beams, windows, etc. is usually not done in practice because that doesn't fit the use case. If the only concern is visualization, which appears to be the assumption of the author, then everything could be optimized into meshes of triangles, which can be done in many other ways much more efficiently than IFC. However, the whole point of IFC is to exchange information to other parties describing how buildings are built, where most objects have unique identity so you can refer to them downstream and annotate them later for change orders, maintenance, etc.