We implement IFC bridge in our bridge calculation software and we have found that for the reinforcement of slabs and box-girders nothing in the IFC is provided to define reinforcement layers in a global way: It is necessary to define the bars one by one. This is totally impractical unless you admit that almost the entire file contains entities of the bar type. In addition, relevant information such as the coatings, the gaps between bars, the level of the layer are not transmitted, whereas they are useful for implementation on the site. I think it is very important to improve the ifcs in this area.
To this end, I have written a proposal that I can make available to those interested.
It looks to me that in your proposal the term “layer” means an array of identical bars, rather than the location of the bar inside concrete (like bottom or top of a slab). If we talk about an array of bars, those can be defined with a single IfcReinforcingBar definition and using IfcMappedItem definitions for the rest of the bars, like presented in the concrete box girder example of Building Smart (I would put a link, but they are not allowed in posts).
That method works fine and I don’t see a need for a new definition for rebar array. However, please share your detailed proposal, so I can take a closer look.
Spacing, coating etc. are not included in IfcReinforcingBar definition but they can be exported as optional properties.
Thank you for your reply. I had noted the possibility of creating identical bars by translation or rotation via the IfcMappedItem class but it does not allow to define a reinforcing layer by a single entity and it remains very heavy.
I want to make a proposal but how can I share a pdf file on this forum?
Thank you for the document. I agree that the current method (IfcReinforcingBar + multiple IfcMappedItems) generates in a typical case of a group of rebars quite many lines into the IFC file and thus it is tempting to look for a more compact way to present it.
The new method, while being more compact, would also have more parameters, which would increase the risk of deviations in interpreting and using those parameters. For example in handling offset curves and calculations along them. The current method is not that compact, but it is simple and thus leaves less space for misinterpretations and errors.
By introducing a new method to define a group of rebars, we would have two alternative ways to write the same data into IFC format, the old and the new method. This may not necessarily be a problem, as the new definition can always be converted to the old. Naturally each receiving software would need to build support for the new method.
We have discussed this proposal within the group of people coordinating IFC development of Tekla Structures. We understand the reasoning behind it but as we have not experienced that the file size of the current method would be a problem, we do not see it would be worth the effort to implement the new method.
Thank you for your opinion. I acknowledge that with regard to reinforcement data the spacings between bars must be unambiguous and clearly stipulated in the documentation. It is also clear that the two approaches can coexist essentially for reasons of compatibility.
From my point of view, what is important is what the receiver can do with such basic reinforcement data as in the current version.
Can he set up a reinforcement control process? Can he set up a manufacturing process? can he make an assessment of the cost of implementation? can he deduce constructive installation data relative to the other layers of reinforcement and relative to the formwork?
To all these questions the answer is in my opinion no or very difficult. This is possibly more important than the data volume in the current version.
It would be interesting to know the point of view of other software companies and end users.