You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
This is the broadest proposal I'm ever going to do here, I think.
The model (or workflow, I don't know how to call it) is described in [1]. It compares the output of a Matlab script against PVsyst and SketchUp and calculates shading factors for direct and diffuse components, in the context of PAR incidence onto ground. Nevertheless part of the workflow seems equally applicable to shadows of other objects onto arrays.
A first step is a geometrical description of the PV arrays and projection of their shadows onto arbitrary planes, described in [3] of [1].
For the direct shading factor:
I already have arbitrary shadow castings onto a random plane: I'm currently at equation 20 of [1], finished section 4.3 of [3]. You can check out some dirty progress at this gist. Next steps include probably using the shapely package, doing intersections and unions of shadows.
For the diffuse shading factor:
A semi-spherical discrete integral is done. I haven't made any progress on it nor I have read enough to be sure about the approach.
Describe the solution you'd like
A functional set of functions in a new submodule, something along spatial.py (shamelessly stealing this idea from @adriesse 😉 ) to handle the array rectangle and rotation creation, projection of the corners, and translation from 3D coordinates to 2D plane system (required for easy area calculations). I usually find functional code more hackable and well-documented.
Then I would like to add at least the fixed tilt agrivoltaic system modelling in an example. I can add the other examples in different PRs.
I'm still unsure regarding how to approach the diffuse integral.
Describe alternatives you've considered
Create a parallel OOP modelling for 3D operations
The base object would be:
Surface -> rectangle to describe arrays, the field or flat obstacles. Internally a shapely polygon. Initialized from azimuth, tilt, length, width and a point (a corner or the centroid). Would have methods to make the boundary checks of the shadows onto the surface (intersection), shadow area calculation (or output as a Polygon)
The pro of this approach is no user mess of mis-reused variables, and ease of use I think. With solar azimuth and zenith and shadowing objects, I think a method can handle the projection: shadow_polygon (or shadow_area) = shaded_surface.shadow_by(solar_azimuth, solar_zenith, array1, obstacle1, array2, obstacle2, ...)
I have doubts regarding trackers, since they change their corners coordinates.
This would possibly allow expanding the obstacles with more complex geometries, or defining them just as Polygons
Add the above to the current Array class (or by inheritance)
Additional context
This is part of my GSoC PAR analysis proposals.
[1] S. Zainali et al., ‘Direct and diffuse shading factors modelling for the most representative agrivoltaic system layouts’, Applied Energy, vol. 339, p. 120981, Jun. 2023, doi: 10.1016/j.apenergy.2023.120981.
[3] Y. Cascone, V. Corrado, and V. Serra, ‘Calculation procedure of the shading factor under complex boundary conditions’, Solar Energy, vol. 85, no. 10, pp. 2524–2539, Oct. 2011, doi: 10.1016/j.solener.2011.07.011.
I request input in:
where to put new code
whether or not to add more examples in a single PR
approach: functional or OOP
The text was updated successfully, but these errors were encountered:
Uh oh!
There was an error while loading. Please reload this page.
Is your feature request related to a problem? Please describe.
This is the broadest proposal I'm ever going to do here, I think.
The model (or workflow, I don't know how to call it) is described in [1]. It compares the output of a Matlab script against PVsyst and SketchUp and calculates shading factors for direct and diffuse components, in the context of PAR incidence onto ground. Nevertheless part of the workflow seems equally applicable to shadows of other objects onto arrays.
A first step is a geometrical description of the PV arrays and projection of their shadows onto arbitrary planes, described in [3] of [1].
For the direct shading factor:
I already have arbitrary shadow castings onto a random plane: I'm currently at equation 20 of [1], finished section 4.3 of [3]. You can check out some dirty progress at this gist. Next steps include probably using the
shapely
package, doing intersections and unions of shadows.For the diffuse shading factor:
A semi-spherical discrete integral is done. I haven't made any progress on it nor I have read enough to be sure about the approach.
Describe the solution you'd like
A functional set of functions in a new submodule, something along
spatial.py
(shamelessly stealing this idea from @adriesse 😉 ) to handle the array rectangle and rotation creation, projection of the corners, and translation from 3D coordinates to 2D plane system (required for easy area calculations). I usually find functional code more hackable and well-documented.Then I would like to add at least the fixed tilt agrivoltaic system modelling in an example. I can add the other examples in different PRs.
I'm still unsure regarding how to approach the diffuse integral.
Describe alternatives you've considered
Create a parallel OOP modelling for 3D operations
The base object would be:
Surface
-> rectangle to describe arrays, the field or flat obstacles. Internally a shapely polygon. Initialized from azimuth, tilt, length, width and a point (a corner or the centroid). Would have methods to make the boundary checks of the shadows onto the surface (intersection), shadow area calculation (or output as a Polygon)The pro of this approach is no user mess of mis-reused variables, and ease of use I think. With solar azimuth and zenith and shadowing objects, I think a method can handle the projection:
shadow_polygon (or shadow_area) = shaded_surface.shadow_by(solar_azimuth, solar_zenith, array1, obstacle1, array2, obstacle2, ...)
I have doubts regarding trackers, since they change their corners coordinates.
Add the above to the current
Array
class (or by inheritance)Additional context
This is part of my GSoC PAR analysis proposals.
I request input in:
The text was updated successfully, but these errors were encountered: