Placing 20 cottages on a complex, forested slope to maximize solar gain while minimizing earthworks is a multi-variable optimization problem that exceeds human cognitive capacity. Manual placement would likely result in compromised solar access for some units or excessive excavation costs. To address this, the thesis employs Computational Design using Dynamo (visual programming) linked to Revit. This shifts the role of the architect from "placing objects" to "defining rules".  

The computational approach allows for the rapid exploration of hundreds of layout iterations. Instead of manually moving a cottage and checking its elevation, the script places all units simultaneously based on the underlying logic. This ensures that the final layout is not just "aesthetically pleasing" but mathematically optimized for the site's specific constraints.

Objective: To move from manual site planning to algorithmic design automation, ensuring the placement of the 20 residential units is optimized according to strictly defined environmental and spatial constraints.

The Shift to Algorithmic Design 

With the site topology accurately mapped and optimized in Chapter 2, the project advances from data acquisition to Generative Design. In traditional master planning, the placement of building units is often a subjective process, relying heavily on the designer's intuition. However, for a high-performance "Eco-Village" located in the severe climatic conditions, subjective placement is insufficient. To ensure that every single dwelling achieves maximum passive solar gain while respecting the strict topographical limitations of the site, a Computational Design methodology can be adopted. By utilizing visual programming (Dynamo), we transform the design intent into a set of executable algorithms. This approach shifts the role of the architect from a "creator of geometry" to a "creator of logic," allowing the software to process conflicting constraints—slope, orientation, and proximity—simultaneously to derive a mathematically optimized layout.

3.1 Computational Logic & Constraint Definition

Theoretical Basis: Bioclimatic Form Generation 

