pvlib.bifacial

[Brock Taute]

The documentation shows that there is a bifacial package for pvlib, yet when I try to run pvlib.bifacial.pvfactors_timeseries(), I get an AttributeError stating the module pvlib has no attribute bifacial.  Has this part of the documentation not been implemented yet?

[William Holmgren]

The bifacial module currently needs to be explicitly imported:

import pvlib.bifacial

On Fri, Jul 26, 2019 at 2:37 PM Brock Taute <taute...@gmail.com> wrote:

The documentation shows that there is a bifacial package for pvlib, yet when I try to run pvlib.bifacial.pvfactors_timeseries(), I get an AttributeError stating the module pvlib has no attribute bifacial.  Has this part of the documentation not been implemented yet?

--
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/631a1970-d0be-454b-a193-c460309cd13d%40googlegroups.com.

[Brock Taute]

Thanks! 

[Nelson Salazar]

Hi.

I am trying to run it as you mention but I get the same error: No module named 'pvlib.bifacial'.

import pvlib.bifacial

bifacial_poa = pvlib.bifacial.pvfactors_timeseries(...)

What should I do?

[cwh...@sandia.gov]

Hi Nelson,

What version of pvlib?

import pvlib

pvlib.__version__

[salazar...@gmail.com]

'0.6.0'. Should I upgrade pvlib to the latest?

[cwh...@sandia.gov]

Yes. pvlib.bifacial was added in v0.6.1. If you go to the latest release 0.7.2 you shouldn't need the separate import.

Cheers,

Cliff

[salazar...@gmail.com]

Thanks a lot, Cliff!

[salazar...@gmail.com]

Hi. Again me with another question.

I am trying to run the function as below:

bifacial_poa = pvlib.bifacial.pvfactors_timeseries(solar_azimuth=solpos['azimuth'],

                                                                                        solar_zenith=solpos['apparent_zenith'],

                                                                                        surface_azimuth=array_surface_azimuth, #[...] where ... is an array of '180' 8760 times

                                                                                        surface_tilt=array_surface_tilt, #[...] where ... is an array of '10' 8760 times

                                                                                        axis_azimuth=0.0,

                                                                                        timestamps=data_weatherforecast.index, #1-Jan 2019 to 1-Jan 2020 hourly

                                                                                        dni=data_weatherforecast['dni'],

                                                                                        dhi=data_weatherforecast['dhi'],

                                                                                        gcr=2.0/7.0,

                                                                                        pvrow_height=0.185,

                                                                                        pvrow_width=1680,

                                                                                        albedo=irradiance.SURFACE_ALBEDOS['urban'],

                                                                                        n_pvrows=153,

                                                                                        index_observed_pvrow=1,

                                                                                        rho_front_pvrow=0.03,

                                                                                        rho_back_pvrow=0.05,

                                                                                        horizon_band_angle=15,

                                                                                        run_parallel_calculations=True,

                                                                                        n_workers_for_parallel_calcs=2)

 

But it is taking to long to run. It is for a 100MW solar system with 250k modules (153 rows of 1603 modules each) and I am running the code for a whole year (1-Jan 2019 to 1-Jan 2020 per hour, that is 8760 data-points).

My questions are:

1. Am I making some mistake and is that why it is taking so long?

2. If everything is correct, what should I do in order to make it faster?

3. I set the parameter 'index_observed_pvrow' as default. That parameter refers to the number of pv-rows that 'reflect' the incident irradiance or what does it refers?

Thanks in advance.

Hope you all are doing well. 

:)

[Brock Taute]

Hey Nelson,

Sorry in advance that I'm only looking at this code at a high level, but I have some comments that might help.

