# General Modelling Practices (IFC+SG)

Source: [CORENET X — General Modelling Practices ↗](https://info.corenet.gov.sg/ifc-sg/modelling---authoring/GeneralModellingPractices)
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):

| Discipline | Storey Name | Z (m) | Purpose |
| --- | --- | --- | --- |
| Architectural | 1st Storey | 3.000 | Architectural floor level |
| MEP | 1st Storey | 3.000 | Architectural floor level |
| Structural | 1st Storey_SFL | 2.950 | Structural slab underside level |

- 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:

| Case | Rule | Examples |
| --- | --- | --- |
| **N.A.** | No SubType required; fill "N.A." or leave blank | IfcWall, IfcColumn, IfcPile, IfcBeam |
| **Predefined** | Use value(s) listed in the Mapping File (no `*`) | IfcSpace→SPACE, IfcDoor→DOOR/GATE, IfcPile→FLOOR/LANDING, IfcAirTerminal→GRILLE, IfcDistributionChamberElement→INSPECTIONCHAMBER |
| **USERDEFINED** | Indicated by `*` in the Mapping File: set SubType = `USERDEFINED` and provide the actual value | IfcSpace→AREA_GFA, IfcDoor→BLASTDOOR, IfcAlarm→FIREALAMPANEL, IfcCivilElement→GUTTER, IfcPipeFitting→DRAINCHANNELBEND |

- **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)_

| Resource | Role |
| --- | --- |
| **Industry Mapping File (.xlsx)** | **HOW** IFC+SG data is structured/populated — components ↔ IFC entities ↔ property sets/names/data types. Used during authoring, data population, QA |
| **Code of Practice (COP)** | **WHAT** is required for each gateway and agency — submission requirements, modelling expectations, required data/documents |
| **Glossary of Identified Components** | Find components fast — definitions, IFC representation, required properties, examples |

**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:**

| Gateway | Modelling guidance |
| --- | --- |
| **DG** (Design) | Design intent only; simplified geometry; only elements required for submission; avoid detailed modelling |
| **PG** (Piling, if applicable) | Foundation + piling elements only; simple geometry focused on scope; exclude unrelated elements |
| **CG** (Construction) | Buildable elements required for submission; detail only where required; avoid fabrication-level / as-built 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):**

| Pipe diameter / width | Result |
| --- | --- |
| ≤ 100 mm | **Pass** |
| > 100 mm and ≤ 200 mm | **Alert** |
| ≥ 200 mm | **Fail** (not allowed) |

- 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)

| Rule | Value | Source |
| --- | --- | --- |
| IFC file size | ≤ 800 MB per file (recommended) | filesize.png |
| IfcSite per file | exactly 1; block name in IfcSite.Name | blockmechanismarchi.png |
| Horizontal CRS | SVY21 (Easting/Northing) | projectcoordinates.png |
| Vertical datum | SHD | projectcoordinates.png |
| Orientation | True North alignment | projectcoordinates.png |
| GUID | unique per element across all submitted models | uniqueguid.png |
| Storey naming | same name + Z across disciplines; `_SFL`-style suffix only at different elevation | level-naming.png |
| Pipe-through-beam | ≤100 pass · 100–200 alert · ≥200 fail (mm) | clashcheck.png |
| Gridlines | exported and associated to every required storey | exportgridlines.png |
| SubType | N.A. / predefined (no `*`) / USERDEFINED (starred in mapping) | predefined.png |