There appears to be a problem with the conda scipy package for Python 3.4 on linux. This impacts us because we use the scipy.special.lambertw function when calculating IV curves. See more:

ContinuumIO/anaconda-issues#243 (comment)

http://stackoverflow.com/questions/30792319/anaconda3-scipy-special-lambertw-function-return-nan

The Perez option in total_irrad does not work due to the fact that the airmass keyword argument was changed in the last release.

A good pattern seems to be to make a separate file for each release.

Possibly helpful links

https://github.com/pydata/pandas/tree/master/doc/source

https://github.com/ipython/ipython/tree/master/docs/source

https://github.com/statsmodels/statsmodels/tree/master/docs/source

I wrote a new tmy_to_power notebook that replaces Test_Scripts.

I have great difficulty with this upstream - pull request thing. I spend more time correcting mashups than doing worthwhile coding.

Perhaps the tmy_to_power notebook was committed, but I did not find it after fetch upstream & merging to my branch. Test_Scripts is still there.

In windows, receive an error using index.astype in solarposition.py line 284:

from datetime import datetime
t = datetime(2014,1,1,12,0,0)
import pandas as pd
panda_t = pd.to_datetime([t,])
import pvlib
loc = pvlib.location.Location(53, -1.5, tz='UTC')
print pvlib.solarposition.get_solarposition(panda_t, loc)
Traceback (most recent call last):
File "", line 1, in
File "C:\Users\ph1jt\Anaconda\lib\site-packages\pvlib\solarposition.py", line 79, in get_solarposition
how='numpy', kwargs)
File "C:\Users\ph1jt\Anaconda\lib\site-packages\pvlib\solarposition.py", line 284, in spa_python
unixtime = localize_to_utc(time, location).astype(int)/109
File "C:\Users\ph1jt\Anaconda\lib\site-packages\pandas\tseries\index.py", line 713, in astype
raise ValueError('Cannot cast DatetimeIndex to dtype %s' % dtype)
ValueError: Cannot cast DatetimeIndex to dtype int32

Changing line 284 in solarposition from:

    unixtime = localize_to_utc(time, location).astype(int)/10**9

to:

    unixtime = localize_to_utc(time, location).astype('int64')/10**9

fixes the issue.

similar to Sandia-Labs/PVLIB_Python#40 , ensure compatibility in the new package

I don't fully understand the differences of meta, location, and systemdef, in terms of how they should be used.

systemdef expects TMY meta to be used in its first parameter. But what if I want to use the lat/long for my plant, not the TMY station? What if I am looking at operating data (which I am), and have no need to pull in a TMY file?

Why doesn't systemdef use a location instead of a TMY meta as its first parameter? (Why isn't a TMY meta a Location object?)

This issue can be a place to list methods that should be identified as private methods. Private methods start with _, they do not show up in the documentation, and they should not be relied on by end-users.

* pvlib.pvsystem.golden_sect_DataFrame
* pvlib.pvsystem.Voc_optfcn
* pvlib.pvsystem.pwr_optfcn

Recommend a 0.2 tag.

This issue is for discussion of the 0.2 release process.

https://pvpmc.sandia.gov/resources-for-members/pv_lib-toolbox/

"Download the PVLIB_Toobox for Python (This sends you to an external GitHub site)"
at the bottom points to
https://github.com/Sandia-Labs/PVLIB_Python

Add
https://github.com/pvlib/pvlib-python/tree/master/docs/tutorials
to
http://wholmgren-pvlib-python-new.readthedocs.org/en/docfixes/index.html#

maybe with a link to the nbviewer.
there's also a ipython sphinx plugin
http://matplotlib.org/sampledoc/extensions.html#ipython-sessions
https://github.com/ipython/ipython/tree/master/IPython/sphinxext

I am having missing values when using DISC to simulate DNI, I trad this using clear sky GHI data and even with data I have from a measuring device
For an example try this:

import datetime
import pandas as pd
from pvlib.location import Location
import pvlib.solarposition
import pvlib.clearsky

