Grasshopper

algorithmic modeling for Rhino

Hi folks,

Last month Honeybee got PV panels simulation components based on EnergyPlus.

Our Ladybug and Honeybee pets love to work together. As a result of this, we are releasing PV simulation components for Ladybug too. They are based on PVWatts v1 online calculator, supporting crystalline silicon fixed tilt photovoltaics.

You can download them from here, or use the Update Ladbybug component instead. If you take the first option, after downloading check if .ghuser files are blocked (right click -> "Properties" and select "Unblock").

You can download the example files from here.

Video tutorials will follow in the coming period.

 

In the very essence these components help you answer the question: "How much energy can my roof, building facade, solar parking... generate if I would populate them with PV panels"?

They allow definition of different types of losses (snow, age, shading...) which may affect your PV system:

And can find its optimal tilt and orientation:

Or analyse its performance, energy value, consumption, emissions...

By Djordje Spasic and Jason Sensibaugh, with invaluable support of Dr. Frank Vignola, Dr. Jason M. Keith, Paul Gilman, Chris Mackey, Mostapha Sadeghipour Roudsari, Niraj Palsule, Joseph Cunningham and Christopher Weiss.

 

Thank you for reading, and hope you will enjoy using the components!

EDIT: From march 27 2017, Ladybug Photovoltaics components support thin-film modules as well.

References:

1) System losses:

PVWatts v5 Manual, Dobos, NREL, 2014

 

2) Sun postion equations by Michalsky (1988):

SAM Photovoltaic Model Technical Reference, Gilman, NREL, 2014

edited by Jason Sensibaugh

 

3) Angle of incidence for fixed arrays:

PVWatts Version 1 Technical Reference, Dobos, NREL, 2013

 

4) Plane-of-Array diffuse irradiance by Perez 1990 algorithm:

PVPMC Sandia National Laboratories

SAM Photovoltaic Model Technical Reference, Gilman, NREL, 2014

 

5) Sandia PV Array Performance Module Cover:

PVWatts Version 1 Technical Reference, Dobos, NREL, 2013

 

6) Sandia Thermal Model, Module Temperature and Cell Temperature Models:

Photovoltaic Array Performance Model, King, Boys, Kratochvill, Sandia National Laboratories, 2004

7) CEC Module Model: Maximum power voltage and Maximum power current from:

Exact analytical solutions of the parameters of real solar cells us..., Jain, Kapoor, Solar Energy Materials and Solar Cells, V81 2004, P269–277

 

8) PVFORM version 3.3 adapted Module and Inverter Models:

PVWatts Version 1 Technical Reference, Dobos, NREL, 2013

 

9) Sunpath diagram shading:

Using sun path charts to estimate the effects of shading on PV arrays, Frank Vignola, University of Oregon, 2004

Instruction manual for the Solar Pathfinder, Solar Pathfinder TM, 2008

 

10) Tilt and orientation factor:

Application for Purchased Systems Oregon Department of Energy

solmetric.com

 

11) Photovoltaics performance metrics:

Solar PV system performance assessment guideline, Honda, Lechner, Raju, Tolich, Mokri, San Jose state university, 2012

CACHE Modules on Energy in the Curriculum Solar Energy, Keith, Palsule, Mississippi State University

Inventory of Carbon & Energy (ICE) Version 2.0, Hammond, Jones, SERT University of Bath, 2011

The Energy Return on Energy Investment (EROI) of Photovoltaics: Met..., Raugei, Fullana-i-Palmer, Fthenakis, Elsevier Vol 45, Jun 2012

12) Calculating albedo:
Metenorm 6 Handbook part II: Theory, Meteotest 2007

 

13) Magnetic declination:

Geomag 0.9.2015, Christopher Weiss

Views: 13397

Replies are closed for this discussion.

Replies to This Discussion

Hi Eli 2xLee,

Yes, the surface normal direction should always be checked. Otherwise we would end up with a surface which would produce electricity on both of its sides.

