Finding an optimal size of PV panel in given array

old forum
1

Hello,
I am working on some façade design and I used Tilt and Orientation Factor (TOF) component to find optimal angle of PV panels. Now need to find out the best size of PV panel size upon given array of windows.

Let’s assume that the façade has 4 by 4 windows and each of it has room at the back side. Also the width of the PV panels are equal to the width of the window. The problem is to find the length of the PV panel. Because the upper panels will obviously make shadow over the lower ones. Thus, what would be the maximum length of the PV panel in terms of solar harvesting?

I have been looking around the forum and watched some tutorial but not very sure whether LB and HB has this kind of component (I don’t think that would exist maybe i should use Galapagos?) and I will be very appreciated if you give any suggestions regarding this issue.

Thank you very much for your time.

Finding optimal size of PV in given array.3dm (169 KB)
Finding optimal size of PV in given array…gh (459 KB)

2

Hi awkweird,

My apologies for the late reply. I had to edit the PV SWH system size component in order for it to support overhang PV panels attached to a vertical building wall.
Previously PV SWH system size component supported only ground PV panels and angled roof PV panels.


Download the newest PV SWH system size component from here (Click on “View Raw” to download it. Then move the downloaded .ghuser file to File->Special Folders->User Objects Folder, an confirm to overwrite it with previously located one).


Just a few opinions on the project you are currently working on:

This kind of fixed, non-transparent (overhang) PV panels attached to a building facade are vert convenient for locations with higher latitudes.
The reason for this is because they (fixed overhang PV panels) are dimensioned according to the sun position at summer solstice. Elevation angles on summer solstice at higher latitude locations are lower, than those of lower latitude locations.

Due to Incheon’s low latitude (37), you will get rather short length of the PV panels***** : less than 10 centimeters (0.097 meters in the attached .gh file below). As you have mentioned, Galapagos needs to be used too.


I will just mention some of the good and bad ways in which the upper issue could be somewhat avoided:

1) Increasing the vertical distance between PV panels (PV panels appear above every second window).

2) Increase the tilt angle. This will increase the length of PV panels also, but will decrease the final annual AC energy output.
An example of this solution has been applied at FKI building in Seoul (latitude: 37N):


I already did some tests (with tilt angles: 40, 45, 55) and this does not seem like a good solution, though.

3) Shrinking the “sun window” by using the minimalSpacingPeriod_ input. In Photovoltaics, a planner is suppose to make the 9h to 15h part of the sun window free of any obstructions. If you try to decrease the “sun window” to 10 to 14h, the length of your PV panels will increase. You can try to experiment a little bit with this (set your minimalSpacingPeriod_ to 21th of June 10 to 14hours). In general, shrinking the sun window on summer solstice is not a good principle during planning.

4) Using tracking PV panels, not fixed ones. But Ladybug Photovoltaics components do not support this kind of PV systems. They only support fixed ones.


I would personally go with the first option. You can also experiment with the second and third one.

Comment back if you have any other questions.

-----------------------

***** By “length of the PV panels” I mean the: tiltedArrayHeight_ input of the PV SWH system size component.

FindingoptimalsizeofPVingivenarray2.gh (572 KB)

3

Dear djordje.

Thank you for your generous answer it really helped a lot. All of the suggestions you made are so meaningful to my small research, and I think I will consider number 3 which seems more suitable to my case. I tired the PV SWH system component but it only worked on ground (xy) plane. I cannot wait to try your updated component and let you know if there are any other things regarding this issue.

Once again, thank you very much and have a great day!

4

Hi awkweird,

Glad it helped.
The baseSurface_ input controls the ground (roof) plane, but you are right, previously it did not support the vertical roof/walls.

Check the attached file below for an example of the 3rd solution.

Do not be confused by the additional division of the initial PV surfaces (yellow group label: “divided PV surfaces”). This is to more accurately account for their self shading.
The attached .gh file takes a little bit more to execute everything, so I internalized some of the results, and the final result also.

Feel free to change something in definition (for example try using a bit larger tilt angle, instead of the optimal one) but be prepared to wait a little bit, before everything is executed. I labeled with green group color the steps I have been using. If you have a bit stronger PC configuration, you only need to internalize once (“2 internalize” label). If not do the steps that that I did.

Have a great weekend!

FindingoptimalsizeofPVingivenarray3.gh (2.69 MB)

5

I am sorry for not replying back quickly because I was working on my thesis and other university class related works. Meantime, I was playing with the definition you have given me last time which works very perfect for the particular case I asked.

Now I am little bit curious about how the Ladybug_Sunpath Shading (SunpathShading) component works. Does _analysisGeometry input only require PV panel surfaces? It seems like Points and normal Surfaces could also work according to its description.

And my main question is that how does Ladybug_Photovoltaics Surface (PhotovoltaicsSurface) take an account of surrounding obstacles which could potentially makes a shade on the analysis geometry.

In this example, the upper floor geometry will make a shadow on the lower floor of a façade that includes the PV I am going to test. In that case, do I have to connect the upper floor façade geometry as a context_ input? Or does the component itself will understand the whole geometry and calculate shading automatically that it would influence the outputs such as ACenergyPerYear?

Thank you very much for your time and concern.
Looking forward to hear from you.


Amaraa

6




Hi Amaraa,

Now I am little bit curious about how the Ladybug_Sunpath Shading (SunpathShading) component works. Does _analysisGeometry input only require PV panel surfaces? It seems like Points and normal Surfaces could also work according to its description.

As you correctly noticed _analysisGeometry input parameter allows supplying both surfaces and points.
Sunpath Shading component actually calculates the shading per each corner point of the supplied surface.
For example: if you supply some rectangular surface to the _analysisGeometry input, it will pick all four corner points of that surface, calculate the annual shading for each one of them, and then calculate their average. That’s the annualShading value of the surface you supplied to the _analysisGeometry input.