# make a location
tus = Location(32.2, -111, 'MST', 700)
# make a pandas DatetimeIndex for some day
times = pd.date_range(start=datetime.datetime(2014,6,24), end=datetime.datetime(2014,6,25), freq='1Min')
# calculate the solar position
solpos = pvlib.solarposition.get_solarposition(times, tus, method='pyephem')
# calculate clear sky data
tus_cs = pvlib.clearsky.ineichen(times, tus, airmass_model='young1994')
ax = tus_cs.plot()
# calculate the direct normal irradiance using GHI from the clear sky data
DNI= pvlib.clearsky.disc(Time= solpos.index, GHI=tus_cs.GHI, SunZen=solpos.zenith)
DNI.DNI_gen_DISC.plot(ax=ax, legend=True)

Am I doing something wrong ??

At what point should we push the initial release to PyPi? I'm leaning towards pushing after #6 and #13 are resolved with the 0.1 tag.

Thoughts?

Calama consulting is developing a set of notebooks using the NREL Regional Test Centre data which will compare the pvlib models to physical reality. Anyone who is interested in assisting with this, please get in touch

A few of us are writing a paper/poster for PVSC 2015, and we need your help to make it better. The main purpose of this paper/poster is to advertise the pvlib-python project to a large audience. This will hopefully attract more users, testers, developers, and maybe eventually some institutional support.

For the poster, we would like to showcase how pvlib-python is being used in your applications with graphics and code snippets. Contributions could be anything from a graph plus caption to a full column on the poster. Please let us know if you have anything to share!

For the paper, I don't anticipate doing much beyond what's already in the abstract. However, let me know if there's anything in particular that you want to see added to the paper. The abstract is available at pvlib/pvsc2015.

I don't think it's possible to add new authors at this point, but you will be gratefully acknowledged in the paper, on the poster, and in any discussions during the poster session.

Thanks!
-Will

cc @Calama-Consulting @alorenzo175 @bmu @jforbess @uvchik

Now that we have our first release we need to make a decision regarding how to handle the git tree. This was discussed a bit in Sandia-Labs/PVLIB_Python/issues/33, and @uvchik brought it up in #15.

I always look first to copy IPython and/or pandas. The ipython system is roughly:

• master should be the next major release. Now that 0.1 is on pypi, this would mean that the master version should be updated to something like 0.2.0dev. See release.py
• Branches should be created for any maintenance releases. So, if we're going to bother with a 0.1.1 release then it should be developed in a 0.1.x branch.

So far as I can tell, pandas just keeps bumping the version number by 0.0.1 or 0.1 according to the scope of whatever has been merged. Maybe they let some bigger PRs rot for awhile if they're trying to focus on a maintenance release.

In principle I like the IPython system, but in practice, I think that we should go with the pandas system at this early stage. The IPython system probably makes more sense if/when we get to 1.0 and 2.0 releases. However, I don't care too much about this (we just need a decision so that we can update the version file), and I am especially willing to go with the IPython system if somebody else volunteers to be the main administrator of the maintenance releases and development.

Whatever we decide on should be added to the Development wiki.

It appears to me that we may be in violation of NREL's SPA license

"The Software is being provided for internal, noncommercial purposes only and shall not be re-distributed."

A couple of potential problems:

• We are redistributing their code rather than just making binaries with it.
• We (or at least I) don't want to limit pvlib-python to non-commerical purposes. Everything else in pvlib-python is, to my knowledge, able to be used in commercial applications.

The license goes on to say that you must contact them about using it in commercial applications.

Am I reading this wrong? @Calama-Consulting did you have a different interpretation of this when you added the SPA code to pvlib?

Scipy either needs to be added to the setup.py file or we need to wrap the scipy statement with try/except and then throw a warning about reduced usability.

I would lean towards the latter as scipy installation is much more difficult than numpy and pandas. Best would be to remove the scipy.io dependency entirely.

@Calama-Consulting and I discussed creating DOIs for pvlib releases. I just hooked up our repo to Zenodo so that it will automatically create DOIs for each release. I'll add the badge to the Readme after we release 0.2.

To test the system, I rereleased the PVSC 2015 repo to trigger the DOI creation and then I added the new badge. It takes a little bit of time for DOIs to propagate, but hopefully the link on that readme will work soon.

