Docs: explain difference to pvlib

[dacoex]

over at pvlib there are efforts for improved system modelling:
pvlib/pvlib-python#17
pvlib/pvlib-python#93
pvlib/pvlib-python#84 (comment)

How do the function in feedinlib comapre to these?
Complemnatry or do they supersede these?

Thanks.

[gplssm]

thanks @dacoex for pointing to the overlapping goals of pvlib-python and feedinlib.

I'm not sure if I got it right. As far as I understand pvlib-python aims for a comprehensive class that describes a PV system on the whole (covering cells, modules, arrays, circuitry, inverter, ...).

feedinlib basically has the same goal: providing methods that generate time series of pv and wind power generation. this, on the pv side, based on pvlib-python. So, in my perception both basically want to do the same.

Does this clarify your questions a little bit?

I have to be honest and say that I don't have the full overview on pvlib-python... But if I got it right and we have the same goals, we should collaborate closely and organize our work together avoiding double effort. I would be happy if you would support this!

[dacoex]

I'm not sure if I got it right.
You got it right.

As far as I understand pvlib-python aims for a comprehensive class that describes a PV system on >the whole (covering cells, modules, arrays, circuitry, inverter, ...).
Yes, it seemed to be a library for the basic stuff.

But as the links I provided show there are plans to expand in order to cover the whole system modeling chain.

take a look at this (PR is pending):
http://nbviewer.ipython.org/github/jforbess/pvlib-python/blob/Issue84/docs/tutorials/system_loss_modeling.ipynb
https://github.com/jforbess/pvlib-python/blob/Issue84/pvlib/data/site_config.csv

feedinlib basically has the same goal: providing methods that generate time series of pv and wind >power generation. this, on the pv side, based on pvlib-python. So, in my perception both basically >want to do the same.

Let me put it this way: what do you plan in feedinlib what cannot be done in pvlib?
Or is it right to understand that feedinlib want to put an higher abstraction on top of pvlib?
I just want to know for my self, which one I should prefer for my own modelling and where I would submit which contributions to.

But if I got it right and we have the same goals, we should collaborate closely and organize our >work together avoiding double effort.

That's the reason for the question. cooperation can happen once the limits / roadmap of the projects are clear.

Does this clarify your questions a little bit?

Thanks, yes it can help given the new questions are answered.

[wholmgren]

I suppose that I should chime in here as a pvlib-python maintainer.

First, let me say that I'm glad that the feedinlib team has found pvlib to be a suitable foundation for their own library and that the work that they're doing here is great. I'd also like to recognize that feedinlib's @uvchik has made good, constructive contributions to pvlib. So, I welcome collaboration and/or friendly competition with the feedinlib team.

As far as I understand pvlib-python aims for a comprehensive class that describes a PV system on the whole (covering cells, modules, arrays, circuitry, inverter, ...).

Yes, that is the primary goal of my proposal in pvlib/pvlib-python#93, though the implementation is far from complete.

The other thing that I'm trying to do in that PR is make the core library slightly less complicated by removing the Location objects from the core library function calls. I think this is the right move regardless of whether or not the comprehensive PVSystem class is added, but I haven't had much feedback on that. It would likely break your existing feedinlib code, though, so I'd love to hear your feedback on it. Also see pvlib/pvlib-python#17 for more. The summary is that the core of pvlib should be as accessible as possible, and that Location (and eventually PVSystem) objects force people into a structure that is may be unfamiliar and not useful.

Aside from the short term pain of breaking existing code that relies on Location objects in function calls, my PR is dangerous because it would be a relatively large feature addition that is not part of the traditional scope of pvlib. Both the matlab and python versions of pvlib have historically been a reference implementation of useful models for PV systems. It may be that my proposed functionality belongs in a separate library, such as this one. It may be that the fragmentation of functionality across libraries makes it harder for people to see any of them as viable choices for their own research or applications. It may be that consolidation into one library leads to faster progress, or it may be that consolidation leads to slower progress as the library becomes more difficult to maintain. If you make a project's scope too small, then you might not have a large enough user base to support it in the long term. If you make the scope too big, then you might not do anything well.

