Hi,
maybe this is a subject for @djordje :
It seems that shading using the photovoltaics components can be considered using the SunpathShading component, which outputs the annualShading value, to be connected to the DCtoACderateFactor component, and from there to a second PhotovoltaicsSurface component that reduces the results by an averaged factor (one value, applied for all hours of the year).
My problem is that I need to consider the shading effect on an hourly basis, i.e. the PV may be shaded from 8:00 until 10:00, and then be unshaded for the rest of the day. In other words, I would like to derive the ACenergyPerHour using hourly shading factors according to how the sky dome is obstructed by surroundings on an hourly basis. Is that possible?
Thanks!
Hi @IasonBournas ,
Ladybug’s Photovoltaics components are created based on NREL’s PVWatts model which is using annual shading. And results are validated against its online version.
I assume the reason for this is the complexity of the PV shading, which may not be proportional to hourly shading.
I would say that some other model needs to be used, if hourly shading must be taken into consideration.
Maybe you can correct ACenergyPerHour for direct radiation shading, as you suggested, but then, it may not be possible to validate results.
Hi, @djordje.
I’m nor sure if it’s a bug, in other ladybug components (e.g. SunPath, Sunlight hours, Radiation) the North starts at 0 and goes anticlockwise while in the Sunpath Shading module, is the opposite.
I realized this because I set the north once in my workflow and connect it everywhere, the radiation analysis was correct but the production results didn’t make sense… so I had to set the North twice (clockwise and anticlockwise)
In the attached img the north is set at 45°
Hi @blancadlf ,
It is not a bug in the “Sunpath shading” component.
Its “north_” input represents an Azimuth angle.
Azimuth angles are defined clockwise, starting from +Y axis representing the North.
So 45 degrees azimuth angle, is exactly what you show in your picture above: it is a (1,1,0) vector:
For Ladybug’s “North Arrow” and all Ladybug components outside of the “Renewables” tab - instead of azimuth angle, they use rotation angle for the “north_” input. (Positive) Rotation angle in mathematics is measured in counterclockwise direction.
So I understand your confusion, and the need to have unified rule for all Ladybug components.
In my opinion, it should be the Azimuth angle, but that’s just my opinion.
Nevertheless, the whole issue is resolved if you use vector input for the “north_” instead of numerical one.
Thank you so much for your response @djordje,
For the Photovoltaics surface module, it seems to work with the positive rotation “_north” input, (my surface is towards south-west). The module says that my PV azimuth angle is at 225° (S-W), so I believe that is the normal or orientation of the PV is that correct?
Can you attach your .gh file please?
Thank you.
Never use different north values for the Ladybug Photovoltaics components in the same .gh file. The same value needs to be used across all components:
But you are right about PVsurfaceAzimuthAngle output. For some reasoning it was showing the angle in the opposite direction. Photovoltaics components are calling methods from other classes as well. Maybe these methods changed in the last 5-8 years. I am not sure.
I modified the “Ladybug_ladybug” components’ "Photovoltaic"class.
Check the attached file.
PV calc analysis-00 20230329.gh (432.5 KB)