We should also discuss how we would want people to cite pvlib in academic papers. See e.g.

http://ipython.org/citing.html

http://matplotlib.org/citing.html

http://deeplearning.net/software/theano/citation.html#citation

My only recommendation for now is to just use the papers in the PVSC 2014 and 2015 proceedings. I don't know how to specifically cite github contributors.

From a conversation started in #37 by @bmu :

As an idea, they could possibly also be used by users in the future, if we would switch to dataframe inputs for some functions or a different kind of api. This would enable us to include som e "magic" functions, e.g the signature of the ominous globalinplane function could look like this:

def globalinplane(df, surface_tilt, surface_azimuth, diffuse_model='perez', 
              decomposition_model=None):
"""Determine GPOA from either GHI and DHI or from GHI only

Parameters
---------------
df : pandas.DataFrame
      A DataFrame containing all necessary columns acoording to naming conventions
      (maybe surface_tilt and surface_azimuth could also be contained in the df, 
       e.g. for tracking systems.) 
decomposition_model : None or str
      The model to use if only GHI is given in the DataFrame
....
Returns
-------
The input DataFrame plus columns `direct tilted`, 'diffuse tilted`, `GPOA` ...
""""

This function could look which columns are in the DataFrame and compute all necessary columns (e.g. if time is given as local time, compute utc or true solar time).

From my experience this is usefull for beginners because there are quite a lot of simulation steps required to calculate GPOA from GHI (maybe convert times, decomposition in direct and diffuse, diffuse model, ground reflection, direct tilted, ...?).
And there are other options, e.g. claculate expected energy yield from only a system description, Location and a DataFrame containing GHI and ambient temperature.

This is just an idea, not sure about the difficulties. There may be some complexity when implementing something like this (more on the definitions, not necessarily from a programmers point of view) and maybe this is difficult to explain to users.

My veiw on this would be to stay away from datframe passing as inputs, especially as the only form of input. One of the advantages of pvlib is that there is the ability to use different inputs (irradiance sources, plane transposition models, etc.) and compare their outputs from the functions. This means that a user might have multiple versions of dni,ghi, pmp, etc. which they are wanting to use in the functions. Though it is possible to repackage a new dataframe for each time a variable is swapped out, this leads to extra unnecessary steps on the user side, and makes it harder to explicitly track what is being passed through a function. When I was originally making tools for myself, I did make them with dataframe inputs, and found that it was leading to too many hard to trace errors, and ended up switching it to explicit inputs.

It might be interesting to have df input as an optional input along with the explicit variables (which might have been what you were suggesting), but I wouldn't want to move completely to df input.

This method does not work and is not tested.

Port of tutorials from sandia labs develop branch.

Here's the offending line.

Working on a DISC PR now...

A list of doc fixes that we may consider before an initial release:

• Add more to the homepage, probably stuff from README.py.
• Describe the relation to PVPMC, PVLIB-Matlab.
• Make a text link for the tutorials instead of my usual url dump.
• Different page for each module?

Any other relatively easy and important doc fixes?

From:
#7 (comment)

Shall we add standard readers for typical data providers such as:

Input:

• Meteonorm
• SolarGIS, e.g. http://solargis.info/doc/_files/sample_data/SolarGIS-climData/SolarGIS-TMY-hourly-P50-PSA-ES.zip
• BSRN
• SoDa-IS

Output:

• epw: http://apps1.eere.energy.gov/buildings/energyplus/cfm/weather_data3.cfm
• SAM

Hints:
https://github.com/pydata/pandas/blob/master/pandas/io/date_converters.py

There was a similar effort at pandas some time ago which stalled:
pandas-dev/pandas#1180

This could be a meta issue for all input and output format existing in the (solar) energy meteo domain.

I'm in need of some single axis tracker algorithms that include back tracking. So:

1. Can anybody recommend a reference for a single axis tracker algorithm with back tracking?
2. Does anybody have a Python implementation of a tracker algorithm?
3. Should we add tracker algorithms to pvlib?

The best reference I have so far is a NREL tech report, but it doesn't include back tracking.

Just to catch your options:

