diffuse optimization example using pvlib

[Mark Mikofski]

Hi Folks,

I hacked together a diffuse optimization example using the Greensboro, NC, TMY3 weather file included in pvlib, get_total_irradiance(), the single-axis tracking functions, and scipy.optimize.minimize_scalar(). It's in this Gist: 

https://gist.github.com/mikofski/ea829908ada38103446097066dc39ed7#file-diffuse_optimization-ipynb

Cheers!

Mark

--

Being deeply loved by someone gives you strength;
loving someone deeply gives you courage.
Lao Tzu

[Will Hobbs]

Mark - this is cool!

If I add this at the end:

```

total_standard_travel = std_tracker['tracker_theta'].diff().abs().sum()

total_optimized_travel = diffuse_optima['tracker_theta'].diff().abs().sum()

diffuse_travel_reduction = (total_standard_travel - total_optimized_travel)/total_standard_travel

print(f'tracker travel reduction: {100*diffuse_travel_reduction:g}%')

```

I get a 15.8% reduction in total tracker travel over the year, which seems significant! Is my math right?

 I've wondered about diffuse optimization *increasing* tracker wear based on lots of subhourly variability, but it seems like if the tracker controller can add the right amount of smoothing, then maybe that isn't an issue? It would be interesting to run this with 5- or 1-minute data without any smoothing, and then maybe with some kind of sliding window smoothing for the tracker setpoint.

Will

[Mark Mikofski]

Hi Will,

So are you saying that standard backtracking travelled *more* than the diffuse optimized tracker or the opposite? I guess that is a surprise, but I was also surprised to see that there were some days when the optimum tracker position was surprisingly close to zero for most of the day. Maybe Greensboro is just a really cloudy site? Might be interesting to try this in a site that is both sunny and cloudy like Houston?

Also I should caveat that this optimization assumes perfect foresight, and I also optimized POA, not DC output. Although I think the non-linearity in energy conversion as a function of effective irradiation wouldn't change the results too much. 

Cheers,

Mark

[Will Hobbs]

Mark,

Yes, that was my conclusion: standard tracking results in more actuator travel than optimized tracking (with perfect foresight, for this site, weather year, time interval, etc...). Your "Detailed Diagnostics" section plot of tracker theta illustrates this for a single day and is what inspired me to test it for the full year. 

Does my calculation of total travel (in degrees rotated) look correct? E.g., `std_tracker['tracker_theta'].diff().abs().sum()`?

I also don't expect that optimizing for POA vs DC power would make a meaningful difference.

If this could all play out in the "real world" (without perfect foresight, with subhourly variability, etc.) then a 15% reduction in actuator wear might have significant value, at least in the same order of magnitude as a 0.75% energy output gain. 

Will

[Anton Driesse]

Hi Mark, Will,

Nice notebook, Mark.  Don't modern tracking systems already do some kind of adaptive control?  The idea has been around since the early days of tracking, for example here:

https://www.degerenergie.de/higher-yield-how/

Will, I do think it's the variable days where the trade-off between actuator wear and motor kWh vs. yield will be most difficult to optimize, and sub-hourly simulations would definitely shed light on that.

Anton

--
You received this message because you are subscribed to the Google Groups "pvlib-python" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pvlib-python...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pvlib-python/c4c388bb-b940-4a2f-82ce-9b72da8f6c7dn%40googlegroups.com.

-- 
PV Performance Labs
Emmy-Noether-Str. 2
79110 Freiburg
Germany

+49-761-8973-5603 (Office)
+49-174-532-7677 (Mobile)

www.pvperformancelabs.com

[Anton Driesse]

Hi Will,

That's quite a difference!  For sure real trackers could never follow the changing conditions in real time.  So if we want to simulate yield with real trackers, we would need some knowledge about their control algorithms...

Anton

On 2023-04-05 1:08, Will Hobbs wrote:

I just tried running Mark's code with 5min NSRDB data for the same location, 2020, and got a 0.57% diffuse boost and a -73% tracker reduction, meaning that the optimized tracker traveled *significantly* more than the standard tracker. 

