Finding an optimal size of PV panel in given array.

Replies to This Discussion

Permalink Reply by Amaraa on May 28, 2016 at 9:51am

Dear Theodore,

I really appreciate your insightful suggestions regarding this matter. I haven’t tried the pollinator yet, but I am testing Octopus component for simple optimization at the moment.  The reason I am using the evolutionary optimizing algorithm is simply because of the lengthy computational time of brute-force search.

Once again, thank you for generous help and I will post some video or good images if the study goes well.

Have a pleasant weekend ahead.

Kind regards.
Amaraa.

Permalink Reply by djordje on May 28, 2016 at 8:34am

Hi Amaraa,

The location of PV module is colored in red in the photo below, right?
And each facade raster is the same, consisted of 3 x 3 fields?

Permalink Reply by Amaraa on May 28, 2016 at 9:21am

Dear djorde,

Yes that is exactly correct. And also the whole facade is divided into identical 3x3 units.

Thank you.

Permalink Reply by djordje on May 28, 2016 at 12:10pm

Ok. You should supply all of those facade elements to the context_ input, regardless if they are glass or opaque panels.

Let me now just clarify the self-shading term, as it may be that we did not understand each other quite well.

I will pick one piece of the PVsurface at the bottom row:

So the label "1" represents the PVsurface for which the shading diagram will be created.

Label "2" is the back facade (made of glass or opaque elements, does not matter).
Label "3" represents the row of PVsurfaces above.

Now take a look at how the shading diagram would look like for the mentioned PVsurface. I made some of its parts a bit incorrect on purpose, so that I could clearly the differences a bit easier:

Label "1" would be first type of self-shading. It's the shading which prevents the PVsurface to "see" anything behind its back.
Label "2" would be shading from the facade wall to which the PV surfaces are attached to. I deliberately colored it blue, to distinguish it from other two types of the shading. Otherwise it would look black.
Label "3" is the second type of self-shading: the shading from the above row of PV surfaces.
In literature, you won't find the terms: first and second type of self-shading. I invented them.
To my knowledge, when self-shading is mention, this will probably be related with label "3" (second type of self-shading). It's the shading from the adjacent rows of PV modules in front, or like in this case above.

So when I said:

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.

This was related to the first type of self shading (label "1").

And when I said:

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.

This was related to the second type of self shading (label "3").

I should also mention that I made the upper photo a bit incorrect. If you would do the shading analysis, the label "3" would be almost non-existent. Here is how the shading diagram would actually look like:

As mentioned this is because PV SWH System size component will position each PVsurface row in such a way, so that there would be no second type of self shading for the chosen minimalSpacingPeriod_ criteria. In our case, as the minimalSpacingPeriod_ criteria we chose the summer solstice in the Northern Hemisphere from 10 to 14 hours. We should have taken from 9 to 15, but we took from 10 to 14 to as on option of lowering the distance between the PV rows.
This means that there will be no second type self-shading all year round from 10 to 14 hours.

Let me know if all of this helps in any way.

Permalink Reply by Amaraa on May 29, 2016 at 2:27am

Dear djordje.

I am so amazed your tremendous help on this small problem I was facing. Your explanations are very informative and comprehensive about how to use the components that people like me would gain sufficient knowledge PV in general.

Ok. You should supply all of those facade elements to the context_ input, regardless if they are glass or opaque panels.

This make everything clear and I am able to do some experiment from now on. My apologies for the confusion that makes you waste your precious time constantly on the same issue over and over again. Maybe it’s better for me to read some literature before doing the simulation.

Indeed, I really appreciate for your help and assistance, if there is such paper exists especially on this component, I would love to cite it for my thesis work.

Have a great weekend.

Kind regards.
Amaraa.

Permalink Reply by djordje on May 29, 2016 at 5:05am

On shading: some application and devices would consider everything to be an opaque obstacle. Others might consider trees to be semi-opaque.
In this case as we are using the PV SWH System size component to position our PVsurface rows, the glass panels are not shading the PVsurfaces beneath them. If they would have shaded them, we could have supply them to the coniferousTrees_ input and set the coniferousAllyearIndex_ input to the transmittance of glass panels (around 0.5 depending on the glass type). But as these are just assumptions, you can always put everything into the context_ input, except for the threes.

For literature: there are a number of papers with detailed explanations on how shading affects a cell/module/array.
Ladybug Photovoltaics components use a generalized shading approach where shading losses are integrated into other system losses (that's what the DCtoACderateFactor_ input is for).
You can read more about shading method in here.
This article on PV shading is very useful. On three pages, it closely replicates the way Sunpath shading component is working.

If you have any other issue, let me know.

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