Output Geometry of Simulated PV Surfaces on Djordje's PV Components

[chriswmackey]

@stgeorges ,

I have been applying your components to a project today and they are really awesome. It's so great to finally be able to account for all of these different coefficients within PV design. However, I have found it a bit confusing how the PVSurface and the TiltAngle / Azimuth Angle interact when you plug in values for both at the same time. I assume that the PVSurface is supposed to represent a roof or ground surface and not plugging in any value for tiltAngle assumes that all PVs are aligned and parallel with this surface (so no PV self-shading). Plugging in an additional value for PVsurfaceTiltAngle is assuming that the PV's are rotated off of this original surface such that they then self-shade each other.

If I am correct in this understanding and that this self-shading is being accounted for in the component, could we get a visual of some self-shaded PV surfaces coming out of the Photovoltaics Surface component so that users are aware of what they are simulating?

If it seems difficult, I can help you write it so that it works for curved and non-curved PVsurfaces. Speaking of this, does your component account for curved surfaces if one is input?

Finally, you should really change the PVSurface input to be a list since I imagine that there a lot of people are going to want to plug in arrays with multiple surfaces and get a single number out. This will also make it easy to write something so that people can plug in polysurfaces and the component will automatically deconstruct it into individual faces (I had to do this for the Shade Benefit components and this is very easy).

Let me know your thoughts on this and if you would like my help.

-Chris

[chriswmackey]

@stgeorges ,

I just realized that the component is not accounting for any self-shading. In this sense, I find it VERY misleading to have separate inputs for the PVSurface and its altitude/azimuth. Now that I understand this, it would be much better is there was only the input for the PVSurface and I really don't understand the point of having inputs for the altitude/azimuth inputs (it's not just redundant but also misleading). Are you imagining that some users will be too lazy to draw a surface and rotate it? Or set up a 3-component parametric model to run whatever angle they wanted?

It would just be so much easier to understand what is going on in the component without these inputs and, if you really want to give users the ability to plug in numbers for altitude/azimuth, do this with a component that gives them a geometric visual of what they are running so that they understand.

Maybe you can put this capability of generating PVSurfaces in another component that also does a PV self-shading calculation upon request to get a value to plug into annualShading_.

-Chris

[stgeorges]

Hi @chriswmackey ,

First of all, thank you for the useful comments and suggestions, as always. The present component itself was shaped based on your suggestions from June.

... However, I have found it a bit confusing how the PVSurface and the TiltAngle / Azimuth Angle interact when you plug in values for both at the same time.

I thought the previously given explanation for PVsurfaceTiltAngle and PVsurfaceAzimuthAngle inputs was clear. Looks like it wasn't. Let me give a more precise answer.

An engineer would not start the PV system analysis with an area, but with the PV system size (size of the PV array).

He would first check for average monthly electricity consumption of the house/building/parking lot... In Serbia, a residential household spends a bit less than 500 kWh per month, on average per year. On the other side of the Atlantic it's somewhat double. For the sake of simplifying the calculation, 600 kWh is taken. For each day (on average) a household would spend 600 kWh / 30 days = 20 kWh/day. He would then take a look at the available solar radiation map for particular location and calculate the amount it receives per day. It can be a horizontal surface, does not matter. Or one can also calculate this for tilted surface with "totalRadiationPerHour" output of the "Photovoltaics Surface" component. For my hometown it's about 1400 kWh/m2/year which is a bit less than 4 kWh per day. 4 kWh per day means that a particular PV system needs to generate 20/4 = 5 kWh of AC energy per hour for each day. The PV modules output Direct Current energy, so one could assume an initial DCtoACderateFactor to be around 0.77 (10% of shading assumed): 5 kWh AC / 0.77 = 6.5 kWh of DC. 6.5 kW is an initially assumed size of the PV array and the input that an engineer would supply to the PVsurface. This is 26 modules of 250 W nameplate rating. An engineer would then analyse the actual shading at the construction site by using the SolarEye or SolarPathFinder (which is what "SunPath Shading" component does), and then check for available area of the roof or ground. Based on this data, an initially assumed 6.5 kW array size will be increased or decreased by 0.25 kW (or any other value based on one module's nameplate rate: 250 W). And moduleEfficiency will be altered too (higher efficient modules are more expensive, but require less space). In the end if a customer can not entirely cover the expenses, 100% coverage of the annual electricity needs will be lowered. There are also a simple rule of thumb values which are taken as the initially assumed PV array size, while skipping the upper calculation. Ladybug "Photovoltaics Surface" component does exactly this: for an inputted initially assumed PV array size, it outputs the amount of AC energy. In order to do that, PVsurfaceTiltAngle and PVsurfaceAzimuthAngle inputs are required.

It can also take the Photovoltaics population area in form of Rhino/Grasshopper geometry (this is what most of architects will be doing). In this case PVsurfaceTiltAngle and PVsurfaceAzimuthAngle inputs are not required, as they are calculated directly based on the inputted geometry.

The third option of supplying a numerical area, was used as a convenient addition.

I just realized that the component is not accounting for any self-shading. In this sense, I find it VERY misleading to have separate inputs for the PVSurface and its altitude/azimuth. Now that I understand this, it would be much better is there was only the input for the PVSurface and I really don't understand the point of having inputs for the altitude/azimuth inputs (it's not just redundant but also misleading). Are you imagining that some users will be too lazy to draw a surface and rotate it? Or set up a 3-component parametric model to run whatever angle they wanted?

