IFC structural models

IFC is the format a structural engineer is most often handed. Tekla, Revit, Archicad, Allplan, AxisVM, SCIA Engineer, RFEM and FreeCAD all write it, and most of them can write the part of it that matters here: the structural analysis view, the nodes, members, surfaces, supports and loads that an analysis program works on. Elementarium reads that view and writes it back.

The analysis view, not the building

An IFC file can hold two different models of the same structure. The physical model is what the architect and the detailer draw: IfcBeam, IfcColumn and IfcSlab, each a solid with a profile swept along a path. The structural analysis view is the engineer's idealisation of it: IfcStructuralPointConnection for nodes, IfcStructuralCurveMember and IfcStructuralSurfaceMember for the members and plates, with supports, releases, load cases and loads attached.

Elementarium imports the analysis view. A file that holds only the physical model is recognised and refused with a plain message rather than imported as an empty project. Deriving analysis members from solids is a decision about where the axis of a member is and which members connect, which is an engineering decision; it is not one the importer makes silently on your behalf.

Importing a file

File › Import › IFC model… reads the file, then shows what it found before anything changes: the project type it will become (2D or 3D, frame, truss or general), the counts of nodes, members, plates, load cases and loads, and a warning for everything it could not map. Nothing is written until you confirm.

The import replaces the content of the current project, in one undoable step. The project itself, its URL and the people it is shared with stay, the same contract as SAF and .elproj. To keep the current model as well, create a new project first.

What comes in

A file meshed by its exporter, with one point connection per mesh corner, comes in as one plate, not hundreds: coincident connections merge, faces belonging to one surface member are merged back into a single outline, and the mesh is made again here.

Catalogue names are hints

A profile named IPE 300 or a material named S355 is matched against the library, but the name is never the whole answer:

• a profile is taken from the catalogue only when every dimension the file states agrees with the catalogue's to 1 %; otherwise the file's own dimensions are used and the mismatch is reported;
• a material is taken from the catalogue only when the file's E agrees to 5 %. An E so low it can only be a unit slip (below 10 MPa) is reported, and the catalogue grade used.

Where the file states nothing usable, the importer substitutes a default (IPE 200, S235) and says so in the warnings. Read them before you solve.

Units

The units are the file's own, read from the project's unit assignment, with SI prefixes, conversion-based units (inch, foot, pound-force, kip, ksi) and derived units. A file in kN and m that never declares a line-force unit is read with line loads in kN/m, composed from the base units it does declare, which is what every exporter we have seen assumes. Your project's display units are a separate setting and are not changed by the import; see Units.

Tolerated, and reported

Real exporters write files that are not quite valid, and the importer reads them anyway rather than failing on the first irregularity:

Exporting a model

File › Export › IFC structural model… shows the counts it will write and lists anything that cannot be carried before writing the file. The output is an IFC4 ADD2 TC1 structural analysis view in SI units, checked against IfcOpenShell.

Everything the model holds

Every feature the app models survives an IFC round trip. Where standard IFC has a word for it, it is written in standard IFC, so any program that reads the analysis view gets it: nodes, supports and springs, members with their axes, releases and eccentricities, plates and openings, line supports, rigid arms, groups, materials with their strengths, sections, load groups, cases and combinations, and every load type, including plate edge loads and graded surface loads.

What IFC has no word for travels in an Elementarium extension: one property set on the project, named Elementarium_* rather than Pset_* (which buildingSMART reserves), holding load panels, wind and snow generators, masses, analysis setups, design checks, exact section and material records, combination definitions and project settings. Another program ignores it and still gets the physics: a load panel arrives as the member loads it produces, and self-weight on selected members as explicit loads. When the file comes back to Elementarium, the extension restores the originals.

Drawings, comments, result probes and report configuration are not model data and are not written. The project file carries those.

GlobalIds stay put

Every entity imported from IFC remembers the GlobalId it arrived with, through edits and renames, and the export writes it back. The dialog says how many entities keep theirs. An entity created here gets a GlobalId derived from the project and its own id, so exporting the same model twice produces the same file, byte for byte, which keeps a diff between two issues meaningful.

IFC, SAF or the project file

The road overpass example was written outside the studio as an IFC4 structural file and brought in through this importer, and it is a reasonable first file to inspect if you want to see what a clean import looks like.