I think that it's important to point out that pvlib is used for a wide variety of applications. I use it to model and forecast 1 GW of PV in AZ (a class model would be helpful to me), somebody could use it to help characterize a single panel's DC characteristics in the lab (classes are probably not helpful here), and others may use it for performance validation or warranty claim support (classes might be helpful depending on the application).

Hopefully it's clear that I am unsure as to what the future scope of pvlib-python should be.

From a project maintenance perspective, I think that collaborating more closely and/or merging parts of the projects would be helpful. I'm sometimes speaking only with myself over at pvlib-python, which makes it hard to think through ideas and get good peer review (no hard feelings pvlib-python users/devs, I know that you're busy). pvlib-python issues such as pvlib/python-pvlib#90 are silly things that don't need to be reinvented by both libraries. There's also a lot of overhead in documentation that could be avoided. I am certainly willing to give pvlib-python commit rights to the feedinlib team, if appropriate.

There is one major issue, though, that is keeping me from saying anything more concrete regarding collaboration vs. friendly competition: feedinlib is GPL and pvlib-python is BSD. This means that feedinlib developers can read, modify, and use pvlib-python code, but it's legally dubious for pvlib-python developers to even look at the feedinlib source code if we're considering any overlapping functionality in pvlib-python. Of course, I am not a lawyer, but that's my understanding of it after spending a good deal of time on the topic of licenses.

Best,
Will

[dacoex]

@wholmgren Thanks for starting to comment also.

This discussion that both libraries are still young and need clear definition of current and planned scope.

In my few, pvlib would provide all the basics to model a PV system from meteo data to grid connection point.

This said, I would like to see the system modelling be part of pvlib because it's core simulation stuff (see:http://nbviewer.ipython.org/github/jforbess/pvlib-python/blob/Issue84/docs/tutorials/system_loss_modeling.ipynb).

