buildingSMART Forums

IfcSurfaceCurveSweptAreaSolid does not consistently orient the swept profile

I’m attempting to create beams which represent a cross section swept along a path. To do this, I’m using IfcSurfaceCurveSweptAreaSolid. The correct result should look like this:

The actual results can be seen below. On the left is ArchiCAD’s interpretation where both beams have their cross section rotated incorrectly. On the right is Solibri where the sweep along the polygon path has its cross section correctly rotated, while the linear beam’s cross section is incorrect.

In both cases, a reference surface is created which is a vertical extrude of the centerline of the beam. So according to the spec, the profiles should both be turned so that their local X axis is normal to that surface. Is this just a matter of incomplete/inconsistent vendor implementation of the spec, or is there more that I need to do to define the direction of the cross section profile?

I’ve added a beam based on an arc using the same strategy, and Solibri gives a wonky result. I would expect the cross section profile to be either vertical (local X normal to the reference surface), or horizontal (local X perpendicular to the reference surface), but certainly not tilted. ArchiCAD doesn’t even show the curved beam and no errors are written to its log.

Could you share the IFC file?

Here’s the file pictured above.

Elements_Beam.ifc (8.6 KB)

There’s an entire discussion to be had on how to validate an IFC file against an mvd, but I think first and foremost expectations on implementations for IfcSurfaceCurveSweptAreaSolid.
You’ve nominated in the header that the file complies with Coordination Model View 2.0, but this shape representation is prohibited in this mvd. As nearly all certifications and testing are in accordance with coordination model view, it’s much more likely there are bugs relating to the use of this shape.

There are improved sweeps in IFC4, I’d suggest the polygon beam should actually be multiple elements for improved reliability.

I chose “Coordination Model View 2.0” without really knowing what the limitations were. I suspect I should be using “Design Transfer View”. Which raises the question… How would I know? A developer has no insight into what’s allowed in an MVD. I suppose developers could read the MVD, but I suspect that nobody does that. It doesn’t help that the documentation site is broken as well as mentioned in: The IFC4 documentation website is broken

The fact that the vendors don’t then flag that a type is not allowed in the specified MVD drives home the fact that vendors aren’t properly supporting MVDs on import either. One would expect import errors logged with a message like “Entities of type IfcSurfaceCurveSweptAreaSolid are not supported in model view definition Coordination Model View 2.0.”

I would also expect that if an entity did load, supported in the MVD or not, that at least it would show up according to the spec.

@ian IFC2x3 or IFC4?

If developing for IFC2x3, then the CV2.0 MVD is the one to base others interpretations on. Many, if not most of the major vendors have certified against that.

For IFC4, then the RV1.2 is the best place to start. Design Transfer View is kinda dead in the water until we get better end user exchange requirements.

However, I do agree that regardless of the requirements of one MVD, that many, if not all, of cases like this should be properly handled. This is one of the things that Implementation Agreements (IAs) used to cover, but we’ve moved away from, looking to just clarify the documentation and narrow the scope, in some cases, instead.

This and similar issues would be good to bring up at the next ISG meeting.

Yes, after IFC4 we have RV & DTV which theoretically RV is a reference, a base, without the ability of any changes, for DTV which develops based on RV

However, after ISO 19650 needs some updates and also inherently had some issues too

It mainly related to IDM and groups/rooms who develop IDM

I ensure that bSI will do its best and soon will see a good official RV and DTV