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!
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.
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:
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:
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?
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.
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:
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)?
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!
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!
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.
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.
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.
Both of your issues deal with component’s output previews.
To display the isocurve in the Tilt And Orientation Factor component, just turn on the preview of the whole component.
Displaying quadrantShadingPercents can be done in two ways: a) less visually appealing - in Grasshopper. It requires hiding of “sunWindowMesh” output and plugging the “Text tag” component to the particular outputs.
b) more visually appealing (the example that you can see in the initial reply of this topic) - just bake the component’s results (set the “bakeIt_” input to True).
I attached a .gh file in here which replicates the upper suggestions.
Also it’s a bit tricky to answer your questions without your .gh and .3dm files. I understand that you are using the Ladybug Photovoltaics Sample files, but sometimes users change something which affects the final result. For any future questions I would be grateful if you could attach your .gh and .3dm files (in case you are using .3dm files). Thank you.
Thank you very much for your response. I will keep in mind to attach the .gh files in the future.
However, the isocurves still don’t appear, even in the .gh file you sent me.
The visually appealing display of the shading percents do not really seem to work either. It doesn’t bake it when the boolean toggle is set to True. I don’t know what I’m doing wrong.
Here’s your .gh file I’ve edited, in case I’m overseeing something.
I already turned off the Sunpath shading component’s outputs. You didn’t have to turn it by yourself. Sorry if my explanation wasn’t good enough.
For baking: by default, when Ladybug components geometry is baked, the last parent layer is turned off. So what you have to do is to turn it on. Sometimes you even have to turn off the very last child layer. I think this may be a bug with Rhino. Also make sure that you choose Shaded or Rendered display mode instead of Wireframe. Here is a screenshots of the mentioned steps:
For the isocurves issue: the file I attached in my last reply creates them. Here is a screenshot:
Can you please post a screenshot of what you are getting?
I have taken some screenshots you can have a look at here below. It’s better, but here’s still a problem in displaying things… The first picture is in the Ghosted mode, as in your screenshot. But I’m obtaining it better in the Rendered mode (second screenshot). Might this be related to the display problem I was talking about earlier?
And then for the isocurves, there are still not appearing, even when baked…
It’s better, but here’s still a problem in displaying things… The first picture is in the Ghosted mode, as in your screenshot. But I’m obtaining it better in the Rendered mode (second screenshot). Might this be related to the display problem I was talking about earlier?
You are ok. You have the “mesh wires” enabled in the first display mode, and do not have them in the second one. So use the second one (that being Rendered I suppose).
And then for the isocurves, there are still not appearing, even when baked…
Can you please: a) attach the .3dm file which contains the baked results of the TOF component?
b) internalize the data, coming out of the TOF component’s geometry output, and then attach that .gh file? So basically you right click on the geometry parameter and choose Internalise data. Then save the .gh file an attach it:
Both your Ladybug discussion.3dm and Ladybug_Photovoltaics_TOF_results_preview internalized data.gh show correct results.
Which means that everything is ok with your Ladybug Photovoltaics components, but that something is wrong with your Rhino display modes.
In Rhino application menu, choose: Tools -> Options -> View -> Display Modes -> then choose the one you are currently using (Rendered if I remember correctly). See if “show curves” check box is enabled. If it is not, enable it:
Attach the Ladybug discussion.3dm file and show them how it looks like on my PC, and then post the screenshot of how it looks like on yours. I think they will solve your Rhino curves preview issue.