Glad it worked for you. It would be useful to check the example files too. They are really simple. Here is a graphical preview of the two example files.

Great work Djordje!

I had a problem regarding the optimum tilt and azimuth angle. I tried to run the same simulation as the figure in the description (Portland, OR) but something is wrong with the results. Even when I changed the weather file to any location in the northern hemisphere, the optimum tilt and orientation are 45 and 180 respectively. Is it possible to attach your .gh file in the example folder?

Another issue would be the same as discussed in the previous replies. Adding more than one PV surface will cause a problem of overlapping between the different shading diagrams.

Other than that, the components are very handy and helpful! 

Hi Marwan,

Both "Tilt and Orientation Factor" and "Sunpath shading" components have "precision" input.
It controls how smooth the calculation mesh is, and therefor how precise the results are.
I am attaching a similar tof_Oregon_Portland.gh example definition to initial topic's photo.

As for the numerous PV surfaces inputed: Each output geometry for each PV surface is located in its own branch. So you just need to use the grasshopper "Tree branch" (or "Explode tree") component to identify the shading diagram you would like to see. Check the attached Photovoltaics shaded analysis.gh.


Thank you for the kind words.

Attachments:

Hi Marwan,

The new outputGeometryIndex_ input has been introduced to Sunpath shading component. It now makes the usage of previously explained Tree branch component redundant.
It will generate the geometry output paramters for a chosen index of the _analysisGeometry input
Check the attached outputGeometryIndex.gh file below:


@ Hi Theodoros Galanos, Dimitrios Papadopoulos, Atis Sedlenieks:
On issue about having a single graphical representation for a couple of PVsurfaces:

Sunpath shading component is essentially replicating the Solapath finder tool. Each PVsurface will have its own numeric shading value (annualShading output).
If you would like to know the average shading value of all those PV surfaces all together, you can just average all of them.
However making an average graphic shading representation of all of them is not something Solapath finder tool does, and I think there is a good reason for that: that kind of averaged geometry would be "unreadable" due to overlapping from all PV surfaces shading meshes.
Here is a bit extreme example:



Just to mention that two new components have been added:
PV SWH System Size and Photovoltaics Module.

PV SWH System Size enables creating the PVsurface from an initial size of the system in kilowatts.
Photovoltaics Module enables defining the settings of the PV module (temperature coefficient, efficiency, module type...)
You can see how they are used in the 2_new_Photovoltaics_components.gh file attached below:

Happy Holidays and Happy New Year everybody!!

Attachments:

thanks djordje

Amazing job..i wanted to ask, is it possible to reintegrate the sandia model calculations of the PV surfaces back to the Heat balance of the space gains in Honeybee to calculate the effect of these panels on the inner simulated zone?

Hi Mohamed,

Thank you for the kind words.
I actually haven't tried doing that, but I think it is possible.
One way might be to directly calculate the conductive heat transfer through the roof/facade construction beneath the PV array.
I the attached an example below, of residential wood roof construction filled with insulation layer in between the roof rafters:

If "heatGainPerYear" output is negative (like in attached .gh file for Calgary) it means the PV's are not increasing the heat gains of the room beneath them. But that again depends on the room temperature, which you could alter with "Tinside" input.

Have in mind that this kind of calculation is only valid for "moduleType = 0" (insulated back PV module):

In cases of "close roof" and "open rack" mount types (moduleType = 1,2,3), probably some cfd simulation would have to be performed to get more precise results.

Attachments:

Hi Djordje and everyone,

I am greatly enjoying these wonderful components. It is refreshing to be able to produce performance-based analyses of PV systems, as opposed to ideal analyses from programs like Tsol.

I have a couple of requests or suggestions, if I may:

