Protocol for documenting a computational design study

1. Research question and domain

State the question that motivates the exploration before generating a large population. Identify the geometric family, the variables that may change, and the conditions that remain fixed. Separate measurable objectives from criteria requiring qualitative assessment.

An example question is how the rise and subdivision of an arched truss affect recorded member quantities while preserving a specified spatial character. This is an illustrative study design, not a reported experiment or a supplied benchmark dataset.

2. Model and evaluation assumptions

Verify the definition before using it for a batch of alternatives. A complete save-and-view cycle should demonstrate that each ID is associated with the intended geometry, numerical outcomes and images.

Interpret a numerical trend only within those assumptions. A correlation between parameters in a generated sample does not establish a causal relationship or validate the design.

3. Generation and selection record

For each run, preserve the settings and the population available at the time of selection. A useful record includes the connected project, iteration limit, mutation probability, spread factor, parent IDs and the exact filter expression.

3.1. Selection semantics

TOP and BOTTOM rank the connected project by highest and lowest values respectively. A combined condition intersects that ranked set with other criteria; it does not first redefine the ranking population. Record the objective direction so the meaning of a ranking is unambiguous.

3.2. Qualitative rationale

When parents are selected by visual inspection, record why those alternatives were retained. Examples include spatial organization, proportion or compatibility with a design intention. Preserve the associated IDs and views rather than relying on an informal recollection.

3.3. Unsuccessful selection

Distinguish a valid rule with no matching parents from an invalid expression. The former falls back to random generation; the latter stops generation. Check the Parents output and component messages, and document the actual behavior observed.

4. Analysis and presentation

For every exported figure, record the dataset, displayed subset, plotted parameters, units and objective directions. Describe the filtering conditions and distinguish the complete saved population from a selected subset.

• Image gallery: state which view and numerical captions are shown.
• Scatter plot: identify both or all three axes and explain the direction of desirable performance.
• Parallel coordinates: identify axis ranges, color encoding and active brush selections.
• Shortlist: list the actual solution IDs and provide the selection rationale.

If a Pareto analysis is performed outside Morpho, document that calculation, the objective set and its directions. The current viewer does not calculate the non-dominated set automatically.

5. Data preservation and repeatability

Preserve the complete project directory and the Grasshopper definition. The local database, generated CSV and associated media serve different roles and should remain together.

study-archive/
  definition.gh                Parametric model
  study-record.txt             Settings, assumptions and decisions
  project/                     Complete Morpho output folder
    solutions.db               Saved population
    solutions.csv              Generated tabular export
    solutions.csv.bak          Previous CSV copy, when present
    …                          Tagged image and text folders
  figures/                     Exported plots with captions

Suggested archive organization; the top-level folder names are not a prescribed Morpho directory structure. Keep the actual project contents intact.

The CSV is regenerated after a save, so manual edits may be replaced. A previous CSV copy is not a backup of the full study. If the input parameter structure changes, use a new project name and record the relationship to the earlier study.

Random generation means that identical settings alone should not be assumed to reproduce identical alternatives. Report the actual saved population, dependency versions and the limits of repeatability.

6. Study-record template

The plain-text template below can accompany a project archive. It is a documentation aid and does not modify the software or execute a study.

Download the study-record template [TXT] ↓

MORPHO COMPUTATIONAL STUDY RECORD

Study title:
Researcher(s):
Date(s):
Research question:

1. SOFTWARE AND MODEL
Morpho version:
Rhino / Grasshopper version:
Operating system:
Definition filename and revision:
Analysis dependencies and versions:

2. DESIGN DOMAIN
Input names, units, bounds and precision:
Fixed assumptions and excluded configurations:
Outputs, units and objective directions:
Boundary conditions and feasibility checks:
Treatment of missing or failed evaluations:

3. RUN RECORD (repeat for each run)
Run identifier and date:
Connected project:
Iteration limit:
Mutation probability:
Spread factor:
Parent IDs / exact filter expression:
Eligible IDs observed in Parents output:
New solution IDs recorded:
Warnings or interrupted evaluations:
Qualitative selection rationale:
Reason for continuing or stopping:

4. FIGURES AND INTERPRETATION
Dataset and subset:
Axes, units and objective directions:
Filter / brush / color settings:
Selected solution IDs:
Observations:
Interpretation and limitations:
External analyses, if performed:

5. ARCHIVE
Definition and dependency locations:
Complete project folder location:
Image and text-file associations checked:
Backup location:
References and attribution:

For installation and component connections, see the implementation protocol. For citations, use the published research and manual records, and state the software versions actually used in the study.