I imagine 1min data would be even more dramatic, and might exceed tracker rotation speed limits. Smoothing and/or limits on how quickly the trackers can move would likely be needed in a real-world system. 

Will

To view this discussion on the web visit https://groups.google.com/d/msgid/pvlib-python/b7673687-1884-4b43-bf41-8aafa8305b2cn%40googlegroups.com.

[Will Hobbs]

It looks like a few messages didn't make it through on this conversation. Anton quoted my last message about trying 5 min data, and Kurt had some comments and a link to notes he had shared that seems to have been deleted. Not sure if that was a google spam filter things, intentional, etc., but I thought I'd mention it. 

Will

[Mark Mikofski]

Hi Will, I noticed it too. I don’t know what happened. I don’t know how to retrieve the emails or even find a log of how it happened. A symptom of Google groups maybe? This system is aging, and I wouldn’t be surprised if Google axes it soon. GH Discussions seems like a better forum, but I am so used to this one, and it is where most of the traffic occurs.

Sent from my iPhone

On Apr 21, 2023, at 1:34 PM, Will Hobbs <will....@gmail.com> wrote:

It looks like a few messages didn't make it through on this conversation. Anton quoted my last message about trying 5 min data, and Kurt had some comments and a link to notes he had shared that seems to have been deleted. Not sure if that was a google spam filter things, intentional, etc., but I thought I'd mention it. 

You received this message because you are subscribed to a topic in the Google Groups "pvlib-python" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/pvlib-python/uYqWRpz_cwk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pvlib-python...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pvlib-python/d72394f3-678c-467b-a615-c8558107ca1dn%40googlegroups.com.

[Anton Driesse]

Hi Will, Mark,

Here is Kurt's message.  Google wasn't able to delete it from my inbox--or maybe they just didn't bother to do so.

Anton

On 2023-04-12 5:23, Kurt Rhee wrote:

Hey Mark,

This is awesome, the bisection optimization method is really slick.  I wish I had thought of that.  My plan for PlantPredict is to introduce the idea of a standard tracking angle, an ideal tracking angle and a corrected tracking angle that sits somewhere between the two.  The standard tracking angle will be calculated normally via a tracking algorithm such as the ones implement in pvlib.  The ideal tracking angle is the one that is calculated via this irradiance optimization method.  The corrected tracking angle will take into account the tracker movement speed and some hesitation factor which represents the percentage of a time-step that diffuse conditions must occur for a tracker to decide to move.  For example, if a given tracker manufacturer's diffuse stow signal is based off of three pyranometers on site, it may be the amount of time that it takes for all three pyranometers to read diffuse conditions due to cloud movement.  I'm not sure how applicable the terms would be in terms of pvlib since they require that the timestep be a known parameter, but I thought I would post some notes here if you were interested.

https://terabase.atlassian.net/servicedesk/customer/portal/3/article/1260060675?src=59595139

To view this discussion on the web visit https://groups.google.com/d/msgid/pvlib-python/E2F0011A-075F-4BE5-92BF-061CB8E7586C%40gmail.com.

[Nicholas Riedel]

Hi all,

Interesting discussion here, thought I would share some results. 

I ran Mark's code using 1 year of DHI, GHI, DNI data that we measured in Roskilde, Denmark (avg diffuse fraction of 49%). The raw data are measured every 10 seconds so I resampled to 1, 5, 15, 30 and 60 min averages. For each timestamp, I also calculated Gpoa using Kurt's 'corrected_theta' angle, which takes into account the tracker's speed and a 'hesitation factor'.  The black points below are calculated using Mark's notebook and the red points use Kurt's corrected_theta with a hesitation_factor of 0.4 and tracker_speed of 1degree per second. The top frame shows 'rel_tracker_movement' calculated with Will's formula (quite a collaboration we have here!) and bottom frame is the so called 'diffuse boost'. 

We see that adding hesitation reduces the GPOA gains, but also results in less tracker movement - especially at shorter time horizons. Tracker manufacturers that use batteries to power the motor will often highlight that diffuse optimization also avoids unnecessary tracker movements. In this sense, I think a diffuse optimization tracking model that reflects industry practices should aim for less movement than standard tracking.

