Severe underestimation of pv power production

[Stefan]

Hi,

I am troubleshooting a modelling issue. I am forecasting clearsky power for a 4kW system on south in EUW and getting very low ac power values. 

The modelling parameters are:

```
model_chain: ModelChain:
  name: South
  clearsky_model: ineichen
  transposition_model: haydavies
  solar_position_method: nrel_numpy
  airmass_model: kastenyoung1989
  dc_model: cec
  ac_model: sandia_inverter
  aoi_model: physical_aoi_loss
  spectral_model: no_spectral_loss
  temperature_model: pvsyst_temp
  losses_model: no_extra_losses
model_chain.system: PVSystem:
  name: South
  Array:
    name: South_array_0
    mount: FixedMount(surface_tilt=40, surface_azimuth=180, racking_model=None, module_height=None)
    module: Trina_Solar_TSM_330DD14A_II_
    albedo: 0.25
    module_type: None
    temperature_model_parameters: {'u_c': 29.0, 'u_v': 0}
    strings: 1
    modules_per_string: 16
  inverter: SolarEdge_Technologies_Ltd___SE4000__240V_
model_chain.system.arrays: (Array:
  name: South_array_0
  mount: FixedMount(surface_tilt=40, surface_azimuth=180, racking_model=None, module_height=None)
  module: Trina_Solar_TSM_330DD14A_II_
  albedo: 0.25
  module_type: None
  temperature_model_parameters: {'u_c': 29.0, 'u_v': 0}
  strings: 1
  modules_per_string: 16,)
```

The peak power produced from this system is about 300W. I would expect at least a factor 10 higher. I have checked the weather data input, and that seems fine (dni is around 800 W/km2).

The code which has this issue is large so a bit difficult to debug (I can link the github repo if needed). I have replicated the same system in a separate file and that system estimates the AC power correctly. So I am at a bit of a loss here on where to search for the issue. 

[Kevin Anderson]

A useful method of figuring out where to look for code errors is to inspect the intermediate modeling results to find where in the modeling chain the unexpected results begin.  Plots are often a good place to start.  For example, with clear-sky weather inputs and a south-facing array, the simulated plane-of-array irradiance profile should be symmetrical and centered at solar noon.  If it isn't, then maybe the array orientation isn't what you expect, or the clear-sky irradiance somehow doesn't correspond correctly to the solar position.  Here's an example where the plot on the left shows correct results and the plot on the right shows strangeness due to a time zone error I introduced:  

If that plot looks correct (good shape, values are correct scale/units, etc), then probably the problem is somewhere "downstream" of the irradiance transposition step, for example in the temperature or power models.  Then you can keep looking at other intermediate results until you find something that looks wrong.

Kevin

--
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/27a9d492-e330-43a8-9319-d1e4e69aa76cn%40googlegroups.com.

[Stefan]

Hi Kevin, thanks. I have found out the issue only occurs when forecasting for dates from 2024 and beyond. So obviously you would think there's some issue in the radiation data, but it's fine. This has really got me stumped. 

Op donderdag 11 januari 2024 om 15:10:05 UTC+1 schreef kevina...@gmail.com:

[kevina...@gmail.com]

If the weather inputs are fine, but the AC power is not, then the problem must be somewhere between those two points in the modeling chain.  Performing a "binary search" as I described should identify where the problem is introduced.

If you are able to extract a data frame containing the weather inputs and various model outputs (solar position, total irradiance, power, etc) for a period that exhibits the issue, someone here might take a look.

Kevin

[Stefan]

I guess the problem is here, plotting the solar position from `modelchain.position.get_solarposition()`

However somehow the AC power looks somewhat okay?

