Designing building-integrated photovoltaics with Energy3D

Fig. 1: An example of solar facade.

Building-integrated photovoltaics (BIPV) represents an innovative way to think and design buildings as both human dwellings and power plants. In BIPV, solar panels or photovoltaic thin films are used to replace conventional constructional materials in parts of the building envelope such as roofs, walls, and even windows. Designing new buildings nowadays increasingly includes BIPV elements to offset operational costs. Existing buildings can also be retrofitted with BIPV (e.g., replacing glass curtain walls with solar panels). BIPV is expected to grow more important in architectural design and building engineering.

Fig. 2: An example of solar curtain walls

We are developing modeling capabilities in Energy3D to support the design, simulation, and analysis of BIPV. Figures 1 and 2 in this article show a few cases that demonstrate these capabilities in their primitive forms. Considering BIPV is relatively new and a lot of research is still under way to develop and test new ideas and technologies, we expect the development of these capabilities in Energy3D will be a long-term effort that will be integrated with latest research and development in the industry.

Fig.3: Power balancing throughout the day.

As the first step towards that long-term vision, the current version of Energy3D has already allowed you to add solar panel racks to any planar surface, being it horizontal, vertical, or slanted. Running a simulation for any day, you will be able to predict the daily output of all the solar panels. You can also compare the outputs of selected arrays. For example, if you want to track down on which side solar panels produce the most at a given time during the day, you can compare them in a graph. Figure 3 shows a comparison of the solar arrays in the model shown in Figure 1. As you can see, the east-facing array produces peak energy in the morning whereas the west-facing array produces peak energy in the afternoon. In this case, the BIPV solution ensures that the photovoltaic system generates some electricity at different times of the day.

Video tutorial: Solarize an imported building in Energy3D

We are pleased to announce that the solar panel and analysis tools in Energy3D (version 6.5.6 or higher) are now fully applicable to arbitrary imported structures. We hope that the new capabilities can help engineers who design rooftop solar systems and building solar facades to get their jobs done more efficiently and students who are interested in engineering to learn the theory and practice in an inquiry-based fashion. The six-minute video in this article demonstrates how easy it is to perform solar panel design and analysis in Energy3D. (Note: Unfortunately, the annotations in the video do not show if you are watching this on a smartphone.)

One of the handiest features is the automatic, real-time detection of the angle of the surface under a solar panel while the user is moving it. This feature basically allows the user to drag and drop a solar panel or a solar panel rack anywhere (on top of roofs, walls, or other surfaces) without having to set its tilt angle manually.

Solar heat map of a house with solar panels

Copy and paste a house with solar panels

Solar panels are "first-class citizens" in Energy3D as they are readily recognized by the built-in simulation engines. Energy3D provides a comprehensive list of properties that you can choose for each solar panel or solar panel array. For example, even the temperature coefficient of Pmax, a parameter that specifies the change of solar cell efficiency with regard to ambient temperature change, is supported. The software also has a variety of analytic tools for predicting the hourly, daily, and annual outputs of each solar panel and their sums. Interactive graphs are available to intuitively show the trends and allow the user to compare the outputs of different solar panels, of different arrays, on different days, or with different environmental settings (e.g., with or without a tree nearby).

These "native" solar panels are now completely blended into the "alien" meshes of structures imported into Energy3D from other CAD software or Google Earth. For example, once you drop a solar panel on a surface of the structure, it will stick to it. In other words, if you move or rotate the structure, the solar panel will go with it as if it were part of the original design. When you copy and paste the entire building, the solar panels will be copied and pasted as well (by the way, it takes only four clicks to copy and paste a building in Energy3D through the pop-up menu: one click to pick which one to act upon, one click to select the "Copy" action, one click to pick where to paste, and one last click to select the "Paste" action). That is to say, the native and alien meshes are completely meshed.

Automatic remeshing in Energy3D for solar analysis

A headache in the practice of simulation-based engineering or computer-aided engineering is the incompatibility of the meshes used to create and render structures (let's call them the drawing meshes) and the meshes needed to simulate and analyze certain functions (let's call them the analysis meshes). This incompatibility stems deeply from the fundamental differences in computer graphics for visual rendering and computer simulation for physics modeling.

