pvlib / twoaxistracking Goto Github PK

Currently only the shaded_fraction gets returned by the shaded_fraction function:

    return shaded_fraction

However, for PV panels the power reduction is not necessarily proportional to the shaded area, due to mismatch losses. Therefore, it may be of interest to some users also to have access to the actual shaded geometry and from that calculate more specific mismatch losses. This could easily be achieved by also returning the unshaded_geometry:

return shaded_fraction, unshaded_geometry

@kanderso-nrel Thoughts on this?

In the solar thermal world, aperture area refers to the glass area and gross area refers to the total area (including the frame). In the field of PV the aperture area is often referred to as the 'active' area which does not include the 'dead' area.

It would be a nice feature to be able to distinguish between the two different areas when calculating the shaded fraction. This could be achieved relatively simple, by defining the reference geometry as the the aperture geometry and the geometry of the shading collectors should then be set to the gross area.

If the aperture geometry is simply a single shape smaller than the gross geometry, then the computation of the shaded area should remain the same. However, if the aperture geometry is defined as multiple shapes (such as the example below), then the computation time will be increased significantly.

The code currently executes relatively slow, hence it is of great interest to find methods to speed up the calculations.

One reviewer has proposed to:

... to calculate a maximum solar elevation beyond which any self-shading is impossible for a given array geometry. That would allow shading calculations to be skipped for a large portion of daylight hours.

An initial bootstrap implementation of this showed a 23 % decrease in computational time for the investigated field layout and aperture geometry. Hence, some improvements is certainly achievable, though it varies significantly with the specific field layout and aperture shape.

In order to implement this concept, an analytical method for determining the maximum shading elevation should be developed. The allowable inputs to the method are the field layout and the aperture geometry. Potentially the maximum shading elevation can be calculated in the generate_field_layout function and be passed to the two_axis_shading_fraction function.

The implementation of this concept in the two_axis_shading_fraction function would simply involve adding an extra optional input argument (max_elevation) and adding the following code to the start of the function:

if solar_elevation >= max_elevation:
    return 0

Consider documenting somewhere (docs page, docstring, etc) the requirements for the shading calculation to be valid. Off the top of my head, the calculation assumes at least that the shading and shaded collectors are both pointing directly at the sun. These assumptions are reasonable for the typical case, but may be violated in some circumstances (for example a tracker stall).

Probably worth reviewing the paper to see if there are other assumptions worth listing as well.

Shapely 2.0.0 (released Dec 12, 2022) on PyPI causes our CI tests to fail:

twoaxistracking/__init__.py:7: in <module>
    from shapely.geos import lgeos  # noqa: F401
E   ImportError: cannot import name 'lgeos' from 'shapely.geos' (/opt/hostedtoolcache/Python/3.7.15/x64/lib/python3.7/site-packages/shapely/geos.py)

That import error occurs on every OS and python version in our test matrix: https://github.com/pvlib/twoaxistracking/actions/runs/3733556578/jobs/6334499080

#38 requires shapely<2.0 just to get the CI working again, but it would be better to change how we use shapely so that we don't have to restrict the version. Either way we should probably deploy a fix soon so that pip install twoaxistracking results in a working environment.

During the most recent GitHub Actions (example) the following warnings have been raised:

The checkout@v2 action is used by all three of the GitHub Actions workflows used in this repository.

I suppose we should update to actions/checkout@v3 and actions/setup-python@v4. @kanderso-nrel is there a way to test if this works?

Right now shading.shaded_fraction is limited to scalar solar position inputs. TrackerField allows array inputs, but uses a python loop to process each element individually. I assume the decision to limit shading.shaded_fraction to scalar inputs was at least in part because shapely's geometry operations were not vectorized.

However, it seems that one of the changes introduced in shapely 2.0 is that geometry operations are now vectorized and allegedly significantly faster than looping like we currently do (see https://shapely.readthedocs.io/en/stable/release/2.x.html#vectorized-element-wise-geometry-operations). @AdamRJensen if you have some time, it may be worth looking into using this new vectorized functionality.

Currently, it is not possible to take into account a field tilt, which certainly would be a useful feature.

Two things are required to allow for accounting for ground tilt. First, the generate_field_layout function should be updated to include an option for specifying the ground tilt. This can either be done by specifying a field_tilt and tilt_azimuth, or by specifying a tilt angle in both the N-S and E-W directions. In addition to the current output of the X and Y matrices, the function would also return a Z matrix with the relative heights of the neighboring trackers.

Second, the two_axis_shading_fraction function has to be adjusted such that the projection of the neighboring collectors onto the reference plane also takes into account the relative height differences. Specifically, the xoff and yoff arrays should be defined so they also take into account the z-axis.

Add a changelog to document the various changes for each version.

Installing shapely with pip does not include some of the underlying binary dependencies necessary.

Instead shapely should be installed using conda:

conda install -c conda-forge shapely

Also, to show users a useful error message when the binary dependencies are missing, an import check should be added to the init.py file as described here.

In #38, it was proposed to run the test suite on a regular schedule (e.g., once a week) in order to detect issues related to the release of new versions of the package dependencies (see #39 for an example).

This is particularly relevant for this package, as it is expected that the time between future PRs will be quite long (several months if not longer) and test failures could potentially go undetected for a long time.

Running the tests on a weekly cron schedule is as simple as adding the following lines to the GitHub Action:

on:
  schedule:
    - cron: '0 0 * * 0'

However, one should be aware of who receives notifications of failed cron jobs as discussed here:

Notifications for scheduled workflows are sent to the user who initially created the workflow. If a different user updates the cron syntax in the workflow file, subsequent notifications will be sent to that user instead. If a scheduled workflow is disabled and then re-enabled, notifications will be sent to the user who re-enabled the workflow rather than the user who last modified the cron syntax.

An alternative solution would be to send an email to one or more specific people, however, this would require specifying the username/password of the email to send from, which seems like a hassle (e.g., in case of password changes).

Thus, my suggestion is simply to add the cron schedule to the existing test workflow file. This will then only notify me of any cron job failures, but I think that is sufficient and certainly better than the current solution (no regular testing).

@kanderso-nrel what do you think?

Currently, there is no button on the readthedocs documentation website that will easily take you to the GitHub repository.

I propose that should be added, which is easily configurable in the conf.py file if I am not mistaken.

I think this condition is not quite correct:

Seems like it should be the tangents of solar_elevation and slope_tilt being compared, not the angles themselves.

Once the package reaches version 0.2 it should be uploaded to PyPi, such that it can be installed with the following command:

pip install twoaxistracking

The upload to PyPi may be done automatically.

A requirements.txt or conda environment file also, so that the specific environment you used for the notebooks/paper results can be replicated in the future.