Workflow (3 units)

Before opening Dynamo:

This is the family I chose for the tower form (since I made my custom tower in Rhino/Grasshopper last week, I used a premade parametric tower from the 220C drive). This is the circular flying chevron, and the family looks like this (original family on the left, optimized tower form on the right):

I constrained some of the family’s parameters to get the structure to behave the way I wanted: namely I changed the rotation of all the levels so that they are all the same. This is because I love the look of the building opening up like a 3 dimensional Pac-man, so I didn’t want any of the levels to twist relative to each other.

I also went to Google Earth and found the project site, and based on the project site, made some conceptual masses to represent the buildings nearby.

I also, of course, set the project location to San Francisco and changed the direction of true north relative to the project orientation to make sure the solar analyses would run properly.

In Dynamo:

A high level overview of my script:

I made a couple of different new evaluators — one for spatial metrics and energy usage, one for economic analysis, one for solar insolation, and one for directness of view of the ‘open’ side of the building. As such, I have 4 separate control panels for the evaluators and a 5th control panel for the weighting factors for the optimization scheme.

I used the same Cartesian product, etc. workflow needed to generate the pairs of parameters for each test case. The two parameters I varied were mid depth and tower rotation — I wanted to see what would produce the best use of space, and what the best direction would be for the tower to face. I really wanted to use rotation as one of the test parameters because of how directional the tower form was. I varied mid depth from 160 to 190 ft in 10 ft increments, and varied the rotation from 0 to 270 degrees in 45 degree increments.

All of these inputs feed into a mega node that I created, which contains all the custom nodes for each of the evaluators.

If we crack open this massive node, it looks like this:

On the left are the four sets of inputs: one for manipulating the building geometry according to the test cases, one for the directness of sight evaluator, one for solar insolation, and one for the economic analysis.

First, the node unpacks all the pairs of input values and updates the building model:

Then, the updated building model is fed into each evaluator/custom node. The first simply retrieves the typical spatial metrics (areas, volumes) and also uses a site EUI input to calculate the annual energy use of the building. I also created a ‘thermal performance evaluator’ which takes the site EUI and multiplies it by a scaling factor, which is just the surface area of the building divided by the volume. The more surface area, the more thermal exchange that can occur through the envelope, and the greater the building volume, the more resistant it is to envelope heat exchange.

Next, there’s a view evaluator node:

If we crack this open, it looks like this:

It follows essentially the same logic as the directness of view examples in the module videos, but I filtered the wall surfaces to only include the two walls that ‘open up’. This is because I wanted to optimize the building such that the best view would be from the ‘open’ side of the building. I also had to reverse the direction of the normal vectors from the wall panels because, counterintuitively, the vectors pointing outward from the building here are actually inwards pointing vectors.

Next, there’s a solar analysis set up:

I did an insolation analysis of the whole envelope, with consideration of shading surfaces from the surrounding masses. I had 18 different shading surfaces.

Finally, there’s an econ evaluator node, which takes in data regarding construction costs on the lowest and highest floors, rents on the lowest and highest floors, and capitalization rate, and spits out construction costs, development costs, building valuation, net operating income, annual rent income, and so on.

If we crack this node open, it looks like this:

The assumptions I used for the econ calculations were:

Development cost is 1.25x construction cost

Net operating income is gross income from rent *60%

Gross profit from development is valuation (i.e. NOI/caprate*100) - development cost

Ultimately, this mega uber node spits out the results from each of these analyses, and since it outputs like 17 different metrics (because I wanted to retain all my output options) I pick and chose which ones I wanted to pass forward to the optimization scheme evaluator — I chose space efficiency, thermal performance, directness of view, cumulative insolation, and gross profit.

I applied the weighting scheme to them using the combined evaluation score node, which I edited according to my list creation methodology and # of evaluation metrics.

I had to change the column multiplication scheme in the blue code block above from Glenn’s original code block, because I had previously filtered out some of the metrics I did not want to pass through to this node, so not all data lists were the same length.

Finally, I exported all the data to Excel:

Excel:

This is what the exported workbook looks like:

The best tower ended up being the one with a mid depth of 190’ and a rotation of 225 degrees. It’s shown at the very top of this journal entry. I had created a separate function that simply returned whether the building floor area was within the specified 1,200,000 to 1,500,000 sqft or not; you can see the results in column S above. The lines that are in red simply do not meet the floor requirements, so they were filtered out of the optimization scheme.

Welp that’s it. This assignment really put me through the wringer, and I lost a lot of sleep and emotional well being this week. I would highly suggest this be made into a two week assignment instead of a one week one in the next iteration of the class.