ModelChain with weather data

[uvchik]

Some time ago we started the feedinlib project to calculated the output of wind and pv power plants with a given weather data set. The pv part of the feedinlib is an application of the pvlib similar to the ModelChain, which did not exist when we started.

In my opinion a ModelChain with weather data is better located within the pvlib, so I would like to move this functionality from the feedinlib to the pvlib. The structure should be similar to the existing ModelChain while the content could be base on the existing feedinlib model.

My idea is to define a weather class containing the weather data and the meta data of the weather data set similar to the weather class of the feedinlib. A weather object could be passed to a new ModelChain or to an expanded ModelChain.

I would like to discuss the idea before creating a PR to avoid obsolete work.

What do you think of this idea?

[wholmgren]

If I'm understanding correctly, feedinlib's FeedinWeather is similar to pvlib's Location but with a data attribute that contains weather data, and then the rest of feedinlib works on that object. In contrast, ModelChain takes a Location and a PVSystem object on initialization, and then the run_model method takes separately defined weather and irradiance data. Of course, one can assign a data attribute to a Location object and then pass the attribute to run_model (I've used this pattern in the past). It seems to me that this kind of data organization is best left to the user, but I could be wrong! Can you say more about why you don't want to simply adopt the pvlib approach here?

On a somewhat related note, I don't particularly care for the fact that run_model has separate irradiance and weather inputs. It may well be better to have a single dict-like weather input that includes irradiance.

[uvchik]

First I have to say that I have overlooked the possibility to pass a weather object to the model chain, so some of the things I wrote above are obsolete now. It definitely makes sense for me to enhance the ModelChain instead of writing something new.

I am pretty sure that we will find a way to keep the API as it is and still make it possible to pass a weather DataFrame containing wind_speed, temperature and(!) irradiation.

One problem is the calculation of the irradiation in plane if you use hourly weather data or measurement data. Sometimes we had a morning and evening peak due to timing differences between the direct irradiation and the height of the sun or due to measurement deviations. In the feedinlib we calculated something like an average angle ors even cut the direct irradiation for very small angles.

But I think these are details and we could easily discuss this in a PR if you do not have any general objections.

[wholmgren]

Sounds good. I've also wondered about those sub hourly issues in ModelChain but I never implemented anything.

[uvchik]

I just combined the feedinlib weather object with the ModelChain and it seems to work fine. We also moved the wind model to a windpowerlib. So one feature of the feedinlib in the future will be: getting the weather data directly from a database and passing it to external libraries such as pvlib or windpowerlib. There will not be a pv or wind model placed in the feedinlib.

Here is the example (fyi):
https://github.com/oemof/feedinlib/blob/dev/example/feedinlib_example_new.py

Processing the weather data so that it suits to pvlib's needs could be part of the feedinlib but I would like to have the following code to be part of pvlib's ModelChain. It fits good with the internal cosd-function.
If you agree I will make a PR.

from pvlib.tools import cosd
...
if irradiance.get('dni') is None:
    irradiance['dni'] = (irradiance.ghi - irradiance.dhi) / cosd(self.solar_position.zenith)

If you like we could do the same for the ghi:

from pvlib.tools import cosd
...
if irradiance.get('ghi') is None:
    irradiance['ghi''] = irradiance.dni * cosd(self.solar_position.zenith) + irradiance.dhi

Then one could either pass ad DataFrame with dni and dhi, or ghi and dhi or all three. We can write such a function for the feedinlib, too but I think its better to have it in the pvlib.

[wholmgren]

Looks good to me. It probably makes sense to have a similar calculation for both ghi and dhi so that supplying any 2 of the 3 components will work.