Return POA and cell temp from main.run_nwp

[williamhobbs]

Would it be possible to modify solarforecastarbiter.reference_forecasts.main.run_nwp to return POA (or effective POA) and cell temperature? Evaluating forecasts of these values could be useful as they can be the last step before PV plant availability/performance issues start to influence forecasts.

[wholmgren]

Hmm. It's doable, but it's not entirely obvious how to do it cleanly.

This line computes AC power

https://github.com/SolarArbiter/solarforecastarbiter-core/blob/24a3aa68a30e0813382cf98f4db558b88dd49942/solarforecastarbiter/reference_forecasts/main.py#L140-L142

So looking at irradiance_to_power...

https://github.com/SolarArbiter/solarforecastarbiter-core/blob/24a3aa68a30e0813382cf98f4db558b88dd49942/solarforecastarbiter/pvmodel.py#L305-L341

We could return poa_effective along with ac, but cell temperature is not immediately available. That could be returned by calculate_power

https://github.com/SolarArbiter/solarforecastarbiter-core/blob/24a3aa68a30e0813382cf98f4db558b88dd49942/solarforecastarbiter/pvmodel.py#L270-L302

Or we could refactor the temperature and wind speed out of calculate_power: compute it in irradiance_to_power and pass the cell temperature to calculate_power.

Perhaps irradiance_to_power would return a namedtuple with those results (like run_nwp and a few other functions). Or perhaps that's a different function like irradiance_to_poa_temp_power.

Would we also want to bundle the dc result? That would require further refactoring of calculate_power.

In any case, I think all of the downstream calls of run_nwp in the Arbiter are robust to the tuple contents since we lookup by attribute instead of position:

https://github.com/SolarArbiter/solarforecastarbiter-core/blob/24a3aa68a30e0813382cf98f4db558b88dd49942/solarforecastarbiter/reference_forecasts/main.py#L454

Technically it's an API breaking change, but I'm not aware of anyone directly using this code except for you.

[williamhobbs]

Maybe I'm just not thinking of the right use-case, but I don't think dc would be too useful, since "unclipped" dc power can't be fully measured, and I don't think there a lot of common scenarios where inverter efficiency drops meaningfully (at least, meaningful relative to forecast errors).

And, to be honest, cell temperature may not be that important. I'm really just interested in POA (which may need to be poa_effective) and I added cell temp since I was thinking that might be useful in the future.

As background, in case it's helpful, I've been running a 4 hour ahead, hour interval AC power forecast with HRRR for a 1-axis tracking facility. It isn't performing as well as I expected, so a created a GHI forecast that seems much better. Now I'm trying to figure out where the discrepancy is, and I've realized things like plant availability can complicate things and evaluating POA accuracy could be useful.

AC power forecast, with a clear positive bias and lots of scatter (values along the y-axis with 0 observed power are from a plant outage, so not a forecast issue):

GHI forecast, with minimal bias and much less scatter:

2021-11-05 Edit: I realized I was running an old release of solarforecastarbiter-core (before the DNI projection fix for POA) and I had the wrong DC loss factor for the facility. POA data could still be useful, but the issue I was seeing is much less of a problem.

[wholmgren]

Thanks for the additional background. @cwhanse and I heard similar feedback when developing Solar Performance Insight for O&M applications.

We allow users to create observations and forecasts for the following list of variables

It's reasonable to think the NWP code should support as much of that list as possible. I also agree with prioritizing POA.

I'd be happy to support a pull request, but I'm not sure when we'd be able to get to it ourselves. We need to focus on issues for the forecasting prize competition over the next few months. I suspect it would take an hour or so to update the pvmodel and run_nwp code but substantially longer to update the tests.

[williamhobbs]

Understood on resource constraints. And I have the fairly easy option of calculating POA outside of run_nwp if I need it.