General Modelling Practices (IFC+SG)

Source: CORENET X — General Modelling Practices ↗ Retrieved 2026-07-10. The page presents 11 practice cards, each backed by a detailed infographic — all transcribed below (source image noted per section). Detail guide pages exist per topic under /ifc-sg-2/modelling---authoring/GeneralModellingPractices/<slug>.

Four practice areas: 01 Model Setup & Structure · 02 Element Modelling & Data · 03 Project Coordinates & Alignment · 04 Model Quality & Coordination

01 · Model Setup & Structure

1.1 Level Naming and Organisation (level-naming.png)

Rule: different physical levels must use different names; names and Z values must be consistent across all disciplines.

Example (same project):

• Structural levels may use a suffix (e.g. _SFL) only when the structural floor level is at a different elevation from the architectural level.
• Good practice: agree naming + Z values at project start; keep consistent across disciplines; coordinate with the same reference model; verify in an IFC viewer.
• Common issues: different names for the same physical level; different Z values for the same level; missing _SFL-type suffix; renaming/re-levelling without coordination.
• Key takeaway: same names + same Z for the same physical level across all disciplines; different names only at different elevations.

1.2 Block Mechanism (architectural models) (blockmechanismarchi.png)

Architecture models are split by blocks. One file = one block.

• Example development → separate architectural files: Block A, Block B, Podium, Basement — each containing only its own elements.
• IFC export (per file): each IFC file has ONLY 1 IfcSite; the block name goes in IfcSite "Name" (e.g. IfcProject → IfcSite (Name: Block A)).
• Site elements (roads, landscape, external works) are modelled in a separate file.
• This breakdown follows industry practice and supports coordination and submission.

02 · Element Modelling & Data

2.1 Use correct IFC entities (correct-ifc-entities.png)

Use CORENET X COP Section 4 + the IFC+SG Excel Mapping File to apply the correct: 1. IFC Entity (what the object is), 2. IFC SubType (if applicable), 3. Property Sets — SGPsets / Psets (what data it must carry).

Examples: Window (Louvers) → IfcWindow / LOUVER / SGPset_Material · Column → IfcColumn / N.A. / SGPset_ColumnReinforcement (e.g. PrefabricatedReinforcementCage) · Pipe → IfcPipeSegment / FLEXIBLESEGMENT / PipeSegmentDimension (e.g. length).

6-step workflow: Identify component → Check COP S4 / Mapping File & Glossary → Assign IFC Entity → Apply IFC SubType (if applicable) → Apply property sets + populate → Validate IFC.

2.2 Predefined Type vs USERDEFINED (predefined.png)

SubType assignment is mapping-driven — three cases:

• Mixed case (e.g. IfcDoor DOOR, GATE, BLASTDOOR, ROLLERSHUTTER): use predefined for standard types (DOOR, GATE); USERDEFINED for the starred ones (BLASTDOOR, ROLLERSHUTTER).
• Common issues: misspelling predefined/USERDEFINED values; spaces in the value; inventing USERDEFINED values not in the mapping guidance.

2.3 When to use COP, Excel Mapping File & Glossary (whentousecopexcelglossary.png)

When to use what (6 steps × primary resource): 1. Understand submission context → COP 2. Check submission requirements → COP 3. Find the component → Glossary 4. Understand IFC representation → Mapping File + Glossary 5. Populate the model with correct data → Mapping File 6. Validate before submission → Mapping File + COP

Worked example: COP confirms "Beam Depth" required at a gateway → Glossary shows the component's IFC entity/pset/property → Mapping File gives exact mapping (IfcBeam, OSPref_BeamDimension, Depth, Length, mm) → populate model → validate against COP.

03 · Project Coordinates & Alignment

3.1 Project Coordinates & Geo-Referencing (projectcoordinates.png)

All models must align to SVY21 (XY), SHD (Z) and real-world orientation (True North).

1. Survey reference: geo-reference with Singapore's national system — SVY21 for horizontal (Easting X, Northing Y), SHD (Singapore Height Datum) for elevation (Z). Use official survey data from the licensed land surveyor.
2. Shared coordinate reference: consistent origin + orientation for all models, based on SVY21 + SHD, oriented to True North.
3. All models aligned: every discipline model uses the same coordinate reference and orientation → correct federation in 3D.

Common issues: not aligned to SVY21; wrong elevation datum (not SHD); discipline misalignment at federation; not oriented to True North; late coordinate changes.

3.2 Ensure models align correctly in federation (federate.png)

Federation = multiple models aligned, NOT merged — models remain separate IFC files, combined for review/coordination.

• Same coordinate system: same origin (0,0,0), orientation, True North, survey reference.
• Spatial structure alignment: same site for all disciplines; same building structure; same storey names and elevations.
• 3-step alignment check: ① pre-check in native software (coordinates, origin, spatial structure) → ② after export in IFC viewer (overlay models, orientation, scale, storey alignment, no unexpected offsets) → ③ during submission on the portal (upload each discipline IFC, review alignment in portal viewer, confirm).

04 · Model Quality & Coordination

4.1 Maintain unique GUIDs across models (uniqueguid.png)

Each IFC element (and each storey) must have a unique GUID for identification, tracking and comparison across models and submissions.

• Duplicate GUIDs occur when model files or elements are reused incorrectly — e.g. duplicating a completed model file as a new project/block file. (Repeated or similar elements are fine; identical GUIDs are not.)
• Good practice: don't duplicate completed model files as new block files; follow the Authoring Tools workflow for preset elements/templates; check for duplicate GUIDs before submission.
• The same GUID appearing in two model files causes tracking/comparison issues.

4.2 Manage file size for performance (filesize.png)

Recommended: ≤ 800 MB per IFC file. Over-modelling increases file size without improving submission outcome.

• Good practice: split models by block/zone/discipline; avoid merging multiple buildings into one file; keep geometry simple; remove unused elements before export.
• Model to the gateway's required detail:

4.3 Model coordination & clash detection (clashcheck.png)

Clash detection in CORENET X is rule-based, not just geometry-based. Clash ≠ always fail — determine action: Resolve / Accept / Alert.

• Certain clashes are not allowed (e.g. architectural door intersecting structural beam = design clash, must not occur).
• Some clashes are conditionally allowed (e.g. MEP penetrations within limits) — acceptance depends on element type and size.
• MEP pipe vs structural beam rule (coordination matrix):

• The CORENET X coordination matrix crosses Architectural (wall/ceiling/door/window) × Structural (column/foundation/framing/wall/slab) × MEP (mech. equipment, ducts, air terminals, pipes, plumbing fixtures) with pass/alert/fail cells.
• How to apply: run clash detection on coordinated IFC models → review against the matrix → resolve / accept / escalate per submission rules. Not all clashes are failures — assess by element type, size, coordination rules.

4.4 Export gridlines to IFC (exportgridlines.png)

Export gridlines to EVERY required storey so IFC grids appear in viewers and submission platforms.

4-step workflow: ① create proper gridlines in the authoring tool (consistent naming) → ② associate gridlines to storeys (extend across levels; all required levels included) → ③ export IFC with grid export enabled (verify export configuration) → ④ check gridlines in an IFC viewer (multiple levels, before submission).

Common mistakes: gridlines exported only at one level; hidden in export view; missing storey association; wrong IFC export settings; grids visible in BIM tool but missing in IFC.

Machine-checkable rules extracted (for the checker)