algorithmic modeling for Rhino
NOTE: Apologies, I posted this on the main Grasshopper discussion page - I now realise this would've been much more appropriate here. Sorry for the double post!
Hi all,
I am an amateur user of Rhino/Grasshopper but am beginning to explore its possibilities in my capacity as a sustainability consultant. I'm looking to use the Ladybug PV tools to provide as much information as possible about PV sizing, orientation, shading and expected outputs.
I've been using the "020 PV shaded analysis" example canvas as a starting point (very useful, thanks to its creators) and have been trying to incorporate the TOF and PV_SWH_SystemSize modules but am having issues with both.
For the TOF module, I find that no matter which inputs I provide, the optimalTilt is always 45 and the optimalAzimuth is always 180. I'm providing a weather file input and a north vector.
I'm then using the optimalTilt and optimalAzimuth outputs to supply the PV_SWH_SystemSize inputs for arrayTiltAngle and arrayAzimuthAngle - obviously this isn't actually doing anything useful at the moment as the outputs from the TOF are always 45 and 180.
With the PV_SWH_SystemSize module, I'm having issues with the spacing it is providing between the rows of PV. I know it calculates this based on the sun position on a date based on the altitude of the location the weather file provides, but I think the spacing is far too large, especially for a rooftop array where the space is more like 1-2m normally. I'm trying to specify a summer date in the format the minimalSpacingDate output provides (15 NOV 15:00) so the calculated spacing is lower, but it just throws up an error whenever I do.
Finally, it would be really useful to be able to get the PV_SWH_SystemSize component to actually produce the array it has created as Rhino geometry, so they can be viewed when rendered; is that possible? Also, is it possible to restrict the module so that it only creates rows with dimensions such that it fits within a surface you provide?
Apologies, I know these are a lot of probably very basic questions! I've attached my canvas - again, I'm sorry it's not as neat as it could be. Thanks in advance for any and all help!
Tags:
Replies are closed for this discussion.
Hi Wigg,
I am stuck with some other work this spring, and this is the reason why you didn't get the reply straight away. I apologize for that. I am probably going to reply even rarely in the next couple of weeks. But if you are patient I think we will try to solve most of the issues.
For the TOF module, I find that no matter which inputs I provide, the optimalTilt is always 45 and the optimalAzimuth is always 180. I'm providing a weather
file input and a north vector.
You are the second user who reported this which means that I was wrong in my assumption of setting a very low default value for the precision_ input, it should have been higher as more user friendly for beginners. Basically the TOF component results depend on the precision_ input. The best would be to set this value to 100, let your PC run the whole night, and in the morning you would get the most precise tilt and azimuth optimal angles. However, as some of us are using weaker PCs, and as sometimes the difference between results from precision_ = 100 and say precision_ = 30 is less than a degree, you can try using the precision_ = 30 for the start.
By default the precision_ is set to only 2. I will make sure this is increased in the next release of this component. Your topic definitively contributed to that!
Another thing I noticed is that "TOF" component does not support north_ inputs not equal to 0, in terms of graphical representation of results. It would probably take me some time to fix this. But the numerical results (which is what we need) are supported.
By looking at some other similar PV applications, I haven't seen the optimal tilt/azimuth graphical representation which supports change of north angle direction, so maybe this is not too much of an
issue after all. The important thing is the numerical part, which is outputs correct results.
I'm then using the optimalTilt and optimalAzimuth outputs to supply the PV_SWH_SystemSize inputs for arrayTiltAngle and arrayAzimuthAngle - obviously
this isn't actually doing anything useful at the moment as the outputs from the TOF are always 45 and 180.
It will make sence now, that you increase the upper precision_ input.
With the PV_SWH_SystemSize module, I'm having issues with the spacing it is providing between the rows of PV. I know it calculates this based on the
sun position on a date based on the altitude of the location the weather file provides, but I think the spacing is far too large, especially for a rooftop array
where the space is more like 1-2m normally. I'm trying to specify a summer date in the format the minimalSpacingDate output provides (15 NOV 15:00) so
the calculated spacing is lower, but it just throws up an error whenever I do.
minimalSpacingPeriod_ input of the "PV SWH System Size" component accepts data from Ladybug "Analysis Period" component. But again, I apologize: as this is my mistake for not mentioning this in its docstring (that's the explanation you get when you hover your mouse over this input). I will make sure this gets added to the next release of "PV SWH System Size" component as well!
I also noticed a bug with "PV SWH System Size" component - at the moment the values it calculates are not correct if north_ input is not equal to 0. This is due to the component using another Ladybug developer's code which calculates sun position angles. For some reason this code does not support changing the north angle direction. I will contact the author to see how this can be solved.
So to be clear: it's not that all Ladybug Photovoltaics component do not support north_ inputs not equal to 0. It's that "PV SWH System Size" component currently does not due to the upper issue. And "Tilt and Orientation Factor (TOF)" component does not support for its graphical representation of results. I will see if at least the first one can be fixed.
Finally, it would be really useful to be able to get the PV_SWH_SystemSize component to actually produce the array it has created as Rhino geometry, so
they can be viewed when rendered; is that possible? Also, is it possible to restrict the module so that it only creates rows with dimensions such that it fits
within a surface you provide?
The PV_SWHsurface output of "PV SWH System Size" component contains Grasshopper geometry of all PV rows. Are you familiar with baking in Grasshopper?
I attached below an example of how to perform a shaded PV analysis. I rotated the whole context by 40 degrees so that the issue with "PV SWH System Size" component could be overlooked. When you determine your minimalSpacingPeriod_ input, we can internalize its "PV SWH System Size" output, rotate back your context and use "40" as a value for north_ input for all components.
Let me know if something was not clear, or if I replied vaguely to some of your questions.
I apology in advance if it may take me a bit longer to answer to your next question. This spring period has really toughen my free time.
Hi Wigg,
The issue with "PV SWH System Size" component not accounting for north_ input has been fixed.
So right now all Ladybug Photovoltaics components support north_ input apart from graphical representation of the "Tilt And Orientation Factor (TOF)" component.
This is what graphical representation means:
So even though the north angle of "40" has been inputted in upper Photovoltaics shaded analysis.gh file, the "TOF" component will still show the graphical result as if north is defined at 0. I do not think I will be changing this, as it will require from me to rewrite much of the "TOF" component.
"TOF"'s numerical calculation will support the north_ input which is what is important.
This is what numerical calculation is (the numerical outputs):
So I attached a new grasshopper definition below where all components have north_ input set to "40" and your context has been rotated back to -40, as you had it on the very beginning.
Let me know if you have any questions.
Hi Djordje,
I'm hoping to be able to start incorporating your changes this weekend but I just wanted to express my gratitude for your quick, detailed and comprehensive response. I've been impressed with the support on the forums as a spectator, but not experienced it myself until now. I know you have been busy yourself and taking the time out to respond to my (probably rather trivial) issues is not expected.
I hope you are well and I haven't distracted you from your work for too long. Thanks again for your help.
Wigg
Hi Wigg,
Your question was certainly not trivial, and it actually contributed in finding and solving the bugs with the north_ input.
With users like yourself and topics like this, the Ladybug tools are becoming more stable and reliable each day. So it is I who needs to thank you.
Let me know when you have more questions.
Regards,
Djordje
Welcome to
Grasshopper
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
© 2024 Created by Scott Davidson. Powered by