Would the documentation benefit from having a section, mapping the functionality against the typical modelling steps outlined in:
https://pvpmc.sandia.gov/modeling-steps/
https://pvpmc.sandia.gov/wp-content/uploads/2014/08/1199X499_slide2.png

If so, I would embark (slowly) on that.
It would help me and maybe others to understand the library.

Additionally, this would show where functionality is still lacking.

OK, this would be similar to
PV_LIB Version 1_2 Release/html/html/pvlib_functions_by_cat.html
But a bit more semantic and linked.

As recommended by @dacoex in Sandia-Labs/PVLIB_Python#34

NOTE: no bug but clarification question.

Reading the tutorials is is unclear how inverter connections are defined and the power of a whole PV system of more than 1 string is calculated.

The notebook shows that 1 module is picked and then DC power calculated.
http://nbviewer.ipython.org/github/pvlib/pvlib-python/blob/master/docs/tutorials/tmy_to_power.ipynb#DC-power-using-SAPM

But the next step
http://nbviewer.ipython.org/github/pvlib/pvlib-python/blob/master/docs/tutorials/tmy_to_power.ipynb#AC-power-using-SAPM

uses a micro-inverter on module level.

How would the whole process be done with a different inverter, say a 30kW multi-string inverter?

And how would these then be added into a system of 500kW?

If it's roof-top, then multiplying by number of inverters would be possible but on a flat roof or ground mounted case, row-to-row spacing would need to be accounted for.

We should decide whether we want to add examples to the docstrings of the functions or not.
While (I think) examples are not included in every pandas object, they are in numpy. numpydoc has an optional section for examples.

