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