The meteo modules (http://pvlib-python.readthedocs.org/en/latest/pvlib.html#module-pvlib.irradiance, http://pvlib-python.readthedocs.org/en/latest/pvlib.html#module-pvlib.atmosphere, http://pvlib-python.readthedocs.org/en/latest/pvlib.html#module-pvlib.clearsky) are rather applied meteorology and would also be of interest to CSP or CPV modellers. Thus, these would actually fit in a separate package. But better to have these that not at all.

Maybe the forecasting (e.g. pvlib/pvlib-python#86) and grid-related stuff (curtailment, etc.) could be moved to feedinlib.

a few things that should be addressed independently:

• typical use cases for each library
• scope & limits
• functional roadmap

After this, other parts may be more clear.

No to the collaboration points:

It may be that the fragmentation of functionality across libraries makes it harder for people to see >any of them as viable choices for their own research or applications. It may be that consolidation >into one library leads to faster progress, or it may be that consolidation leads to slower progress as >the library becomes more difficult to maintain. If you make a project's scope too small, then you >might not have a large enough user base to support it in the long term. If you make the scope too >big, then you might not do anything well.

After above is more clarified, I think it will be easier to know where goes what.
There is already a lot of fragmentation:

• Sandia researchers of PVPMC continue work in matlab
• Others may choose to work in python (i.e. pvlib) as said on 4th PVPMW, Cologne
• Python also has pysolar

I think that collaborating more closely and/or merging parts of the projects would be helpful. I'm >sometimes speaking only with myself over at pvlib-python, which makes it hard to think through >ideas and get good peer review

that's right and I admire your commitment of stringent and good code quality!
The issue is probably that most potential users are not "coders for life" but have PV project work as their main activity. So they use the library to solve problems where other tools fail.

The only thing to change this probably to concentrate on 1 library and make pvlib the "pandas of PV". More eyes can review more making everyone more productive.

There is one major issue, though, that is keeping me from saying anything more concrete
regarding collaboration vs. friendly competition: feedinlib is GPL and pvlib-python is BSD.
Oh, yes, this needs to be sorted.

For the benefit of a common conclusion, let's use this issue to clarify scopes and then develop the roadmap within each project.

What do you think?

[gplssm]

Thank you a lot for your extensive answers/ explanations! That really helped me to clarify things...

I'll try to answer your questions as far as I'm able to, but I must say that @uvchik is the one pushing things forward in the feedinlib project and so he can be seen as the maintainer. Thus, I can't decide to much concerning future development of feedinlib. Currently he is off for probably the next 10 days.

First of all I'd like to describe the scope/ future features of the feedinlib. We use the feedinlib to generate time series of renewables (wind and pv) feedin, that we apply to energy system models. Often we use region-models where we need a single time series representing pv/ wind power generation for a larger area ranging from a city, federal state up to a whole state (i.e. countries of EU). This requires features exceeding pvlib's scope. For example, we would like to apply the pv and the wind power model to all wind and pv power plants listed in a published register of power plants in germany, calculating the power and aggregating it covering an area of i.e. a federal state.

We really appreciate having found pvlib-python that saves us a lot of time, because we don't have to implement a pv model!
So, I think it's clear that we don't want to be compete with pvlib, we are happy of each block of code we don't have to hack in. Our goal is to provide higher level functionality that produces time series that can be applied in energy system models to investigate power dispatch, capacity expansion, ...

You are right, that a clear roadmap for both libs would be perfect to define the scope of the lib and to present a concise description of features to new users. Currently, we don't have that for the feedinlib, but we should set it up.

The class PVSystem of the PR discussed in pvlib/pvlib-python#93 quite exactly fits our need of applying the pvlib in feedinlib. Thus, from my personal perspective it would be helpful if it would be part of pvlib. I guess we would edit feedinlib's code to make use of this class (opinion of @uvchik may differ).

Concerning the planned changes of the Location object I can't give you feedback right now. I not the deep into pvlib to judge this right at the moment, but I will have a look at it soon. In general: if you, @wholmgren, decide to change/ improve your code and this would break existing code in feedinlib, we have to manage it and I think we are fine with that if it not happens every day.

From my personal perspective it would be perfect if pvlib ends at modeling the whole system of a pv power plant (after inverter) with an easy interface as it is provided by PVSystem. This would lead to no overlapping scope of both libs. But I'm curious to hear @uvchik opinion...

There is one thing else we haven't had the discussion: feedinlib also contains a wind model that is totally independent from pvlib. In my opinion it makes sense to have wind and pv power in the same lib (feedinlib) in order to apply aggregation methods to both types of power plants models.

The licensing issue could get really nasty in terms of discussing any merging intentions of both libs. Aside from that it shouldn't be a problem, right? I'm open to discuss licensing of feedinlib to switch to a not that restrictive one, but this again up to @uvchik. For further reading on the license thing: The openmod initiative compiled some facts about choosing a license (for energy system models)

If I missed some questions, please just point me on that.

[dacoex]

@gplssm Thanks.

First of all I'd like to describe the scope/ future features of the feedinlib. We use the feedinlib to >generate time series of renewables (wind and pv) feedin, that we apply to energy system models. >Often we use region-models where we need a single time series representing pv/ wind power >generation for a larger area ranging from a city, federal state up to a whole state (i.e. countries of >EU).

It's now very clear that feedinlib adds a higher abstraction layer on top of pvlib and others.
Maybe you could even add this to your main docs. It is a good description.

There is one thing else we haven't had the discussion: feedinlib also contains a wind model that is >totally independent from pvlib.

You may want to check this also:
https://github.com/wrobstory/climatic

I agree with most. Except:

From my personal perspective it would be perfect if pvlib ends at modeling the whole system of a pv >power plant (after inverter) with an easy interface as it is provided by PVSystem.

Let's consider PV plant up to grid connection point.

This would lead to no overlapping scope of both libs. But I'm curious to hear @uvchik opinion...

This is great. Because urbs devs and others would contribute to the right place.

You are right, that a clear roadmap for both libs would be perfect to define the scope of the lib and >to present a concise description of features to new users.
Currently, we don't have that for the feedinlib, but we should set it up.

@wholmgren What do you say about adding a wiki page for the same over at pvlib?

[uvchik]

First, I would like to say, that I am a maintainer but not the maintainer.

The class PVSystem of the PR discussed in pvlib/pvlib-python#93 quite exactly fits our need of applying the pvlib in feedinlib. Thus, from my personal perspective it would be helpful if it would be part of pvlib. I guess we would edit feedinlib's code to make use of this class (opinion of @uvchik may differ).
Concerning the planned changes of the Location object I can't give you feedback right now. I not the deep into pvlib to judge this right at the moment, but I will have a look at it soon. In general: if you, @wholmgren, decide to change/ improve your code and this would break existing code in feedinlib, we have to manage it and I think we are fine with that if it not happens every day.

@gplssm, I totally agree with that. As we started the feedinlib, pvlib was a toolbox. So we started to use the toolbox with our weather data set. This is now the pv part of the feedinlib. If there is a higher class in the pvlib that shortens our code I would change the feedinlib code to use it. I am not interested in writing duplicate code. The only important thing for me is, to have one weather object that can be passed to the pv model and the wind model. So that every user can create a weather object using any weather dataset and will get the electrical output of wind and pv systems.

Both the matlab and python versions of pvlib have historically been a reference implementation of useful models for PV systems. It may be that my proposed functionality belongs in a separate library, such as this one. It may be that the fragmentation of functionality across libraries makes it harder for people to see any of them as viable choices for their own research or applications. It may be that consolidation into one library leads to faster progress, or it may be that consolidation leads to slower progress as the library becomes more difficult to maintain.

@wholmgren, I'm not sure, either, what is the best way to do it. Whatever I could link to a higher pvlib class or develop an own one within the feedinlib. In my opinion the higher classes of the pvlib should be supplementary, so that the library does not lose its toolbox character. Such classes could make it easier for non-experts to use the pvlib. But for me it is not important where the code is located within the pvlib or within a library such as the feedinlib. I really like the pvlib project and I will help as much as I can, but in the next three month I will not be of much help. Our aim is the publish the whole energy modelling framework soon and this will take my time.

I hope the licence will not prevent us from a productive collaboration but I am not a lawyer.

It's now very clear that feedinlib adds a higher abstraction layer on top of pvlib and others. Maybe you could even add this to your main docs. It is a good description.

@dacoex, Do you like to make a concrete suggestion as a PR, because I do not fully understand what you want to add to the documentation.

[dacoex]

Do you like to make a concrete suggestion as a PR, because I do not fully understand what you >want to add to the documentation.

I guess the conclusion of this disussion to either documentation under a section "scope / limitation" or alike.

[wholmgren]

@gplssm and @uvchik: thanks, this is a great discussion and feedinlib is a great project. I'm leaning towards adding the higher level functionality to pvlib, but I think I would need several months to thoroughly try it, test it, and document it.

In my opinion it makes sense to have wind and pv power in the same lib (feedinlib) in order to apply aggregation methods to both types of power plants models.

I agree with this so long as the individual wind and pv parts of the library are at a relatively high level (feedinlib). It's hard for me to see how pvlib and a similar library for wind could be cleanly combined, and I'm not interested in adding anything related to wind power to pvlib. It wasn't totally clear, but I think we're all in agreement on this.

Regarding the license issue, that openmod page is a nice reference. Here are a couple of pro-BSD links that mostly explain why I want to keep pvlib BSD licensed: Jake VanderPlas, Titus Brown and John Hunter. That being said, I'll respect your choice if you want to stick with the GPL.

[uvchik]

Done!