1. I don't believe n_pvrows beyond 3 will impact your results if you have the index_observed_pvrow at 1.  It might be slowing down the runtime of the code, though.  I'd suggest leaving this at the default of 3.
1. index_observed_pvrow is the index of the row that is being used for the irradiance calculations.  The default means the middle row out of 3 rows, which is often appropriate to avoid the "edge effects" of the rows on the ends.
2. Your pvrow_width is rather wide.  This should be the "width" that is used in the GCR calculation (so when viewing the tracker from a row-to-row perspective).  It's confusing without having a visual, so please check out the diagram in the "Understanding PV array 2D geometries" section at this link:  https://sunpower.github.io/pvfactors/concepts/index.html#d-geometries
1. I'd also double check your pvrow_height is at the center of the racking and not the bottom.
3. run_parallel_calculations has given me trouble in the past depending on the python environment you are running.  I'd see what happens when you set it to False.

I can typically run 8760 data points through this function in less than 10 seconds without using parallel calculations.

Hopefully that helps.

[salazar...@gmail.com]

Tautebro, thanks for taking your time and answering me. Your comments are indeed very useful and clear to learn and to better understand about the function.

I made the corrections that you mention and now the code runs fast. Now, I get this error message: build() missing 1 required positional argument: 'pvarray'.

Do you know what it could be?

Again, thanks for your clarification!

[Brock Taute]

Happy to hear that helped.

Your new error is coming up in the "build" method called from the PVFactorsReportBuilderClass.  This is a convenient function that pvlib includes to make interfacing with PVFactors simpler.  However, a bug was formed during a PVFactors package update that had breaking API changes.  An unreleased version of PVLib fixes this bug, which leaves you with 2 potential solutions.

1. Change your PVFactors package to version 1.0.1.  You can do this by running:  pip install pvlib==1.0.1

2. Update to the development version of pvlib on github.  This one is a bit more work if you aren't familiar with github, but the pvlib documentation does outline how to do it here: https://pvlib-python.readthedocs.io/en/stable/installation.html

I strongly recommend using the latest version of PVFactors if you are able to do so, as it is a lot faster than version 1.0.1.  (Seconds vs. Minutes)  If option #2 is too daunting, you can work with PVFactors directly by following their tutorials (https://sunpower.github.io/pvfactors/tutorials/Getting_started.html#Run-simulation-using-the-full-mode).

I have a repo available that you could use as an example as well, although it is very poorly documented.  (Pay attention to the pvfactor_build_report function https://github.com/btaute/solar-models/blob/master/solar_functions.py)

--

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/fd5975f7-49fb-4caa-987c-29878afaabeen%40googlegroups.com.

[Brock Taute]

Sorry, a correction to the message above.  For option 1, the code would be pip install pvfactors==1.0.1

[salazar...@gmail.com]

It works perfectly! Thank you very much!

I really thank you for taking the time to help me and for your explanation. It is very enriching. I managed to understand more and more of how the library works.

Again, thank you very much, Tautebro!

[salazar...@gmail.com]

Hi, I hope you all are well.

I have a question regarding the axis_azimuth parameter of the pvlib.bifacial.pvfactors_timeseries function. For a fixed mount scenario (e.g. flat roof close mount), what value should this parameter take?

Thanks in advance. :-)

Nelson Salazar

[cwh...@sandia.gov]

Nelson,

I don't know pvfactor well enough to know how a fixed mount system should be described. Can you leave it out, or set axis_azimuth=None? It looks like it's an optional parameter.

Cheers,

Cliff

[kevina...@gmail.com]

I suspect, since pvfactors is designed for tracking systems, fixed tilt systems are appropriately modeled by pretending they are tracking systems that just aren't moving.  E.g. a south-facing FT array would have axis_azimuth=90 or 270.  But I don't know pvfactors well enough to say for sure either.

Kevin

[salazar...@gmail.com]

Hi Cliff and Kevin, thanks for your responses.

The alternative I took is aligned with what Kevin said. For example, for a south facing fixed mount, we would have:

• surface_tilt = list(np.repeat(surface_tilt, len(data)))
• surface_azimuth = list(np.repeat(surface_azimuth, len(data))
• axis_azimuth = sur_azimuth + 90

The addition of + 90 degrees is following the PVlib convention for single axis trackers. Therefore, in this example, the axis_azimuth = 270, as Kevin comments.

Nelson Salazar