Add irradiance QC algorithm from Forstinger et al.

[cwhanse]

Conference paper here. Looks to be an improvement over Long and Shi.

[kandersolar]

cc @AdamRJensen as he's on the author list

[AdamRJensen]

I uploaded the code here just to have a stable link for the paper. Ideally it would be contributed to a library, so I would be happy to contribute it here. We still have a few improvements of the multiplot that we're working on finalizing.

[wholmgren]

Nice plot!

[cwhanse]

Another paper describing a QC method to concurrent GHI and DHI.

[kandersolar]

Another paper describing a QC method to concurrent GHI and DHI.

I think this is #172

[AdamRJensen]

@YvesMSaintDrenan Would you be willing to add the multi-plot function to pvanalytics? I know that it's part of libinsitu, but I still think it would be a valuable contribution to pvanalytics.

I'd also be happy to do the implementation, if you agree.

[YvesMSaintDrenan]

I am all for it ! Just before you start please contact Raphaël who is currently updating the code to implement plotly (we want to make it possible to zoom and annotate the plots). In addition, we would like to implement the last tests of Nollas et al. (https://doi.org/10.1016/j.renene.2022.11.056) in the visual inspection.

[AdamRJensen]

@YvesMSaintDrenan I imagine that as a first step, we might just want to add the basic plotting function, which takes a boolean series of flags, arrays of GHI, GHI_clear, DNI, and DHI, and solar position. How people calculate the flags and the remaining inputs can then be up to them as a first step. This would simplify this initial contribution significantly and make it rather flexible. A Class that can make it more user-friendly, e.g., calculate flags and retrieve CAMS can then be added secondarily. Would you be ok with that?

@cwhanse @kanderso-nrel Are you okay with adding plotly as a dependency to the project?

[kandersolar]

Some reasons I hesitate to include plotting functionality in pvanalytics:

• Visualizations are more in need of user-specific customization than algorithms are
• Thorough testing is complicated to the point of impracticality
• Everyone has their own favorite plotting package (e.g. I personally much prefer matplotlib over plotly)
• Speculation: it may be a slippery slope to creating a "junk drawer" of everyone's personal favorite plots. Of course requiring a publication would prevent this.

As an alternative to including plotting functionality in pvanalytics itself, how about implementing them in gallery examples? Note that plotly can be used with sphinx-gallery (see docs).

[wholmgren]

Ill-considered idea: create a new package under the pvlib organization (pvlib/pvplotting?) that embraces the junk drawer mentality and has a low barrier to entry.

[bt-]

That is a very cool plot! My 2 cents along the lines of everyone has their favorite plotting package :) - the [holoviews] (https://holoviews.org/index.html) library would allow specifying the plot without specifying the plotting library. I'm not sure if the full figure would reliable work in each of the possible plotting backends (matplotlib, bokeh, and plotly), but might be something to investigate. I always use Bokeh as the backend when I'm using holoviews or hvplot.

Regardless, it is a cool plot, and it would be awesome to have access to a function somewhere to generate it, especially an interactive version!

[cwhanse]

Ill-considered idea: create a new package under the pvlib organization (pvlib/pvplotting?) that embraces the junk drawer mentality and has a low barrier to entry.

Supporting both pvanalytics and pvlib-python? I could support that if we come up with an organizing structure. Otherwise, an example gallery makes sense to me.