As explained above, the PVsurfaceTiltAngle and PVsurfaceAzimuthAngle inputs are not a product of the assumption of users laziness, but a prerequisite in order to be able to define the PV system size.

Numerical inputs of PVsurfaceTiltAngle and PVsurfaceAzimuthAngle always have "advantage" over the _PVsurface input. I will add this information to their respective input parameters descriptions. Thank you for the correction, it truly is an important thing to mention.

Hope that now the diversity of the _PVsurface inputs makes sense.

If it seems difficult, I can help you write it so that it works for curved and non-curved PVsurfaces. Speaking of this, does your component account for curved surfaces if one is input?

"Photovoltaics Surface" component supports mono and poly crystaline silicone PV modules. They cover 91-94% of the world global PV market. The rest of the market is shared between thin film technology producers. Crystaline silicone modules are mostly flat. There are "curved" ones, but they have limitations in the radius of the curvature, and their cover is different from the glass we are using in the Thermal model. Incidence angle modifiers are different. So I would not advice modelling such curved panels with "Photovoltaics Surface" components. As for the thin film ones: The issue is that: it is not possible to implement them in the current thermal model with distinction between different modelTypes (open rack, roof mount, insulated back). I can only implement open rack modelType of thin-film ones, while most people would probably want an insulated back one, like in your case. If you would be satisfied with an open rack moduleType one, I could add it. Please let me know.

As a work around, I would advice paneling your surface into a series of flat panels, and then using the modelType: insulated back (1):

Finally, you should really change the PVSurface input to be a list since I imagine that there a lot of people are going to want to plug in arrays with multiple surfaces and get a single number out. This will also make it easy to write something so that people can plug in polysurfaces and the component will automatically deconstruct it into individual faces (I had to do this for the Shade Benefit components and this is very easy).

I would keep the "Item access" for _PVsurface input. "Sunpath Shading" and "Photovoltaics Performance metrics" components use a list of 8767 values from "Photovoltaics Surface" component. Keeping the "Item access" input type for _PVsurface input of "Photovoltaics Surface", "Sunpath Shading" and "Photovoltaics Performance Metrics" components keeps the whole process of cooperation between these three (four: "DC to AC derate factor") very consisted and do not allow any issues which could arise if _PVsurface would have had a "List Access". If you have a multiple surfaces inputted into the _PVsurface, simply use the "Mass addition" component at the end of calculation to find out the total AC energy.

I just realized that the component is not accounting for any self-shading.

Input the surface geometry to both "PVsurface" and "context" inputs of the "Sunpath Shading" component. "annualShading" will then account for self shading of each one of them. I intend to add more possibilities to the "Sunpath Shading" component (like shading of points instead of PV surfaces). Automatically adding the shading geometry to the "context" too, blocks the point itself. In this way I need to lift the analysis point. So for now I will keep the manual way of inputting the analysis geometry into the "context" input. Thank you again.

[chriswmackey]

@stgeorges ,

I apologize for not realizing that this was a duplicate issue of https://github.com/mostaphaRoudsari/ladybug/issues/150 . I will post my response there and close this issue out if you are of with that (this issue will still be referenced in the new one.

-Chris