The only difference I see is this, this is the datetimeindex for the broken modelchain:
DatetimeIndex(['2023-01-11 00:00:00+00:00', '2023-01-11 01:00:00+00:00',
               '2023-01-11 02:00:00+00:00', '2023-01-11 03:00:00+00:00',
               '2023-01-11 04:00:00+00:00', '2023-01-11 05:00:00+00:00',
               '2023-01-11 06:00:00+00:00', '2023-01-11 07:00:00+00:00',
               '2023-01-11 08:00:00+00:00', '2023-01-11 09:00:00+00:00',
               '2023-01-11 10:00:00+00:00', '2023-01-11 11:00:00+00:00',
               '2023-01-11 12:00:00+00:00', '2023-01-11 13:00:00+00:00',
               '2023-01-11 14:00:00+00:00', '2023-01-11 15:00:00+00:00',
               '2023-01-11 16:00:00+00:00', '2023-01-11 17:00:00+00:00',
               '2023-01-11 18:00:00+00:00', '2023-01-11 19:00:00+00:00',
               '2023-01-11 20:00:00+00:00', '2023-01-11 21:00:00+00:00',
               '2023-01-11 22:00:00+00:00', '2023-01-11 23:00:00+00:00',
               '2023-01-12 00:00:00+00:00'],
              dtype='datetime64[us, UTC]', name='datetime', freq=None)

And this is the datetimeindex for the separate script which is working:

DatetimeIndex(['2023-01-11 00:00:00+00:00', '2023-01-11 01:00:00+00:00',
               '2023-01-11 02:00:00+00:00', '2023-01-11 03:00:00+00:00',
               '2023-01-11 04:00:00+00:00', '2023-01-11 05:00:00+00:00',
               '2023-01-11 06:00:00+00:00', '2023-01-11 07:00:00+00:00',
               '2023-01-11 08:00:00+00:00', '2023-01-11 09:00:00+00:00',
               '2023-01-11 10:00:00+00:00', '2023-01-11 11:00:00+00:00',
               '2023-01-11 12:00:00+00:00', '2023-01-11 13:00:00+00:00',
               '2023-01-11 14:00:00+00:00', '2023-01-11 15:00:00+00:00',
               '2023-01-11 16:00:00+00:00', '2023-01-11 17:00:00+00:00',
               '2023-01-11 18:00:00+00:00', '2023-01-11 19:00:00+00:00',
               '2023-01-11 20:00:00+00:00', '2023-01-11 21:00:00+00:00',
               '2023-01-11 22:00:00+00:00', '2023-01-11 23:00:00+00:00',
               '2023-01-12 00:00:00+00:00'],
              dtype='datetime64[ns, UTC]', freq='H')

As you can see the broken one has no frequency defined. Could that be it? I can hardly believe that would break the whole modelchain...

Op donderdag 11 januari 2024 om 15:44:43 UTC+1 schreef kevina...@gmail.com:

[Stefan]

I have managed to narrow it down. This fixes the issue:

weather.index = weather.index.astype("datetime64[ns, UTC]")

While this causes the issue:

weather.index = weather.index.astype("datetime64[us, UTC]")

This has to be a bug right?

Op donderdag 11 januari 2024 om 22:54:35 UTC+1 schreef Stefan:

[Stefan]

By 'causes the issue', I mean that using the datatype datetime64[us] breaks the model chain. I was able to replicate this in my separate script.

Op vrijdag 12 januari 2024 om 00:46:10 UTC+1 schreef Stefan:

[cwh...@sandia.gov]

What version of pandas as you on?

[Stefan]

I'm on pandas  2.0.2

Op vrijdag 12 januari 2024 om 00:52:41 UTC+1 schreef cwh...@sandia.gov:

[kevina...@gmail.com]

Yes, a bug.  Sorry for the inconvenience!  It is tracked here, to be fixed in the next release: https://github.com/pvlib/pvlib-python/issues/1932

Just for my own learning, do you know why that index has unit='us' instead of the default 'ns'?  Where did it come from?

Kevin

[Stefan]

Hi Kevin, in my case it's because I use polars intead of pandas internally and before passing the dataframe to pvlib I convert it. Apparently the default timeunit for all polars datetime functionality is 'us'. 

Op vrijdag 12 januari 2024 om 15:42:06 UTC+1 schreef kevina...@gmail.com: