/parametric-modeling

title: Parametric Modeling
description: Parametric design methodology, data structures, constraint systems, Grasshopper and Dynamo patterns, parameter space exploration, and associative geometry for AEC computational design
version: 1.0.0
tags: [parametric, grasshopper, dynamo, data-trees, constraints, associative-geometry]
auto_activate: true
user_invocable: true
invocation: /parametric-modeling

Parametric Modeling for AEC Computational Design

This skill provides a complete reference for parametric design methodology as applied to architecture, engineering, and construction. It covers the intellectual framework, data structures, constraint logic, tool-specific taxonomies for Grasshopper and Dynamo, associative geometry patterns, and professional best practices.

---

1. Parametric Thinking Methodology

1.1 What Makes Design Parametric vs. Static

A static design is a fixed artifact — a single geometric configuration with hard-coded dimensions. Changing one element requires manually adjusting every dependent element. A parametric design is a system of relationships: a directed graph of inputs, transformations, and outputs where modifying any input propagates changes through the entire dependency chain automatically.

The distinction is not merely about sliders. Parametric thinking means encoding **design intent** rather than design outcome. The designer authors a set of rules that describe a family of possible designs, not a single instance.

**Key characteristics of parametric models:**

• **Dependency awareness** — Every element knows what it depends on and what depends on it.
• **Reversibility** — Changes propagate backward and forward through the logic chain without loss of intent.
• **Multiplicity** — A single definition produces an infinite set of valid design instances within the parameter space.
• **Traceability** — Every output can be traced back through the logic to its originating inputs.

1.2 The Input-Logic-Output Paradigm

Every parametric definition follows a three-stage pipeline:

INPUTS              LOGIC                    OUTPUTS
───────────────     ─────────────────────    ──────────────────
Parameters          Transformations          Geometry
 - Sliders          - Mathematical ops       - Points, Curves
 - Toggles          - Geometric ops          - Surfaces, Solids
 - Points           - Conditional branching  - Meshes
 - Geometry refs    - Data restructuring     - Data (areas, etc.)
 - Data files       - Constraint solving     - Text, Reports
 - User text        - Optimization loops     - Fabrication data

**Inputs** define the design space. They must be carefully named, ranged, and organized so that every combination within the parameter space produces a valid (even if suboptimal) output.

**Logic** is the design intelligence — the rules, relationships, and transformations that encode the designer's intent. This is where computational design expertise lives.

**Outputs** are the artifacts consumed by downstream workflows: visualization, analysis, documentation, fabrication.

1.3 Design Intent Encoding

The most critical skill in parametric modeling is translating design intent into computable relationships. This requires decomposing design decisions into:

1. **What is fixed** — Constraints that never change (site boundary, structural grid module, code-mandated setbacks). 2. **What varies** — Parameters the designer wants to explore (floor-to-floor height, facade panel density, roof curvature). 3. **What is derived** — Values calculated from other values (total floor area from footprint and floor count, structural member depth from span length). 4. **What is conditional** — Logic that switches behavior based on thresholds (if panel area > 2 m², subdivide; if slope > 15%, add retaining wall).

1.4 Parameter Identification: Independent vs. Dependent Variables

**Independent variables** are the inputs the designer directly controls. They are the sliders, number inputs, point positions, and toggle switches at the top of the dependency graph. They have no upstream dependencies.

**Dependent variables** are computed from independent variables through the logic chain. They cannot be directly set — only influenced by changing their upstream inputs.

**Intermediate variables** sit between inputs and outputs. They are dependent on upstream inputs but serve as inputs to downstream logic. Identifying these is critical for modular definition design.

**Rules for parameter identification:**

• Start with the design question: "What do I want to explore?"
• List every dimension, proportion, count, and configuration option.
• Classify each as independent (I control it), dependent (it is calculated), or fixed (it never changes).
• Establish the direction of dependency: which parameters drive which.
• Identify feedback loops (rare but possible in optimization workflows).

1.5 Constraint Hierarchies

Not all constraints are equal. Parametric models encode a hierarchy of constraint strength:

| Priority | Constraint Type | Example | Behavior | |----------|----------------|---------|----------| | 1 (Highest) | Legal/Code | Setback lines, FAR limits | Hard boundary, never violated | | 2 | Structural | Maximum span, minimum depth | Hard boundary with safety factor | | 3 | Functional | Minimum room area, corridor width | Soft boundary, can flex slightly | | 4 | Environmental | Solar access, wind comfort | Optimization target, not hard limit | | 5 | Aesthetic | Proportional ratios, rhythm | Preference, fully negotiable | | 6 (Lowest) | Exploratory | Novel geometries, experiments | No constraint, free exploration |

Constraint hierarchies determine what happens when parameters conflict: higher-priority constraints override lower-priority ones.

1.6 Associative vs. Explicit Modeling

**Explicit modeling** defines geometry by its absolute coordinates and dimensions. A wall is a box at position (0,0,0) with width 6m, height 3m, thickness 0.2m.

**As