I was curious about the effect of the hesitation_factor, so I did a sweep from 0 to 1. No hesitation gives the highest GPOA gain, but also significantly more tracker movement - especially at short time horizons. Too much hesitation can result in less GPOA than standard tracking. 

Implementing this in real time tracking control seems challenging to me. For example, consider when the diffuse fraction is high and the tracker is near stow position, but suddenly the clouds disperse. In this case the tracker must quickly revert to its standard tracking angle (optimized for beam component). Otherwise, you could quickly lose all the GPOA that was gained during diffuse stow. 

-Nick   

[Benjamin Pierce]

Hi all,

Thanks for the demo, Mark, and everyone for the great discussion. I have a few things to add:

At Sandia, we have a Multi-Planar Irradiance Sensor (MPIS), which is basically a rotating pyranometer that looks across the sky in a 180 degree arc. If this axis lines up with the axis of a tracker, it'll get irradiance measurements at all possible tracker angles for each point in time. We have this data for Albuquerque, NM in 1 min intervals. This data is quite nice for evaluating tracking algorithms as we can get easy comparisons in actual received irradiance, as well as the “optimal tracker angle”, which is the position that maximizes received irradiance at each time step. We can use PSM3 instead of TMY data for these comparisons. This can be compared to other tracker algorithms, like Mark’s:

Note the oscillation in the MPIS signal. At very fine resolutions, due to the presence of clouds and other atmospheric factors, we see quite a bit of minute-to-minute change in what is truly “optimal”.This can be evened out with some Gaussian smoothing, but the minute-to-minute fluctuation is still important to consider when doing this in real time.

Additionally, using models other then Perez can (naturally) lead to different results:

In the long run, if evaluated over about 2 years, most models (except for the isotropic and King) appear to perform quite similarly.
However, the oscillation effect seen in the MPIS ground truth at finer resolutions also has a large effect on the transposition models, even when using measured ground data:



Ideally, the maximized transposition models (orange) would exactly match the MPIS (green, blue) in both tracker theta and predicted irradiance, but on a minute-by-minute basis, the transposition models tend to struggle, especially when it is intermittently cloudy.


Since the predicted POA profiles have such high variance, the predicted best angle tends to oscillate between bounds.


Note that this is not really a property of the optimization method; if you replace the optimizer with a grid search for the maximum within the bounds (that is, just loop through all possible values with a resolution of 1 degree), the same thing happens. This leads me to conclude that the instability is in the transposition models, not the optimizer.
However, if we use 30m mean resampling on our 1-min GHI,DNI,DHI and give that to the transposition models, we get a result much more in line with the PSM3 & TMY datasets:

That figure also uses a grid search instead of the optimizer, to remove that variable from play. We’re also only using the Hay-Davies model in this figure, but as stated earlier, they all are pretty close. If desired, the Gaussian smoothing procedure can also be applied to the model, to get a more realistic/less spiky movement profile. This is more data-driven then something physical like the hesitation factor Nick used.

Of course, all this averaging results in a somewhat muddled view of what actually is happening. This may result in an adverse midpoint effect, where the clearsky and cloudy conditions average out and you end with something in the middle. However, if the conditions are actually sunny, there is a much greater penalty for being at that (wrong) midpoint estimate than if it was actually cloudy. Additionally, in a real tracker, we wouldn’t have future information to average over, only the past and whatever predictions you can calculate. Based on physical factors like climate, you’d also want to consider how much risk you want the algorithm to take on a case-by-case basis. For example, winters in Albuquerque, NM are very sunny, so it would be a great risk to move the tracker off the direct beam at all. However, in the summers, ABQ sees regular cloudiness and rain in the afternoon due to the North American Monsoon, so moving a tracker then would be much less risky.

All-in-all, I think my take-aways are the following:

