Finding an optimal size of PV panel in given array.

Replies to This Discussion

Permalink Reply by djordje on March 31, 2016 at 3:56am

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.

Attachments:

• FindingoptimalsizeofPVingivenarray2.gh, 572 KB

Permalink Reply by Amaraa on March 31, 2016 at 9:53am

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!

Permalink Reply by djordje on March 31, 2016 at 12:11pm

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!

Attachments:

• FindingoptimalsizeofPVingivenarray3.gh, 2.7 MB

Permalink Reply by Amaraa on May 22, 2016 at 7:29am

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

Permalink Reply by djordje on May 22, 2016 at 9:06am

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.

Attachments:

• FindingoptimalsizeofPVingivenarray4.gh, 2.7 MB

Permalink Reply by Amaraa on May 24, 2016 at 1:19pm

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

Permalink Reply by Theodoros Galanos on May 26, 2016 at 9:29pm

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.

Permalink Reply by Amaraa on May 28, 2016 at 12:32am

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

 

Permalink Reply by djordje on May 28, 2016 at 2:18am

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.

Attachments:

• FindingoptimalsizeofPVingivenarray5.gh, 678 KB
• upper_floor_facade_geometry.jpg, 57 KB

Permalink Reply by Amaraa on May 28, 2016 at 1:01am

My mistake that I haven't red the last part clearly. As you explained, the thing i was looking for is 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."

I will test some cases and check how it effects the result. 
Thank you once again. 


Kind regards.
Amaraa.

Permalink Reply by Amaraa on May 28, 2016 at 2:58am

Dear djordje.
My apologies for not making the issue clear. Since I cannot reply to your last comment, I am commenting here. 

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.

What I meant about the upper floor geometry is that I was assuming that not only PV form upper floor, but also the other elements such as glazing, opaque panels, and external shading device.


Here in the picture, you would understand what I am trying to explain verbally. The testing PV panel is one in the middle of 3 by 3 building facade. 
The question is how to calculate the shadings from the other geometries, which are painted in brownish colour in the image.

Just in case if the image is not seen, please find it here

Hope its clear now. 

Kind regards.
Amaraa.

Permalink Reply by Theodoros Galanos on May 28, 2016 at 4:25am

Hi Amaraa,

I hope my comment won't complicate things, unfortunately I'm not at my computer to provide examples, or even test my suggestions.

In the hydrashare page for Honeybee, if memory serves well, you can find examples of parametric design using LB/HB, specifically the HB component pollinator workflows.

In these examples, a GH component (data recorder) is used to locally store either input parameters or output values of different model configurations and transmit them to pollinator. I can imagine, depending on how your facade is made parametric in GH, that you could save those input parameters (e.g. angle of surfaces or height of extrusion) and output variables for each iteration (e.g. annual shading).

This a search process through the design space. I do think that if you would set up the model as such, then it would be ok that the components in the PV workflow resetted after each iteration as the results would be saved. There is even a really good visualization platform Mostapha has shared to go along pollinator.

You can find examples of these workflows in the forum, simply search pollinator. I have one that I shared somewhere as well, although it was doing rudimentary things it would help.

This design space approach is a bit different than the optimization approach utilizing components like galapagos. It gives you an idea of the space of possible different desings and allows you to compare alternatives. Plus, it usually allows me to avoid all these issues of losing results between components in the workflo.

I also find it very handy and much more efficient than simply allowing a component optimize everything for me. However, it can ncrease almost exponantially (or is it geometrically, I am always bad at this) to the range and number of your input parameters. So, if each square on the wall has more than a couple of input values for a a few input parameters, I would expect this to take a long time. Thankfully, the components in the workflow will let you know exactly how many iterations.

If this method is interesting to you and you follow it I would suggest a few things to hasten the process like utilizing only the squared above and on the sides of the PV panel, since the others won't really affect shading, selecting just 2 or 3 characteristic angles for extrusions, and perhaps approximating energy production through annual shading numbers (since I imagine they have an almost linear relationship).

I do hope that I have understood what you want to do and the above information helps. I'm sure Djordje will give much better feedback on the specifics of the PV workflow. I will try and keep this page saved so that I can send over the example once I'm back at work mid of next week.

Good luck!

Kind regards,

Theodore.

• ‹ Previous
• 1
• 2
• Next ›
• Page