1. The components seem to be doing a lot of heavy duty calculations, especially relating to the number of surfaces that are used (I have noticed a correlation with working time and number of input surfaces). In generally, the workflow can get quite time consuming. I was wondering then if it is possible to allow for parallel computation for these tools? Especially in the case of number of surfaces it should provide with a significant improvement (different surfaces assigned to different processors)?

2. As discussed, the performance-based results according to the specific geometry of the site and building is the greatest advantage of these tools, along with them being integrated to the HB/LB and Rhino/GH community. However, for practical reasons, programs like TSol have very detailed databases for equipment characteristics. I am not entirely sure but I believe that the data for these (propriatory) databases has been extracted from open sources. I was wondering if anyone knows if this is true. If yes, is there a way we can assist in creating a database for these tools in order to quickly and easily select equipment characteristics for our PV systems?

Thank you for all the great work, testing, and feedback!

Kind regards,

Theodore.

Hi Theodoros,

I am glad to hear that you are enjoying the Photovoltaics components!

You mentioned TSol. Is this the T*SOL from Valentin software? Isn't it specific for solar thermal energy analysis? Are you working on a PV system which will power a domestic hot water boiler?


To answer your questions:

1) Each grasshopper component (ghpython being one of those too) is using grasshopper's data matching algorithm. This algorithm takes care of complex issues which may arise from combining lists with single items, data trees with different number of items per branch and so on.
I think there is a way of introducing a call to other processor's threads per each inputted surface, but this will be a very difficult job, as it will require writing a custom data matching algorithm. I do not think I am up to that task.
Instead I tried to introduce the multithread only to the final part of the PVsurface component and one of its time consuming parts: calculation of sun angles, solar radiation and ac/dc power output.
I attached the test file below, but sadly it didn't go well: the multithreaded version mostly runs at the same time as the regular version.
I do not think I am qualified enough to answer why is that so, but I think that it may have something to do with the type of the function that the multithreading is applied to: the code is suppose to run few separate functions a couple of thousand times, and work with a couple of lists. From my experience, the multithreading works the best when a single list or two are supplied to a single function. I may be wrong on this.
I am very sorry to say that I can not implement this feature.


2) I am not familiar if open source PV modules database has been released.
But one can always download the data for specific modules from producers websites. It can then easily be transferred to a .csv file or other text file.

Ladybug Photovoltaics are based on NREL's PVWatts model.
In comparison with other commercial software applications, PVWatts offers a more generalized system model, with some of the values and characteristics being assumed or embedded.
The Fuentes empirical thermal model we are currently using follows the same logic: it generalizes the Module characteristics. The following characteristics are only editable: module efficiency, temperature coefficient and module mount type.
It may be possible to replace Fuentes with some other, less generalized 5 parameter thermal model. But as an architect, I would definitively need help on this.

Sorry if my reply did not fulfill your expectations, and thank you for the kind words!

Attachments:

Hi Djordje,

Thank you for the informative answer. I will test the attached script during this week and share my experiences.

Also, I understand now better the modeling process of the PV systems. I guess I was only thinking to open a discussion in case someone was already working on compiling such a database of different installations, etc. But it's not really a problem inhibiting me using these awsome components.

Kind regards,

Theodore.

The thermal model mentioned in the reply above should be: Sandia, instead of Fuentes.
The link to the publication is correct though. Apologies for the correction.

Hi there,

This is probably may not be related to Ladybug, rather to my display settings.

It's a problem I have been facing all along in Rhino.

Every time my shaded view looks all glossy and translucent when orbiting, even when my display settings are set to default. I only have this issue on my laptop.

Could someone please help me out?

Thanks.

Hi Erik,

I think your display settings are fine.

The precision_ input of both "Ladybug Photovoltaics" and "Ladybug Tilt And Orientation Factor" components ranges from 2 to 100, where 2 is the default value.
Increase the precision_ input of both components. This will increase the number of the resulting mesh faces, and therefor will remove the blurry-like effect.

RSS

About

Translate

Search

Photos

  • Add Photos
  • View All

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service