• This method is good for modeling trackers that say they do “diffuse tracking” but the actual way of doing that is proprietary, so we need to guesstimate.
• Optimization using the transposition models can get reasonably close to the true optimal position measured by the MPIS.
• Using 1-min resolution measurements is unstable, but this can be rectified with mean aggregation at 15m/30m resolution to reduce oscillation. 
• Applying Gaussian smoothing can be quite useful to make the movement curve seem more realistic/easy to view, but along with mean aggregation, can result in a tracker ending up in an “in-between” state that is optimal in neither sunny or cloudy instantaneous conditions.
• Like Nick concluded, I think moving this to an actual tracker control algorithm would be quite difficult without some form of look-ahead forecasting.
  

Ben Pierce
R&D S&E Systems Research and Analysis
Sandia National Laboratories
bgp...@sandia.gov

To view this discussion on the web visit https://groups.google.com/d/msgid/pvlib-python/b6b78479-5d42-4c35-93c0-31a49393e503n%40googlegroups.com.

--

Ben Pierce

Sandia National Laboratories

R&D S&E Systems Analyst

mobile: (614) 787-8389

[Will Hobbs]

Nick and Ben,

This is all really interesting. 

Regarding forecasts, it would be interesting to incorporate real sky imager based forecasts into these analyses. I haven't read the report, but maybe this recently completed NYPA/EPRI project published data (or could share if someone asked): https://www.epri.com/research/products/000000003002026232, https://www.nypa.gov/news/press-releases/2023/230330-solar-forecasting-study. A university team like Jan's at UCSD certainly has sky imager forecast data and maybe they could share as well. 

On the topic of time averaging before modeling (e.g., aggregating 1min data to 15 or 30min averages), I'm thinking that any perceived benefits there might not be realized in the real world - is that correct? At least, beyond the extent that time averaging in models somewhat represents spatial averaging in plants with large footprints? Something like a rolling (lagging) average could work in a real system, but I think that ends up being similar to a simple persistence forecast in some ways (e.g., in each minute, assume the next 15 minutes look similar to the last 15 minutes).

Will

[Kurt Rhee]

Hey all,

On the topic of time averaging, in my experience, it will depend quite heavily on the tracker manufacturer's controls algorithm.  For example tracker company X may employ an architecture which controls a given Tracker Control Unit 1 [TCU 1] via a Network Control Unit A [NCU A].  Company X may sample weather at a second timestep, but then aggregate to 5 minute timesteps and then send move commands from NCU A to TCU 1 every 15 minutes.  Company Y may send move commands every 5 minutes.  These companies also probably differ in what threshold to achieve in order to go to diffuse stow in terms of spatial distribution of weather samples, time duration of weather conditions and irradiance levels.

Best,

Kurt

To view this discussion on the web visit https://groups.google.com/d/msgid/pvlib-python/d892c4bf-99f0-461f-a871-6919a6603253n%40googlegroups.com.

[Benjamin Pierce]

Hi all,

Kurt, that makes sense. It would be very useful to know the rate at which each company sends move commands in particular. 

We've found that sky cameras are pretty useful for this. What I'm doing currently is something like this:

1. Using sky images, estimate angle of maximal irradiance. I go back and forth on ways to do this, but it's basically just finding some offset theta_d from clear-sky tracking angle. A simple model would be that if the sky image has more then x% cloud coverage, then the offset will move the tracker towards diffuse stow by some amount. I've also experimented with neural networks to learn a direct mapping between the sky image -> angle of maximal irradiance.

2. Using the previous n timesteps, including the current sky image nowcast,  fit a linear regression to the tracker's movement history.

3. If the slope of the LR exceeds some threshold, move the tracker by a fixed amount (~5 degrees).

By working with the slopes of the regression, it's more about expected momentum of the previous time period then the values, and the set movement threshold reduces oscillation. The idea here is that although the trackers may only move every 15m, we keep track of where they would have moved during that time period as well, as that's useful to inform the next actual movement.

When modeling, I agree that the effect of the aggregation is pretty important, and this depends on what the trackers would actually be doing (like Kurt said, time resolution and threshold to diffuse stow). My intuition is that in absence of that information and when modeling a large enough plant, the averaging of the aggregation should get us reasonably close. I don't have utility scale data to test this on, however.

Ben