The morphological development of the Eco-Village is grounded in the bioclimatic principles established by Givoni (1998, Climate Considerations in Building and Urban Design. Van Nostrand Reinhold.), particularly regarding architectural response to severe cold climates. Givoni argues that in heating-dominated regions, the primary design objective must be the reduction of the building’s thermal exposure through a minimized "Surface-to-Volume" ratio ((S/V) ratio measures a building's compactness, representing the ratio of its external surface area (envelope) to its internal volume, crucial for energy efficiency), strictly balanced against the potential for passive solar gain. This theoretical framework validates the generative logic applied to the massing algorithm: the cottage geometry is constrained to a compact volume to reduce conductive heat loss, while the orientation is locked to the solar window to maximize radiant gain, effectively operationalizing Givoni’s passive heating strategies within a modern computational workflow. 

Focus: Translating qualitative design requirements into quantitative algorithmic rules for computational processing.

From Philosophy to Syntax 

Before generating geometry, the "syntax" of the site must be defined first. In a manual workflow, an architect looks at a site plan and intuitively spots a "good location." In a computational workflow, this intuition must be hard-coded into a script. Utilizing Dynamo (Visual Programming) to act as the logic engine is the automated way. The script requires strict input parameters to filter the thousands of potential coordinate points on the site down to the optimal twenty locations. This phase defines the mathematical boundaries that the Generative Design algorithm must obey.

Tools:

• Autodesk Revit: Host environment for the site model.

• Dynamo: Visual programming interface for rule definitions.

• Python Script: Used within Dynamo for complex loop calculations (e.g., proximity iteration).

Concept: Before engaging software, we define the "rules of engagement" for the algorithm. These constraints ensure the generated layout meets project parameters.

Defined Algorithmic Constraints: To ensure the placement of the 20 cottages aligns with the project's ecological and spatial goals, three primary algorithmic filters can be established:

• Solar Vector Analysis (The Energy Constraint)

  • Objective: Maximize passive heating/cooling efficiency.

  • Logic: The algorithm analyzes the vector direction of the site topography. I define a "Solar Vector" representing the optimal South facing direction (Azimuth 180°). The script calculates the angle between this Solar Vector and the Surface.Normal (the direction the ground faces) at every potential point.

  • Rule: Strict Azimuth Compliance. The script filters for an allowable deviation of only -8°/ +10° (Targeting the 172°--190° range defined in Chapter 2.4.2). If the topography forces a rotation outside this narrow window, the point is discarded. This ensures cottages are only placed where the land naturally aligns with the calculated "Solar Income" requirements.

• Slope Gradient Filtering (The Topography Constraint)

  • Objective: Minimized earthworks (Cut/Fill) and foundation complexity.

  • Logic: Utilizing the Digital Terrain Model (DTM) generated in Chapter 2, the script queries the slope percentage at 1-meter grid intervals.

  • Rule: The algorithm acts as a filter, accepting only points where the slope gradient falls between 2% (minimum drainage) and 12% (maximum accessible ramp). Steep zones >12% are automatically designated as "Non-Buildable / Vegetation Zones."

• Radial Proximity & Privacy (The Spatial Constraint)

  • Objective: Fire safety compliance and Japandi spatial philosophy (interstitial space).

  • Logic: This constraint uses a "Circle Packing" logic. Each potential cottage center point is assigned a proximity radius.

  • Rule: A minimum radial buffer of 10.0 meters is enforced between unit centroids. While the Russian Fire Safety Code (SP 4.13130) allows for tighter grouping based on timber class, the distance was increased to 10.0m to prioritize acoustic privacy and visual seclusion in alignment with the Eco-Village ethos. The Python script runs an iterative collision check; if a new unit violates this 10m buffer, it is automatically relocated or deleted. The Python script runs an iteration check: if a new unit's buffer intersects with an existing unit's buffer, the new unit is moved or deleted. This mathematically guarantees that density never compromises privacy.

Data Output:

• Constraint Parameter Matrix [.xlsx or PDF table defining the ruleset]

3.2 The Dynamo Script (Automated Placement)

The placement logic is governed by three strict environmental and spatial constraints that the script must satisfy:The Solar Vector (Energy Constraint): In the Siberian winter, passive solar gain is vital. Cottages must be oriented within ±15C of True South. The algorithm analyzes the surface normal of the terrain; if a slope faces North, it is deemed "Unbuildable" for habitation but suitable for buffer vegetation or access roads. This constraint directly impacts the energy efficiency of the units.The Slope Gradient (Topography Constraint): To minimize the cost and complexity of the reinforced concrete foundations, cottages cannot be placed on slopes greater than 12%. The Dynamo script queries the Civil 3D DTM at 1-meter intervals and filters out steep zones, ensuring that the "Japandi" cottages sit lightly on the land rather than requiring massive retaining walls. The "Circle Packing" (Privacy Constraint): To maintain the Japandi philosophy of "Ma" (negative space) and ensure fire safety between timber structures (+distance increase for privacy), a radial buffer of 10.0 meters is enforced around each unit. The script uses a circle-packing algorithm to maximize density without violating this privacy buffer.

Focus: The technical execution of the placement algorithm within the BIM authoring environment, utilizing the terrain data from Chapter 2.

From Static Rules to Dynamic Execution 

Defining the constraints is only the theoretical first step; the practical application requires an engine capable of processing these rules against the complex site topology. To achieve this, we utilize Dynamo, a visual programming interface integrated within Revit. This tool acts as the bridge between the raw data (terrain, climate vectors) and the architectural geometry. By converting the logic defined in Section 3.1 into a visual script, we move away from "hard-coded" design solutions to a parametric workflow. The strength of this approach lies in its adaptability: while the current parameters are set for specific solar angles and slope tolerances, the script itself is agnostic. It can be instantly recalibrated for different latitudes or site conditions, making this a transferable digital asset for rapid housing deployment in any non-standard or harsh environment.

Tools:

• Host Software: Autodesk Revit.

• Visual Programming: Dynamo (integrated within Revit).

• Input Data: The geo-referenced IFC terrain model generated in SierraSoft/Civil 3D (from Section 2.3).

Process:

• Inputs & Geometry Capture: The Dynamo script first selects the imported IFC terrain surface element within Revit.

• Point Generation & Filtering: The script generates a grid of potential placement points across the site boundary. It then filters these points, removing any that violate the "Topographical Constraint Rule" (slopes >12%).

• Family Deployment: The script selects the pre-modeled "Cottage_TypeA.rfa" family.

• Vector Alignment: An algorithmic loop places a family instance at each filtered valid point. Crucially, the rotation of each instance is not arbitrary; it is strictly governed by the Solar Orientation Rule defined in Section 2.4.2. The script restricts the Azimuth rotation to the optimal range of 172° to 190° (True South ±9°), ensuring that every placed cottage maximizes passive solar gain for the Vladivostok winter.

• Collision Check (Iterative Loop): The script runs a geometry intersection test. If two placed instances violate the 10.0m "Proximity Tolerance Rule," one is deleted, and the script re-runs until all conditions are met for 20 units.

Data Output:

• Visual Programme Script [.dyn]

• Revit Project Model populated with 20 generic cottage instances [.rvt]

Post-Algorithmic Refinement: The Human-in-the-Loop While the Dynamo logic successfully generated a valid topological distribution (Figure 3.2.B), the resulting raw output required qualitative architectural refinement. Algorithms excel at satisfying hard constraints (Solar Physics, Terrain Grades), but they often struggle with soft parameters such as "sense of seclusion" or "neighbourly privacy."

The Optimization Strategy

Consequently, a manual "Post-Processing" phase was enacted.

• What Changed (Location): The X and Y planar coordinates of specific units were manually adjusted. The objective was to increase the interstitial "breathing space" between clusters beyond the script's rigid 10m safety buffer, breaking the artificial uniformity of the grid to create a more organic, "Village-like" composition.

• What Remained Fixed (Orientation): Crucially, this manual intervention operated under a strict non-negotiable rule. While the position of the units was adjusted for spatial comfort, the rotation (Azimuth) remained strictly locked to the climatic constraints defined in Chapter 2.4.

  • Solar Gain: Entrances and glazing remained locked to the South (172° to 190°).

  • Wind Defense: The defensive rear facades remained oriented to the North-East to deflect prevailing Siberian winds.

Conclusion

This multi-staged approach confirms that the generative workflow serves as a powerful optimization baseline—quickly solving complex density and connectivity problems—rather than a final dictator. The computational model provided the structure; the architect provided the sensibility. The final outcome is a curated environment where rigorous performance optimization is seamlessly merged with subjective spatial quality.

3.3 Data-Driven Verification

Objective: To validate the placement, a Python script (using the Pandas library) can be embedded within Dynamo to export the final coordinates and elevations of the 20 units to Excel. This "Feasibility Report" includes a "Delta Elevation Analysis" to verify if a single municipal water pump can service the vertical spread of the village, bridging the gap between architectural layout and civil engineering infrastructure.

Focus: Extracting factual data from the generated model to validate construction feasibility outside the BIM environment.

From Geometry to Tables: The Objective Validation 

While Chapter 3.2 generated the visual layout, relying solely on a visual "looks good" check is a critical vulnerability. In complex topography, the human eye cannot detect if a cottage is 50mm over the property line or if the elevation difference between the first and last unit exceeds the capacity of a standard water pump. To validate the design, the workflow must bypass the graphical interface to query the database directly. By utilizing Python, the raw numerical DNA of the project can be extracted to mathematically prove that the proposed layout is buildable and strictly adheres to the site's engineering limits. This step bridges the gap between Architectural Design (Geometry) and Civil Engineering (Physics).

Tools:

• Execution: Revit Python Shell (for direct API access) or Dynamo Python Node.

• Library: Pandas (Python Data Analysis Library) for high-performance data structuring - – Used for creating high-performance, in-memory data tables that allow for complex relational math (comparing Unit A vs. Unit B).

• Library: XlsxWriter for writing formatted Excel reports - Used to programmatically generate Excel files with automated conditional formatting (e.g., turning cells red if a value fails a test).

Process:

1. API Interrogation (Data Extraction - Mining):

Using the Revit API (Application Programming Interface), the Python script acts as a "miner," digging through the model database. It iterates through the entire document to collect all placed instances of the generic model Family: Cottage_Concept.

• The Difference: Unlike a standard Revit Schedule, which is limited to displaying pre-defined parameters (like "Level" or "Type Mark"), the API script extracts derived geometry data. For example, it retrieves the exact Global XYZ coordinates relative to the Survey Point, a value that does not exist as a simple parameter in a standard schedule.

• Code Logic: FilteredElementCollector (Find all items...) --> OfCategory(OST_GenericModel) (...that are generic models) --> Get_Location (...and tell me exactly where they are in 3D space).

2. Analytical Structuring (The Virtual Spreadsheet): 

The mined data is passed into a Pandas DataFrame. Think of a DataFrame as a "virtual spreadsheet" that exists only in the computer's memory. Unlike Revit schedules, which list items individually, Pandas allows for comparative analysis across the entire dataset.

• Hydrostatic Analysis: The script identifies the cottage at the lowest elevation (Zmin) and the highest elevation (Zmax). It calculates the vertical head differential (DeltaH = Zmax - Zmin) to verify if a single municipal water pump can service the entire village without requiring booster stations.

Why this matters: If DeltaH > 40m (approx. 4 bars of pressure), the village would require expensive booster pumps. This analysis flags that cost risk instantly.

• Coordinate Validation: It converts the internal Revit coordinates to Geo-referenced Northing/Easting values to ensure no unit falls outside the legal property boundary lines.

3. Serialization (Intelligent Reporting):
The validated dataframe is serialized and exported as a .xlsx file. This is not a dumb data dump; using XlsxWriter, the script conditionally formats cells (e.g., highlighting coordinates in Red if they exceed the site boundary) before sending the file to the Civil Engineering team.

Data Output:

• Verification Script [.py]: The reproducible code block used for auditing.

• Feasibility Report [.xlsx]: A strictly formatted Excel register containing:

  • Unique Element IDs: For tracking back to the model.

  • Northing / Easting / Elevation: Precise data for surveyors.

  • Delta Elevation Analysis: Critical data for MEP engineers sizing the infrastructure.