When importing a model from a CAD tool into a simulation tool, engineering analysts often have to recreate new analysis meshes for their computation, which requires fine-grained discretization such is in the case of finite element analysis and other methods. It becomes a nightmare when the conversion from the drawing meshes to the analysis meshes can only be done manually. Even if only a few drawing meshes need to be taken care by hand while the majority of the meshes can be converted automatically, the analyst still would have to check all the meshes to make sure that every mesh is good for simulation. So we really need a tool that can deal with all sorts of scenarios. And this kind of tool is by no mean easy to develop.

Mesh incompatibility was (and may remain for a long time) a problem for Energy3D when it imports structure models created by other tools such as SketchUp. For example, in most architectural CAD models, a structural element such as a wall or a roof (or a part of them) is represented by two planar meshes that have exactly opposite normal vectors, representing the interior and exterior surfaces, respectively. These two meshes have identical coordinates for their vertices, though the orders of their definition are different (one goes clockwise and the other anticlockwise in order for their normal vectors to be exactly opposite). Whatever they represent has therefore no thickness, but with the two faces, we can apply two different textures to them so that the viewer can tell if they are looking at its interior or exterior surface.

While this sounds good to people who use such models in 3D games, it spells troubles to Energy3D. The first problem is that it increases the number of vertices that Energy3D has to load and, therefore, the memory footprint of such models. In a physics simulation, a structural element without thickness is meaningless. If we don't really need the two faces in most cases (we do in some other cases, but I will skip that line of discussion in the article), why bother to import them in the first place? Despite spending days on researching on the Internet and checking the Collada specification, I couldn't figure out how to force SketchUp to export only the exterior meshes (SketchUp's Colloda export function does provide the option of exporting two-sided faces or not, but it sometime exports only the interior sides for some meshes, mixed with exterior sides for others). So it occurred to me that I had to deal with them in the Energy3D code.

If we don't treat them and use the meshes as they are, we then have the second problem: which mesh should we pick to be the side that receives solar radiation? While it is self-evident which mesh of the two identical ones faces outside when we look at the 3D model after it is rendered on the computer screen, we absolutely have no way to tell from their coordinates alone in our code. Somehow, we have to invent an algorithm that simulates how people discern it when they look at the 3D view of the model on a computer screen.

Picking and choosing the right meshes, of course, is crucial to the correctness of the simulation results. In order to test the new algorithms in Energy3D, I selected the lower Manhattan island and the US Capitol Building as two test cases. The results of the lower Manhattan island have been reported in an earlier article. But the Capitol Building has turned out to be a harder case as -- with over 15,000 meshes -- it is geometrically more complicated and it has so many details that really put our code to test. After more than a week of my work on solving a myriad of problems, it seems that Energy3D has passed the test (or has it?). The screenshots of the solar irradiance heat maps of the Capitol Building from different angles show that severe anomalies are practically non-existent across the heat maps.


The heat maps occasionally suffer from a flickering effect called "Z-fighting" when two planar surfaces are visually close, especially when being looked at from a distance sufficiently far away. For the Z-fighting between identical meshes, this can be mitigated by increasing the offset of their distance. But, as this doesn't affect the simulation result, it is less a concern for the time being.

Automatic remeshing for solar analysis may also need to include automatic repair of models that contain errors. For example, some models may contain surfaces that have only one mesh with the normal vector pointing inward (this could happen if the original designer accidentally used the "Reverse Faces" feature in SketchUp without realizing that the normal vectors would be flipped). This kind of mesh is tolerated in SketchUp because it does not affect rendering. But they cannot be tolerated in Energy3D because such a single-face mesh with a north-pointing normal vector, which appears to the viewer as south-facing, will show little to zero solar radiation when the sun shines on it. Luckily, due to the visualization in Energy3D, we can quickly spot those incorrect surfaces and fix them by reversing their faces manually. But we will need to find a way to automate this process (not easy, but not impossible).