Retractable (operable) PV panel study

Is it possible to quantify a gain in kWh for a solar PV array that is in fixed position over an array that is on a retractable armature? I am looking to see if there is any significant benefit to investing into a system that would track Sun throughout the year, vs just doing a fixed panel system.

I think the rule of thumb is that a fixed system gets roughly 70% of available sun vs. a system that can track sun would allow to collect 100%. I am not sure how that translates to actual dollar amounts so I would like to do a study to prove/disapprove this rule.

Any suggestions would be welcome. Cheers!


If you assume that your moving PV panel is always in the optimal location to receive the sun, you actually do not even need to run a radiation study. The EPW file contains this data in the directNormalRadiation output. This is the solar energy that is directly normal to the sun angle. The 70% statistic does not seem to be right for Boston. I’m getting something closer to 94% between a dynamic panel tracking the sun and a flat panel oriented horizontally on the ground (globalHorizontalRadiation):

Then again, Boston is really cloudy and I could see the 70% statistic holding in some places like a desert climate

Note that, if the movable panel is not always at the ideal sun angle, you can still model it with Ladybug. You are just going to have to pass a grafted list of 8760 hours into the selectedSkyMtx component and run 8760 radiation simulations using the output data tree.

-Chris (370 KB)

1 Like

Unfortunately my panel will not always be in the optimal position since I am investigating different scenarios:

  • always in an optimal position, full scope of movement on an actuator.

  • only allowed to rotate along its vertical axis

  • only allowed to rotate along its horizontal axis

We are looking at price/feasibility of an actuated system like that as compared to actual yield or improvement in yield in kWh per year to see if its justified to invest into it.
Yes, my location is in Dubai so pretty much a desert climate.

Here’s my approach to do a brute force study like you suggested. Thoughts? (417 KB)

Hi Kondrad,

You can do this with Ladybug Photovoltaics components with tilt/azimuth angles combinations.
Check the attached file below.

To switch between single and dual axis tracker types use the drop list on the very left.
The values grouped in blue color on the very left are the ones that you need to change. The larger they are, the more precise your calculation will be. They do not need to be larger than 90 and 180 respectively.

To run the definition, check the elements grouped in red.

In the attached definition Abu Dhabi is used as a location. You can download the .epw file for Dubai from here. (492 KB)

1 Like

Hi @djordje

Thanks for the reply. I have some questions about the set up:

  1. When creating the “PV SystemSize”, how much does the Base Surface matter? What I am seeing is that the output is not dependent on the input surface and it always produces the same PV Surface. Wouldn’t I be able to squeeze more PVs on a larger surface and wouldn’t that affect the total kWh output? How can I model that? Do I use Number of Rows for that?

  2. In the “Photovoltaics Surface” component. Is DCtoACderateFactor important? Like I mentioned I am looking at desert climate and I think that my default soiling factor will be more in range of 5.5-5.8 rather than standard 2.

  3. Should I plug North vector into all components? Is that value propagated, or contained in each component?

Hi Kondrad

  1. There are two types of surfaces that Ladybug Photovoltaics use:
    _PVsurface - this is basically what you’ve mentioned: a surface which will be populated with PV modules. The larger the surface, the larger the number of modules and system size, there for the higher annual energy generation.
    baseSurface_ - this input exists only for “PV SWH system size” component. It’s purpose is to represent a mounting plane on which the PV modules will be put onto. The dark blue colored roof in the photo below is that mounting surface in this case:

So the size of area of the baseSurface_ is not important but its plane.

2) It is important. It basically sets the initial losses of the system.

If that is the soiling value you have, then yes, you need to add it to the DC to AC derate factor component, and then plug its output to “DCtoACderateFactor_” input. I did that in the attached definition below.

  1. The north vector/numeric value is not propagated due to possible independent usage of components.
    I plugged the 0 value to all three component’s which have “north_” input. You can change it to what ever value you need.

Please let me know if I didn’t answer completely to your questions, or if you have more of them. (496 KB)

I guess what I am asking with the surface is this:

Input into the TOF component has a surface that has area of 372

Then what comes out of the SystemSize component is a surface that has area of 29

