buildingSMART Forums

Provision for Voids in IFC4x3 RC1

In the current release candidate for IFC4x3, IfcBuildingElementProxy has been deprecated, and IfcBuiltElement should be used instead.

Is there a new way to represent a Provision for Void object? Until now in IFC4, we’ve used BuildingElementProxy with PredefinedType set to PROVISIONFORVOID. I can’t find any way to do this in IFC4x3 RC1 without using the deprecated IfcBuildingElementProxy.

I wonder if the Clearance geometry context can be used as a substitute?

What’s the reasoning to remove Proxy? I know it is a class to avoid, but not everything is already available in the IFC scheme.

Voids, origin marker objects, abstract things etc… are not built elements. Should they use something else instead?

IfcVirtualElement > used to define a boundary
IfcProxy > deprecated


Overall Provision for Voids are important part of communication between disciplines (MEP <-> structural) and there is quite a few different software communicating each others with current implementation. What are the benefits if IfcBuildingElementProxy is replaced with IfcBuiltElement should be used? And from vendor perspective: are we doing extra work for little benefits?

“IfcBuildingElementProxy has been deprecated” is this really the way? I am quite sure that this lead misusing classes (perfect (class) fit can’t be found and no change of putting object to generic class -> have to use some class). This could lead out of the frying pan, into the fire. Receiver (importing software) can’t even guess that incoming object is wrong class. If received get proxy then it known that object is unknown.

Hello everybody!
this topics was once addressed after the presentation of our German Working Group “Provision for Voids” during the bSI Summit in Dusseldorf.

If you still have an access to the Summit folder you may see that presentation.
Maybe @mweise could help as a team-member?
All the best
Mirbek Bekboliev
P.S. So far under the Leadership of Prof. @steinmann VDI (Association of German Engineers) together with buildingSMART Germany published VDI/bS 2552.2 IDM on Provision for Voids. This publications is based on IDM: (in German)

1 Like

even the draft is 75 Euro … :frowning:

Hi @bernd, its not actually a draft! Maybe that was misinterpreted… Its a “public review” with a limited time frame in order to collect feedback (corrections, improvements, further suggestions) from industry experts. Guess the price doesn’t change after the final release…
@steinmann please correct me if I wrote smth wrong.

How is a “public review” possible it the acces to the data is 75 Euro?

VDI calls it “Green Print”, which for English they chose “Draft”. In fact its indeed a trial review. I couldn’t find a proper alternative for a “Public review” - guess “Industry Review and Feedback” would be more suitable.
If no further comments from industry experts would follow, then after this limited period a document would be passed as a “White Print” - Final.
Like in my previous Comment its an official release with an opportunity for comments. Within that period experts may provide their critique, comments and further ideas.

No matter how it is called it is still 75 Euro and it is not even finaly released … As I am interested in this I would like to read it but I am not gone pay 75 Euro from my private money for a document which is not even finally.

cheers bernd

BTW: buidingSMART is a worldwide organisation. In some countries this is quite a lot of money …

1 Like

Thank you for your comment.
However, there are 2 different approaches.
Just an example. ISO publishes (Final) Standard, which will be under review later on. See publishing steps by ISO: After that review an Update / Withdrawal will follow.
While VDI also publishes its final Work but won’t call it yet Standard until review period would be over.
If someone is really interested would contact corresponding team. Like I suggested in my 2 previous messages. Feel free to contact @mweise (Member of the WG Provision for Voids). They had a chance to present their work at the bSI Summit in Dusseldorf in 2019 within the Building Room.

Thanks for your informations.

Is it possible to make a copy of this work available for review?

Hello Bernd,

I cannot share the VDI document, but I can point you to the documentation and all related files (IFCs + mvdXML) from the working group. This documentation is in German and still up-to-date, but there are some formal differences to the VDI document. The files are available here.
Please note that the described workflow is based on the use of IfcBuildingElementProxy and Pset_BuildingElementProxyProvisionForVoid.

Best regards,

1 Like

Hi Matthias,

thanks for the documents. Just had a look at this. In most of what is written I am with you.

Just one remark. In your small example all MEP openings will be adoped in the TWP and ARC modell. I am structural engineer for concrete buildings. Means we do make TWP modells and parametric modell related drawings. We do include all openings in our TWP concrete model. We do make the buildings site model and the drawings for the foam work and the reinforcement. Means we have to include the openings. But non of the architects I have worked with has ever put all openings in his modell. Some of them have tried to input all openings but have given up after the third or even more change of the opening. It is just not worth to do because we do make the model for the building site. (Die Werkplanung für die Schalung und Bewehrung).

I am curious, if it is different in other projects. Someone around here who has done BIM-Projects in real world?

The most important part is missing. How is it possible to automate the process to get the openings from the MEP modell into the TWP modell. Or even more important because the later does work if ProvisionForVoid is used (at least it does in Allplan), how is it possible to automate the process of the changes of openings. The later is what takes the most time.

cheers bernd

keep up the good work. Hopefully the VDI does not want to charge every BIM-Workflow document with 75 Euros.

Is there a publicly available set of English documents to see what work is being done? Unfortunately most of this is lost on me. I could run it through a translator but that isn’t ideal…

1 Like

Hi Bernd,

you are right, change management is a big challenge! Main focus of the group was to propose and coordinate new openings.
In theory, changing an existing opening could be handled in a similar way by proposing a new opening in a different location (+ request to delete the old opening).
Such changes have to be issued in a change request ideally communicated via BCF messages. The change requests will then run through the same approval process as new openings so that changes are properly communicated between MEP, ARC, TWP and other stakeholders. The (big) downside of this workflow is the communication overhead, which hopefully will be automated to some extend in future.

Converting ProvisionForVoids into Openings was also discussed and tested in the group, but I do not know the latest state.

Best regards,

@Moult Unfortunately I do not have an English documentation. Attached you will find a presentation given in March 2019 at the buildingSMART summit in Düsseldorf. Maybe it helps a bit to follow the discussion and suggested workflow.

BR5_ProvisionForVoids-Example_GermanSpeakingGroup.pdf (1.2 MB)

Hi Bernd,

you asked for an architect who puts all the openings in his model. I know Tobias Döring from hammeskrause architekten - they found out an efficient way to handle the openings in their model and to do all the change management in real projects. So yes, if we want to use BIM consequently, we have to plan the openings and the belonging changes in the model. The question is: do the TWP and the ARC planner the same changes all the time in a redundant way or does the architect find a way to integrate the openings from the TWP planner in an automated way. For this hammeskrause architekten found a semi-automatical workflow.

Best regards

Here “TWp” (German “Tragwerksplaner”) - Structural Engineer

1 Like

Finally! Thanks bro! Someone taking care of non-german speakers :smiley:

1 Like