Solar Analysis via Flux

Please note that Flux.io shut down on 31 March 2018 and is no longer available. However, this tutorial has been kept for legacy purposes.

In this previous tutorial, it was demonstrated how to undertake a detailed SEPP65 solar access compliance check. The methodology involved using Rhynamo as a means to extract Revit rooms for analysis in Grasshopper and Ladybug. This example offers an alternative method by eliminating Rhynamo and replacing it with Flux:

Step 1: Setup Flux

• Set up/sign in to your Flux account.

• Create a new blank project.

• Select ‘open project’.
• Create ‘keys’. These are geometry/data that will be transferred to/from Flux. Simply hit the plus button in the data table on the left.

• Add the name and description as required. We need to create ten keys in total: 
  • Floors;
  • Walls;
  • Groups;
  • Meshed floors;
  • Meshed walls;
  • Meshed groups;
  • Combined universal mesh;
  • Room crvs;
  • Room numbers; and
  • SEPP65 compliance.

These keys can be created in each application, but it is easier to plan it out first and do it all in one go. The purpose of all of these keys will be elaborated on later.

Step 2: Export Revit rooms and context using Dynamo and Flux

• Currently, Flux doesn’t support breps, so we need to convert the Revit geometry into a mesh. Unfortunately, Dynamo out-of-the-box does not have meshing tools so you’ll need to install the ‘Dynamo Mesh Toolkit’ package by Autodesk. 

• Simplify the context geometry for export. The easiest way to do this is to set up a 3D view within Revit. Using Visibility Graphics (VG) in conjunction with worksets and filters, turn off any unnecessary geometry. Essentially all we require are party walls, floors and roofs. Extraneous geometry such as planting, furniture, doors and mullions can all be hidden. Windows are effectively transparent and therefore, can also be excluded from the analysis. The same also applies to glass balustrades. However, since these are often modelled as a wall, you will need to set up a filter to turn off only the glass balustrade wall types and not all walls. It is critical the context model is as clean as possible to minimise computational time later in the workflow. 
• From this view, duplicate and create three separate views isolating different elements – walls, floors and groups (internal walls).

• Open Part 1 of the Dynamo script. This script exports the context geometry. Due to the file size, the model will be exported in batches – walls, floors and roof. Note that you will need to run the script several times if you have Dynamo set to ‘Manual’ to pick from the menu in the Flux nodes. Otherwise, you’ll need to set Dynamo to ‘Automatic’. Therefore, Flux’s Flow control node does not have much meaning when you are working in Dynamos manual mode. For additional control you can leave the flow control mode in ‘once’, and then after the manual run in Dynamo you can right-click the ‘to Flux’ or ‘from Flux’ components and click ‘push data’ or ‘pull data’.

• The Python script shown below extracts all the geometry in the view, so there is no need to select elements manually. You will need to re-run on the three views created, each time writing to a different Flux key.

• Open Part 2 of the Dynamo script. This script exports the room geometry. The easiest way to do this is to use the LunchBox ‘Room element collector’ node. 

Step 3: Flux refactoring

• In Flux, check that the data has been transferred. For some of the keys, particularly the context and room curves, you might get the following image. Simply click the ‘load value’ icon to preview the geometry.

• If you don’t already have access, go to Flux Labs and sign up for the ‘Dynamo Mesh converter‘. Hopefully, in the future, this will be much more accessible. The reason we need this is that Dynamo meshes have a unique format that will not be recognised by Grasshopper. Therefore, Flux has developed a converter block that turns a Dynamo mesh into a universal mesh that you can view in Flux and send to Grasshopper. Essentially the difference is as follows. Rhino takes the form of a list of vertices (points with X,Y,Z coordinates) which are stored in an ordered list. Also, it has a list of faces which are each an ordered list of vertex index points. 

• Dynamo, on the other hand, creates a similar list of vertices, but then rather than store the faces as a list of index points, it stores them again as a list of vertices with repeated X,Y,Z coordinates. It is unclear why the Dynamo team have chosen this data structure, but obviously, it leads to much larger file size to store the same sized mesh as the X,Y,Z coordinates of each vertex is repeated many times.

• Go to Flow, which is Flux’s visual scripting platform and generate the following code. Hover in column A and pick the add a data node (shortcut ‘D’). Drag the ‘Context mesh’ key to the left-hand side of the data node. In stage A-B, add Flatten and the dynamoMeshEater nodes. (Note that once you have the mesh in Flux and have been invited to use the ‘Dynamo Mesh converter’ block, you will be able to double click in the Flux Flow and search for DynamoMeshEater). In the menu icon on the top right of the dynamo MeshEater node, set the lacing to Longest. In column B, add a data node and drag the ‘Universal mesh’ key to the right-hand side of the node. Repeat this process for the other elements (walls, floors, roofs, etc.).

By going back to the data pane, you should see the preview of the ‘universal mesh’ now.

Step 4: Solar Analysis with Ladybug

• Open a blank Rhino file and then open the Grasshopper Part 3 file. Ensure the Flux components are pointing to the correct Flux project and keys. Once Ladybug has finished running, the list of complying room numbers will be pushed to Flux. Note that if your rooms have internal islands or aren’t clean geometry, you may need to modify the polycurve and planar surface creation nodes to ensure the room surfaces and room number lists match up.

Step 5: Import results into Revit

• In Dynamo, open up the Part 4 file. The script will first ‘reset’ all the rooms to be non-complying, before updating only those rooms imported from Flux.

Conclusion

While in theory Flux appeared to simplify the workflow, the main limitation was the processing of the context geometry. Due to the large file size, the upload process to the Flux website was incredibly slow. However, this tutorial was produced with Flux/Dynamo 0.9.2. According to Flux, the new Flux plug-in for Dynamo 1.0 performs significantly better.

The other issue that I faced was the refactoring process. For example, Flux doesn’t accept polycurves (yet), so the original Grasshopper script that used Rhynamo had to be modified slightly. Similarly having to use the Dynamo Mesh converter is somewhat annoying and in an ideal world, this would be eliminated from the workflow.

In conclusion, for this particular exercise, I don’t believe Flux added much value to the workflow. Since Flux was only used to export dumb geometry, a simple *dwg export from Revit would have been much faster. But in any case, this exercise probably wasn’t the most strategic use for Flux and its potential lies elsewhere.