Retractable (operable) PV panel study

Replies to This Discussion

Permalink Reply by Chris Mackey on November 21, 2016 at 7:48pm

Konrad,

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

Attachments:

• DirectNormalRadiation.gh, 370 KB

Permalink Reply by konrad k sobon on November 22, 2016 at 9:57am

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? 

Attachments:

• sunTracking_01.gh, 417 KB

Permalink Reply by djordje on November 22, 2016 at 7:27pm

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.

Attachments:

• fixed_vs_tracker_PV.gh, 492 KB

Permalink Reply by konrad k sobon on November 23, 2016 at 9:39am

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? 

Permalink Reply by djordje on November 23, 2016 at 11:23am

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.

3) 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.

Attachments:

• fixed_vs_tracker_PV2.gh, 496 KB

Permalink Reply by konrad k sobon on November 23, 2016 at 1:47pm

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. 

Permalink Reply by djordje on November 23, 2016 at 3:08pm

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

Can you attach it please (with internalized geometry)?

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

Permalink Reply by konrad k sobon on November 23, 2016 at 3:15pm

Yes, my bad. Please see attached. 

Attachments:

• fixed_vs_tracker_PV_ks.gh, 432 KB

Permalink Reply by djordje on November 23, 2016 at 5:29pm

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%).

moduleEfficiency_,

systemSize_.

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 fixed_vs_tracker_PV2.gh 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.

Permalink Reply by konrad k sobon on November 23, 2016 at 7:19pm

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. :-) 

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. 

Cheers! 

Permalink Reply by djordje on November 24, 2016 at 1:42am

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)?

Permalink Reply by konrad k sobon on November 25, 2016 at 12:04pm

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

Attachments:

• 20161121_PhotovoltaicsStudy.zip, 549 KB

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