bifacial PV system modeling

[cwhanse]

implement NREL's rear-surface irradiance model for regular, fixed tilt arrays of bifacial PV models.

[adriesse]

Is this your practice problem, Cliff?!?

[cwhanse]

uh no this will be a big lift :) #423 is a good practice problem.

[cwhanse]

Mapping out how a fixed tilt bifacial PV system would be represented, here's a summary of my approach:

1. System description : add attributes to PVSystem for array racking geometry: number of array racks, distance between racks, height of rack above the ground, number of module rows on each rack, orientation of modules on the rack (landscape or portrait), spacing between modules (probably the rack area occupied by a module, rather than a distance between module edges), fraction of rear-surface module area 'obscured' by racking (this will be a derate on the rear irradiance), DC optimizers (module or cell level). Perhaps we should use a new class as a child of PVSystem to contain these attributes?
2. A new database for bifacial module parameters that support only PVWatts. Bifacial modules have unique characteristics that aren't present in the SAPM or CEC datasets. We have only measured a few bifacial modules so we're mostly providing a pattern to follow, not a dataset. Bifacial parameters include: bifaciality (ratio of rear to front power), temperature coefficient of power, rated power, length and width dimension, transparency factor (the fraction of front side irradiance that can pass through the module), cell array (number along length, number along width).
3. Irradiance functions. Two primary functions, one for rearside irradiance, and one for total effective irradiance. The rearside irradiance returns the rearside irradiance for each row of cells along the vertical dimension of the rack. This is a port and cleanup of the NREL bifacialvf code.
4. A total irradiance function which returns the per-cell-row irradiance, front + rear, modified for 1) bifaciality factor, 2) soiling, 3) reflection, 4) rear-side shading, and 5) spectral effects.
5. A bifacial power function which calculates per-cellrow power from total irradiance and temperature, using PVWatts - I believe this is already pvwatts_dc.
6. A string power function which operates on per-cellrow power, DC optimizer settings, and string geometry (which I haven't figured out) to return power per string of modules. I think this is in place of scale_voltage_current_power but I'm not clear on this point.

Interested in your thoughts.

[adriesse]

Getting the irradiance on different surfaces right seems to be the biggest challenge here. With the expectation of having different levels of irradiance on different cells (or rows of cells) some kind of mismatch model might be helpful too.

[wholmgren]

Regarding each numbered item:

1. Many of those racking parameters could be useful for (unimplemented) features for standard PV systems.
2. Easy to add a database to the pvlib/data directory.
3. I'm not familiar with the bifacialvf code, but that generally makes sense. Thinking dimensions... D_out = D_in x N_rows ?
4. Are the soiling and spectral effects unique to the bifacial nature of the system? I can imagine that they are.
5. Yes, it sounds like you could call pvwatts_dc on your D_in x N_rows array.
6. Maybe you need some combination of summing along the output array and using scale_voltage_current_power?

I do think a new subclass of PVSystem would be useful for standardizing the process. It would override the PVSystem.get_irradiance method and implement new methods specific to the bifacial functions.

pvsystem.py is already a big module. I wonder if we'd be better off putting most of the new stuff in e.g. bifacial.py.

ModelChain can probably accommodate this with very few changes.

[cdeline]

Thanks everyone - are you planning to work off the existing Python code in the github.com/NREL/bifacialvf repository?

[cwhanse]

Yes, but substantially refactored to integrate with the rest of pvlib, for transparency and hopefully less maintenance risk.

[wholmgren]

@cdeline thanks for sharing -- I didn't realize it was on github. Dare I ask what the license is? I am not a lawyer, but if the license is not BSD 3 compatible then I think we need to stick to working off of papers or similar instead of from code.

[adriesse]

Cool, I wasn't aware of it either. I suspect the pvlib version will look different enough that copyright will not be a problem.

[cdeline]

Will, we are using BSD-3 licenses as well, and received an open-source designation from DOE so there should be no problems with porting the software into pvlib. I don’t yet have our license document finalized and uploaded, but your question prodded me to make some progress on this! Chris Deline National Renewable Energy Laboratory (303) 384-6359 From: Will Holmgren [mailto:[email protected]] Sent: Thursday, February 15, 2018 2:56 PM To: pvlib/pvlib-python <[email protected]> Cc: Deline, Chris <[email protected]>; Mention <[email protected]> Subject: Re: [pvlib/pvlib-python] bifacial PV system modeling (#421) @cdeline<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcdeline&data=02%7C01%7Cchris.deline%40nrel.gov%7C3dc304a8b0ff400fc42008d574bee0a1%7Ca0f29d7e28cd4f5484427885aee7c080%7C0%7C0%7C636543285526107361&sdata=7JHfGlPgDZiQszjJDECO5DgoQbA%2B4pJjRbj8zOSJdl8%3D&reserved=0> thanks for sharing -- I didn't realize it was on github. Dare I ask what the license is? I am not a lawyer, but if the license is not BSD 3 compatible then I think we need to stick to working off of papers or similar instead of from code. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpvlib%2Fpvlib-python%2Fissues%2F421%23issuecomment-366074666&data=02%7C01%7Cchris.deline%40nrel.gov%7C3dc304a8b0ff400fc42008d574bee0a1%7Ca0f29d7e28cd4f5484427885aee7c080%7C0%7C0%7C636543285526107361&sdata=IbkCboZxeOhf3D0PpEy4vy2y3qqbM0OCl9hRQdgOBZs%3D&reserved=0>, or mute the thread<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAWKtOHc99AFMJ-SmhyUbeyvEvqHozjJkks5tVKflgaJpZM4SCe-g&data=02%7C01%7Cchris.deline%40nrel.gov%7C3dc304a8b0ff400fc42008d574bee0a1%7Ca0f29d7e28cd4f5484427885aee7c080%7C0%7C0%7C636543285526107361&sdata=XmZMUgnNEIOVItObu7OnUOCxsrkl32%2F%2FPxyFMtQSF3I%3D&reserved=0>.

[cwhanse]

I should have asked first, thanks @wholmgren for bringing this up. @cdeline good to here. We'll keep prominent comments maintaining attribution and the supporting reference papers.

[wholmgren]

@cdeline thanks for clarifying!

[dberrian]

@cwhanse is right. Updating bifacial PV system modeling to PVlib will be a great job. I have been working on this topic recently, I can contribute and there is a lot to learn about bifacial systems and how it differs from standard PV. The issue of bifacial energy yield prediction is of interest nowadays.

[anomam]

@cwhanse @wholmgren I'm also interested in contributing on this if you guys need help, but is there any open PR?
Btw, SunPower also open-sourced a 2D view factor irradiance model presented at PVSC 44: it's called pvfactors, and here is the docs. @wholmgren Is it possible to implement models in pvlib that rely on external packages? If that's the case it may take me less than a day to have this working in pvlib. But I don't think I've seen that done yet?

[cwhanse]

@anomam There isn't an open PR. I have a conversion of NREL's bifacialvf.py package to pvlib about 50% done. There's still substantial work left on that project. I glanced through the pvfactors package. Two concerns we should discuss as we consider a merge into pvlib, or another path to more closely linking pvfactors with pvlib:

1. how much overhead is incurred to define the system? I am not familiar with the geopandas package but it looks like it brings a number of significant dependencies with it that haven't yet found use in pvlib.

2. with the radiosity approach, what is the anticipated performance for simulating irradiance on a small array for ~8000 time steps? I'm asking because we have choices for a 'default' bifacial modeling component, and I would guess that most users would value speed over model completeness.

If we decide to go forward with an import (e.g., make pvfactors into pvlib.bifacial.py) we should talk about the API before you get started.

[mikofski]

Curious, why convert NREL bifacialvf to pvlib? IMHO it would be better to leave it as an external dependence if possible. Ditto for other packages.
Imo Easier to maintain IMO.

[cwhanse]

In my opinion (but I've heard agreement from others) pvlib would benefit from an integral bifacial component (I could use it for our work at the lab). The NREL code will be difficult to maintain in its current state, and isn't really interfaced well with pvlib. So we thought it worth the effort to migrate.

[mikofski]

Ok

[anomam]

@cwhanse thanks a lot for the replies. To answer your questions:

1. geopandas is indeed the underlying structure that's used to build the "registry", where the inputs/outputs and geometries are stored during the calculations. But it's used essentially as a convenient open-source wrapper around pandas that integrates shapely geometries, the real core package of the model. Originally when I created the algorithm, I was using simple dictionaries and lists. I'm sure there are much smarter and more efficient ways to do this, and it wouldn't be very difficult to change the nature of the registries, and use something more native to Python.

2. you're very right about the overhead though. Using shapely geometries makes building the PV geometries and calculating the view factors very intuitive and easy to maintain: since the 2D geometry is handled by the package, the view factor formulas look like these, and you can visualize the PV array and shades on a plot at any point. Besides, the way pvfactors accounts for reflections is through a linear system of equations for all the surfaces in the PV array.
   But the cost for this is the computation speed: on my machine (i7 processors) it takes about 1 min and a half for 8760 points, and ~50s on a better machine when I was running batch simulations. Apart from model parametrization (which works very well btw), I haven't spent time thinking about replacing shapely with something that would make the computation faster.

Speed is a top priority for me as well. And maintainability and simplicity are big ones too .
I was also planning on looking at bifacialvf because I heard it can run in 4 or 5 seconds, so I'd like to offer some help and contribute to the conversion of that package if that can accelerate its implementation in pvlib.
Let me know!

[wholmgren]

@anomam we can add models to pvlib that depend on external packages. For pvfactors, I'd recommend making it an optional dependency, but I'll have to look at your package more carefully if we want to pursue this.

No reason we can't implement/wrap several bifacial algorithms in pvlib if there is community interest. We have multiple clear sky algorithms, transposition models, solar position models, pv models, etc.

[cwhanse]

@anomam 2 minutes for an 8760 is OK for me, for a bifacial simulation. If we can not have the geopandas dependency I think in the long run we'll be happier, since that package is low versioned and brings a chain of dependencies, I worry about maintaining the connection.

I'd say go ahead with preparing a pull request. I really like the use of shapely and I think it will open possibiltiies for pvlib we haven't yet considered.

I will learn how to create a repository and get my partial translation of bifacialvf up, and I'd welcome help getting this project finished.

[anomam]

@cwhanse @wholmgren Thanks a lot for the feedback!
Agreed, I will try to come up with something better than geodataframes for pvfactors before opening a PR.

[anomam]

Hi @cwhanse @wholmgren , I removed the geopandas dependency in pvfactors, but I haven't made any new release yet. I was hoping to get additional feedback from you if possible to integrate your requests into the next release before opening a PR in pvlib. Is there any chance you could spare some time looking at the pvfactors package and let me what changes you would like to see? Any feedback would be much appreciated

[cwhanse]

@anomam happy to.