These small surfaces are what goes into the _PVSurface input and I think they are being analyzed here…right? If that’s the case then we are not getting the right kWh output…

Unless I am getting something wrong here. Sorry for all these questions.

There seem to be some changes in your version of the file.

Can you attach it please (with internalized geometry)?

We are here to help. Ask as much as you want.

Yes, my bad. Please see attached. (432 KB)

Thank you.

Ladybug Photovoltaics components sometimes can have a couple of purposes, depending on the situation. This is one of those situation.
“TOF” component in general should be used to calculate the TOF and TSRF indices. They show, how “distant” is your _PV_SWHsurface from the optimal _PV_SWHsurface surface in terms of tilt and azimuth angles.
However, in your case we are not interested in TOF and TSRF indices. We would just like to know what are the _PV_SWHsurface optimal tilt and azimuth angles, regardless of the supplied _PV_SWHsurface.

So the circular surface supplied to the “TOF” component’s _PV_SWHsurface input is irrelevant. It can be of any area, and any tilt/azimuth angle.

The PV_SWHsurfacesArea output of the “PV SWH system size” component depends on a couple of factors:
moduleActiveAreaPercent_ (leave it at 90%).



Calculation of systemSize_ depends on your electricity demand, cost of the PV system, type of the object, country, local regulations etc. This is something that an engineer needs to determine.
For example, in USA for a residential house in the Sunbelt, depending on finances, a household would try to cover 100% of its annual electricity needs with their PV system. Which means that the **systemSize_ **you chose needs to cover the annual electricity consumption. You can perform EnergyPlus simulation or use any other way to get the annual electricity consumption.

Ladybug “Photovoltaics Performance” component can calculate the optimal systemSize_ by given the annual electricity consumption.
However the component is made to address fixed tilt and azimuth PV systems only.
An approximate way to overcome this is to calculate the optimal systemSize_ for fixed tilt and azimuth PV system, and then multiply it with the “difference in %s” panel at the very right of the file. Again, this is not what Ladybug “Photovoltaics Performance” component is made to do, but it will probably get you in a ball park.

Inputted 32 degrees for north_ direction is actually 328 degrees.
This is due to Ladybug Photovoltaics being based on NREL model which uses clockwise angles convention. This convention is also most commonly used in solar radiation analysis.

Dubai weather data files are uploaded in here.

OK, so if I understand this correctly I need to first figure out what my demand is, then it will size the PV array (square meters) to accommodate that demand.

If I was interested in calculating a certain system output (kWh) based on surface square footage that is available to me, then i would need to give it a “fake” demand. This would be a sort of backwards way of finding out what is the possible max output of a system of certain square footage coverage…and later I can compare that against my actual demand when that becomes known to me. Of course I understand that this is ass backwards and not the intended use for your components, but unfortunately at the moment I don’t know what the demand is. I will find out sooner or later. :slight_smile:

Thanks for all the help. I think I am getting closer to figuring out what is what in these components. I would hate to perform any sort of analysis without having at least some basic understanding of what’s happening and you have sure helped me here.


Yes, you are correct: you can use both methods: from systemSize to energy output, or the other way around: find how much energy will the system output for the given area.

Are your PV modules going to put on a flat roof, ground or angled roof? Can you attach the geometry of one of these three (that’s basically the baseSurface_ input)?

You can find the sample surface that I am working with attached. Thanks for looking into this. (549 KB)

Hi Kondrad,

Thank you for the attached files.
Check the attached definition below. Small python component will replicate the area of your circular surface to rectangular surface and calculate systemSize_ for it.
The annual output that you are looking for are the same previous ones at the very right of the definition (“tracker PV (kWh per year)” and “fixed PV (kWh per year)”). (512 KB)

Thanks a lot!

This seems about right now. The conclusion would be to give up the idea for a tracking system at this size since the $$$ savings are not enough to justify this sort of investment and instead just make sure that Tilt and Azimuth are optimal. :slight_smile: This assumption is based on actual kWh * cost of electricity (.23 dirham or $0.06 / kWh). Thanks for help!

1 Like

Very interesting conclusion Konrad!!
Thank you for posting it!