I would like to include examples and also I would like to use doctests.
For the moment we have some examples, but some doctests fail
(see output of nosetests -v -w pvlib --with-coverage --cover-package=pvlib --with-doctest).
I once had a discussion with pandas developers (see pandas-dev/pandas#3439) and they didn't see their examples as tests.
However for pvlib, doctest may have an additional benefit for testing purposes and also it tests if our documentation is up to date with the state of the objects we document.

PyRTM contains functional python wrappers for SMARTS and SBdart, and is capable of modelling spectra in clear-sky and cloudy conditions. This would be a great set of functionality to incorporate into PVLIB. It could be a good project to either integrate the whole code base into the pvlib project (I was involved in the PyRTM project, and I think this would be great). Or, it might we worthwhile to pull in a set of functions to reference it in PVLIB, as PyRTM is already up on pip.

@uniphil any thoughts?

Add additional functions introduces in PVLIB-matlab 1.2

The pvsystem.sapm_celltemp function currently returns a dict {'tcell':tcell, 'tmodule':tmodule}. I think it should return a DataFrame with the keys temp_cell and temp_module (as described in the wiki).

I actually like the simplicity of the function parameter names here, but maybe they too should be changed.

The documentation is broken:
http://pvlib-python.readthedocs.org/en/latest/pvlib.html

I tried to compile it myself but I get import errors from sphinx, which I don't understand. Maybe for the same reason as the build on readthedocs.

Example:
The import of tools (from pvlib import tools) works fine for me but sphinx raises the following:

.../pvlib-python/docs/sphinx/source/pvlib.rst:23: WARNING: autodoc: failed to import module u'pvlib.irradiance'; the following exception was raised:
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/sphinx/ext/autodoc.py", line 335, in import_object
    __import__(self.modname)
  File ".../pvlib-python/pvlib/__init__.py", line 4, in <module>
    from pvlib import tools
ImportError: cannot import name tools

I would like to implement real nose test cases or pandas based TestCases

Also pandas like testscripts for lokal testing would be nice (see https://github.com/pydata/pandas).

At the moment I don't know how to run the test suite locally.

See #13, #31, #34

Beside scipy there may be other optional dependencies? spa , ...?
We should first define optional dependencies, test if they are installed, if not skip
tests that need them.

I have started work on bringing the notebooks in line with the latest code.

The first thing I ran into was the issue of versions. Is the following ok with your versions?

Python 2.7.8 32bit [MSC v.1500 32 bit (Intel)]
IPython 3.0.0
numpy 1.9.2
scipy 0.15.1
matplotlib 1.4.3
pandas 0.15.2
pvlib 0.2.0dev

Let's try to agree on the variable names and capitalization rules for all terms in the library. PEP8 is a good place to start, but it may be reasonable to break those rules for some terms.

I don't expect that we can come to agreement on everything in this issue, but let's at least write down the terms and rules for which we do agree and change the code to reflect whatever consensus emerges.

A wiki would probably be a good place to put the results.

In no particular order, here are some problems that I'm aware of:

• Acronyms such as DNI, GHI, DHI, AOI.
• Beam irradiance and similar could be Eb, beam, beam_irrad, irrad_beam. I know that at least two those are currently in use.
• diffuse, sky_diffuse, diffuse_ground, In_Plane_SkyDiffuse, aoi_projection, etc.
• airmass, AM, or am? I think we may be using all three. How do we use a modifier like relative or absolute?
• lat, latitude
• tz, TZ
• surf_az, surfazi, surfaceazimuth
• Variables that are closely tied to a particular equation (see many of the pvsystem functions).
• temp, T, Tcell.
• Vmp, V_mp, vmp, v_mp.

Fixing this without breaking things requires good tests.

Here's the offending lines:

    Ztemp=SunZen
    Ztemp[SunZen > 87]=87

Ztemp references the same object as the input SunZen, so the 87 assignment rudely modifies the input object.

This can be fixed by using Ztemp=SunZen.copy().

Can be closed in the same PR as #6.

I think we should make sure, that time zones, other time references are used correctly.
We can have time stamps given as UTC, really related to a time zone, local time (without DST), mean solar time, true solar time, ...? This is an everyday problem from my experience, so we should be able to handle all of these formats at least in the future.
For now it could be ok to define, that all times should be given as UTC and leave all time conversion issue to the user.

As pandas has support for Julian dates since 0.14 (this is the pull request). I was thinking about creating a pull request to implement to_solar_time in pandas. However this is not easy to implement and I am not sure, if they accept it. But this way all time conversion would be in pandas an we could implement thinks based on pandas.

The disc algorithm is currently in clearsky, but I think irradiance is a better place for it (and the rest of the similar models that still need to be implemented #2 #4).

Hello,
should this page not be added to the docs itself?

https://github.com/pvlib/pvlib-python/wiki/Projects-and-publications-that-use-pvlib-python

The singlediode function, located in pvsystem.py, does not have the capability to return continuous current and voltage values. I have modified the code to include a loop:

si = np.ones((NumPoints,1))
sv = np.linspace(-1,1,NumPoints)
if NumPoints >= 2:
for i in range(NumPoints):
V[i,:] = Voc.values * sv[i]
I[i,:] = I_from_V(Rsh=Rsh, Rs=Rs, nNsVth=nNsVth, V=V[i,:], I0=I0, IL=IL)

This may not be the most efficient way but it worked.

• Birk

The issue link does not work:

Add What’s New section to docs (:issue:`10`)

on page
http://wholmgren-pvlib-python-new.readthedocs.org/en/docfixes/whatsnew.html#new-features

If we agree on it, we could either completely rely on pandas or give some rules, where we use our own conventions (in the wiki or in the docs).

It looks like this is related to the downloads from the NREL website. When I tried to manually download the files, it took about a minute for the first download to happen (and it was fine after that). We might want to consider hosting the files locally? I'm not sure what the limitations are on that.

returns solar azimuth angle in wrong definition with zero = south. But irradiance.aoi needs as input panel azimuth angles from north.

This function is discouraged anyway, so may it be better to remove it from the library?

These seem to miss on the environmental input side:
https://pvpmc.sandia.gov/modeling-steps/1-weather-design-inputs/shading-soiling-and-reflection-losses/

Maybe this meta issue can track this as mentioned in
#2 (comment)

I think we should use github milestones. Also it is not clear to me on which version we are at the moment (pvlib.version says 0.3, but we are on something like 0.4dev I think).

I would also like to use github labels for the issues.

SAM just released new equipment CSVs dated 2015-06-30. Not sure if there is a better fix for the retrieve_sam function than just to update the URL. Probably worth updating for 0.2.1.