Sunpath shading component can also be used to analyse the impact of shading per point. This can be beneficial for solar radiation or comfort studies, where one would supply a grid of points to the _analysisGeometry input.

As you are concerned with Photovoltaics, you do not have to worry about supplying points instead of surfaces. You can, but it’s easier if you supply only the surfaces.

And my main question is that how does Ladybug_Photovoltaics Surface (PhotovoltaicsSurface) take an account of surrounding obstacles which could potentially makes a shade on the analysis geometry.

To account for the shading from the surrounding objects, use the context_, coniferousTrees_ and deciduousTrees_ inputs of the Sunpath shading component. The context_ input requires opaque obstacles (terrain, buildings, houses…) while coniferousTrees_ and deciduousTrees_ ones will account for the transparency of trees. I attached the file below with some internalized obstacles.

In this example, the upper floor geometry will make a shadow on the lower floor of a façade that includes the PV I am going to test. In that case, do I have to connect the upper floor façade geometry as a context_ input? Or does the component itself will understand the whole geometry and calculate shading automatically that it would influence the outputs such as ACenergyPerYear?

This is called self shading.
You do not have to supply the surfaces additionally to the context_ input. The component will “under the hood” add them to the context_ input to account for self shading. Last year this hasn’t been the case, but after the suggestion by Chris Mackey, I changed this feature.
However, as we are using the PV SWH System size component, there will be no self-shading. The PV SWH System size component positions the PV rows in such a way, that no self shading will appear for the given minimalSpacingPeriod_ criteria.

If these explanations were not clear, or if you still have some issues, do not hesitate to reply back.

FindingoptimalsizeofPVingivenarray4.gh (2.73 MB)

7

Dear djordje

Thank you very much for your detailed explanation it really helps to save lot of time. I have tested couple of simulations according to the context_ input.

I have noticed that daylight simulation runDaylightAnalyis havs a _HBObjects input which directly take other geometries thus it influences the daylighting results (tested).

Then, I have tried to connect as you sketched on the grasshopper definition, however it shows the error of recursive function. Which makes me think that I have to internalize the data output from ACenergyPerHour instead of directly connect ot ACenergyPerHour_ on SunpathShading as well as the annualShading to annualShading on DCtoACderateFactor (image). Please correct me if I am wrong about connecting these three components.


If I need to internalize the data from each generation, what would be ideal algorithm to deal with it when I do Galapagos or other GA? (maybe couple of rec component with Boolean toggle on dispatch component) Because as you expect now, I am parametrically changing the façade geometry and in every generated instances should be take an account of shading from upper floor of the façade geometries to get realistic data from PV surface electricity generation.

Image upload is not working, click here to see the screenshot.
I hope you understand what I have written above.

Kind regards.
Amaraa

8

Hi Amaraa,

GH will not allow recursive relationships, unless you use a few addons available.

In this case what I do is to copy/paste the DCtoACderateFactor (I am not on Windows I hope it’s the right name) component and input the results from annual shading to the new component further down the workflow. At the end I have 2 of those components in my analysis.

Hope this helps!

Kind regards,

Theodore.

9

Dear Theodore.

I really appreciate your suggestion, however i cannot quite implement the way you have mentioned.

My main goal now is to find a best PV panel in terms of electricity generation (maximizing output) that the panel itself take account of surrounding shadings. When I do it parametrically, the shading obstacles are also changes simultaneously as the PV panel change its shape.

Could you please elaborate little bit how you deal with this kind of issue? I cannot replicate as you explained above.

The overall issue is that PhotovoltaicsSurface component needs a data on input DCtoACderateFactor_* *node, which requires a data from DCtoACderateFactor component. To get this data, we need a SunpathShading component which needs another information from PhotovoltaicsSurface component. These three components are somehow connected to each other in order to yield potential electricity generation with the consideration of surrounding shading if I am not mistaken.
In this case it the number of DCtoACderateFactor does not matter unless the recursion is solved is some other way.

Kind regards.
Amaraa

10

Theodoros, thank you for the useful reply!

Amaraa my apologies for taking me too long to reply.

-I have noticed that daylight simulation runDaylightAnalyis havs a _HBObjects input which directly take other geometries thus it influences the daylighting results (tested).


Sunpath shading component needs to distinguish between opaque and semi transparent objects. That is why there are three types of context inputs. Do you find this troubling?

-Then, I have tried to connect as you sketched on the grasshopper definition, however it shows the error of recursive function. Which makes me think that I have to internalize the data output from ACenergyPerHour instead of directly connect ot ACenergyPerHour_ on SunpathShading as well as the annualShading to annualShading on DCtoACderateFactor (image). Please correct me if I am wrong about connecting these three components.


I agree that this principle of internalizing the ACenergyPerHour from Photovoltaics surface component and then getting back the annualShading back to it, is a bit clumsy solution. But I do not think there is a better one. This is due to the method we are using for calculation of the shading.
It needs to calculate the unshaded ACenergyPerHour, and then the shaded ACenergyPerHour with the use of unshaded ACenergyPerHour.
As Theodore mentioned in his reply, a small trick to overcome this is to use another Photovoltaics surface component at the end. Check the attached file below.


-I am parametrically changing the façade geometry and in every generated instances should be take an account of shading from upper floor of the façade geometries to get realistic data from PV surface electricity generation.


Just to be sure I understand you correctly: when you mention the “upper floor of the façade geometries”, is this what you have in mind (check the attached photo)?

I think I understand what was causing the confusion, and if you reply to my last question I will elaborate a bit more on the shading issue.

FindingoptimalsizeofPVingivenarray5.gh (678 KB)