Solar Analysis via Flux
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 methodology by eliminate Rhynamo and replacing it with Flux:
Step 1: Setup Flux
- Set up/sign into your Flux account.
- Create a new blank project.
4. 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.
5. Add the name and description as required. We need to create 10 keys in total:
- Meshed floors;
- Meshed walls;
- Meshed groups;
- Combined universal mesh;
- Room crvs;
- Room numbers; and
- SEPP65 compliance.
These keys can be created in each individual 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.
2. Simplify the context geometry for export. The easiest way to do this is to setup 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 that the context model be as clean and minimal as possible to minimise computational time later in the workflow.
3. From this view, duplicate and create 3 separate views isolating different elements – walls, floors and groups (internal walls).
Revit walls to be exported
Revit floors to be exported
Revit groups (internal walls) to be exported
4. 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’ in order to pick from 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 simply extract all the geometry in the view, so there is no need to manually select elements. You will need to re-run on the 3 views created, each time writing to a different Flux key.
Dynamo script to export context geometry using Flux
5. Open the 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.
Dynamo script to export rooms geometry and room numbers using Flux
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. Simple click the ‘load value’ icon to preview the geometry.
2. 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. In addition, it has a list of faces which are each an ordered list of vertex index points (refer more here).
Grasshopper Mesh definition
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 a much larger file size to store the same sized mesh as the X,Y,Z coordinates of each vertex is repeated many times.
3. 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 size 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 size 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.
Flux universal mesh
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.
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. Having said that, 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. This was because all it was being used for was to export dumb geometry and a simple *dwg export 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.